Come capire meglio gli utenti come programmatori

Question

Come capire meglio gli utenti come programmatori

#1 da (3 voti)
#2 da (2 voti)

6

Lavoro in un'azienda che vuole essere agile, ma gli analisti aziendali spesso ci forniscono "user story" che sono più una soluzione che un'affermazione problematica. Ciò rende difficile prendere buone decisioni di progettazione o, nei casi più estremi, lascia poche decisioni di progettazione. Non aiuta i programmatori a capire le esigenze dell'utente o a prendere decisioni migliori sul design in futuro. Il nostro proprietario del prodotto si sforza di fornirci dichiarazioni sui problemi, ma a volte riceviamo anche dichiarazioni di soluzione, che tendono a una situazione di "scimmia del codice".

Una sfida aggiuntiva è che alcuni (non tutti) i miei compagni di squadra non vedono un problema con questo, e alcuni di loro sinceramente vogliono sentirsi dire cosa fare. Quindi, quando riceviamo una dichiarazione di soluzione sul nostro arretrato, sono ansiosi di saltare a destra e lavorarci sopra.

Credo che come ingegnere del software parte del mio lavoro sia capire le esigenze dell'utente in modo da poter costruire la cosa giusta per l'utente. Tuttavia, all'interno della nostra struttura organizzativa, ho zero contatti con l'utente. Che tipo di cose posso fare per capire meglio i nostri utenti?

systems-analysis users

posta Kazark 04.03.2014 - 23:32

fonte

2 risposte

2

La comunicazione diretta e onesta tra il team di sviluppo e tutte le parti interessate è l'unico modo affidabile per fornire soluzioni eccezionali che io conosca.

Questo è dannatamente difficile da organizzare e le organizzazioni prendono scorciatoie con proprietari di prodotti, project manager, gestori di programmi, esperti in materia che possono dare il team di sviluppo di volta in volta. Credo che il ruolo con il maggiore impatto sia il proprietario del prodotto.

Parlando pragmaticamente ti suggerisco di scegliere una funzionalità per gli animali domestici e renderla il meglio che puoi - se funziona, potresti ottenere una funzionalità più grande su cui lavorare e il successo della prima funzione ti darebbe di più sfruttare le discussioni su come fare le cose.

Se vuoi esprimere pareri su questo problema, chiedi su workplace.stackexchange.com.

risposta data 15.11.2016 - 01:39

fonte

Leggi altre domande sui tag systems-analysis users

Design pattern per segnali / eventi bidirezionali Programmazione di PHP senza MVC, classi o framework: riscrivi o continua sulle nuove funzionalità?

score 3 · Accepted Answer

Questo dipende molto dalla tua gestione.

Quello che ho trovato in oltre 13 anni di ingegneria del software è che ho bisogno di parlare direttamente con i clienti e talvolta anche con gli utenti finali (spesso nel software queste sono entità separate). Gli analisti di business sono imprevedibili: alcuni di loro comprendono il cliente e gli utenti finali e scrivono davvero dei buoni requisiti (non soluzioni), alcuni di loro vanno troppo lontano e assumono troppo.

Consiglierei di parlare con il management e sostengo che è necessario essere coinvolti prima nel processo, idealmente subito dopo l'uscita dall'immagine e l'immissione dei BA. Non essere solo una mosca sul muro: devi farti valere come un esperto di prodotto che cerca di capire il dominio del problema (ugh, parole d'ordine: conosci il tuo software, vuoi imparare ciò che il cliente vuole che tu faccia con esso).

Per i progetti esistenti, lavorerei attraverso il tuo project manager e cercherò di far uscire i BA dall'immagine. Probabilmente otterrai risposte che corrispondono a ciò che ti è stato già detto. Non accettarlo. Cerca di entrare in incontri con il cliente per discutere dei requisiti. In un ambiente Agile non ci dovrebbero essere problemi con questo: se non capisci qualcosa, il cliente è l'arbitro finale per i requisiti (ma non necessariamente per ciò che la tua azienda ti autorizzerà a fare nelle ore fatturabili pagate).

In pratica, continua a fare domande e non chiudi bocca finché non comprendi appieno ciò che il cliente desidera. Solo perché un BA ti ha dato un requisito dal suono strano non significa che questo è ciò che il cliente vuole, o che è il modo migliore per soddisfare i desideri del cliente.