Responsabile del progetto che desidera bloccare la stima del tempo con un contratto firmato

In un precedente impiego, un project manager (PM) non era soddisfatto dei tempi di consegna del codice su un progetto in cui mi trovavo. Mi è stato detto dal mio capo del progetto che il Primo Ministro stava prendendo in considerazione l'idea di farmi firmare un contratto per bloccare le mie stime di tempo che avevo dato per le attività e le date di consegna.

La situazione del progetto era che stavamo lavorando con nuove tecnologie, base di codice, standard di codifica e requisiti molto inclini al cambiamento. Stavo imparando cose nuove e applicandole il meglio che potevo sui requisiti che continuavano a cambiare. I requisiti durante le iterazioni sono cresciuti di 2-3 volte, con la stima da completare a crescere di circa 5-8 volte. Le uniche cose che non sono cambiate sono state le stime e le date di consegna.

Sì, alla fine ho perso la maggior parte delle scadenze. E stavo lavorando su alcune nuovissime tecnologie sulle quali nessun altro membro dell'intero team di sviluppo poteva davvero dare una mano perché non ne avevano familiarità. Almeno non facilmente.

Allora mi è sembrato che il Primo Ministro volesse sommare i suoi numeri, e quindi voleva che firmassi un contratto per "garantire" che avrei sempre consegnato il codice di lavoro in tempo. Suppongo che con un contratto firmato il PM potrebbe usarlo contro di me se non potessi consegnare in tempo.

Credo che quello che è successo dopo è stato che altri project manager e / o project leader mi hanno difeso, e non hanno permesso che ciò accadesse.

La mia domanda è: questo dovrebbe sollevare una bandiera rossa sul manager? È prassi comune per un manager bloccare le stime dei tempi di uno sviluppatore di software con un contratto firmato? O in questo caso, prova a.

Nota, ero un dipendente a tempo pieno, non un consulente indipendente.

Aggiornamento : voglio aggiungere che ho dato nuove stime settimanalmente, ma sembra che le stime originali e le date di consegna siano state fissate sul PM.

La mia domanda è: questo dovrebbe sollevare una bandiera rossa sul manager?

Sì . Significa che è tempo di aggiornare il tuo curriculum / CV e iniziare a cercare un nuovo lavoro. Oppure significa che il tuo manager sta per iniziare a giocare ad alcuni giochi molto cattivi con te.

È prassi comune per un manager bloccare le stime dei tempi di uno sviluppatore di software con un contratto firmato?

Non ho mai sentito parlare di questo essere applicato a un dipendente.

La stima del tempo e dello sforzo è sempre difficile. Soprattutto perché la nostra professione è piena di eccessivo ottimismo. Ci sono alcuni sistemi di stima che potrebbero aiutare con le stime in futuro, ma hanno bisogno di raccogliere statistiche storiche da te stesso. Uno è PSP . Un altro è Punti funzione . A molti sviluppatori non piace nessuno dei due e troverai opinioni molto forti su entrambi.

La principale difficoltà nella stima dei tempi e degli sforzi è la mancanza di feedback nella nostra euristica di stima. Una delle chiavi è scrivere ciò che pensi sia la stima e quali parametri hai usato per stimarla. Quindi, in base a ciò che effettivamente fai, confrontalo con quello che pensavi di fare. E usalo per modificare i parametri di stima. In ingegneria, chiamiamo questo " feedback ".

Sì, dovrebbe assolutamente suonare un campanello d'allarme.

Se fossi stato nella posizione, per il mio intrattenimento personale, avrei chiesto al gestore di firmare un contratto che congelasse tutti i requisiti. Immagino che il manager probabilmente salverebbe. Poi me ne andrei.

Bene questo è semplice. Devi solo dire al tuo manager che firmerai per bloccare il tuo tempo stimato quando firmerà per bloccare le specifiche. Perché non puoi, di sicuro fornire eventuali stime per qualcosa che è sconosciuto. Specifiche complete del progetto prima di iniziare, nessuna modifica - e puoi finirlo in tempo :)

