Cosa fare quando la stima del tempo va storta?

Pubblicazione di cattive notizie

Devi assolutamente sollevare la questione prontamente, tuttavia se puoi farlo in tempi ragionevoli (ovvero 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 (anziché limitarsi a "essere in ritardo"), quindi fornire tanti / molti di:

1) Stime / scadenze riviste per le attività che sono scivolate.

2) Stime / scadenze riviste per compiti futuri che ora pensate, alla luce del sapere che alcune cose sono già finite, potrebbe richiedere più tempo.

3) Motivi molto brevi per cui lo slittamento si è verificato (non girare, solo la verità, ma non sembra che tu stia scusando). In questo caso dichiari "Abbiamo stimato in base alle regole X e Y, ma ora includono Z che non è mai stato menzionato". Potrebbe essere in grado di usarlo per spiegare il ritardo nei confronti dei clienti e istruirli sull'importanza di essere accurati in primo luogo.

4) Se possibile, alternative per riportare le cose in pista (di solito riducendo lo scope ma potrebbero esserci altre opzioni - altre parti del progetto potrebbero essere in anticipo e potrebbe essere possibile spostare le attività in giro).

Ricorda con slittamenti l'impatto psicologico / credibilità è culmulativo. Potresti riuscire a farla franca, ma la seconda sarà più dura e la terza ancora più dura.

Ecco perché il punto 2 è importante: rivedere non solo ciò che è già scivolato, ma anche i compiti futuri che ora ritieni possano richiedere più tempo del previsto. Scivolare accade in IT, non imparare dai tuoi errori è un peccato più grande.

Prevenire di consegnare cattive notizie

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

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

Con rispetto, se succede sempre, non dovrebbe essere una sorpresa . Se si ottiene sempre solo la metà delle regole aziendali, è necessario presumerlo nelle stime e tenere conto della funzionalità di scorrimento.

Puoi farlo aumentando le stime per le regole che hai (funziona ma non stai educando nessuno a ciò che sta realmente accadendo), ma è meglio indicare le tue stime "Storicamente le regole che otteniamo sono una versione semplificata di ciò che vogliono veramente: le regole che hanno dichiarato impiegano 3 giorni per essere implementate, tuttavia dovremmo concedere altri 3 giorni di contingency per le regole che non sono state menzionate ma che probabilmente verranno scoperte durante lo sviluppo e il test. "

Se il PM chiede questo, allora devi ricordargli tutte le volte che è stato vero (con esempi - è difficile argomentare gli esempi) e anche suggerire gentilmente che è nel suo interesse di consegnare in tempo così come il tuo quindi non è è meglio essere prudenti?

Ma la linea di fondo: se sottovaluti sempre a causa di un fattore specifico (in questo caso la caratteristica insinuante), allora calcola questo nelle tue stime.

Le stime basate sul tempo sono supposizioni sul futuro, e ciò fallirà sempre nel lungo periodo. È una battaglia inutile che non puoi vincere.

Interrompi la stima in giorni e avvia invece utilizzando la stima relativa . Ecco un semplice esempio:

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

La prossima settimana ripeti il processo. Scommetto che la tua velocità cambierà, ma non molto. Dopo alcune settimane con questo, la tua velocità dovrebbe essere abbastanza stabile e questo è ciò a cui miriamo. Ora puoi iniziare a fare progetti con sicurezza. Scegli le attività che riassumono la tua velocità e il tuo PM può essere certo che sarà completato come promesso. Ecco come dovresti affrontare i tuoi leader di progetto.

Non appena vedi che la stima è sbagliata, devi alzare il campanello d'allarme. Informare coloro che si aspettano la consegna per il ritardo.

Se possibile, chiedi aiuto ai compagni di squadra. Assicurati di fornire sempre il software di alta qualità possibile.

Una scorciatoia molto probabilmente farà più male alla fine, e tutti coloro che sono coinvolti dovrebbero saperlo. O almeno dovrebbe essere possibile spiegarlo a loro.

Succede così spesso che nessun progetto esperto può fare molto di questo. Basta essere onesti e non fare nuove stime troppo ottimistiche; quando lo vedrai 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 sbagliata in primo luogo o erano circostanze avverse (trascorse un giorno a cacciare un insetto) il motivo del ritardo? Nel primo caso, c'è qualcosa di sbagliato nel processo di stima, forse è troppo ottimista o ingenuo. Nel secondo caso, è un caso per il buffer che si sperava fosse incluso nel piano del progetto.

