Boss non crede alla mia stima del tempo ... consiglio / backup? [duplicare]

Potresti voler tornare indietro:

• Scopri la scadenza realistica (ad esempio, è corretto consegnarlo in 5-6 mesi?). Tutti i # in questo esempio sono in qualche modo relativi a questo #.

• Definisci le pietre miliari per le attività che devono essere raggiunte in base a tale scadenza. Per esempio. 1 mese per la raccolta di richieste e la creazione di competenze / esperienze su SDK / hardware / ecc .... 2 mesi per lo sviluppo attivo. 2 mesi per il test. 1 mese per schifo imprevisto derivante dalla complessità di tutto questo.

  Questa è una buona granularità per la prima passata, ma poi è necessario eseguire un confinamento con attività secondarie a qualcosa con una granularità di 2-3 giorni per quanto riguarda il piano e preferibilmente a maglia temporale, ad es. dovresti avere alcune attività di codifica iniziali assegnate al primo mese.

• Quindi, seleziona i requisiti o il set di funzioni se vedi che mancano le pietre miliari. Tieni presente che hai bisogno di questa "attività di codifica all'inizio" che ho elencato prima, poiché ti consentirà di determinare la correttezza del tuo ritmo e le stime per la codifica prima di passare i 3 mesi.

Fondamentalmente, sto gestendo questo (in qualche modo contrario al solito approccio di gestione del progetto) dal punto di vista "DEVE CONSEGNARE DA" che sembra aver sottolineato nel tuo post. Per esempio. La mancata consegna entro una scadenza rigida NON è un'opzione.

Hai ragione di sentirti confuso e spaventato. Prima di iniziare, ricorda che c'è sempre la possibilità di trovare un altro lavoro. Detto questo:

L'entusiasmo del tuo capo per una data di consegna anticipata è solo un riflesso del bisogno aziendale. Se non può promettere al cliente il prodotto all'inizio del prossimo anno, allora sa che non vincerà il contratto, né farà la vendita, o qualsiasi altra cosa. La realtà di questa situazione riguarda anche te: se il tuo datore di lavoro non conquista nuovi affari, non ci vorrà molto prima che tu abbia bisogno di trovare un nuovo lavoro. Quindi, la prima lezione è che il tuo capo sta esprimendo un bisogno reale, e questo è il tuo bisogno oltre al suo.

Tutti i progetti in questa situazione vanno in questo modo: il fornitore vincente è colui che accetta le scadenze più folli e offre le stime di personale più basse. Tre mesi dopo, quando il cliente si aspetta che il suo nuovo brillante software venga consegnato in una scatola termoretraibile, il venditore se sarà fortunato sarà in grado di dire,

"well, we've run into some problems so it's not ready, but here's something that does 50% of what you asked for. Sorry about the bugs and quirks - we're working on them, and we'll have it all sorted in another couple of months!"

Se quella funzionalità del 50% è sufficiente per far passare il cliente nei prossimi 3 mesi, magari addestrando il proprio staff alla soluzione parziale, probabilmente rimarranno un po 'in sospeso. Se poi puoi dare loro una versione che corregge il 50% principale e aggiunge un altro 30% di nuove funzionalità, allora sono l'80% del modo per ottenere ciò che vogliono. Sì, sei già in ritardo di tre mesi, ma se passano a un altro fornitore ci vorranno almeno 6 mesi prima che ottengano qualcosa. Sicuramente sarai in grado di ripulire l'ultimo 20% del progetto in altri 3 mesi? ...

... e così via.

Questo è ciò che accadrà veramente !!

Se il tuo manager non ammette che sia un pazzo o (più probabilmente) è in contatto regolare con il cliente e ha bisogno di mantenere la sensazione di ottimismo irrealistico necessario per convincerli a firmare il contratto.

Non puoi permetterti di essere ottimista. Pianificare il progetto da consegnare in più fasi. Inizia a identificare subito che il 50% della funzionalità è fondamentale per il cliente in quei primi 3 mesi. Inizia a disegnare il 10% della funzionalità che mai verrà consegnato. Cerca di coinvolgere il cliente in questo processo il più possibile - questo ti aiuterà a gestire le loro aspettative, in modo che non siano totalmente scioccati quando la realtà non è all'altezza delle loro speranze e dei loro sogni.

