Pianificazione delle tappe e del tempo

Ecco un eccellente articolo di Joel Spolsky: link

È un processo molto semplice che fondamentalmente sostiene di stimare quanto errate saranno le stime tenendo traccia di quanto errate sono state in passato. Col passare del tempo ti ritroverai con ipotesi molto migliori al momento di fare le cose. Non è una soluzione istantanea, ma, di nuovo, una pianificazione accurata dei progetti software è molto difficile.

Inoltre, sostiene la demolizione di progetti in parti molto piccole (e teoricamente più facili da valutare).

L'unico modo per ottenere una stima migliore è farlo più, gli sviluppatori meno esperti sono generalmente eccessivamente ottimisti. Da quello che hai scritto non sembra che il tuo problema sia stato la stima, è stato scope creep .

Probabilmente avrai una lezione sulla gestione del progetto, ma come una rapida panoramica il PM è responsabile molto più che impostare il programma e tenerlo in pista. Sono inoltre responsabili di garantire che il progetto che è stato definito all'inizio nella carta del progetto / altri documenti sia il progetto su cui si lavora. Nel tuo caso, sembra che tu abbia finito per fare uno scarso lavoro di questo perché sei passato da una piccola app a un'app aziendale. Questa è una cosa difficile da gestire, specialmente quando sei anche uno sviluppatore del progetto. Gli sviluppatori tendono a voler sempre aggiungere e migliorare tutto ciò su cui lavorano a tempo indeterminato e mai veramente arrivare alla parte di rilascio. Come un PM a volte hai bisogno di dire agli sviluppatori che i loro piani sono fuori portata o che la funzionalità X è già abbastanza buona per iniziare a lavorare su Y.

Parte del sapere come pianificare le scadenze, le dipendenze, ecc., verrà dall'esperienza. Tuttavia, detto questo, è un set di abilità molto diverso rispetto allo sviluppo e alla programmazione web. Parte di quell'esperienza che stai guadagnando è che la gestione del progetto probabilmente non è la tua cosa, e non c'è nulla di cui vergognarsi. Ad essere onesti, sono sorpreso che si aspettassero un completo project manager, sapendo che sei ancora nel bel mezzo dei tuoi studi. Ho conosciuto persone che hanno gestito professionalmente il project management per molti anni e ancora non lo capiscono!

A meno che tu non abbia davvero bisogno del denaro, ti incoraggio a porre una maggiore enfasi sui tuoi studi su questo lavoro. Se ti piace davvero fare lo sviluppo web e vuoi riuscirci, allora dovresti concentrarti sul miglioramento delle tue conoscenze e competenze su quel tipo di lavoro e allontanarti da questo ruolo di project management. Non c'è da vergognarsi nel dire al tuo capo che sei arrivato a capire che hai morso più di quanto puoi masticare e che hai incontrato limitazioni personali che potrebbero danneggiare la tua organizzazione. Digli che ti piacerebbe continuare a lavorare con lui, ma rigorosamente in un ruolo di sviluppo. Se è un grande capo, riconoscerà come ciò andrà a vantaggio di entrambi, e potrai spingere la tua carriera più lontano di quanto potresti altrimenti.

Una cosa che ci aiuta molto è avere un modello di stima standard che usiamo per ogni progetto. Ci costringe a includere il tempo per cose che gli sviluppatori potrebbero dimenticare nelle loro stime come riunioni e comunione di clienti, gestione dei progetti, test delle unità, supporto per i test QA e UAT, documentazione. Quando aggiungi tutti i pezzi che 8 ore di sviluppo possono facilmente trasformare in 22 o 23 ore.

Lo scorrimento viscoso di cui hai sofferto anche significa una nuova stima. Ogni volta senza eccezioni. Quando decidi di aggiungere una nuova funzione (o ti viene richiesta), è necessario sapere quante ore aggiuntive e fino a che punto spingeranno la scadenza. È meglio spingere il prodotto e spostare le modifiche apportate all'ambito alla successiva iterazione per la maggior parte del tempo.

Ottieni un prodotto e aggiungi funzionalità anziché ritardi continui per aggiungere altro materiale interessante. E assicurati che lo scope creep non provenga dagli sviluppatori. Le modifiche dell'ambito dovrebbero provenire dai clienti o dalle parti interessate nell'organizzazione, non dagli sviluppatori. Non c'è davvero nessuna scusa per questo. Se pensi a qualcosa che vuoi aggiungere, aggiungilo alla versione successiva dopo aver esaminato l'idea con gli stakeholder invece di ritardare la versione corrente a meno che qualcosa non sia effettivamente così rotto che non funzionerà senza la nuova cosa. La spedizione del prodotto è un'abilità critica da avere. Ogni pezzo di software mai scritto può avere alcune nuove cose brillanti aggiunte a loro prima della fine. Resisti alla tentazione e pianifica le tue nuove funzionalità nelle versioni future.