Una modifica al contratto spec => è nulla. Probabilmente la cosa sarà nulla dopo 10 minuti il ​​tuo primo giorno :)

Sì, questa è una bandiera rossa. Ciò che ti dice è che il gestore non capisce come gestire i rischi nei progetti software. Quello che dovrebbe fare è capire cosa ha causato esattamente il ritardo in primo luogo e quindi iniziare a strumentare un processo per gestire efficacemente i rischi di pianificazione che inevitabilmente si verificano durante un progetto software.

MAI in nessun caso firmerei un contratto con il mio manager che garantisca un programma. Altri hanno menzionato di avergli fatto firmare un blocco sulle specifiche. Questo secondo me non è sufficiente. Ciò non tiene conto di difficoltà impreviste con gli strumenti o la tecnologia, la progettazione incompleta o scadente, le prestazioni degli altri membri del team, ecc.

Questa non è una bandiera rossa, questa è stupidità di livello militare.

Se le stime e le scadenze vengono costantemente saltate, la cosa razionale da fare è identificare le cause e migliorare i processi.

Se dai la colpa e dai un calcio al cavallo perché non sai dove stai andando, non stupirti se il cavallo ti morde e scappa!

Mentre il direttore era in linea con la sua richiesta. Non è completamente da biasimare. Se lavoravi in ​​un territorio completamente sconosciuto, non c'è niente di sbagliato nel dire "Non lo so". Mi ci è voluto un po 'di tempo per capire che "Non lo so" è una risposta perfettamente accettabile, quindi so quanto pungi pronunciare quelle parole. Ma se davvero non lo sai, questa è la risposta. E se si oppongono a quello chiedono loro di darti una stima di quanti penny ci vorranno per fare una pila alta quanto la Sears (rendila Willis) Tower. E sarebbero disposti a firmare un contratto pagandoti ogni centesimo che avevano spento?

Qualsiasi Project Manager degno del suo stipendio dovrebbe sapere che alcune cose non si adattano bene a un foglio di calcolo. A volte le cose sono fatte quando sono fatte. Penso che tu stia andando bene facendo progressi su quanto hai fatto. Basta smettere di dare gli aggiornamenti numerici.

Un altro esercizio è quello di suddividere il grande compito in unità più piccole e più stimabili. Questo esercizio ti aiuterà a capire meglio anche quello che devi fare. Scopri di Steve McConnell Stima del software e di Stephen Withall Requisiti software Patterns per suggerimenti su come abbattere i compiti e scoprire esigenze nascoste, rispettivamente.

Non sparare dall'anca su un preventivo. Prenditi il ​​tempo per scomporlo. Stimare un gran numero di piccole attività ti darà una migliore stima complessiva (a causa della legge delle medie alcune delle tue stime saranno sotto ma alcune saranno finite e tenderanno a pesarsi) del grande compito.

Chiedi al tuo "project manager": stiamo vendendo software o scadenze?

Sono un project manager e un programmatore :-) Potrei andare avanti a lungo su come la maggior parte dei PM provengono dall'esterno del settore e non riesco a gestire tutto ciò che non si adatta bene a un modello di linea di produzione ... ma io no, non qui. Invece ecco una lunga polemica su cosa fare realmente (Mr Mod, se è troppo lungo fai quello che vuoi con esso). Sono d'accordo con i commenti già fatti qui, alcuni che dovresti fare prima di altri, ma ecco cosa penso che sarebbe stata la tua prima mossa . Oh, e la risposta ovvia alla tua domanda è sì, ma è elaborato in un linguaggio colorato e dettagliato di seguito.