E buona fortuna!

Anche se ora è obsoleto, mi piace usare Excel per le stime, come spiegato qui.

link

Prendi ciascuna attività principale, scomporla fino a quando non puoi dare una stima, quindi stimala. In questo modo, ti costringe a progettare l'applicazione, e i poteri-in-essere possono vedere ciò che è coinvolto, in quanto potrebbero esserci molte parti che non si rendevano conto di essere coinvolte.

Puoi quindi tenere traccia del tempo necessario e vedere perché la stima originale è disattivata.

Quindi, per il primo punto, come verranno raccolti i campioni di terreno? Saranno memorizzati in un database o in un file xml o cosa? È quindi possibile progettare come funziona l'interfaccia utente e quindi fornire una stima. Se vogliono un supporto multilingue, come attività secondaria separata e virata su qualche ora in più.

La pugnalata iniziale potrebbe dover essere rielaborata un paio di volte, ma dovresti riuscire a farlo in circa 1 o 2 giorni, e avere un'idea approssimativa di quanto tempo ci vorrà, e poi mostrarli i dati.

Ora, se ci sono attività che richiedono troppo tempo a causa di un SDK non supportato o mancanza di formazione, allora possono decidere di ottenere un SDK migliore o assumere un appaltatore, quando questa parte è necessaria, per sviluppare la parte che gli sviluppatori non possono fare.

In questo modo, tuttavia, consente loro di determinare il budget e le tempistiche.

Suddividi il progetto in tutte le attività dettagliate possibili.

Quindi valuta ogni attività separatamente. Sommateli e date un budget di tempo (di solito in unità man.month = la quantità di lavoro che un uomo può compiere in un mese). Nella tua stima includi documentazione, integrazione e test. Consenti anche un buffer per le festività, il supporto su altri progetti, ecc.

Infine, dividi la stima totale per il numero di risorse e ti ritroverai con un ETA decente (tempo stimato di arrivo).

Puoi confrontare i tuoi risultati con i tuoi colleghi e media / ri-valutare se necessario.

Vorrei vederlo a un anno.

Le applicazioni che supportano la localizzazione sono uno sviluppo all'avanguardia. Qui si applicano tutti i rischi di stare su quel lato.

Stai esaminando almeno due applicazioni distinte, probabilmente tre e alcuni processi in background che puliscono i dati e eseguono analisi e rapporti aggiuntivi.

Quello che vorrei fare è chiedere un mese per sviluppare un prototipo. Preferibilmente su hardware live, ma almeno su un simulatore. Hai un sacco di decisioni tecnologiche da prendere.

Una volta che hai il tuo prototipo, puoi iniziare a iterare per sviluppare funzionalità e demo bisettimanali. Probabilmente ci vorranno mesi prima che tu possa produrre una stima affidabile.

Probabilmente c'è una comunicazione errata.

Forse fraintende quali sono le sue esigenze. Forse fraintenderai quali sono le sue esigenze. Non discutere su posizioni: invece di dimostrarti giusto, prova a capirlo meglio.

Agile esiste per aiutare con problemi come questo.

La situazione descritta è molto comune soprattutto nella definizione dello sviluppo del software e nella fase di pianificazione ed è incredibilmente importante imparare come gestirlo. Quando si creano cose nuove, spesso non è solo la soluzione a essere sfocata, ma la stessa affermazione del problema manca di chiarezza e richiede una ridefinizione.

Essenzialmente lo scenario implica almeno una delle tre cose:

1. Il tuo capo non sa di cosa sta parlando e non ha aspettative realistiche.

2. Non sai cosa stai facendo o non abbastanza intelligente o semplicemente pigro.

3. Tu e il tuo capo avete un'idea completamente diversa di quale sia il problema o quale sia la soluzione o probabilmente entrambi.

