La brutta verità sul processo di sviluppo del software

fonte: perfectdigital.com

Conoscete questa immagine, vero?

Penso che dimostri molto bene che grandi discrepanze e una mancanza di visione possono apparire in progetti di sviluppo software tra tutti i partecipanti e le persone coinvolte. I problemi sorgono spesso fin dall'inizio, quando il cliente si presenta con un progetto (teoricamente) definitivo. prodotto visione e la presenta al squadra. Seguono ulteriori malintesi, interpretazioni errate e, alla fine, il progetto si avvia rapidamente sulla strada sbagliata dello sviluppo.

Analizzando il grafico precedente, presenterò passo dopo passo tutte le possibili minacce e suggerirò come combatterle. Andiamo subito al sodo!

1. Come il cliente ha spiegato l'idea?

Ci saranno discrepanze nella visione del prodotto fin dall'inizio. Perché? Il motivo è molto semplice: ognuno interpreta la realtà a modo suo, ha un'idea di qualcosa nella mente e può non presentare accuratamente questa visione all'altra parte. Se descrivete a parole un prodotto che vorreste costruire, è molto probabile che il team di sviluppo comprenda la vostra visione in modo diverso da come la intendete.

Naturalmente è possibile evitarlo. È necessario iniziare a visualizzare il prima possibile e discutere i singoli elementi delle funzionalità del prodotto sulla base di schizzi. È interessante notare che i primi schizzi di solito non hanno nulla in comune con il prodotto finale. In questa fase, tuttavia, la cosa più importante è rendere coerente la visione.

2. Come l'ha capito il responsabile del progetto?

Vi chiedete perché la prima e la seconda immagine sono così diverse? Il leader del progetto guarderà sempre più da vicino la visione del prodotto. Tuttavia, è importante che tale persona, essenzialmente responsabile per l'intero sviluppo software processo, comprende appieno il problema e le esigenze relative al prodotto. Il responsabile del progetto deve avere chiaro il "quadro generale". Come potete vedere, le due immagini non differiscono in termini di funzionalità. Hanno solo un aspetto diverso. Per capire meglio questo punto, torniamo all'immagine numero uno. All'inizio del progetto non c'erano schizzi e questo ha già portato a un malinteso. La funzionalità del prodotto è corretta, ma il design è completamente diverso.

3. Come lo ha progettato l'analista? e 4. Come lo ha scritto il programmatore?

A volte, analisti e sviluppatori non conoscono le esigenze degli utenti o gli obiettivi aziendali stabiliti. Vedono solo una piccola parte dell'intero progetto, che cattura la loro attenzione principale. Non sono in grado di guardare da una prospettiva più ampia, e questo è particolarmente vero per i progetti di grandi dimensioni, dove molti sviluppatori lavorano contemporaneamente.

Possiamo anche usare un altro esempio. Può accadere che il problema da risolvere sia descritto in modo errato, ad esempio dal proprietario del prodotto. Ciò comporta la fornitura di informazioni incomplete sulle quali lo sviluppatore o il progettista creano le proprie interpretazioni e il prodotto si allontana sempre più dal percorso di sviluppo previsto.

Come cambiare questa situazione? Credo che una buona soluzione sia quella di assicurarsi che le persone chiave per il progetto abbiano una conoscenza dettagliata del progetto stesso, il cosiddetto "quadro generale". In caso di incomprensioni, sarà più facile per loro portare il progetto a conoscenza di tutti. processo di sviluppo del software sulla strada giusta. Pertanto, ricordate: se ognuno vede solo il suo piccolo frammento di funzionalità sviluppata, le incomprensioni nella visione diventano una probabile minaccia.

5. Come lo ha descritto il consulente aziendale?

In questo caso, la questione è semplice. Il prodotto deve vendere. Bisogna distinguersi in qualche modo, in modo che, ad esempio, una semplice altalena per il giardino raggiunga elementi straordinari. L'idea è quella di convincere un potenziale acquirente. Il reparto marketing e vendite farà sicuramente di tutto per dimostrare che il prodotto è unico.

