Sales Manager: "Perché la stima del tempo è così complessa?" [duplicato]

Chiedigli quanto tempo ci vuole per trovare la sua strada attraverso un labirinto. Nessun labirinto particolare o qualsiasi dimensione particolare di labirinto - solo "un labirinto".

La programmazione è in qualche modo simile. Non puoi essere sicuro di quanto ci vorrà prima di aver esplorato a fondo i problemi che dovrai risolvere. L'unica volta in cui puoi essere sicuro di averlo fatto è quando hai già il prodotto finito.

Viene in mente l'analogia dell'edilizia: quanto ci vuole per sistemare una casa? Non lo saprai finché non saprai in che forma si trova una casa, che tipo di lavoro deve essere fatto. Dipingi o hai bisogno di ricablare il posto, abbattere i muri e aprire un nuovo tetto?

Tuttavia, ritengo che se si fa un inventario (e in base alle righe di codice si possa stimare il tempo necessario a fare un inventario con maggiore sicurezza), allora si può essere più specifici su ciò che si aspetta che debba essere fatto, e quanto tempo ci sarebbe voluto. (Questo è un processo a doppio senso: documentando le diverse problematiche si ottiene una maggiore comprensione del progetto e conoscendo il progetto si ottiene una visione più chiara dei problemi, quindi prenditi del tempo per analizzare la situazione e prenditi del tempo per scrivere la tua spiegazione sul motivo per cui pensi che ci vorrà del tempo per pensare. Per la necessità di spiegarlo a qualcun altro, diventa più chiaro per te.)