Non è difficile capire come le prime due implicazioni siano davvero offensive. È molto facile entrare in una situazione naturale quando potresti assumere la posizione che implica che il tuo capo è un pazzo sognatore incompetente e allo stesso tempo che il tuo capo adotti l'opinione che coinvolge te sia un tecnico ingannevole e incompetente che non è consapevole delle realtà aziendali.

Da qui l'unica via di fuga sana che ti aiuterà a mantenere buoni rapporti e a fare qualche progresso sul lavoro che fa funzionare la società sembra essere la terza opzione. Normalmente uno di voi direbbe: "Giusto, una discrepanza così grande nelle cifre può significare solo una cosa: comprendiamo il problema o la soluzione in modo piuttosto diverso, permettiamo nuovamente di parlare del problema e della soluzione, ora in modo molto più dettagliato, fino a quando vediamo dove queste differenze sono e riescono a raggiungere una comprensione comune ".

Alla fine potrebbe risultare che sia la comprensione del problema sia la soluzione proposta non erano corrette. Potrebbe risultare che è necessario lavorare per un obiettivo, rispettare una scadenza per incassare la vendita; magari con una soluzione semplice che è solo il 60% e quindi espandendola ulteriormente all'80% nella seconda versione, invece di onorare lo scopo iniziale del 100% e includendo funzionalità meno preziose, ma che richiedono tempo prezioso che possono essere facilmente sacrificate.

In una piccola start-up nessuno può essere sulla difensiva; è abbastanza difficile portare il nuovo lavoro e tutti devono essere molto intraprendenti nel risolvere i problemi date le circostanze. Quindi tu e il boss dovete perseverare ugualmente nel tentativo di riformulare il problema e cercare una soluzione realistica finché non siete d'accordo su un unico modo sensato per andare sul progetto.

Ciò che il tuo capo ha è un'idea. Ciò di cui ha bisogno è un'analisi completa del progetto. Quali sono i problemi che verranno risolti, qual è il set di funzionalità per l'applicazione. Tu (e gli altri sviluppatori) hai davvero bisogno di sederti con lui e discutere, alla grande lunghezza, proprio quello che ha in mente. Una buona regola è che per ogni ora di tastiera, dovrebbe essere preceduta da almeno 10 ore di discussione. I manager sono così - fanno una rapida spiegazione di due minuti della loro idea, poi vogliono una esatta stima proprio allora - come se fosse anche possibile ( NOT! ).

Come suggerisce il secondo commento al post originale, è necessario eseguire un'analisi completa dei sistemi del progetto dall'inizio alla fine. Rendilo dettagliato come il boss ti consente - e spinge per un livello elevato di dettagli - quindi inizia a organizzare i pezzi e ad assegnare loro delle stime. Aggiungi un "fattore Scotty" di almeno 1,5 al totale e avrai un'idea approssimativa di quanto tempo ci vorrà in circostanze ideali .

Ci saranno sempre cose che non prevedi, anche se la funzionalità creep e le modifiche ai requisiti non aggiungono il loro carico di tempo prolungato.

La chiave qui è il dettaglio: il capo deve capire che, mentre ha in mente il quadro generale, sono i dettagli a fare il progetto. E se i dettagli non sono disposti in bella vista per tutti da vedere, scegliere, riorganizzare, modificare, ecc. Allora ci sarà il progetto no da consegnare. Dovrai combattere con il boss - i gestori assolutamente odiano i dettagli - a loro piace agitare le mani, dire "prendersi cura di esso" e aspettarsi che i miracoli accadano. Si chiama sindrome di "Eroe" - qualche povero scemo interviene, fa 16 ore al giorno per mesi e consegna una versione bastardata del progetto che funziona a malapena e il capo dice "guarda, può essere fatto".

Conta su di esso - e sentiti libero di mostrarlo al capo - Ho fatto progettazione del software per oltre 31 anni e devo ancora imbattersi in un progetto che non funziona secondo le linee guida di cui sopra - almeno uno che è riuscito!

