Trattare con stime orribili

Un recente progetto a cui ho lavorato si è dimostrato fortemente sottovalutato dall'architetto. La stima era fuori di almeno il 500%.

Purtroppo sono stato coinvolto nel progetto dopo che il preventivo era stato firmato con il cliente. Come senior dev, ho capito rapidamente che le specifiche funzionali e tecniche. conteneva enormi lacune e incertezze.

Di conseguenza, mi sono sentito obbligato a convocare un incontro di emergenza con i direttori tecnici e commerciali per far loro conoscere la realtà. Essendo innanzitutto uno sviluppatore, ho trovato questa situazione molto stressante e difficile. L '"impresa" ha accusato l'IT di essere incompetente e di essere il messaggero che ho ricevuto alcuni "proiettili".

Il cliente ha minacciato di cancellare l'account, tuttavia ad oggi il progetto è ancora incompiuto e non sono più direttamente coinvolto con esso.

L'architetto era un bravo ragazzo socialmente, ma basato su questo episodio era o semplicemente incompetente o c'erano forti pressioni commerciali / commerciali che influenzavano la sua stima.

Quindi, come programmatori, qual è la tua esperienza in questo tipo di situazione e come consiglieresti di affrontarla?

Risposta lunga, ma hey, ho un riepilogo alla fine, quindi salta al riepilogo se non puoi disturbarti a leggere l'intera cosa!

Come sviluppatore ho dovuto affrontare la situazione letteralmente ogni altro progetto, ma è stato solo quando sono passato alla gestione del progetto che ho imparato a gestirlo in modo efficace. Per me trattare in modo efficace riguarda due cose: gestire le aspettative e capire come funziona la stima.

Inizia con una premessa che non è etico fornire una stima, impegnarsi in una stima o fornire qualsiasi altra indicazione dell'accuratezza della stima senza essere in grado di portare prima un po 'di dovuta diligenza. Altre persone si affidano alla tua capacità professionale di prevedere una quantità di lavoro richiesto, fornendo una falsa indicazione farà male a loro e alle loro attività.

Ma devi dare qualcosa, nella vita reale ti sei trascinato in una riunione improvvisata o in un progetto in ritardo e il tuo superiore probabilmente chiarirà che si aspettano che tu arrivi a qualche cifra o commenti la stima che hanno fornito. È qui che entra in gioco la gestione delle aspettative.

Spiega che sarebbe sbagliato da parte tua fornire qualsiasi cifra o indicazione senza capire il problema e calcolare i numeri per te stesso. Dì che le loro cifre potrebbero essere del tutto corrette, semplicemente non lo sai prima di aver svolto tu stesso l'esercizio di stima. E anche se potresti avere una buona immagine di ciò che è necessario lì e quando, dire che hai ancora bisogno di un po 'di tempo per elaborare i numeri. C'è solo una stima che potrebbero aspettarsi che tu dia: quando sarai in grado di fornire una stima. Fornisci sicuramente quella cifra.

Come sviluppatore non assumersi mai la responsabilità (o dare indicazioni che possano essere interpretate come accettazione di) stime di altre persone senza essere in grado di rivederle prima. Come project manager è una questione totalmente diversa, perché in realtà hai un certo controllo sul processo di stima: il modo in cui una stima viene derivata e rivista e devi fare affidamento su altre persone per ottenere il lavoro effettivo e devi fare certo che sono impegnati.

Non commentare mai le stime senza essere in grado di fare la dovuta diligenza. Questo è etico Un avvocato o un medico chiarirà in modo chiaro che non possono dare alcun consiglio a meno che un cliente (o un paziente) non rispetti le loro regole e segua prima una procedura di valutazione. Allo stesso modo hai il diritto di soddisfare le tue domande prima di dare un parere professionale.

La seconda parte riguarda il funzionamento della stima. Suggerisco di ricercare vari approcci per fare stime e come funziona il processo di stima, compresi settori diversi dallo sviluppo del software (produzione, mercati finanziari, edilizia). Questo ti darà un'idea di cosa ci si può ragionevolmente aspettare da te dal tuo capo o cliente e, stranamente, ti aiuterà a fare previsioni più accurate sulla quantità di lavoro. Migliorerà la tua capacità di difendere le tue stime e dovrai difendere le cifre ogni volta che sono diverse da quelle fornite da un architetto o da un addetto alle vendite.

