Qual è l'importanza del documento di visione e di come aiuta lo sviluppo?

Il documento di visione descrive come le parti interessate vedono quale dovrebbe essere il futuro del prodotto.
L'obiettivo del documento di visione è quello di mantenere tutti coloro che sono coinvolti nello sviluppo del prodotto focalizzati sulla direzione in cui il prodotto deve essere inserito.

Senza un documento di visione, è molto probabile che diversi stakeholder / dipartimenti cercheranno di orientare lo sviluppo nella loro stessa direzione, con gli sviluppatori coinvolti in una serie di requisiti in conflitto.
Se c'è un documento di visione, allora è più facile dire "questo documento di visione è la direzione in cui tutti i soggetti interessati sono d'accordo e le tue nuove esigenze si discostano da questo: non possiamo prenderle in considerazione fino a quando non verrà concordata una nuova visione".

Considerando che stai lavorando da solo, il documento di visione sarebbe meno utile per te della maggior parte degli altri perché è principalmente uno strumento di comunicazione . Ancora più importante, tuttavia, il documento di visione è un punto di riferimento , qualcosa a cui puoi guardare indietro e determinare se i tuoi sforzi stanno andando nel posto giusto.

Pur essendo uno sviluppatore solista, possiamo avere due idee sulle decisioni di progettazione o cambiare le nostre menti nel tempo. Potrebbe essere utile per avere fiducia nella tua visione originale . Se il tuo focus per uno strumento è "multipiattaforma", ma ti ritrovi impantanato nell'usare codice specifico della piattaforma perché affronti le soluzioni, potresti guardare indietro al documento e ricordare a te stesso la tua idea originale e il modo in cui di pensare. Può aiutarti a stabilire le priorità.

Il documento di visione ti aiuterà anche a comunicare con gli altri quello che stai facendo agli altri appassionati, amici e se il progetto crescerà in futuro per includere un pubblico o altre parti interessate.

Ti costringe a pensare a tutte le domande giuste: perché, come e cosa . Personalmente ho trovato molto più facile recitare un "elevator pitch" dopo aver scritto un documento di visione, perché ho appena citato le righe del documento di visione.

Vedo il beneficio del documento di visione principalmente come mezzo di comunicazione con gli stakeholder. Porta un'idea sulla carta e serve come base per creare un prodotto. Non è certamente un documento scritto dallo sviluppatore, ma piuttosto il product manager.

Come altri già hanno sottolineato, il documento ti aiuta a tenere il passo. Puoi fare riferimento ad esso quando si derivano i requisiti.

Può essere difficile rimanere concentrati su un progetto come sviluppatore solitario. Alla fine sei in carica, quindi se vuoi apportare modifiche o aggiungere cose, spesso non c'è nessuno nel modo di fermarti.

Avere questo documento dovrebbe aiutarti a formalizzare il tuo obiettivo e usarlo come uno strumento per aderire al piano. O almeno se cambi il piano, cambi il documento per mostrare il tuo nuovo focus.

La maggior parte sarà il vantaggio per l'utente. Sareste sorpresi di quante app vengono create laddove non è determinato, figuriamoci inserire un documento. È la mentalità "se lo costruisci, verranno". Se non puoi scrivere questo documento, non iniziare con questo progetto.

L'unica parte che puoi farla franca non entrando all'inizio è il "come" hai intenzione di costruirla. Questo potrebbe accadere un po 'più tardi dopo aver fatto qualche ricerca e sperimentazione, ma una volta identificato e deciso, documentalo e tieniti bene.

È un ottimo modo per avere un po 'di respingimento su di te e impedirti di aggiungere un sacco di funzionalità che nessuno vuole. È già abbastanza brutto quando qualcun altro ti fa questo. Non farlo per te.

La documentazione è una parte essenziale di qualsiasi progetto.

Ci aiuterà a centralizzare tutto e durante la discussione, possiamo parlare di cosa centrale con riferimento al documento.

Semplice esempio, La maggior parte dei clienti ha requisiti generici.

• In un posto mostrano Lion e gli piace, ora lo ricercano e poi concludono che vogliamo creare un solo animale.
• allora verrà con il requisito che voglio creare un animale con quattro zampe, un naso, due occhi ecc ecc
• mentre discuti, hai ottenuto il chiaro requisito e sei giunto alla conclusione che il cliente vuole Elephant con quattro gambe ecc.
• hai ottenuto il requisito e avviato lo sviluppo e la consegna, poi ha detto di no non voglio creare questo e poi tu sostieni che ho creato animali con quattro zampe e poi continua.

Scusa se questo esempio non ti piace, ma spero che dia chiarezza su ciò che voglio trasmettere.

Invece, se abbiamo documentato tutto ciò che possiamo avere una discussione su di esso, fai un brainstorming intorno ad esso e le cose saranno chiare in quel momento.

Non dico che non ci sono cambiamenti, ma almeno posso dire che l'80% delle cose sarà chiaro.

Per riferimento, sto solo riflettendo sulle cose da considerare mentre creo la visione doc.

Ogni volta che sviluppi software / prodotto, prova a rispondere a queste tre domande di base.

1. Perché il cliente vuole, quali problemi specifici hanno provato a risolvere?
2. Ciò che il cliente vuole, qui puoi fare un brainstorming su Why part e preparare domande a quale cliente otterrà una risposta dal sistema? 3 Come possiamo fornire, puoi creare wireframe e flussi di base e mostrarli a loro?

Ti costringerà anche a pensare al problema e alla soluzione e a cancellare le tue idee.

Fammi sapere il tuo feedback su questo.