HTC High Tech Consultant Corp

Lievitazione dei costi di progetto. Come evitarli. Nel precedente post ho analizzato il rischio dei ritardi di progetto e come soluzione ho suggerito di migliorare la capacità di gestire le scadenze.   Il secondo rischio che voglio trattare qui è l’aumento dei costi.   E’ noto che i ritardi di progetto sono un aumento dei costi.   Ma perché?   Perché il ritardo di progetto in realtà è l’effetto degli errori di pianificazione e gli errori di pianificazione sono la prima causa dell’aumento dei costi. Se vi andate a vedere il post precedente trovate che le giornate previste per la modifica con scadenza il 15/12 erano quasi esclusivamente quelle del programmatore che doveva consegnare il 14/12. Nell’analisi seguente sono state considerate anche le attività dei consulenti funzionali (test interni e test con gli utenti), giornate dei sistemisti per la pubblicazione in produzione e degli utenti stessi. E’ un aumento dei costi di progetto (non solo per la software house). Ma erano stati preventivati?   La sottostima del preventivo è quindi la prima causa di aumento dei costi. In realtà i costi non aumentano. Alcuni sono non-stimati.   Ho poi citato poi il fatto che a volte nel test con gli utenti, questi ultimi espongono nuove idee, propongono miglioramenti, che il consulente non riesce a raccogliere -> inserire in una roadmap -> tempificare -> far emergere come costi aggiuntivi espliciti. Nella negoziazione il tecnico è un po’ “sottomesso” al cliente e spesso risponde “Ok, va bene, inseriamo anche questa modifica”. La modifica ulteriore viene aggiunta, testata e pubblicata e programmatori e consulenti addebitano il tempo impiegato (costo) al progetto. Poi qualcuno dovrà andare dal cliente per recuperare quel costo. Apriti cielo.   Un buon Project Manager deve intercettare queste dinamiche consulenti funzionali / utenti / programmatori. Ma il PM non può essere onnipresente, alcune sessioni consulenti-utenti sono parallele e il PM non gestisce un solo progetto alla volta quindi sfuggono.   Ma il PM non è l’unico attore del progetto. I consulenti devono sottolineare al PM queste situazioni. Giusto. E gli utenti?   Questo è il punto chiave. Gli utenti non sono preparati a partecipare a progetti. Non è il loro mestiere. Quindi l’unica arma che hanno è “chiedere”. Il cliente poi pensa come un cliente al ristorante: “Ho ordinato la cena, mi aspetto che mi arrivi quello che ho ordinato. Io devo solo consumarla.” Purtroppo nei progetti IT non è così. Questo per dire che è necessario fare un lavoro PRIMA DEL PROGETTO con gli utenti. Bisogna farli diventare un po’ chef!   E’ quello che ti propongo con il metodo ITNoPain. Altre soluzioni: qui https://lnkd.in/dCh6UZze --------- I love helping PEOPLE complete SW projects ON TRACK. I love helping STARTUP get SOFTWARE built.

Rischi di progetto #1. Nei prossimi post analizzerò i rischi di progetti ed esporrò le soluzioni. L'obiettivo non è quello di mostrare che conosco il tema ma farvi riflettere. Partiamo dal primo rischio   Ritardi -> Soluzione: imparare a gestire le scadenze   Il mondo IT è sempre più veloce. Ma noi umani siamo rimasti quelli di un tempo. Facciamo fatica a prendere decisioni e spesso sbagliamo la scelta. Quindi se una modifica del software deve essere fatta per il 15/12 questo NON significa che il programmatore può consegnare la modifica il 14/12 o il 10/8 e nemmeno l'1/8.   Quando la deve consegnare? Normalmente tutti pensano che basti una settimana di anticipo. No è più probabilmente il 15/11. Vediamo quali sono le fasi necessarie dopo la pubblicazione.   1 - Test consulenti funzionali N 1. La modifica viene rilasciata in ambiente di TEST e va testata dai consulenti funzionali prima che la testino gli utenti.   2 - Rework. Se un consulente funzionale dedica 4 ore al test e se questo non presenta errori bloccanti mediamente servono comunque 3 giorni per le correzioni. 3 - Test consulenti funzionali N 2. Il rework va testato. Infatti “non si può vedere” un test con gli utenti che fallisce. Gli utenti devono “certificare” la funzionalità non la correttezza del codice. L’ipotesi molto ottimistica è dopo questo secondo test sia tutto ok. 4 - Test utenti N 1. Siamo nell’ipotesi che tutto funzioni, anche se non ho mai visto utenti contenti al primo test. A volte è un problema di specifiche non chiare, a volte gli utenti hanno maturato piccoli requisiti aggiuntivi e il consulente funzionale non sa dire di no, a volte è proprio con l’utente ci si accorge che la modifica impatta su altre funzionalità e a volte ci sono errori di codice che non sono stati rilevati prima. Quindi altri 3 giorni di modifiche sono da prevedere. Non siamo in un ambiente semplice, ma in un ambiente complesso. 5 - Pubblicazione in produzione. La migrazione in ambiente di produzione deve essere pianificata magari aggregandola con altre modifiche da pubblicare. 6 - Test in Produzione. Anche qui facciamo l’ipotesi che vada tutto bene perché abbiamo considerato le correlazioni tra le modifiche. Se il sistema è nuovo vanno considerate le integrazioni con gli altri sistemi che potrebbero introdurre altri ritardi.   Tutto ciò sembra rappresentabile in un Gantt in modo perfetto, ma ahimè non è così. I programmatori vanno prenotati, i test vanno schedulati incrociando le disponibilità degli utenti e dei consulenti, i test spesso falliscono.   Torniamo quindi alla data. Dopo questa analisi ottimistica, vi pare possibile adesso chiedere al programmatore di consegnare il 7/12?   Sembrava ragionevole.   Prima. Ora forse anche il 31/11 è troppo ottimistico. Altre soluzioni: qui https://lnkd.in/dCh6UZze --------- I love helping PEOPLE complete SW projects ON TRACK. I love helping STARTUP get SOFTWARE built.