Il lavoro stimato rimanente non si abbassa [duplicato]

È un progetto software, quindi è in corso.

Questa è una risposta un po 'sfacciata, ma questo è un problema molto comune. Dici che ci sono "i requisiti cambiano costantemente in entrata": ecco perché stai superando. Devi assolutamente avere un congelamento dei requisiti o non spedirai mai. Solo con i requisiti congelati puoi rilasciare una data di rilascio.

Il tuo manager deve anche essere consapevole del triangolo di compromesso costo / qualità / caratteristiche. Puoi avere un prodotto perfetto con molte funzioni solo se sei pronto a spenderlo per decenni. Startup e piccole aziende tendono a puntare su un "prodotto minimo vitale", riducendo al minimo tutte e tre le quantità.

Inserisci il foglio di calcolo nel sistema di controllo di revisione. Non importa se è binario e indifferente, l'importante è tenere traccia delle modifiche. Quindi puoi estrapolare il foglio di calcolo di tre settimane fa e sottolineare che hai lavorato per tre settimane e ridotto il tempo previsto di tre settimane, ma il foglio di lavoro di oggi ha aggiunto altre quattro settimane di funzionalità!

La correzione degli errori di per sé di solito mostra delle carenze nelle specifiche. Tu hai per giudicare i bug e concentrarti sulla riduzione al minimo dei rischi per l'utente. È utile se il tuo software può fallire con garbo e riprovare, ma questa opzione non è disponibile per i bug di sicurezza.

Ciò che senti è chiamato

funzione di scorrimento

IlsitoDilberthauna bella raccolta su questo argomento .

Now, my suggestion at the beginning was to: 1: Set priorities for all the features.

Avrei proposto lo stesso.

This didn't work out well, since about 70% of the features got priority 1, all the others got priority 2. And the verdict was: all features must be included in the first release.

Il proprietario del tuo prodotto o l'equivalente di esso è debole o ha un conflitto di interessi con il cliente. A meno che le risorse disponibili da parte tua non siano adeguatamente dimensionate, questo non accadrà dall'inizio. Soprattutto sapendo che nei progetti tipici ci sarà (e dovrebbe) essere un feedback, e di conseguenza ci saranno dei cambiamenti Questo è un dato di fatto.