Normalmente, il modo in cui funziona è che la tua stima viene prima scansionata per oggetti dall'aspetto strano o relativamente grandi. Quindi preparatevi a difendere qualsiasi cosa con un nome "non standard". Suddividere anche le attività più grandi in modo che tutte le attività abbiano lo stesso ordine di grandezza, vale a dire se la maggior parte delle attività richiede 2 giorni e una singola attività è 10 giorni, è necessario essere preparati per l'esecuzione.

Sii chiaro su ciò che è incluso in ogni attività, è meglio dividere dev e unit test invece di avere solo dev e far supporre che qualcuno includa anche la documentazione. Ovviamente in questo modo dovrai produrre una stima a grana fine.

Quindi arriva la perforazione. Dal momento che è abbastanza difficile rivedere una lunga interruzione del lavoro, è probabile che il tuo cliente o capo adotti una strategia diversa: concentrarsi su un bit casuale di cui potrebbero conoscere qualcosa e approfondire fino a quando non riescono a screditare l'intero preventivo o saranno soddisfatti del tuo risposte. La credibilità dell'intera stima potrebbe dipendere da un campione casuale! Quindi, ancora una volta, hai bisogno di tempo per prepararlo con cura, includere solo parti rilevanti, escludere eventuali extra o spostarli in una sezione "simpatica" e pensare attraverso come difendere le figure.

Ovviamente puoi essere coerente nel tuo approccio, ovvero stimare sulla base di funzionalità, numero di schermate ecc. O avere un mix di approcci, ma in ogni caso essere pronto a difendere il motivo per cui hai selezionato un determinato modo di stima. Preparati anche a spiegare perché le tue figure sono diverse dal tentativo di chiunque altro di prevedere la quantità di lavoro richiesto.

Scopri i segni evidenti di stime deboli:

• Pieno di attività generali ordinarie, copiate dal modello (buone stime sono specifiche dell'attività a portata di mano).

• Stime a grana grossa (ovvero attività più lunghe di un paio di giorni).

• Stime effettuate nella fase iniziale di un progetto o da qualcuno che potrebbe non avere conoscenza effettiva dei requisiti o del lavoro coinvolti.

• Stime compilate da persone diverse da quelle effettive

• Stime vaghe (non chiaro cosa è incluso e, altrettanto importante, escluso).

• Differenza sostanziale nell'ordine delle dimensioni del compito.

Esercitati nella valutazione delle stime di altre persone e nella perforazione dei dati senza una reale conoscenza dei dettagli di implementazione. Ciò contribuirà a sostenere il reclamo per qualche tempo in più quando viene premuto con la richiesta di confermare la stima di qualcun altro quando non si dispone di prove concrete.

Riassumere:

• Non impegnarti in una valutazione terribile o qualsiasi per quella materia, prima di avere l'opportunità di fare due diligence.

• Metti in chiaro all'inizio, non lasciare che nessuno pensi che sia diversamente e interpreta il tuo silenzio come un segno di accordo.

• Sapere come funzionano vari metodi di stima, la loro applicazione pratica e i loro meriti, compresi questi sviluppi software esterni.

• Preparati a difendere il tuo preventivo.

• Scopri come valutare le stime di altre persone in modo da non doverti impegnare in cifre molto imprecise.

È impossibile prevedere il futuro. Richiedere una previsione ("stima") è semplicemente chiedere problemi. Lo fanno tutti e tutti sbagliano.

Il tuo giudizio di "fuori del 500%" è probabilmente sbagliato quanto la stima dell'architetto. Dopo tutto, "... ad oggi il progetto è ancora incompiuto ..." Non ci sono fatti disponibili qui.

Nessuno conosce la risposta "corretta". E fino a quando non sarà fatto, nessuno lo saprà.

E anche dopo che è stato fatto, la stima "originale" (con o senza controllo delle modifiche) potrebbe non essere correlata con qualsiasi cosa sia stata effettivamente realizzata.

La stima è una trappola - è un gioco truccato. non puoi vincere, non puoi andare in pareggio e non puoi nemmeno uscire dal gioco.

modificare

Gestire stime errate; Una stima "legacy" che appare errata .

Eccolo. Non sei d'accordo con le stime di qualcun altro. O hanno omesso qualcosa che ritieni necessario; avevano un ambito di lavoro diverso da quello che avevi tu, o avevano un tasso di produttività diverso. Inoltre, se la stima è più di un semplice sforzo, hanno una base di costo diversa. Tutto ciò è discutibile. Quindi contestare i dettagli che portano alla stima. Non contestare il numero complessivo: non ci sono informazioni reali in un riepilogo. Contestazione dei singoli dettagli su cui si basa il preventivo. Scopri cosa stavano pensando.

È altrettanto probabile che le tue assunzioni siano sbagliate come le loro assunzioni. Ugualmente probabile.

Quando viene chiesto di stimare .

1. Ti sbaglierai.

   1. Mentono sulla portata del lavoro.

   2. Non conosci la produttività del team.

   3. Qualunque sia la nuova tecnologia coinvolta è stata travisata.

2. Non puoi semplicemente gettare l'imbottitura per coprire queste cose a caso. In realtà non lo sai e non hai una base per "stimare". Sta solo indovinando. Farsene una ragione.

Regola 1: poiché stai solo indovinando, indovina a piccoli incrementi.

La domanda fondamentale in qualsiasi situazione di "stima" non è la previsione del futuro. Non puoi farlo con alcuna precisione per periodi di tempo molto più lunghi di una settimana o due. Limita le tue previsioni a un orizzonte temporale su cui hai una conoscenza dettagliata diretta e immediata. Ad esempio, la prossima versione.

La domanda fondamentale è - di solito - il processo decisionale da parte dei tuoi acquirenti o clienti. La domanda non è "quale sarà il costo?" - è incompleto. La domanda è "ne varrà la pena l'investimento?" La vera domanda è più sulla falsariga di "qual è il rapporto costi / benefici" e "quando dovremmo smettere di spendere perché più investimenti non creeranno più rendimento?" Queste sono le vere domande.

Regola 2: supportare il decisore con informazioni concrete.

Molte persone sono meglio servite da un approccio Agile. La prima versione - tra un mese - richiederà 5 persone × 4 settimane e produrrà la caratteristica X che corregge le perdite di $ 1 milione / giorno e la caratteristica Y che corregge le opportunità mancanti di $ 200.000 / settimana. Hai una conoscenza dettagliata di ciò che stai facendo, quindi questa previsione ha senso. Il rilascio dopo è un po 'confuso.

Il rilascio tra un anno è così lontano in futuro che qualsiasi previsione in un numero casuale. Non sudare i dettagli di qualcosa di più di 6 mesi in futuro, basta usare semplici regole pratiche.

Quando chiedono che cos'è il TCO, devi essere sincero. "Il costo totale si verifica quando smetti di pagare per lo sviluppo. Fino a quando non smetti di pagare, dovrai sempre sostenere i costi."

La vera domanda è "quali problemi stai cercando di risolvere?" o "quale nuova opportunità stai perseguendo?" e "quanto vale?"

Regola 3: rendere il software meno costoso del problema che dovrebbe risolvere.

Se non conosci molto bene il problema, la stima verrà giocata per adattarla alla percezione. Cerca di evitarlo.

Sulla probabilità . Tranne che per malattie o incidenti debilitanti, nessuna parte dello sviluppo del software è governata da reali probabilità. I "rischi" sono semplicemente cattiva gestione. Generalmente nella forma "non abbiamo tenuto conto della complessità del bisogno aziendale A o della tecnologia B". Più spesso del modulo "man mano che imparavamo di più sul problema o sulla tecnologia, abbiamo modificato il programma", che è punito come "creep scope".

Non vi è alcuna probabilità di apprendere cose e cambiare l'ambito. Questa è una certezza.

Sulla pianificazione . C'è "pianificazione" e c'è "stima". Pianificare cosa costruire è una cosa, meglio rappresentata come una lista di controllo o un grafico delle dipendenze. "Stimare" lo sforzo richiesto si basa su fattori inconoscibili.

"Pianificazione" è una buona gestione ordinaria.

La "stima" richiede una conoscenza inconoscibile. Per "stimare lo sforzo" in modo accurato, è necessario disporre di un livello di conoscenza del codice sorgente del prodotto e conoscere la persona che digiterà quel codice sorgente e quali errori farà quell'individuo. Dal momento che non puoi saperlo, qualsiasi stima deve essere errata. E spesso sbaglia il punto di fuorviante e quindi inutile.

Se la stima era fuori del 500% e il progetto continuava, quale valore ha una stima?

Nessuna. Tutto ciò che ha fatto è stato rendere le persone infelici. Ma il progetto è andato avanti comunque.

Dal momento che nessuno può vedere il futuro, ottenere un preventivo giusto non significa nulla. Rendilo utile, aiuta le persone a prendere decisioni.

Tieni l'orizzonte corto. Offri valore il più rapidamente possibile. Crea un piano che consenta al cliente di annullare il progetto in qualsiasi momento e abbia comunque valore.

Non lasciare che il piano diventi l'unica "sacra verità" nel progetto. La funzionalità consegnabile è sacra. Tutto il resto dovrebbe cambiare quando cambiano i risultati finali.

Non lasciare che il piano superi il valore che sta creando.

Se non c'è abbastanza tempo, non c'è abbastanza tempo. Non esiste comunque una soluzione magica per completare il progetto. Secondo me hai fatto quello che potresti affermare. Alla fine hanno dovuto scoprirlo nel modo più duro. È così che va di solito. Spero che l'architetto e il management abbiano imparato dai loro errori e non lo facciano più. Se questo è come al solito quando la direzione è troppo ignorante per ascoltare i tuoi argomenti e intraprendere le azioni appropriate, potrebbe essere una buona idea cercare altri progetti o un'altra società.

"Gli sviluppatori sono artigiani e la cosa peggiore che puoi fare per un artigiano è fargli consegnare un prodotto scadente". Citazione famosa da qualche parte ma non ricordo da dove.

L'onestà dovrebbe essere sempre onorata. Ero alla ricezione di una "visione dell'architetto", e quando lo sviluppatore venne da me con la terribile notizia che l'intera soluzione non avrebbe funzionato, andammo nelle unità aziendali e discutemmo terribilmente. Lo sviluppatore ha quindi elaborato una nuova stima che comprendeva l'80% delle funzionalità, ma ha consegnato in tempo e budget.

Le unità aziendali furono conquistate dal fatto che lo sviluppatore parlava loro con sincerità, riconosceva le carenze delle sue aziende e lavorava come un cane da consegnare. Abbiamo fatto lavorare questo ragazzo per noi negli ultimi 7 anni perché era sempre onesto.

L'intero scenario è così raro - la maggior parte delle volte le business unit pensano che tu sia un idiota per non essere in grado di fornire. È necessario cercare quei clienti che non operano in questo modo, poiché nel lungo periodo guadagnerai di più con loro di quanto tu voglia provare a soddisfare i cretini che vogliono solo trattarti come un coglione.

Per quanto riguarda gli architetti che non conoscono il loro campo, evitali come la peste. Avevo un mentore che era solito rafforzare con me in modo aspro - "Questo. Non lo è. Per. Pratica!" Tollera gli errori solo se li fai in anticipo, li correggi e non li fai mai più. Le aziende che consentono a persone non tecniche e inesperte di ricoprire posizioni con i clienti perché possono "comunicare" meritano di cessare l'attività.

Una volta avevo affrontato questa situazione. Un progetto è scaduto perché il business ha cambiato il requisito e c'era un gap comunicativo e l'alta direzione voleva il progetto in tempo. A peggiorare le cose, un ragazzo che stava lavorando a questo progetto è stato tirato fuori per colmare un altro vuoto che aveva più priorità.

Il mio team stava passando le notti per terminare il progetto. Una sera tardi verso le 3:00 del mattino (stavo lavorando 19 ore di fila) ho mandato un'e-mail ai miei manager per fare qualcosa al riguardo.

Il giorno successivo abbiamo avuto un incontro (solo i ragazzi degli sviluppatori). L'intero team è arrivato durante un fine settimana e ha testato il progetto anche prima che fosse completato. Pochi altri si sono uniti al team nel fare soluzioni rapide. Finalmente siamo riusciti a consegnare il progetto con lo sforzo di tutto il team (non solo del team di progetto). Abbiamo seguito lo stesso processo per altri progetti.

L'intero team (anche se non è coinvolto nel progetto) ha testato l'applicazione e ha aiutato a risolvere rapidamente i bug.

Nota: il mio team è composto da circa 25 persone che avevano di nuovo team secondari che lavoravano su diversi progetti.

Il mio unico consiglio sarebbe "Parla con il direttore. Dì loro con fermezza che il progetto non può essere consegnato in tempo. Inoltre, dai loro un'alternativa. Il gestore si aspetta sempre che il bambino venga consegnato in tempo, non importa cosa :)"

Mentre alle aziende spesso non piace la verità che le cose richiedono molto più tempo del previsto, preferiscono essere ancorate insieme. Prima fai sapere a qualcuno quanto tempo ci vorrà davvero, più velocemente tutti possono pianificare le circostanze. Mentre questo può inizialmente essere un momento difficile, a lungo termine sarà più facile. Basta farlo bene la seconda volta e costruire in contingenza.

Consentitemi di enfatizzare un punto chiave quando trattate con il vostro management: i manager apprezzano le soluzioni.

Se devi andare dalla tua direzione con un problema (ad es. La stima è incredibilmente irrealistica), lavora sodo in anticipo per includere alternative su come affrontare la situazione. Ad esempio, potresti fare un'analisi di Pareto (la regola 80/20) per comprendere il valore del sistema, potresti creare un caso prioritario per tagliare le funzionalità (almeno da una prima versione) per concentrarti su quelle con il massimo valore aziendale, potresti cercare alternative (progetti open source, ecc.) che siano sostituti adeguati per parti personalizzate del sistema, ecc.

Non c'è dubbio che un sacco da cinque libbre non conterrà venticinque libbre di sabbia, ma parte dell'aiutare la tua direzione ad assorbire il tuo messaggio spiacevole sta offrendo la prova che sei un alleato impegnato.

Potresti essere interessato a questo articolo IEEE di cui ho già scritto un blog . Ecco i punti salienti.

• Uno dei principali fattori alla base del fallimento del progetto sono le stime eccessivamente ottimistiche.
• Un grande motivo per cui le stime sono troppo basse è la troppa pressione dall'alto per consegnare in anticipo.
• L'altro è il ridimensionamento dell'ambito durante l'attrezzo senza rivedere le stime.

In primo luogo, vorrei parlare con l'architetto in questione, in modo informale, e consultare un elenco dei tuoi problemi con il suo preventivo, e cercare di convincerlo dove si trovano i problemi e la differenza di tempo che avrebbero impiegato per risolvere.

Quindi proverei ad andare dal tuo line manager / project manager e ne discuterei con lui / loro.

Alla fine della giornata, l'architetto ha fornito PREVENTIVI, quindi sono soggetti a modifiche e, talvolta, in grandi quantità, quindi a condizione che ne siano a conoscenza, in modo da poter fare piani alternativi, come distribuire un prodotto in fasi, riducendone la funzionalità o altri mezzi.

Alla fine della giornata, una volta fatto quanto sopra, non è più tua responsabilità.

Non dovresti assolutamente andare direttamente al cliente, o al capo degli architetti, questo promuove solo cattivi sentimenti e quasi invariabilmente avrai la colpa.

La cosa migliore che puoi fare è imparare dalle tue cattive stime (non le tue personalmente, in questo caso). Una cosa da imparare è non lasciare mai a qualcuno diverso dalla persona che implementa le idee stimare quanto tempo ci vorrà. Le velocità dei programmatori possono variare di un ordine di grandezza, quindi stimare per qualcun altro è quasi impossibile.

Sento il tuo dolore ... Non sono sicuro di come gestire tutta questa frustrazione :(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

In passato ho avuto a che fare con i project manager che hanno ridotto le stime per incontrare una cifra che il reparto vendite pensava che il cliente avrebbe pagato. Il direttore era dell'opinione che fosse meglio chiedere perdono piuttosto che chiedere il permesso.

Questo è il motivo per cui gli sviluppatori hanno imparato a riempire le loro stime, perché sanno che saranno tagliate dai loro manager. Quindi, se raddoppi il preventivo e aggiungi il 30%, hai buone probabilità di ottenere un programma ragionevole.

I clienti lo desiderano sempre in modo più economico e, se si arriva a loro con una stima ragionevole, si opporranno a ciò e chiederanno di tagliare i costi o di camminare. Ma, se vai troppo in alto, cammineranno semplicemente senza discussione ("Lo considereremo e ti risponderemo").

È un gioco di aspettative gestite.

Il problema non era che le stime originali erano fuori - è che il management non ti ha creduto.

Il modo migliore per convincere il management a prendere una decisione è:

1. Descrivi il problema con prove a sostegno; e
2. Fornire soluzioni multiple tra cui scegliere (in ordine dal meno preferibile al più preferibile).

Per (1) l'implementazione di Scrum e il monitoraggio dei dati effettivi rispetto alle stime non attendibili funziona bene per il backup dei tuoi reclami.

Per (2) una delle mie opzioni sarebbe quella di "Sviluppare un elenco di caratteristiche prioritarie con il cliente (noto anche come Product Backlog in termini Scrum)". Ciò sarebbe complicato per le organizzazioni a prezzo fisso o altamente burocratiche, ma è possibile .

Spero che aiuti!

Io (come sono sicuro di quasi tutti coloro che codificano) sono in sintonia. La mia ultima compagnia è stata piuttosto terribile: i venditori andavano e vendevano un progetto, poi entravi, vedevi le stime e ridevi.

Come ha detto Tomh, c'è solo così tanto tempo in un giorno. Anche se non dormi.

Tre cose, penso.

Il più delle volte devi solo gestire le aspettative del cliente ed essere trasparente . Sii sincero con ciò che puoi fare e mostra ciò che hai fatto, tutto. Ciò è particolarmente vero se ti vengono consegnati requisiti troppo grossolani (come menzionato da Totophil). Se riescono a vedere la quantità di lavoro che hai dovuto fare, possono vedere quanto è stata negativa la stima. Se vedono produttività e progressi, questo è più importante di qualsiasi altra cosa nella mia esperienza.

Penso che oltre a gestire le aspettative ed essere trasparente nel carico di lavoro, l'altra cosa importante è la gestione dell'ambito . C'è una vasta area tra l'essere anale / offensivo nell'essere un nazista di portata e coprire la propria coda. Quando qualcuno desidera questa caratteristica o funzionalità extra, accettala! E poi dare loro una stima relativamente precisa di quanto tempo che si aggiungerà al progetto Il vantaggio di questo è non solo (o versione successiva.) Non vadano a finire se stessi in un'altra settimana 80 ore - si ottiene qualche pad in quella stima troppo possibilmente mettersi al passo con l'altro.

In bocca al lupo!

Non affrontare mai nulla senza vederlo o capirlo. Se il cliente o il tuo mgmt non è disposto a permettertelo così tanto, non ti stanno preparando per avere successo.

Questo è stato (e spesso è) un errore nel comprendere i dettagli, i dati e il modo in cui interagiscono durante l'applicazione che viene costruita. Vengono fatte ipotesi invece di porre domande, trovare risposte e inchiodare il tutto.

Una cosa che dico spesso ai miei clienti è che, se hai intenzione di impiccarmi, almeno lasciami impiccare con la mia stessa corda o spararmi con la mia pistola e i miei proiettili, non qualcun altro.

Avere una porta girevole di persone che cercano di risolverlo sarà molto peggio alla fine per loro.

La pianificazione non realistica, scarsa e la mancanza di lungimiranza possono essere segnali di un problema a livello di organizzazione, nel qual caso è meglio abituarsi o andare avanti.

Innanzitutto, considera la possibilità che stai sopravvalutando l'ambito del progetto. I venditori e gli architetti tendono a esagerare le loro soluzioni. Non prenderli al valore nominale; probabilmente si aspettano che ti venga in mente meno di quanto hanno promesso al cliente.

Quello che farei qui è prendermi tutto il tempo che ho e spenderlo il più saggiamente possibile. Capire le priorità del cliente e realizzarle. Nove volte su dieci, il cliente sarà felice che le sue massime priorità siano state soddisfatte e trascuri l'80% del lavoro che non è stato svolto.

L'ultima cosa che vuoi fare è convocare riunioni di emergenza e accusare le persone di essere malvagie. Tu dici:

"far loro conoscere la realtà"

ma la realtà è solo un'opinione! Rilassati, fai il tuo lavoro e spendi il tuo capitale politico in cose che contano per te . Come, promozione, più soldi, più vacanze.

Il tuo capo che commercia una promozione per te lavorando molto duramente sul cliente ha un senso. Non andrai in tilt per conto di un cliente.

Una cosa da ricordare è che le stime non includono il creep dell'ambito o inevitabili ritardi (o problemi basati sul fatto che il cliente non ti dà quando hanno detto che avrebbero voluto un file di informazioni in un particolare formato).

Abbiamo imparato a respingere la stima e / o la data di scadenza ogni volta che accade una di queste cose. Aggiungi una nuova funzionalità, ottieni un nuovo preventivo e una nuova data di scadenza. Non fornire le informazioni necessarie alla data concordata, ottenere una nuova data di scadenza. Fornire le informazioni ma renderle incomplete o errate o comunque diverse da quanto promesso, inviare una nuova stima e data di scadenza, modificare i requisiti delle funzionalità concordate, ottenere una nuova stima e data di scadenza. Smetti di lavorare al progetto perché il cliente voleva che tu lavorassi con una priorità più alta, invia una nuova data di scadenza (e possibilmente una nuova stima perché ci sarà tempo di recupero se il progetto è in attesa a lungo).

Se la stima originale proveniva dall'esterno del gruppo di sviluppo e non sono stati consultati su di essa, allora quando la ottieni, prepara una tua stima (a un livello dettagliato di tutti i compiti che pensi che avrà - a un livello molto più alto di dettaglio rispetto al preventivo che ti è stato fornito) e forniscilo immediatamente alla catena e chiedi cosa dovresti ritagliare per soddisfare il preventivo che ti è stato dato.

Se la risposta è nulla, insistere sul fatto che il cliente sia informato del nuovo preventivo, ora che abbiamo esaminato la questione in modo più approfondito. Se la direzione insiste sul fatto che il cliente pagherà solo per X ore, chiedi a chi pagherà per il resto delle ore di sviluppo perché il lavoro che ti è stato descritto non può essere fatto per un importo inferiore al tuo preventivo. Si potrebbe scoprire che la società è disposta a prendere il colpo e pagare per le ore stesse.

Se non sono disposti a trarre profitto dal loro profitto e non diranno al cliente che hanno bisogno di più ore e la società non appoggerà le stime dettagliate dello staff di sviluppo sulle vendite "" cosa pensiamo che il cliente cercherà di ordine per vincere il progetto "stima, sei su un progetto della marcia della morte e la tua migliore scommessa è uscire il prima possibile. Puoi sottolineare che il cliente sarà più felice sapendo che il progetto impiegherà più tempo possibile di quanto non faccia quando passano le 50 ore per cui hanno accettato di pagare e non sei nemmeno vicino al completamento con le 500 di cui avevi davvero bisogno. Ricorda loro che stime eccessivamente ottimistiche sono uno dei maggiori fattori predittivi di fallimento del progetto. Non funzionerà con questo tipo di aziende, ma forse alla fine affonderà se lo ripeti abbastanza volte.

Vorrei anche prendere in considerazione il raffinamento della stima. Intendo "come lo vedo ora, questo progetto richiederà X ore-uomo". Dopo il 20-30% rivaluterò e così via.

Dopo tutto, come fa un downloader di file a fare la sua stima? Lo affina costantemente.

Penso che non abbastanza stimatori non mettano abbastanza enfasi sui fatti di "La stima mi stai chiedendo di fare matematica e ipotesi per prevedere il futuro in modo utile" e "L'impegno che prendiamo è completamente separato dalla matematica che facciamo per fare una stima; possiamo concordare di fare stupide quantità di lavoro, concordare con cose che vediamo che probabilmente non possiamo finire, ma nessuna di queste cambia davvero la matematica della soluzione "e" Possiamo fare metodologie di sviluppo che non sono giganti la serie di funzioni A verrà eseguita entro la data B che rende il fallimento molto meno probabile "

Per molte stime sono redatte nella lingua della negoziazione. Devono essere preparati nella lingua della matematica e parlare delle incertezze della matematica .

Lo stimatore non può fare nulla per far piegare la realtà alla volontà degli imprenditori di negoziarlo. Il suo unico lavoro è far smettere di provarci.