Prima di iniziare, però, nota che molto probabilmente il Primo Ministro ti sta dando dolore, perché qualcun altro più in alto nella catena alimentare sta dando loro dolore. Loro (noi) sono creature semplici ... Ci sono modi per evitare la situazione che hai descritto - Mike Brown lo copre abbastanza bene. Inoltre, non c'è niente di sbagliato nello spostare qualcosa per 3/4/5 .. ore prima di attivarlo (in realtà tutti i tipi di allarmi devono spegnersi se ciò non accade). E se stai andando in un territorio sconosciuto, fai un passo indietro e chiedi una settimana di ricerche sull'area e sulle tecnologie per essere in grado di fare una stima ragionevole (ti consigliamo di farlo correttamente perché vuoi che le nuove tecnologie imparino e giochino con don tu?). Se il tuo PM e la direzione del luogo in cui ti trovi non lo capiscono ... quindi aggiorna il tuo curriculum e cerca l'uscita più vicina, lasciandoli al destino che meritano così tanto. Che il Primo Ministro avrebbe persino pensato di ottenere un dipendente a tempo pieno per firmare un contratto del genere è un brutto segno negativo ... l'unico modo in cui ho potuto vedere che loropotrebbe non essere del tutto incompetente il fatto che stessero davvero giocando a giochi mentali con il capo del tuo progetto e tu (da quello che ho letto non te lo hanno messo direttamente e alla fine non hanno seguito la minaccia). Dopotutto, il PMing è un paradiso per il tuo psicopatico aziendale standard. È stato positivo che gli altri ti abbiano preso in giro per quello che hai detto, quindi i consigli qui sotto sarebbero probabilmente risultati positivi per te alla fine. Immagino che avrebbero avuto una rivoluzione nelle loro mani se si fosse rivelato più che parlare.

Quindi alla situazione / buco che hai descritto , perché accadrà di nuovo a qualcuno, da qualche parte (come circa 5 minuti fa, e di nuovo in altri 5, scheduleRepeat ()). Probabilmente senza la stupidità del contratto, ma la trama di base è sempre la stessa. Organizza un incontro (!), A loro piacciono gli incontri ;-) Alla fine tutti possono darsi una pacca sulla spalla come se fosse stato fatto qualcosa. IMPORTANTE:Assicurati di includere il capo del progetto tecnico / il caposquadra / l'architetto / il responsabile della progettazione nell'invito alla riunione che ha già esaminato il problema con loro e li ha inseriti a bordo. Più in alto nella gerarchia puoi scegliere qualcuno dalla tua parte, meglio è. Perché il tuo PM lo vedrà e proverà ad abbinare il tuo design manager con un equivalente. In caso contrario, sono stupidi e hai già vinto. Questo di per sé generalmente li rimetterà in linea, perché ora sono visibili a qualcuno che probabilmente li può licenziare sul posto. Se stanno giocando con te, puoi restituire il favore.

Durante l'incontro, esamina i dettagli tecnici di ciò che stai trattando e del perché impiega il tempo necessario. Dovrebbero volerlo sapere (e come possono aiutarti a farlo), ma il fatto triste è che generalmente non succede ... probabilmente avrai 10 minuti prima che i loro occhi tornino nella loro testa. Ora quello che vorrei fare qui probabilmente non è legale ... sì, ho controllato, in realtà è altamente illegale e non vuoi andare in prigione per così tanto tempo. Il punto è che hai fatto del tuo meglio per essere proattivo e se hai dei superiori, il tuo dolore è ora loro ... come dovrebbe essere. Dovrai usare il tuo giudizio su come potrebbero andare le cose, perché "l'escalation" è ciò che accadrà. Se la leadership nel posto in cui ti trovi è per metà decente, faranno la cosa giusta, e fai la cosa giusta anche per te. In caso contrario, avresti avuto il tuo curriculum in anticipo sul mercato ... avresti comunque lasciato alla prima opportunità (e sembra che alla fine lo hai fatto). La leadership si dividerà in due gruppi: o sono tecnicamente esperti e vedranno immediatamente il tuo punto di vista; o non lo sono e cosa faranno al di fuori del sorriso e sopportarlo? Se potessero fare quello che fai, lo farebbero già. te cosa faranno al di fuori del sorriso e del sopportarlo? Se potessero fare quello che fai, lo farebbero già. te cosa faranno al di fuori del sorriso e del sopportarlo? Se potessero fare quello che fai, lo farebbero già.