Mantieni sempre le parti interessate consapevoli dei tuoi progressi, incluso (soprattutto!) il fatto che le tue stime sono eccessivamente ottimistiche. Non saranno felici, ma sapranno dove si trova il progetto e potranno pianificare di conseguenza.

Idealmente il tuo elenco di funzionalità sarà MoSCoWed - Must, Should, Could, Will not.

Quando ti stai dirigendo verso il superamento, taglia le Coulds, poi le Shoulds. Taglia le funzionalità in modo da poter essere spedite in tempo: il tuo progetto di solito non vive in isolamento, e andando oltre la data di rilascio significa che i progetti downstream ora supereranno anche il loro programma.

Idealmente avrai solo ~ 60% di mosti. Se devi tagliare quelli in cui hai problemi molto profondi (con un sovraccarico molto serio), nel qual caso dovrai tagliare gli angoli.

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

La stima del progetto è il gioco d'azzardo, semplice e semplice. Non c'è premio senza rischi.

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

La domanda è: chi copre il rischio?

Se sei su un contratto a prezzo fisso, allora stai coprendo il rischio.

Se tempo e materiali, allora sta coprendo il rischio.

Quindi, quando valuti, è importante capire che stai indovinando, e hai bisogno di avere un'idea di quanto sia incerta la stima e di chi sta coprendo il rischio.

Credo che la strategia migliore sia a perfezionare costantemente la stima . Lo so, sto dicendo: la tua domanda è in qualche modo fuori luogo.

Lettura Introduzione a Deliberate Discovery di Dan North Sono giunto alla conclusione che posizionare la stima lo sforzo nella fase iniziale equivale a fare una previsione esattamente quando la tua ignoranza del problema e il dominio sono al massimo livello. Affrontalo, non puoi prevedere cosa non è sicuro, soprattutto se è ancora sconosciuto .

Le metodologie Agili risolvono questo problema rompendo la durata del progetto in più parti (sprint, in Scrum) e ripetendo la stima (le storie di dimensionamento) ogni settimana. Ogni settimana, ciò che sai del problema è raffinato, e lo è anche la stima.

Per me, una stima non può essere vera o falsa. Può solo essere ulteriormente rifinito . 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 alza il fatto al cliente non appena possibile. Si chiama gestione del rischio. Prima fornirai 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 fargli decidere cosa ha più valore aziendale per lei e dovrebbe schierarlo prima .

Ne ho scritto qui Stima errata, aiuto! Sono in ritardo! Taglia le feature e smettila di cascarci!

Si chiama stima perché è un'ipotesi istruita. Non è una descrizione infallibile del futuro, e ho poca pazienza per le persone che trattano le stime del software in questo modo. In definitiva, molte cose impiegheranno più tempo del previsto, in rari casi potrebbero richiedere più tempo. Questo succede anche ai migliori programmatori del mondo. Come potrebbe un manager aspettarsi che non ti succeda? 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 avrai la chiara idea che una funzionalità richiederà più tempo del previsto, discuterla con il tuo manager. Ci sono spesso modi per procedere che risolveranno sia i tuoi problemi che quelli del tuo manager. Cioè, la porzione della caratteristica 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. Raccomando 3 soluzioni, dalla priorità alta alla bassa:

a. Prova a trovare un hot-fix temporaneo o un rapido

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

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

c. Overtime-lavoro

Opzioni:

• Taglia funzioni
• Qualità di taglio (lasciare correzioni di bug per dopo)
• Aumentare la produttività
  • Trova e rimuovi i blocchi
  • Break / resto
  • Taglia personale / tempo 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 (hardware migliore, mobili, ecc.)
    • Cambiare ambiente - lavorare da un bar o spostare tutta la squadra in un posto fresco - un rifugio di montagna o una casa sul lago?

Questo è un problema comune:)

Uno degli approcci più semplici consiste nell'aggiungere un buffer a qualsiasi stima effettuata, poiché i problemi imprevisti si verificano sempre. La dimensione del buffer dipende dalle dimensioni del team e dall'incertezza della tecnologia e del problema stesso.

I team più grandi hanno più persone che potrebbero ammalarsi e meno persone che conoscono "tutto".

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

E quando vedrai che non sarai finito alla data stimata, comunica presto con gli stakeholder. Forse è possibile riordinare le cose o ritardare determinate funzionalità dopo aver parlato con il cliente / stakeholder.