Avviare un progetto

Partiamo dal nulla per diventare eroi esaminando i componenti necessari per un progetto che diventa un prodotto utile.

Stai per costruire un grande prodotto, ma ho delle notizie per te. Tutto inizia come un progetto. Va bene. Possiamo chiamarlo Prodotto, MVP (Minimum Viable Product) o come preferiamo, ma inizierà sempre come un progetto.

Molte aziende discutono il perché e quali benefici apporterebbe questa attività. Consulta Budget per informazioni su NPV (Valore attuale netto - qual è il suo valore attuale?) —calcoli e Costruisci o Acquista.

Esistono molte metodologie di gestione dei progetti che possono aiutarti a iniziare, pianificare, implementare, testare, rilasciare e chiudere il tuo progetto. Ci sono anche alcune metodologie che lo eseguono in iterazioni, ovvero brevi ripetizioni, invece di fasi più lunghe.

Ciò significa che per i progetti ci sono implicazioni importanti su come vengono impostati, come vengono gestiti e come vengono consegnati.

Per completezza di questo piccolo libro, spiegherò rapidamente la gestione di progetto classica, nota come "Waterfall". Immagina un fiume. Questo è il tuo processo di progetto. Ti sposti sempre lungo il fiume e non torni indietro per cambiare le cose, è fisso e deciso.

Quindi ti sposti più avanti e entri in diverse fasi, come la fase di implementazione dove tutto il codice dovrebbe essere codificato, e successivamente la fase di test quando dovrebbe essere testato. Tutto si basa su specifiche upfront che erano state scritte prima di iniziare il progetto.

Sapevi esattamente cosa volevi costruire, fino all'ultimo pulsante. Quindi hai trascorso mesi a metterlo in un documento, poi i tuoi sviluppatori senior o l'architetto ti hanno aiutato a scrivere le Funzionalità nel documento di Specifiche Funzionali. Poi, nella fase di implementazione, costruisci esattamente ciò che era in questa specifica. Poi lo testiamo per vedere se funziona come specificato.

Questo non ha mai funzionato in nessun progetto tecnologico. Le migliori consegne di questi tipi di progetti hanno prodotto un'applicazione che faceva esattamente ciò per cui era stata intesa, ma non ha tenuto conto di alcuna scoperta o idea trovata durante lo sviluppo.

Aggiungiamo anche che il tempo è passato durante la durata del progetto e hai perso alcune opportunità di mostrare questo a un potenziale cliente e ottenere feedback prezioso. Ora hai costruito qualcosa che non è stato testato contro alcun utente reale. Mi azzardo a dire che probabilmente non sarà ciò che volevi.

Leggi di più in "Il Playbook del CTO" disponibile su Amazon/Kindle.