Mantieni il problema dei requisiti mutevoli come la tua carta vincente da usare alla fine ... servirà come uscita per tutti. Il progetto stesso e il maledetto cliente / stakeholder avranno il loro nome preso invano. Il modo più indolore per procedere sarebbe una sorta di reset sul progetto, e forse quel PM sarebbe stato riassegnato tranquillamente a un'area diversa. I miracoli accadono di tanto in tanto. Se il problema del contratto è stato sollevato durante la riunione dal Primo Ministro, ha risposto con i requisiti congelando la domanda di contro-contratto - per quanto mi riguarda hanno già bruciato i loro ponti con te e con l'intero team di sviluppo, quando hanno iniziato giocando a quei tipi di giochi mentali.

Prima di firmare: Cambiare ambito / requisiti - uno dei migliori motivi per adottare la metodologia Agile, quindi i clienti / le parti interessate sono adeguatamente responsabili di cambiare idea su ciò che vogliono ...

Oh, un'altra cosa: sull'affermazione "Non lo so", è sempre stato il mio punto di riferimento personale su come valutare il valore di un collega tecnologo o membro in uno dei miei team di progetto. Trovo le uniche persone che sono in grado di dire che direttamente sul tuo viso sono le migliori che ci siano, principalmente perché qualcuno che sa di essere fuori dalla profondità non lo dirà mai - le apre ad essere chiaramente esposto da qualcuno con abilità reali in un battito cardiaco. D'altra parte, qualcuno che si schiererà e lo dirà, avrà anche un piano di base (anche se non è stato pensato attraverso) su come affrontare le incognite in modo che tra 24 ore ci sia una risposta più utile, e in una settimana ancora migliore. Quando Apollo 13 stava volando intorno al lato oscuro della Luna, ci sono stati un sacco di eventi "Non lo so".

Sì, questo dovrebbe sollevare una bandiera rossa, soprattutto se sei un dipendente a tempo pieno. Quali erano le condizioni del contratto? Saresti effettivamente licenziato se avessi mancato le scadenze? O ti perderesti un bonus? Cosa farebbero?

La bandiera che questo solleva è che il manager non ha idea di come gestire un progetto che si occupa di tecnologie nuove / non familiari e che sposta i requisiti che incidono direttamente sullo sforzo stimato. Mentre a volte si verificano scadenze rigide, un manager che conosce la situazione non dovrebbe cercare di convincere i dipendenti a firmare contratti per farli rispettare. Le ore tardive e i periodi di crisi saranno male, ma è probabilmente la norma. E ancora a volte la scadenza scade. Succede, e come è stato pubblicato da qualcun altro, l'unico modo per attenersi al programma è congelare i requisiti PRESTO SU in modo che ci sia ancora abbastanza spazio per mantenere la sequenza temporale.

Da quello che hai detto, le campane di allarme sono in ritardo di qualche mese. Normalmente è rischioso basare un progetto sensibile al tempo su tecnologie che il personale non conosce già. È insensato farlo se non si ha la conoscenza della raccolta dei requisiti e della gestione dell'ambito.

Detto questo, sono d'accordo con le altre risposte. Inoltre, potresti voler aggiornare il tuo curriculum se non l'hai già fatto.

Proprio come tutti gli altri intervistati, non potrei essere più d'accordo sul fatto che questo dovrebbe sollevare una bandiera rossa.

Sembra che il PM non voglia essere coinvolto nel processo di sviluppo.

Nella mia pratica personale mi sono allontanato da molto tempo dal trattare con specifiche anticipate dettagliate, firme, stima completa del progetto o prezzi a offerta fissa (dal punto di vista della consulenza).

La ragione di ciò è la realizzazione, di cui parlano molti guru di Agile e Lean Software, che il software non è un'entità fabbricabile fissa, ma è principalmente un processo di scoperta.

Molte persone hanno ancora problemi con questa nozione, e sembra che anche il tuo PM lo abbia fatto. Dipende da una semplice comprensione dei compromessi.

