Cosa fare quando la stima del tempo va storto?

Supponiamo che il tempo stimato per un caso sia di 3 giorni. Nel secondo giorno noterai che il caso sta crescendo e stanno emergendo nuovi scenari che non sono stati conteggiati quando è stata effettuata la stima del tempo. La nuova scoperta porta a 2 giorni in più (in totale 5 giorni). Questo è un problema tipico che affronterai prima o poi come sviluppatore.

• Quale strategia può essere utilizzata quando si comunica al capo progetto il nuovo orario di consegna?
• Spesso capisci perché? Come si motiva il nuovo tempo di consegna?

Il fatto è che molti progetti non dedicano molto tempo all'analisi e alla progettazione durante SDLC.

EDIT: in progetti molto complessi, indipendentemente da quanto tempo ragionevole dedichi ad Analysis & Design, ci sono sempre sorprese poiché le regole aziendali sono troppo complesse. Tuttavia, in tali casi, credo che il responsabile del progetto debba essere consapevole della complessità e avere il giusto atteggiamento quando si presentano sorprese inaspettate. La domanda è come affrontare i leader di progetto che non comprendono la complessità.

Fornire cattive notizie

Devi assolutamente sollevare la questione prontamente, tuttavia se riesci a farlo in un lasso di tempo ragionevole (cioè poche ore, non di più) dovresti fare un po 'di valutazione dell'impatto prima di farlo.

Come per tutte le cattive notizie, è meglio fornire informazioni dettagliate (piuttosto che sfocare "sarà tardi"), quindi fornire altrettante / molte di:

1) Stime / tempistiche riviste per i compiti che sono scivolati.

2) Stime / tempistiche riviste per compiti futuri che ora pensi, alla luce del fatto che alcune cose sono già finite, potrebbero richiedere più tempo.

3) Ragioni molto brevi per cui si è verificato lo slittamento (non girare, solo la verità, ma non sembra che tu stia facendo delle scuse). In questo caso affermi "Abbiamo stimato in base alle regole X e Y ma ora hanno incluso Z che non è mai stato menzionato". Potrebbe essere in grado di usare questo per spiegare il ritardo ai clienti e educarli sull'importanza di essere approfonditi in primo luogo.

4) Se possibile, alternative per riportare le cose sulla buona strada (di solito riducono la portata ma potrebbero esserci altre opzioni - altre parti del progetto potrebbero essere in anticipo e potrebbe essere possibile spostare le attività).

Ricorda che con gli slittamenti l'impatto psicologico / di credibilità è di tipo culminante. Potresti riuscire a cavartene uno, ma il secondo sarà molto più duro e il terzo ancora più duro.

Ecco perché il punto 2 è importante: rivedere non solo ciò che è già sfuggito, ma anche le attività future che ora ritieni possano richiedere più tempo di quanto inizialmente previsto. Scivolare succede negli IT, non imparare dai tuoi errori è un peccato più grande.

Prevenire la necessità di fornire cattive notizie

Ci sono due scenari qui: in primo luogo, non hai fatto tu stesso le stime, nel qual caso non c'è molto che puoi fare altro che spingere per essere coinvolto nelle stime la prossima volta.

In secondo luogo, hai fatto tu stesso le stime, nel qual caso devi guardare come fare stime migliori. Per me la frase chiave nella domanda è "ci sono sempre sorprese poiché le regole aziendali sono troppo complesse" .

Con rispetto, se succede sempre, non dovrebbe essere una sorpresa . Se ottieni solo la metà delle regole aziendali, devi assumerlo nelle tue stime e consentire lo scorrimento delle funzionalità.

Puoi farlo aumentando le stime per le regole che hai (funziona ma non stai istruendo nessuno su ciò che sta realmente accadendo), ma è meglio affermare con le tue stime "Storicamente le regole che otteniamo sono una versione semplificata di ciò che vogliono veramente. Le regole che hanno dichiarato impiegheranno 3 giorni per essere implementate, tuttavia dovremmo consentire un'altra contingenza di 3 giorni per le regole che non sono state menzionate ma che probabilmente saranno scoperte durante lo sviluppo e i test. "

Se il PM lo mette in discussione, allora devi ricordargli tutte le volte che è stato vero (con esempi - è difficile argomentare esempi) e anche suggerire delicatamente che è nel suo interesse consegnare in tempo così come il tuo, non è vero? meglio essere conservatori?

