Come possiamo pianificare progetti realisticamente tenendo conto delle problematiche di supporto?

Stiamo riscontrando un problema sul lavoro: stiamo cercando di pianificare il lavoro in modo da poter valutare i tempi e ottenere le scadenze.

Il problema è che è difficile pianificare un progetto senza sapere tutto ciò che accadrà.

Ad esempio, in questo momento abbiamo pianificato tutti i nostri progetti fino all'inizio di dicembre, tuttavia in quel momento avremo varie riunioni interne ed esterne, teleconferenze e lavoro extra. Va bene e va bene dire che un progetto richiederà tre settimane, ma se c'è una settimana di interruzione in quel momento, la data di completamento verrà rinviata di una settimana.

Il problema è 3 volte:

1. Quando pianifichiamo i progetti, le scale temporali vengono prese alla lettera. Se stimiamo tre settimane, la scadenza è fissata per tre settimane, viene comunicato al cliente e non c'è spazio per l'estensione.

2. Lavoro interinale e tale significa che perdiamo tempo produttivo lavorando al progetto.

3. A volte i clienti non hanno il tempo necessario per svolgere il lavoro, quindi a volte vengono da noi e dicono che hanno bisogno di un progetto realizzato entro la fine del mese anche quando pensiamo che il lavoro richiederà due mesi - per non parlare del fatto che abbiamo già del lavoro da fare.

Abbiamo un diagramma di Gantt che stiamo cercando di compilare con tutti i progetti che abbiamo e compiliamo schede attività, ma non sono affatto paragonati al diagramma di Gantt. Questo rende difficile dire "Beh, abbiamo programmato 3 settimane per questo progetto, ma abbiamo perso una settimana qui, quindi la scadenza deve tornare indietro di una settimana."

Inoltre, non è professionale mantenere scadenze mancanti comunicate al cliente.

In che modo le altre persone affrontano questo tipo di situazione? Come gestite la pianificazione dei progetti? Quanto tempo "extra" pianifichi in un progetto per tenere conto del lavoro non di progetto che si verifica durante un progetto? Come gestite i problemi di supporto, i bug e le cose? Cose di cui non puoi tenere conto durante la pianificazione?

AGGIORNARE

Molte buone risposte grazie.

Il problema è che è difficile pianificare un progetto senza sapere tutto ciò che accadrà.

Questo è il punto della gestione del rischio. Non puoi sapere tutto, quindi pianifichi in base a ciò che sai e identifichi quali cose potrebbero avere il maggiore impatto sul tuo piano e sulla probabilità che ciò accada. Valuta anche il potenziale impatto della pianificazione dicendo che se si verifica X, ciò causerà uno slittamento della pianificazione di Y giorni o settimane stimati (parola chiave - stima).

Va bene dire che un progetto richiederà 3 settimane,

Non dare mai una stima così specifica. Fornisci un intervallo o quantifica la probabilità di raggiungere tale stima. Ad esempio, dire "questo progetto richiederà 2-5 settimane" o "c'è una probabilità dell'85% che questo progetto sarà realizzato in 3 settimane e una probabilità del 95% che sarà fatto in 4 settimane".

Inoltre, non è professionale per il cliente continuare a dire che abbiamo perso una scadenza.

Vero. Tuttavia, stai mescolando i concetti di "stima", "pianificazione" e "scadenza". La tua stima è un'approssimazione di quanto tempo ci vorrà per completare un determinato compito o progetto e la probabilità di soddisfarlo. La scadenza è una data imposta dal cliente in cui il progetto deve essere fatto per aggiungere valore. Il programma prevede l'utilizzo delle risorse disponibili per rispettare la scadenza.

Ci sono momenti in cui semplicemente non è possibile finire il lavoro assegnato entro una scadenza e tutte le stime e la programmazione nel mondo non faranno la differenza.

Quindi la mia domanda ... come fanno gli altri a farlo? Come gestite la pianificazione dei progetti? Quanto tempo "extra" pianifichi in un progetto per tenere conto di ciò che accade nel frattempo?

Consiglio di leggere due libri, entrambi di Steve McConnell: Stima del software: demistificare l'arte nera e lo sviluppo rapido: domare i programmi software selvaggi . La stima del software consiste nell'elaborare stime, presentarle ai clienti e alcuni aspetti della negoziazione e della gestione di aspettative non realistiche. Lo sviluppo rapido è la gestione generale del progetto, che si occupa di cicli di vita dello sviluppo, pianificazione, allocazione delle risorse e come pianificare e pianificare al meglio i progetti per rispettare le stime e le scadenze.

Suggerirei di scavare nei dettagli del processo di sviluppo di Scrum . Copre tali attività di sidetracking dalla focus factormetrica. Fondamentalmente devi lavorare 2-3 sprint / iterazioni e quindi misurare il fattore di messa a fuoco del tuo team (e per ogni membro sarebbe utile anche). Dopodiché sarai in grado di fornire stime più accurate che coprono l'attività quotidiana.

Dai un'occhiata a questo articolo - "Il fattore di messa a fuoco"

Se qualcuno di voi ha familiarità con lo sviluppo Agile, probabilmente avrete sentito parlare del fattore di concentrazione (o fattore di produttività). È usato per pianificare per aiutare a determinare quante "ore reali" devi lavorare su qualcosa. È la differenza tra "ore reali" e "ore ideali".