Specifiche rigide e stime fisse funzionano per sistemi in cui il costo del cambiamento è elevato. Come costruire un grattacielo. Se hai dimenticato di specificare i pozzi degli ascensori in avanti, sarà davvero difficile adeguare l'edificio una volta che è stato eretto. L'elevato costo del cambiamento richiede molta pianificazione iniziale, apprendimento delle incognite di componenti e tecnologie e sperimentazione iniziale. Solo una volta che hai fatto tutti questi compiti, puoi stimare budget e costi.

Nel software le persone si sono abituate molto all'idea che il costo del cambiamento è basso e quindi amano trarre vantaggio dal fatto di poter cambiare le cose una volta che vedono un rilascio, incorporare una nuova comprensione dell'applicazione, del business, del cliente su una base permanente. Tutto questo è buono e un'enorme opportunità se sfruttato correttamente. La maggior parte delle persone di software con cui ho incontrato e con cui ho lavorato in realtà non ama passare molto tempo a pianificare o investigare; la maggior parte di noi (inclusi i PM) desidera vedere una trazione continua. È qui che è nato lo sviluppo iterativo con le sue piccole versioni incrementali di funzionalità. Esistono altre pratiche che possono essere utilizzate, come lo sviluppo guidato dai test per garantire che il costo del cambiamento rimanga basso e che il debito tecnico sia contenuto.

Fare questo lavoro implica un "contratto" tra le due parti, il proprietario del prodotto (Agile parla per il tuo PM o clienti o team di controllo qualità) e gli sviluppatori. Gli sviluppatori concordano di lavorare solo su elementi a cui è stata data la priorità più importante per la data iterazione e di non occuparsene per sempre, ma si sforzano di rilasciare blocchi di funzionalità completamente integrati frequentemente (ad esempio settimanalmente o mensilmente). I proprietari dei prodotti, al contrario, accettano di rivedere continuamente le versioni incrementali e di fornire un feedback tempestivo. Accettano inoltre di stabilire le priorità per la prossima iterazione e una volta impostate per non cambiare idea per la durata dell'iterazione.

Quest'ultima parte dell'accordo è qualcosa che il tuo PM probabilmente non capisce. Molti PM tradizionali in realtà non lo fanno. Alcuni di loro pensano che il loro lavoro sia finito quando abbandonano le specifiche; non vogliono conoscere problemi, alternative, modi migliori, ecc. Il rovescio della medaglia è che questo non è solo contro il flusso di sviluppo del software, ma danneggia anche l'organizzazione lasciando molte opportunità sul tavolo.

Dai un'occhiata al Manifesto Agile: http://agilemanifesto.org/ Potrebbe risuonare con te. Un buon libro da leggere è anche "Lean Software Development" di Mary Poppendieck

In bocca al lupo.

Sembra che il manager stia cercando qualcuno da incolpare quando riferisce al suo superiore.

Trovo che se hai un manager irragionevole che pensa che una "stima" sia la stessa di un "periodo fisso", la cosa migliore da fare è pensare a un periodo di stima molto generoso e poi raddoppiarlo!

Inoltre, forzare il manager a garantire che i requisiti siano completamente dettagliati e fissi. Eventuali modifiche da quel momento in poi non verranno affrontate senza una "rinegoziazione formale" con il project manager del nuovo tempo di completamento.

Alla fine il project manager ottiene l'idea e pianifica di conseguenza.

La mia esperienza personale con questo genere di cose è che il project manager sta cercando di creare una scia di carta per sbarazzarti di te rendendo la tua risoluzione colpa tua. Ciò renderebbe una bandiera molto rossa. Il chilometraggio può ovviamente variare leggermente.

Buone risposte, ma lasciami aggiungere i miei 2 centesimi.

Se studi la probabilità, esiste una "variabile casuale". Questo è un numero di cui non conosci il valore, ma puoi descrivere il tuo non sapere con una distribuzione, come una normale distribuzione (curva a campana) o un'altra.

Il punto è che il lavoro richiederà un certo periodo di tempo, ma qualsiasi stima precedente sarà errata, di un po 'o molto, sul lato negativo o positivo, quindi c'è il rischio e qualcuno deve assumersi il rischio. Generalmente, se le persone corrono rischi, vengono pagate per questo. L'assicurazione costa denaro.

