Sono uno sviluppatore di software e lavoro in una piccola società di sviluppo web. Sembra essere un tema ricorrente che un dirigente intermedio mi chiederà quanto tempo ci vorrà qualcosa, e quando darò loro la mia stima, pensano che sia troppo alto. Se si tratta di un manager più tecnico o di un altro sviluppatore, di solito hanno già in mente una stima propria e iniziano a provare a implementarlo a modo loro perché pensano di poterlo fare più velocemente.
C'è una tendenza, tuttavia, in cui gli altri sviluppatori hanno finito per utilizzare molto più tempo di quanto hanno quotato. Otterranno metà del loro budget, quindi realizzeranno che c'è qualche necessità commerciale che il loro piano di implementazione non possa affrontare correttamente. Più volte, il mio piano avrebbe risposto a questa esigenza, ma è stato scrollato di dosso come un " Non ne avrai bisogno ".
Peggio ancora, quando colpiscono questo muro, di solito vengono da me per aiutarli a uscire dall'angolo in cui si sono dipinti, ma ci sono solo tante ore ai miei tempi.
Caso migliore : queste interruzioni riducono il tempo che ho assegnato per il mio lavoro di sviluppo, causando il ritardo di altri progetti o il fatto che devo fare gli straordinari perché sono "l'unico può fare X ".
Il peggiore dei casi : finisco per dover assumere il compito / progetto come mio e, a quel punto, non c'è più tempo nel budget per farmi fare il "mio" modo. Devo cercare di finire quello che hanno iniziato nel modo in cui hanno iniziato, quindi "la compagnia non perde più soldi". Questo torna sempre a mordermi perché poi diventa il "mio" codice hacky, e quando si rompe le persone mi chiedono perché è stato creato così (dopotutto non hanno idea di chi lo abbia effettivamente creato.)
Quindi la mia domanda è : come posso aiutare questi colleghi a capire quando le cose non sono così semplici come loro immaginano e devono rivalutare la loro comprensione dei bisogni del cliente?
Diversamente da questa domanda simile su Convincendo la gestione a trattare con il debito tecnico [esistente] , la mia domanda cerca strategie per aiutare la squadra a realizzare [proattivamente] prima di incorrere in un debito tecnico, in un tentativo di impedire che ciò accada all'inizio. Queste due cose vanno di pari passo, ma sono distintamente differenti nella mia mente. Le risposte dell'altra domanda suggeriscono di aggiungere il tempo di refactoring alle stime per le funzionalità future. Questo non può mai funzionare se altri sviluppatori (e quindi i manager) pensano sempre che detta funzione futura impiegherà meno tempo di quanto effettivamente sarà, e non posso convincerli che la mia stima è più realistica.