Il problema delle interruzioni è che per determinati individui o team tendono ad accadere in un intervallo relativamente piccolo di probabilità. Ad esempio, hai circa lo stesso numero di riunioni ogni settimana o circa lo stesso numero di ore trascorse ogni mese per risolvere urgenti bug o lo stesso tempo impiegato per rispondere alle domande delle persone che si avvicinano alla tua scrivania, soprattutto se mediate un lungo periodo di tempo.

Molte moderne tecniche di pianificazione ne tengono conto. La mischia lo calcola in velocità. La pianificazione basata sulle prove utilizza anche una velocità con un intervallo di confidenza per ogni stima. Pomodoro prende in considerazione le interruzioni quando decidi quanti "pomodoros" puoi contare sul completamento in una determinata settimana. Tutto ciò dipende dal monitoraggio delle misurazioni storiche delle interruzioni e dal loro calcolo in qualche modo nelle stime. Ti consiglio di dare un'occhiata a tutti loro e escogitare una tecnica che funzionerà per la tua squadra.

Un buon consiglio dappertutto.

Un'altra cosa che potrebbe essere utile per affrontare i problemi di supporto è dedicare le persone al supporto su base fissa "round-robin".

Ad esempio, se hai 5 sviluppatori ne assegnano uno a ogni giorno della settimana. Quando arriva quel giorno, lo sviluppatore assegnato lavora per quel giorno SOLO sul supporto. Il giorno successivo un altro sviluppatore assume il supporto. In questo modo ognuno ha la possibilità di rimanere nel proprio "flusso", tutti hanno un assaggio del cibo per cani.

In che modo scegliate REALMENTE di dividere il normale lavoro di supporto non importa (il round robin dei giorni della settimana è solo un esempio). Ciò che conta è limitare il tempo di supporto a intervalli regolari fissi. Ciò rende i tempi di sviluppo più prevedibili con il compromesso che non è possibile avere "tutti eliminano tutto" per affrontare i problemi di supporto.

Questa è un'abilità che arriva davvero con l'esperienza, e spesso alle persone viene chiesto prima di essere in grado di giudicare con precisione una cosa del genere. Ho sempre lavorato in un gruppo abbastanza affiatato con uno stile informale, ma abbiamo sviluppato alcune regole empiriche che sembrano reggere bene.

Innanzitutto, nessuna attività richiede meno di una settimana. Stima sempre in settimane, anche se un'attività sembra richiedere solo alcuni giorni per essere eseguita. Ci saranno alcuni motivi per cui non sarà fatto prima della fine della settimana.

In secondo luogo, fai del tuo meglio per stimare il tempo impiegato dall'attività, comprese interruzioni, problemi di assistenza clienti, superamento dei test, ecc. Ora raddoppia il numero. Questa è la tua stima (in settimane).

Terzo, assicurati che il tuo manager non stia già aggiungendo un po 'di riempimento alle tue stime. Il nostro team ha avuto un manager lamentarsi delle nostre stime. Si è scoperto che avrebbe già moltiplicato per 2,1 (la sua stima dell'imbottitura derivata empiricamente) e che avevamo già raddoppiato prima di dirglielo.

Non è uno strumento sofisticato e potrebbe non essere un metodo perfetto, ma funziona sorprendentemente bene.

Le persone che effettuano la stima devono capire che nessuna squadra partecipa mai al 100% a un progetto. Congedo per malattia, ferie, incarico di giuria, congedo per lutto, riunioni per le risorse umane richieste (è tempo di indennità!), Riunioni di gruppo che non sono correlate al progetto, inevitabili ritardi, interruzioni del bagno, attività di supporto su articoli già in produzione, gestione delle email , configurare il nuovo computer dopo la morte di quello vecchio, rispondere alle domande sul lavoro futuro e fare stime per quel lavoro, tutorare i giovani, ecc. che devono essere presi in considerazione. È irresponsabile che uno stimatore assuma più di 6 ore su 8 disponibile al giorno. Questa è una garanzia che la scadenza non può essere rispettata. Se stai garantendo che la scadenza non può essere rispettata, stai garantendo un cliente infelice.

Hai assolutamente ragione: è difficile pianificare un progetto senza sapere tutto ciò che accadrà. Ma è molto importante tenere traccia delle cose che sono una norma e dei compiti che prevedi. Ecco dove la gestione della pianificazione gioca un ruolo. Ho utilizzato la gestione dei progetti Microsoft (versione standard) per la quale include anche funzionalità che fanno parte di un software di pianificazione della gestione dei progetti.

È possibile visitare http://www.microsoft.com/project/en/us/schedule-management.aspx per ulteriori informazioni.

Sembra che ci sia un sacco di sforzo nascosto attinto dai tuoi team di progetto attraverso il quale stai perdendo concentrazione e velocità. Potrebbe essere utile separare effettivamente l'attività da affrontare

..supporta problemi e bug e cose?

a un gruppo specifico di persone in modo che gli altri membri del team possano concentrarsi sui nuovi compiti di sviluppo. In questo modo la loro produzione complessiva potrebbe diminuire leggermente, ma la qualità migliorerà perché c'è meno distrazione. Questo in cambio ridurrà il numero di bug, quindi un lavoro ad hoc che si farà strada nei tuoi progetti.

Per quanto riguarda la parte relativa alla pianificazione, concordo pienamente con la risposta di Thomas Owens.