In questo breve post espongo le otto migliori pratiche di gestione di un progetto, apprese strada facendo. Qualora riteneste valide queste indicazioni potreste attuarle presso la vostra azienda, credo vi potrebbero aiutare a mantenere un flusso di lavoro snello, adeguato ed a motivare i vostri dipendenti.
Sono semplici riflessioni, nulla di accademico; ho infatti rivolto semplicemente, ai miei colleghi, una domanda: cosa odiano i programmatori? In pratica cosa li manda fuori di testa?
(1) I requisiti del software non chiari
Spesso il primo problema riscontrato è il gap dei requisiti. Un progetto non ben chiaro oppure una comunicazione non chiara tra il cliente, i responsabili di progetto e gli sviluppatori, conducono alla creazione di software difettosi oppure incompleti.
Se cliente ed il responsabile del progetto non sono abbastanza specifici sul prodotto richiesto, non dovrebbero aspettarsi che gli altri leggano le loro menti e facciano il lavoro che loro non hanno svolto correttamente. I programmatori non sono legilimens.
È il compito di un manager raccogliere le specifiche del progetto e renderlo più completo possibile, per cui gli sviluppatori non hanno bisogno di indovinare oppure chiedere più volte le specifiche.
(2) Le attività ripetitive
Il problema qui può essere, ad esempio, far lavorare un programmatore molto su un progetto per un lungo periodo. Può anche essere il caso di un cliente che cambi spesso la propria idea su una o più funzioni dello stesso software. In entrambi i casi, se uno sviluppatore si sente bruciato dalle attività ripetitive che sta facendo, forse è giunto il momento di parlarne.
Se possibile, spostare il dipendente in un altro progetto. A volte un semplice cambiamento dei task su cui uno sta lavorando può essere defaticante e serve a mantenere il dipendente motivato.
(3) L’entropia del software da debito di progettazione
Il debito di progettazione è l’effetto causato dall’adozione di una semplice soluzione senza però tener conto della futura scalabilità del progetto. In sintesi, riflette il lavoro di sviluppo aggiuntivo che si presenta quando viene utilizzato codice facile da implementare nel breve periodo anziché applicare la migliore soluzione a lungo termine. La ragione per cui gli sviluppatori odiano questo tipo di debito è semplice: proprio come il caso di un debito finanziario, ci sarà un momento per “restituirlo”, che in termini di sviluppo significa affrontare nuovamente lo stesso problema.
Per risolvere il problema, gli sviluppatori spesso devono riscrivere il codice per terminare “il lavoro non completato”. Inoltre, causa scadenze mancate, in quanto è chiaramente difficile stimare quanti lavori sono necessari per pagare il debito stesso maturato.
La soluzione da applicare è semplice: non cadere nella scelta più semplicistica solo perché più facile quando si pianifica. Pensate alla soluzione valida una volta per tutte. Questo debito non è necessariamente una cosa negativa, talvolta il debito di progettazione (o debito tecnico se preferite) è positivo e necessario per far evolvere i progetti.