Ma la linea di fondo: se si sottovaluta sempre a causa di un fattore specifico (in questo caso la caratteristica si insinua), quindi figura nelle stime.

Le stime basate sul tempo sono ipotesi sul futuro e che a lungo termine falliranno sempre. È una battaglia inutile che non puoi vincere.

Interrompere la stima in giorni e iniziare invece a utilizzare la stima relativa . Qui c'è un semplice esempio:

1. Assegna un numero a ciascuna attività. Il compito più difficile può essere 10 e il compito più semplice 1.
2. Inizia a programmare per completare le tue attività.
3. Dopo una settimana, interrompi il lavoro e somma i numeri di tutte le attività completate. Diciamo che finisci con 14. Questa è la tua velocità settimanale.

La settimana prossima, ripeti nuovamente il processo. Scommetto che la tua velocità cambierà, ma non molto. Dopo alcune settimane con questo, la tua velocità dovrebbe essere abbastanza stabile ed è quello che stiamo puntando. Ora puoi iniziare a fare piani con fiducia. Scegli le attività che si sommano alla tua velocità e il tuo PM può essere abbastanza certo che sarà completato come promesso. È così che dovresti affrontare i tuoi leader di progetto.

Non appena vedi che la stima è sbagliata devi alzare il campanello d'allarme. Informare coloro che prevedono la consegna del ritardo.

Chiedi aiuto ai compagni di squadra, se possibile. Assicurati di fornire comunque il software di alta qualità possibile.

Una scorciatoia molto probabilmente farà più male alla fine, e tutti i soggetti coinvolti dovrebbero saperlo. O almeno dovrebbe essere possibile spiegarglielo.

Ciò accade così spesso che nessun project manager esperto ne trarrà gran parte. Sii onesto e non fare nuove stime troppo ottimistiche; quando vedi ci vorrà molto più tempo, dillo. Non dire "Ho bisogno di un po 'più di tempo" su base giornaliera.

Dovrai spiegare al manager: la stima era in primo luogo errata o erano circostanze avverse (trascorse una giornata a caccia di un bug) il motivo del ritardo? Nel primo caso, qualcosa non va nel processo di stima, forse è troppo ottimista o ingenuo. Nel secondo caso, è un caso per il buffer che si spera fosse incluso nel piano di progetto.

Tieni sempre le parti interessate pertinenti sui tuoi progressi, incluso (soprattutto!) Il fatto che le tue stime siano eccessivamente ottimistiche. Non saranno felici, ma sapranno dove sta realmente il progetto e potranno pianificare di conseguenza.

Idealmente il tuo elenco di funzionalità sarebbe stato MoSCoWed - Must, Should ,ulduld, Won't.

Quando stai per invadere, taglia i Coulds, quindi i Shoulds. Taglia le funzionalità in modo da poter essere spedite in tempo: il tuo progetto di solito non vive in modo isolato, e se vai oltre la data di rilascio significa che anche i progetti a valle supereranno il loro programma.

Idealmente avrai solo il 60% di mosti. Se devi tagliare quelli che hai nei guai molto profondi (avendo un sovraccarico molto grave), nel qual caso dovrai tagliare gli angoli.

Assicurati di concederti abbastanza tempo dopo il rilascio per ripulire il casino fatto tagliando gli angoli!

La stima del progetto è il gioco d'azzardo, chiaro e semplice. Non c'è ricompensa senza rischio.

Se il manager non lo capisce, è la prima cosa che spiegherei.

La domanda è: chi copre il rischio?

Se hai un contratto a prezzo fisso, stai coprendo il rischio.

Se tempo e materiali, allora sta coprendo il rischio.

Pertanto, quando si effettua una stima, è importante capire che si sta indovinando e che è necessario avere un'idea di quanto sia incerta la stima e di chi copre il rischio.

Credo che la migliore strategia raffini costantemente le tue stime . Lo so, sto dicendo: la tua domanda è in qualche modo fuori posto.

Leggendo Presentazione di Deliberate Discovery di Dan North Sono giunto alla conclusione che porre lo sforzo di stima nella fase iniziale ha lo scopo di fare una previsione esattamente quando la tua ignoranza del problema e del dominio è a un livello massimo. Ammettilo, non puoi prevedere ciò che è incerto, soprattutto se è ancora sconosciuto .