Se la tua stima è compresa tra 9 e 18 mesi, il costo sarà più vicino a 24-36 mesi. È la natura dello sviluppo in tutti gli ambienti aziendali in cui ho lavorato. Ci saranno inevitabili cambiamenti delle specifiche e oscillazioni dello scope lungo il percorso. Le informazioni e le risorse necessarie saranno ritardate. L'imprevisto sarà visto. Forse sono solo stanco di ogni singolo progetto su cui ho lavorato fino ad oggi nella mia carriera. =)

Dalla descrizione del progetto, non credo che 3 sviluppatori possano completare tutto ciò in tre mesi nelle circostanze ideali, molto meno nel "mondo reale". Soprattutto quando aggiungi che mentre stai sviluppando, parte del tuo tempo verrà trascinato in altre cose: riunioni, supporto di app di produzione esistenti, assistenza clienti, rapporti ad hoc, ecc. Ecc.

Aiuta sempre ad avere qualcosa di tangibile (che possono guardare) da presentare alla direzione. Raccomando un foglio di calcolo (o un'esportazione di MS Project) con tutte le attività a cui puoi pensare che andranno in questo progetto suddivisi in blocchi che, una volta sommati, daranno una stima accettabile.

Dovrebbero essere in grado di guardare il tuo documento e vedere che, hey (!), ci vorrà un mese per sviluppare un prototipo di questo componente, 3 mesi per testare e così via.

È anche utile fornire stime migliori, previste e peggiori.

È improbabile che nessuno di noi qui abbia abbastanza informazioni per fare un'ipotesi più accurata di te. Detto questo, non penso che tu sia nel campo sinistro. Potrebbe essere che la tua squadra potrebbe fare un lavoro pessimo in tre mesi, assumendo che tutto vada alla perfezione. Potrebbe anche darsi che, anche nel migliore dei mondi possibili, non sia ancora possibile farlo in tre mesi.

Chiedi al tuo direttore qual è il suo fondamento logico per il preventivo. Potresti scoprire qualcosa che non stavi considerando, o potresti aggiungere cose che non stava prendendo in considerazione.

Digli che ti stai attenendo al tuo preventivo, ma prova a spiegarlo in questo modo. C'è una grande quantità di incertezza in questo momento e la tua stima è di 12 mesi -25% o + 50%. Man mano che le cose diventano più chiare, la stima potrebbe cambiare e il margine di errore si ridurrà. Se è politicamente utile, puoi espandere il margine e dire al tuo capo che è 12 mesi -75% o + 150%. Quindi i 3 mesi sono lì, ma lo sono anche 2,5 anni.

Se vieni escluso, fai del tuo meglio comunque, e sarà un'esperienza di apprendimento (si spera non troppo dolorosa) in un modo o nell'altro.

Molto probabilmente né il tuo capo né l'idea completa dell'app proposta, poiché è solo un'idea su un tovagliolo. Piuttosto che discutere delle stime forse dovresti fare qualche spunto, solo per testare le tue stime, è un'opzione?

Come ha detto Dustin, questo sicuramente sembra un esempio di libro di testo di un processo agile. Al fine di ridurre al minimo il rischio su questo progetto, è possibile scegliere di distribuire una versione ogni mese o giù di lì. Se il cliente è contento del prodotto, è perfetto, ma se annulla il progetto durante lo sviluppo, la tua azienda ha perso solo X mesi di lavoro, quindi i 18 mesi completi.

With that description in mind I thought things over (albeit rather quickly). With our current staff size, limited budget, and limited resources, I projected that such an endeavor would take roughly 9 to 18 months.

Dare una stima fuori dal comune come quella è una pessima idea, perché di solito si sbagliano. Vi sono numerosi suggerimenti forniti in The Pragmatic Programmer .

Penso che il più pertinente per te sia il loro suggerimento su cosa dire quando ti viene chiesto un preventivo. L'unica risposta è "tornerò da te". È necessario dedicare un po 'di tempo a riflettere sui requisiti, capire esattamente cosa è necessario fare e cosa potrebbe essere già fatto, costruire un modello (sia su carta o nella testa) del sistema finale, correlando il lavoro che è necessario fare a progetti simili che hai svolto in passato, analizzando la disponibilità delle risorse e così via.

Rallenta, prenditi il tuo tempo e sii diligente. Non ho mai fatto stime a braccio.

Se hai l'opportunità, puoi anche dare un'occhiata ai metodi di stima parametrici, come COCOMO o SLIM (il modello Putnam). Questi prendono database storici, ma con le giuste informazioni di base e parametri abbastanza precisi, in genere danno buone stime. Un'altra opzione potrebbe essere quella di consultare il resto del team e svolgere una qualche forma di stima Delphi a banda larga .

Forgive me if I'm off in left field, I'm a recent CS grad and pretty new to the "real" world.

La stima richiede molto tempo. Il modo migliore per migliorare le stime è tenere un registro per ogni progetto. All'inizio del log, registra le tue stime sulla dimensione del progetto, l'ambito e lo sforzo richiesto. Durante il progetto, tieni traccia di ciò che accade. Alla fine, registra le dimensioni finali, la portata e lo sforzo. Con tempo e pratica sufficienti, puoi ottenere una stima migliore.

Inoltre, nessuna quantità di corsi o di letture ti aiuterà a migliorare la stima. Ho letto della PSP e della metodologia PROBE, ho seguito un certo numero di corsi sulla gestione dei processi e sulla gestione dei progetti. Ho studiato economia di ingegneria del software. Ho persino letto il libro di Steve McConnell sulla stima del software . Ho appreso molte buone tecniche e strategie, ma nulla mi ha reso migliore della stima, quindi ho eseguito valutazioni, commesso errori e imparato da loro.

Poiché la stima richiede pratica, sono sorpreso che ti stiano facendo valutare attività di questo tipo su larga scala. Probabilmente hai poca o nessuna esperienza di lavoro a livello di progetto, quindi non sono sicuro di come ci si può aspettare di stimare da solo. Se fossi il tuo manager o lead, ti avrei coinvolto con la stima, ma non stimando l'intero progetto.

However, the project is currently only realized in my director's head, with no design documentation or specs.

Questo è problematico. Le stime provengono direttamente dalla comprensione del progetto. Hai bisogno di qualche tipo di requisiti, specifiche o obiettivi finali per poter iniziare a stimare. Inoltre non puoi stimare ciò che è nella testa di qualcun altro. Io, personalmente, non valuto nulla a meno che non sia stato scritto tutto. Le mie stime corrispondono a quanto è stato documentato, e se ciò che è il documento cambia, allora anche la mia stima cambierà.

Anche avere una scia di carta è sempre una buona idea. Aiuta a garantire che le persone giuste siano sempre responsabili. Questo potrebbe essere in qualsiasi decisione, da una stima a un progetto postmortem.

My question here is, how far off am I, really? Once again, my director -- who has no background in software or IT whatsoever, but is a subject matter expert insofar as soil sampling goes -- put the project at about a 3-month duration.

Come sviluppatore di software, probabilmente sei un estimatore migliore di qualcuno che non ha esperienza software, almeno delle attività di sviluppo software. Ho dimenticato la citazione, ma penso che sia stata detta da Barry Boehm o forse da Watts Humphrey, ma è stata una cosa sulla falsariga dei migliori stimatori di compiti ingegneristici sono gli stessi ingegneri. Quando si pianifica un'attività di progettazione, gli ingegneri sono quelli che devono essere coinvolti in ogni fase.

Una volta ho scritto un programma che fa il 70% di ciò di cui stai parlando (era anche per campioni di terreno), oltre a un mucchio di altre cose (era un robot di campionamento del suolo, quindi c'erano i controlli del robot) in circa 6 mesi come unico sviluppatore. L'interfaccia utente non era sul dispositivo mobile, ma era un programma di controllo su un laptop ... forse non dissimile dal tuo sito web? Ho anche diviso la progettazione e la costruzione dell'elettronica del robot con un altro ingegnere durante quel periodo.

Se hai un team di 3 sviluppatori esperti che hanno familiarità con l'hardware, il sistema operativo, la lingua e il dominio problematico, penserei che 3-4 mesi sarebbero una stima ragionevole.