(Oh, e non dimenticate di ricordare al direttore delle vendite che tutti conoscono qualcuno che ha iniziato con lo stripping di un pezzo di carta da parati solo per scoprire che in realtà era un pezzo di carta da parati piuttosto resistente che veniva incollato fondamentalmente su sabbia o gesso sbriciolato , quindi hanno finito con un grande buco e la necessità di ricostruire il muro prima.Le cose che potrebbero sembrare semplici cambiamenti estetici potrebbero improvvisamente scoprire un'intera gamma di nuovi problemi.)

La stima del software è difficile perché:

• Lo sviluppo del software è pieno di incertezze .
• Le stime vengono spesso prese come impegno dai gestori.
• Il tempo necessario per implementare una funzione può essere molto diverso da una persona all'altra
• L'essere umano difficilmente può stimare in tempo . Tuttavia, l'umano può facilmente stimare in termini di taglia .

La soluzione che utilizzo:

Pianificazione del poker in combinazione con tracciamento della velocità e punti della storia unità.

Funziona perfettamente su grandi progetti con team di sviluppatori da 5 a 7 e team molto piccoli. Importante: non assegnare compiti. Lascia che sia la squadra a decidere.

"Non so, perché la stima delle vendite è così complessa? Che ne è dell'analisi di mercato? Tassi di conversione?"

Chiedigli quanto tempo impiegherebbe per prendere il posto di un collega che è stato investito da un autobus. Questo collega ha tenuto appunti in un formato criptico che prima doveva capire prima di poter seguire i lead di vendita.

Quando dice "Non lo so", sorridi.

Confrontalo con la previsione di quanto prodotto l'azienda intende vendere per l'anno. Ovviamente non è esattamente la stessa cosa, ma si spera che riesca a raggiungere il punto. Potresti anche chiedergli perché è così complicato capire come vendere un prodotto.

Inizia con " nove donne non possono fare un bambino in un mese " e vai indietro allo stato del tuo progetto (speriamo ancora in tempo).

Digli che non puoi documentare un negativo e la linea temporale per un progetto che deve ancora essere consegnato è un negativo . Non lo saprai finché non sarai vicino a essere pronto a spedirlo.

Se il droide vendite ti costringe a una linea temporale, dì six to eight weeks (wow, come è stato preso in considerazione, il testo evidenziato può essere cliccato), quindi rivedi quello a partire dalla prima settimana, dopo aver saputo in cosa ti sei messo.

Chiedigli se ha mai lavorato su un cruciverba o meglio ancora su un puzzle di sudoku. Spiegagli che lo sviluppo del software richiede un costante perfezionamento dopo che alcuni sconosciuti sono diventati noti. Con l'aumentare della tua comprensione, aumenta anche l'accuratezza delle tue stime, almeno in alcuni casi.

Se fallisce, chiedigli "Quanto ci vuole per trovare le chiavi?"

Per capire perché le stime del software (basate sul tempo) sono difficili, dobbiamo riflettere sulla natura dello sviluppo del software.

La differenza tra le attività produttive e il lavoro di progettazione è probabilmente il concetto più importante che gli uomini d'affari hanno bisogno di capire. Durante l'era industriale c'era una netta distinzione tra design e produzione. Abbiamo progettato progetti che sono stati riprodotti in una fabbrica tutte le volte che volevamo.

Applichiamo lo stesso modello nelle nostre teste al processo di sviluppo del software, assumiamo che prima qualcuno debba progettare il prodotto dopo di che diverse persone lo producono. Una volta che inizi a pensare a quando il design fase finisce e quando inizia la produzione, ti rendi conto che questo non si applica allo sviluppo del software. Considera la seguente rappresentazione di un ciclo di sviluppo del prodotto:

... => design => (blueprint) => manufacture => (product) => ...

L'intuizione potrebbe dirti che si traduce in uno sviluppo software come questo:

... => design => (Interaction design deliverables) => manufacture => (Source Code) => ...

Mentre in realtà è più simile a questo:

... => design => (Source Code) => manufacture => (Software application) => ...

In altre parole: il codice sorgente è il design e non il prodotto! Il software di produzione è completamente automatizzato (compilando la fonte). Altri hanno spiegato meglio di me, ti consiglierei di leggere questo saggio di Jack Reeves: Cos'è il Software Design?

La differenza tra design e produzione non è solo concettuale e ha alcune implicazioni molto reali per il modo in cui gestiamo lo sviluppo del software. Il lavoro di progettazione è per sua natura altamente imprevedibile e dipende dalle persone, mentre la produzione è molto più prevedibile e dipende dalle risorse.

Da questa linea di pensiero segue che la variazione della produttività individuale tra gli sviluppatori è così alta che è impossibile prevedere quanto qualcuno può produrre in un certo periodo di tempo. Per ulteriori approfondimenti su questo, consulta il seguente saggio di Paul Graham: Come fare ricchezza.

Ci sono molte altre implicazioni del modo di pensare "design! = manufacturing". Un altro importante è il fatto che non hai mai deciso di progettare qualcosa che è già disponibile. Ciò aumenta la quantità di incertezza nel lavoro di sviluppo.

Combina questi con le molte ragioni per cui gli uomini d'affari costringono gli sviluppatori a stime più basse, oltre al fatto che le persone hanno difficoltà a stimare le misure assolute e tu hai ottenuto una stima per stime molto imprecise.

Se il tuo responsabile vendite ha ancora dubbi, questo articolo potrebbe chiarire:

Dita nell'aria: una delicata introduzione alla stima del software

...software development community has a very poor record in estimating anything—in fact is very common for projects to run over-time and over-budget, and deliver poor quality products with fewer features than originally planned.

Part of the problem is that software is quite difficult to estimate. In fact, huge differences in individual productivity, the fact that creative processes are difficult to plan, the fact that software is intangible, and the fact that during the life of the project anything can change - e.g., scope, budget, deadlines, and requirements—make software estimation a challenging task.

However, in my experience, the main cause of poor estimates is that the various stakeholders are often unaware of what estimates are for, and what they should look like. This lack of knowledge means that they have no way to judge if the project goals and the associated expectations are realistic. The result can be either overestimation which causes the allocation of an excess of resources to the project, or, more often, gross underestimation which often leads to "death march" projects [You], which are characterized by "project parameters" that exceed the norm by at least 50%, e.g.:

• The schedule has been compressed to less than half the amount estimated by a rational process
• The staff is less than half it should be in a project of the same size and scope
• The budget and resources are less than half they should be
• The features, functionality and other requirements are twice what they would be under normal circumstances

The rest of the article is an introduction to the software estimation process aimed at project managers, developers and customers who want to get a better understanding of the basics this subject, and avoid to make their projects a death march one...

Digli che dopo 8 anni il progetto è molto grande. Ora, quando introduci alcune piccole modifiche, può attivare più modifiche nel sistema prima che tu possa farlo funzionare e ciò non dipende da te.

Devi 1. fai il tuo lavoro / scrivi il tuo codice
2. testarlo
3. quindi verificare come il cambiamento interferirà con altre funzioni del sistema.
4. correggi il comportamento del sistema.

Puoi stimare 1 e 2 ma non puoi dire in che modo i cambiamenti interferiranno con l'intera cosa prima che tu lo abbia fatto. Perché è impossibile senza test. A volte dovrai solo scrivere il tuo codice e tutto funzionerà all'istante e qualche altra volta dovrai apportare molte altre modifiche al sistema oltre a scrivere la nuova funzionalità per farlo funzionare come previsto.

È stato dimostrato che puoi risolvere qualsiasi configurazione cubica di Rubik in 20 mosse o meno (http://www.bbc.co.uk/news/technology-10929159).

Chiedi quanto tempo ci vorrà per risolvere alcuni cubi di Rubik puoi solo guardare, ma non raccogliere.

Il software in questione è probabilmente molto più complesso di un cubo di Rubik, ma spesso ti è permesso solo "guardarlo, ma non prenderlo e giocherellare con esso".

Immagino che tu dia raramente stime troppo alte. Assicurati di non operare sotto la paura / riluttanza a dare una stima lunga. Tutti gli addetti alle vendite cercheranno e comunicheranno un alto livello di urgenza per una richiesta del cliente. Nella tua mente stai cercando di capire qual è il minimo tempo che ci vorrà.

Se hai qualche domanda, offri di dare una rapida occhiata al problema in modo da poter raccogliere abbastanza informazioni per fare una stima migliore. Devi anche essere in grado di determinare quanto tempo avrai a disposizione. Non promettere qualcosa in 10 giorni quando sei in vacanza per 2 settimane.

Per la parte sovra-lavorata, scopri quale richiesta precedente desideri che tu ridistri la priorità. Sarai scioccato dal fatto che più della metà delle volte vorranno continuare a lavorare su quello precedente.

Non sono d'accordo con alcune delle risposte date. Non è possibile confrontare la programmazione con la ricerca di una strada attraverso un labirinto, sono d'accordo sul fatto che ci sia un aspetto di apprendimento, ma non c'è molta abilità nel risolvere un labirinto. Né è come costruire o ristrutturare una casa, è un processo piuttosto definito.

La migliore analogia che ho trovato per programmare IMO è come un artista che dipinge un quadro, è impossibile stimare perché c'è un aspetto artistico e più pittori non finiscono prima un dipinto (beh, potrebbero, ma non meglio). Le persone tendono a pensare alla programmazione è come l'ingegneria, ma in realtà è più simile all'artigianato con un po 'di talento artistico, ed è difficile da stimare