Quando ero un consulente, di solito avevo la possibilità di firmare un contratto di tempo e materiali rispetto a un contratto a prezzo fisso. Con tempi e materiali il cliente si assume il rischio. Con il prezzo fisso, sopporto il rischio. Con il prezzo fisso, costruisco un margine di sicurezza, perché se non riesco a raggiungere l'obiettivo, nessuno vince.

Chiederti di impegnarti a una data di consegna fissa, soprattutto senza requisiti fissi, sembra come provare a trasferire il rischio a te, anche se non è chiaro cosa stai effettivamente rischiando. In ogni caso, una risposta è semplicemente quella di mettere un margine di sicurezza davvero generoso.

PS Lo vedi sempre con contratti governativi. C'è una richiesta iniziale per le proposte, le offerte vengono fatte, viene accettata un'offerta bassa e quindi iniziano le richieste di modifica, quindi i palloncini dei costi e l'appaltatore vengono incolpati. Le cose funzionano molto meglio se esiste una relazione di lavoro di squadra tra cliente e appaltatore, piuttosto che una contraddittoria.

Sì, ovviamente questo solleva una bandiera sull'esperienza e la competenza del tuo ex capo. Sì, come suggerito dalla maggior parte delle persone, sarebbe un buon momento per aggiornare il tuo CV.

Sì, come affermano le altre risposte, nella maggior parte dei casi non vorrai firmare tale accordo. Tuttavia, voglio suggerire che potrebbero esserci alcune situazioni in cui potresti prendere in considerazione l'idea di firmarlo.

La maggior parte degli sviluppatori e dei manager sono consapevoli del costante attrito tra funzionalità, scadenza e budget. Molti nominerebbero anche la qualità come quarta dimensione ("Sono in grado di soddisfare qualsiasi serie di requisiti desiderati, entro domani per un budget ridotto, purché tu sia disposto ad accettare che non funzionerà!")

Ma c'è ancora un'altra dimensione: il rischio. Se devo solo consegnare con successo il 50% delle volte, posso abbassare immensamente le mie stime; sono imbottiti per gestire un tasso di consegna molto più elevato.

Siamo in grado di affrontare il rischio in vari modi (e le stime del riempimento sono uno di questi). Il gestore non è disposto ad accettare alcun rischio e desidera metterlo a rischio. Normalmente, dovresti rifiutare una simile mossa ... a meno che tu non sia ben ricompensato.

Se sei in grado di nominare la tua scadenza, con una quantità reciprocamente accettabile di riempimento per far fronte a ritardi imprevisti, e sei in grado di negoziare un bonus (molto grande) se lo colpisci, e sei in una posizione finanziaria per essere in grado di gestire il penalità (es. licenziamento) se non ci riesci, potresti scoprire che vale la pena "accettare" quel rischio e firmare il contratto - con clausole adeguate per gestire le modifiche ai requisiti.

Questa è una stupidità diretta. Non so quale fosse l'obiettivo finale, ma ogni project manager a metà decente responsabile dei prodotti software dovrebbe essere consapevole che le stime sono esattamente quelle che vengono chiamate: stime. Non sono promesse e non possono essere fatte senza svuotare lo sviluppatore di software di tutta la loro energia o costringerli a mantenere la loro "promessa" comunque.

Se vuoi dimostrare quanto sia ridicolo un contratto del genere, ecco due suggerimenti:

a) Altamente sopravvalutato al punto in cui il progetto impiega cinque o dieci volte il tempo che si stimerebbe senza un contratto. Se il responsabile del progetto chiede perché le stime sono così alte, dite semplicemente che vi state solo assicurando di poter adempiere al vostro contratto.

b) Questo è già stato suggerito: chiedi un contratto che assicuri che non cambi un singolo requisito e assicurati che ciò includa la correzione degli errori di ortografia. Nella mia esperienza non esiste un singolo progetto software in cui i requisiti non cambiano ad un certo punto durante lo sviluppo. È più probabile che il project manager debba rompere il contratto di te.