6. Come è stato documentato il progetto?

La documentazione mancante è un problema molto comune. A volte, la creazione di documentazione durante sviluppo del prodotto sembra un'inutile perdita di tempo. Si tratta di un errore. Dico molto spesso che le modifiche si fanno più velocemente sulla carta che nella realtà. codicee c'è qualcosa di vero. Inoltre, è più facile fare riferimento alla documentazione per tenere traccia di eventuali modifiche. Credetemi, un progetto senza documentazione corre un rischio molto elevato di perdere la visione.

7. Quali operazioni sono state installate?

Questa fase si riferisce al posizionamento dell'ambiente sul server. Come nel caso dei programmatori e degli analisti, senza dati completi e con lacune nella comunicazione, può risultare che sia stata creata solo una parte dell'ambiente necessario.

8. Come è stato fatturato il cliente?

È il risultato di una scarsa comunicazione, di una mancanza di UX e così via. La comparsa di errori aumenta i tempi di sviluppo. E il tempo è denaro, giusto? Il mio suggerimento è quello di gestire il progetto in conformità con Agilemantenere i più alti standard di comunicazione e mantenere chiare le linee guida del budget. Non ho dubbi che così facendo eviterete questi problemi.

9. Come è stato supportato?

Spesso i clienti si concentrano solo sulla realizzazione di un prodotto e si fermano a quello. Tuttavia, viviamo in un'epoca di molti cambiamenti e innovazioni tecnologiche, motivo per cui è necessario mantenere un'assistenza tecnica costante. L'idea è quella di evitare una situazione in cui qualcosa smette improvvisamente di funzionare perché diventa obsoleto e il prodotto perde il suo valore. Anche questo aspetto non va dimenticato.

10. Di cosa aveva realmente bisogno il cliente?

Abbiamo raggiunto l'ultimo punto. Osservate la discrepanza tra il primo e l'ultimo grafico. Entrambi si riferiscono alla prospettiva del cliente. Perché succede questo? Tutti lo dicono in modo semplice 🙂 I risultati dei sondaggi differiscono sempre dalle reali esigenze degli intervistati. Nel rispondere alla domanda del ricercatore, gli utenti vogliono mostrare il loro lato migliore. Pertanto, SPESSO NON RISPONDONO IN MODO SINCEROma piuttosto in un modo in cui pensano di dover rispondere. In sostanza, non vogliono essere esposti alla valutazione negativa degli altri. Ecco un piccolo suggerimento: menzionate nelle istruzioni che non ci sono né risposte buone né cattive.

Dove appaiono le differenze? Spesso le persone non sanno cosa vogliono veramente. Molto spesso gli utenti dichiarano inizialmente di aver bisogno di 10 funzionalità nel prodotto, mentre in seguito ne usano solo 3.

Come risolvere questo problema? Oltre a chiedere agli utenti ciò che vogliono e di cui hanno bisogno, consentite loro di testare il prodotto, preferibilmente su articoli autentici per mantenere la credibilità. Più test vengono effettuati durante la creazione dei prodotti, maggiore è la possibilità che il risultato sia accurato.

Sintesi

Se diventate membri di un'associazione sviluppo software progetto, ricordate i miei esempi e traete le conclusioni per non copiare gli errori di cui sopra. E ricordate che questi concetti sono molto importanti nella costruzione di un prodotto (applicazione) da zero:

- una buona UX e dei test, in modo da poter capire quali sono le reali esigenze degli utenti,

- comunicazione all'interno del progetto, in modo che le persone chiave del progetto abbiano a disposizione una comprensione profonda del problema e delle esigenze,

- sviluppare il prodotto in conformità con Agile,

- non dimenticate il supporto tecnico.

Per saperne di più:

– Come gestire efficacemente gli sviluppatori remoti? La guida per gli CTO

– Python vs. Ruby? Quale tecnologia utilizzare per lo sviluppo dei prodotti?

– Una guida rapida alla costruzione e allo sviluppo del proprio mercato. Cosa vale la pena di sapere?