Ciò che trasforma in un problema è il fatto, che nessuno nella tua squadra sembra avere le palle (o forse l'autorità) per dirgli, che questo non funzionerà.

1. Dati presenti . Raccogliere dati su caratteristiche e stime in varie fasi del progetto. Disegna un grafico di burndown . Prova a fare delle previsioni. Puoi anche provare a utilizzare Pianificazione basata sull'evidenza .

2. Versioni minori Proponi di rilasciare il prodotto in più punti cardine più piccoli anziché in una versione di grandi dimensioni. Cerca di ottenere un consenso su cosa dovrebbe essere parte di ogni rilascio. Per raggiungere questo obiettivo, le persone dovranno dare la priorità ai loro desideri. Spiega loro che questa è una buona cosa per entrambe le parti.

3. Ottieni back . Se il PO o l'equivalente di esso è il problema, prova a trovare qualcun altro nella tua azienda, con l'autorizzazione necessaria, per darti un po 'di sostegno. Spiega il problema come sopra e illustra le tue idee. Spiega chiaramente che vuoi che il progetto diventi un successo, ma sei preoccupato per come va. Quindi chiedi consiglio.

La chiave è farli realizzare, che il giorno ha solo 24 ore e le risorse sono limitate, mentre le caratteristiche non lo sono. Se vogliono più funzioni, vanno bene, ma dovranno pagarle. Principalmente soldi, ma in una certa misura anche il tempo.

Alla fine, è uno sforzo di squadra e l'obiettivo è il successo del progetto. L'obiettivo non è quello di affondare migliaia di dollari solo per risolvere definitivamente la colpa. Questo non aiuta nessuno.

Sono un po 'preoccupato che sia il program manager, non il marketing, che aggiunge continuamente nuove funzionalità. Ma in un certo senso, questo non è il tuo problema.

Ogni volta che il manager presenta una nuova richiesta di funzionalità, prova a stimare non solo quanto tempo ci vorrà per programmare, ma aggiungi un margine generoso per il bug fixing e il test di reversione causato dal cambiamento. Aneddoto: alcuni anni fa, il mio direttore del programma mi chiedeva regolarmente di stimare il tempo necessario per aggiungere funzionalità. Qualche tempo dopo, mi ha detto che ha sempre raddoppiato ogni stima che gli ho dato. Stavo solo guardando quanto tempo ci sarebbe voluto per progettare e programmare, non per quanto tempo ci sarebbe voluto per integrare, testare e fare il debug.

Se non lo stai già facendo, crea un database con tutti i bug conosciuti. Per ogni bug, tieni traccia di quanto tempo ci è voluto per risolvere. Controlla come il numero di bug diminuisce nel tempo. Da questi due bit di informazioni, dovresti essere in grado di calcolare quanto tempo ci vorrà prima che il numero di bug in sospeso sia banalmente basso.

Se il numero di bug non diminuisce sensibilmente nel tempo, allora è così pieno di bug che non è neanche lontanamente pronto per la spedizione.

In qualche modo questo è il tuo fallimento per non "gestire correttamente il cliente". Dici che hanno aspettative irragionevoli e questo è il nocciolo del problema.

La maggior parte delle aziende e le persone non hanno problemi a spendere soldi se pensano che ne traggano valore. Nella maggior parte dei casi questo è limitato dal budget, ma una società spenderà $ 2.000 se pensano che ci sia valore e bawk oltre $ 2 quando pensano che non ci sia. Questo è giusto, ed è come dovrebbe funzionare.

Ora per correggere il tuo problema, la tua necessità di fare alcune cose.

In primo luogo soffia il tuo corno un po '. Elenca tutte le caratteristiche che hai fatto e mostrale. Fai sapere al cliente che il tempo e il denaro spesi hanno un valore. Se possono vedere il valore saranno più felici con i tempi.

Secondo, finisci i tuoi compiti in tempo. Il tuo non riuscire a farlo. Con buona causa, intendiamoci, ma è comunque un fallimento. Se dovessi fare un widget entro mercoledì, finisci il widget entro mercoledì. Se hai finito con il widget di martedì, il segno è finito. Quando il cliente torna e dice "hai dimenticato di implementare questa funzione di cui non ti abbiamo parlato", quindi tracciala come una cosa nuova e incollare una nuova data su di essa. La parte importante qui è mostrare che stai facendo ciò che dici che verrà fatto quando dici che lo farai. È tutta percezione, ma non mettendo un vicino (o altro) in quella colonna, il tuo aspetto negativo.

Terzo, prova a cambiare le parole usate. Provo ad usare "problema" e "errore". Gli errori sono cose che producono codici di errore. E se ne hai molti di questi, allora scrivi il tuo brutto codice. I problemi sono tutto il resto. Questo consente "hai dimenticato di implementare una funzione di cui non ti abbiamo parlato", per essere un problema e non un bug. Dà ancora importanza, ma non sembra un brutto codice.

Principalmente quello che hai qui è un fallimento della percezione. Il tuo non è riuscito a impostare le aspettative e ora è necessario tornare indietro e farlo. Questo può essere abbastanza difficile, ma gratificante. Fai attenzione a stabilire aspettative che puoi incontrare. E tieni presente che il cliente non vorrà spostare alcune delle sue aspettative dopo tanto tempo. Considerare anche l'assunzione di qualcuno esterno al progetto per fare una revisione del codice o qualcosa del genere. Avere una revisione di terze parti di solito aiuta la situazione. Ha i suoi difetti, ma se hai scritto un buon codice, avere una terza parte d'accordo e dichiararlo così, aiuterà il cliente a sentirsi meglio riguardo alla situazione.

Penso che la maggior parte delle persone nello sviluppo del software prima o poi passerà attraverso un progetto come quello che descrivi. La cosa buona che posso dirti: imparerai molto. Una volta percorsa la strada difficile, vedrai le cose in modo diverso e il tuo prossimo progetto sarà già migliore.

Ecco alcuni pensieri su cosa puoi fare ora:

• Sembra che il tuo project manager abbia un background aziendale e nessuna esperienza con i progetti software. (Queste persone pensano che la programmazione sia lo stesso tipo di lavoro come, ad esempio, il caricamento di pacchi su un camion.) Siediti con lui e spiega che non esistono "codice senza bug" o "copertura di prova del 100%". Spiega anche che la stima nello sviluppo del software non è facile, perché a differenza del lavoratore del camion, devi spesso stimare qualcosa che non hai mai fatto prima.

• Devi interrompere la funzionalità creep o non sarai mai pronto. Spiega che ogni nuova funzionalità rallenterà anche lo sviluppo delle altre funzionalità, dal momento che hai dipendenze complesse (credo che sia il caso del tuo sistema)

• Il tuo project manager deve chiarire cosa è più importante: la data di rilascio o un set completo di funzionalità? Ho vissuto entrambe le situazioni, a seconda del settore. Ma devi chiarire che questa decisione deve essere presa.

• Se le persone non sono disposte a dare priorità, fatele da soli. Naturalmente sarebbe molto meglio se le priorità venissero dai "proprietari di prodotti", ma nella mia esperienza è meglio dare priorità a se stessi che non avere priorità (70% di priorità 1 è praticamente uguale a "nessuna priorità"). a tutti ")

• Devi includere un buffer nelle tue stime per la correzione dei bug, ecc. Certo, non sai quali saranno i bug, ma sai che alcuni errori si verificheranno di sicuro. Per la tua scheda Excel di stima, assicurati di includere tutto che consuma del tempo, diciamo: sviluppo delle caratteristiche (questo è ciò che hai già), riunioni, correzione dei bug, testing, lavoro di rilascio / distribuzione, amministrazione del sistema (se necessario), ferie, congedi per malattia, conferenze telefoniche, oltre a: un buffer per errori di stima

• Prendi un libro sulla gestione dei progetti software (ad esempio, qualcosa su Agile o "Ship It" dei Pragmatic Programmers è buono per l'inizio). Questo è più a lungo termine

Ho avuto un manager che mi è piaciuto che descrivesse un progetto come "spingere un muro in avanti". Cioè, per la maggior parte del progetto c'è un intervallo quasi travolgente di compiti che devi portare avanti più o meno alla stessa velocità - come spingere un muro.

Ma a un certo punto, direbbe, hai raggiunto una soglia critica, e poi il muro scomparirà, e il gioco è fatto.

L'ho anche sentito nel senso di "convergente" e "divergente". Divergente significa che l'ambito del progetto si sta espandendo e che la convergenza significa che l'ambito si sta riducendo e restringendo. È un processo naturale per i progetti: potresti trovare qualche documento che lo descriva online.

Una cosa a cui prestare attenzione è che convergenza e divergenza sono anche uno stile di conversazione personale - ad alcune persone in conversazione piace pensare sempre più in generale, inserire più idee correlate e l'odio sistemarsi sulle risposte. I convergenti sono il contrario: a loro piace mettere insieme idee, riassumere e trovare risposte chiare. Convergenti e divergenti, come ci si potrebbe aspettare, possono impazzire l'un l'altro.

Quindi potresti stare attento che tu abbia un divergente da qualche parte nella definizione del progetto, che è insoddisfatto di avere una risposta. Oltre a questo, potrebbe essere che sei ancora nel processo naturale di scoprire il lavoro necessario - prima di raggiungere il punto di crossover in cui tutto inizia a concludersi.

È necessario bloccare su una serie di requisiti su cui si lavorerà e fornire l'ETA per esso e contare il tempo per i bug e un po 'di tempo di buffer aggiuntivo durante l'assegnazione dell'ETA. Eventuali modifiche che si verificano dopo il rilascio del set di requisiti che hai bloccato o dovrebbero andare al gestore che richiederebbe quindi di dare la priorità e dare un nuovo ETA.