Se il project manager accettasse qualcuno di questi due suggerimenti, sapresti per certo che sono fuori di testa.

A proposito, come funzionerebbe comunque un contratto per un dipendente a tempo pieno? Non conosco le normative sul lavoro in altri paesi, ma come dipendente a tempo pieno in un'azienda non credo che qualcuno potrebbe costringerti a firmare un contratto vincolante per rispettare una scadenza e avere un caso valido. Certo, potrebbero darti un inferno se non rispetti la scadenza, ma non hanno bisogno di un contratto per quello. Nessuno potrebbe licenziarti o darti meno soldi. Potrebbero tagliare il bonus concordato nel peggiore dei casi. Quindi, a meno che non sia diverso in altri paesi, questo sembra più una minaccia vuota che qualsiasi cosa che dovresti prendere sul serio.

Ho intenzione di andare contro il grano qui.

La situazione che descrivi non è poi così insolita a livello di team di ingegneri , specialmente dopo un progetto / rilascio particolarmente tardivo. In molte situazioni, la direzione e l'intera organizzazione potrebbero in effetti essersi registrati per una data di rilascio specifica e altre parti dell'organizzazione saranno adattate per tale data. Può esserci un'enorme pressione sulla catena di gestione per raggiungere quella data.

È qui che entra in gioco un processo di ingegneria generale. Probabilmente hai sentito parlare del modello a cascata. Esistono altri modelli, ma l'obiettivo finale di tutti è quello di consegnare costantemente qualcosa quando è previsto e contenere ciò che è stato concordato. Specifiche funzionali, progetti, elenchi di attività, ecc. Contribuiscono a rendere questo processo prevedibile. La comunicazione, l'analisi dei rischi e (come hai detto) aggiornando regolarmente le aspettative sulla pianificazione riducono le sorprese e rendono disponibili le informazioni il prima possibile in modo da poter adattare i piani. E sì, ci dovrebbero essere aggiustamenti al piano ogni volta che vengono aggiunte o rimosse funzionalità.

In alcune delle squadre con cui ho lavorato, non esiterei a trattare le mie stime come impegni firmati, ma ciò riflette la qualità delle squadre e della direzione, e non una particolare abilità nella stima. Una squadra che è disposta a firmare un contratto per la consegna in tempo è un indicatore di una squadra ben funzionante, non una bandiera rossa.

Dico mettiti nei suoi panni e cerca di capire cosa l'ha motivato. Dal potenziale manager / contabile hanno bisogno di un numero per giustificare ciò che sta accadendo e come stanno andando le cose.

Potrebbe essere che essere ridicolizzato nella sala riunioni per aver spostato le scadenze, mancando troppe scadenze, ha provato il modo più semplice possibile per bloccarle. Dammi un numero e firma qui! Essendo dall'altra parte, avresti potuto solo percepire che è qualcosa contro di te. Tuttavia, fare stime e continuare a rendersi conto che devono essere adeguati è ciò che gli è più utile. Se capisci cosa ha motivato la richiesta e qual è il vero problema che sta affrontando, potresti essere in grado di aiutare lui e te stesso. Come programmatori risolviamo i problemi. Questo non è diverso, capire e risolvere il suo problema e sarà il tuo migliore amico. C'è così tanto lavoro da fare che nessuno ha il tempo di tracciare una vendetta personale! Ha bisogno di aiuto con il suo lavoro, la soluzione più semplice era quella di avere qualcuno che firmasse un documento! Probabilmente lo ha ottenuto da un libro di gestione per manichini, "Fai firmare i tuoi lavoratori ed essere responsabile per un numero". Divertente ma triste

"Camminare sull'acqua e sviluppare software da una specifica sono facili se entrambi sono congelati".

-Edward V. Berard

Se le tue esigenze cambiano, è irragionevole aspettarsi che le tue stime iniziali siano accurate. Sì, questa dovrebbe essere una bandiera rossa.

Il contratto prevede una penalità per non aver rispettato la scadenza? In caso contrario, non è affatto un problema: stai semplicemente firmando un preventivo basato sulle tue conoscenze al momento.