Metodologie agili risolvono questo problema spezzando la durata del progetto in diversi pezzi (sprint, in Scrum) e ripetendo la stima (dimensionamento delle storie) ogni settimana. Ogni settimana, ciò che sai del problema viene perfezionato, così come la stima.

Per me, una stima non può essere vera o falsa. Può solo essere sempre più raffinato . Una stima non è un impegno. Ecco perché si chiama stima.

Il meglio che puoi fare quando sei in ritardo (e anche quando "rischi di consegnare in anticipo", perché il problema è lo stesso: hai stimato male) è l'escalation e portare il fatto al cliente il più presto possibile. Si chiama gestione del rischio. Prima di dare un feedback, più efficaci saranno le contromisure. Di solito ciò significa che, se hai prove che non puoi consegnare tutto, dovresti parlare con il tuo cliente, dirle che puoi consegnare solo il 70% dell'impegno e lasciarle decidere cosa ha più valore commerciale per lei e dovrebbe essere distribuito per primo .

Ne ho scritto qui Stima sbagliata, aiuto! Sono in ritardo! Taglia le funzionalità e smetti di precipitare!

Si chiama stima perché è un'ipotesi colta. Non è una descrizione infallibile del futuro e ho poca pazienza per le persone che trattano le stime del software in quel modo. Alla fine, molte cose impiegheranno più tempo del previsto, in rari casi potrebbero richiedere un ordine di grandezza più tempo. Questo succede anche ai migliori programmatori del mondo. Come può un manager aspettarsi che non succeda a te? Se il tuo manager non lo capisce, non ha molta esperienza. Se finge di non capirlo per applicare la pressione del programma, è irragionevole.

L'approccio migliore è il più ovvio. Non appena si ha la chiara idea che una funzione richiederà più tempo del previsto, discuterne con il proprio responsabile. Esistono spesso modi per procedere che risolveranno sia i tuoi problemi che quelli del tuo manager. Cioè, la parte della funzione che sta rallentando le cose può essere relativamente poco importante o facile da modificare in un modo che rende possibili progressi più rapidi. In ogni caso, non essere vittima di bullismo in una seconda stima ottimistica.

Fai sapere a tutto il team e prova a trovare una soluzione. Consiglio 3 soluzioni, dalle priorità più alte a quelle più basse:

un. Prova a trovare una correzione temporanea o una soluzione rapida

b. Il lavoro che puoi fare, fallo al meglio. Dopo aver mostrato al cliente la tua eccellente parte di lavoro, chiedi il loro aiuto: possiamo farlo, ma c'è qualche problema e potrebbe rallentare la produttività del tuo lavoro ... Forse puoi chiedere loro se c'è qualche richiesta non necessaria / funzione che può essere rilasciata o ridotta.

Proporre un approccio alternativo al loro problema, forse una buona idea.

c. Overtime-lavoro

Opzioni:

• Funzioni di taglio
• Qualità di taglio (lasciare correzioni di bug per dopo)
• Aumentare la produttività
  • Trova e rimuovi i bloccanti
  • Break / riposo
  • Riduci il tempo personale / di sonno
  • Ottieni più forza lavoro
  • Ottieni strumenti migliori
  • Formazione
  • Aumentare la motivazione
    • Cibo gratis
    • [Promessa di] aumento / promozione / vacanza / bonus / ecc.
    • minacce
    • Migliorare le condizioni di lavoro (migliore hardware, mobili, ecc.)
    • Cambia ambiente - lavora da un bar o sposta l'intera squadra in un posto fresco - una baita di montagna o una casa sul lago?

Questo è un problema comune :)

Uno degli approcci più semplici è quello di aggiungere un buffer a qualsiasi stima effettuata, poiché si verificano sempre problemi imprevisti. Le dimensioni del buffer dipendono dalle dimensioni del team e dall'incertezza della tecnologia e del problema stesso.

Squadre più grandi hanno più persone che potrebbero ammalarsi e meno persone che sanno "tutto".

Le nuove tecnologie sono sempre più rischiose di quelle che già conosci.

E quando vedi che non sarai finito alla data stimata, comunica in anticipo con le parti interessate. Forse puoi riordinare le cose o ritardare alcune funzionalità dopo aver parlato con il cliente / stakeholder.