Come spiegare a una persona non tecnica perché il compito richiederà molto più tempo di quanto pensino? [chiuso]

Quasi ogni sviluppatore deve rispondere a domande dal lato aziendale come:
Perché ci vorranno 2 giorni per aggiungere questo semplice modulo di contatto?

Quando uno sviluppatore stima questa attività, può dividerla in passaggi:

• apportare alcune modifiche al database
• ottimizzare le modifiche al DB per la velocità
• aggiungi HTML front-end
• scrivere il codice lato server
• aggiungi la validazione
• aggiungi javascript lato client
• utilizzare i test unitari
• assicurati che la configurazione SEO funzioni
• implementare la conferma via email
• rifattorizzare e ottimizzare il codice per la velocità
• ...

Questi potrebbero essere difficili da spiegare a una persona non tecnica, che in sostanza vede l'intero compito semplicemente mettendo insieme un po 'di HTML e creando una tabella per archiviare i dati. Per loro potrebbero essere 2 ore al massimo.

Quindi c'è un modo migliore per spiegare perché la stima è alta per un non sviluppatore?

L'hai appena fatto nella tua domanda.

Dividi l'attività in singole fasi e fornisci stime per ognuna. Questo mostrerà che hai considerato tutte le opzioni e (si spera) coperto tutte le eventualità.

Se i tempi sono troppo grandi, puoi discutere quali parti (ad es. La conferma via e-mail) non sono necessarie in questo caso con dati concreti piuttosto che cercare di inserire un quarto in una pentola.

Fallo abbastanza spesso e spero che insegnerai loro che di solito c'è di più in uno sviluppo che non a prima vista.

Elencare le attività è quasi perfetto, ma tenere presente che le attività che hanno perfettamente senso per un ingegnere hanno molto poco senso per una persona non tecnica. Ad esempio, nell'elenco sopra, so che "ottimizzare le modifiche del DB per la velocità" può essere una o più attività che richiedono tempo che includono la profilazione del codice, eseguirlo alla ricerca di punti lenti, rivederlo con esperti o lanciarlo attraverso un serie di test predefiniti specifici per il prodotto. E poi probabilmente hai diverse ore, se non giorni, per battere la testa sulla scrivania mentre cerchi di trovare un modo per riparare le aree troppo lente.

Ma potresti aver perso la gestione del tuo progetto sulla parola "DB" se non sulla parola "ottimizza".

In genere esprimo queste cose al project management in termini di GRANDI passaggi con parole che descrivono il rischio in termini di business. Prendendo la tua lista, la ridurrei in questo modo se stavo parlando con il mio project management:

1. Innanzitutto, ci sono due parti in questa cosa: la pagina web che l'utente vede e il server che fa il lavoro pesante. Entrambe le parti devono essere presenti perché questa funzione funzioni.
2. La prima parte sarà quella di creare una pagina Web che abbia senso per l'utente (aggiungere HTML front-end, aggiungere javascript sul lato client). La chiave qui è che la pagina web deve apparire come parte di questo prodotto, deve funzionare in tutti i browser che supportiamo e deve essere liscia. Questo è ciò che l'utente vede, quindi se sembra male, l'utente penserà che il nostro prodotto sia cattivo. Lo sviluppo e il test richiederà X giorni.
3. Successivamente, ci deve essere roba sotto la pagina web che fa il lavoro. In questo caso ciò significa inserire qui la descrizione della funzione (mappe per - apportare alcune modifiche al database, scrivere il codice lato server, implementare la conferma e-mail, aggiungere la convalida, utilizzare i test unitari). Non posso semplicemente metterlo insieme. Se il codice viene sviluppato e quindi testato, rischiamo di causare danni ai dati di TUTTI gli utenti. Ciò significa che una semplice novità potrebbe danneggiare la reputazione del prodotto su tutta la linea, anche per gli utenti che non utilizzano questa particolare funzionalità. Le nostre pratiche di sviluppo coprono tutto ciò - facciamo molti test per assicurarci che ciò non accada - ma ciò significa che devo pianificare in tempo per testarlo correttamente. Mi ci vorranno Y giorni.
4. La velocità è un grosso problema nel nostro prodotto. Se le cose non accadono velocemente, gli utenti penseranno che il prodotto non va bene. Quindi, dopo aver scritto tutte queste cose, ho bisogno di passare attraverso il lavoro e assicurarmi che sia all'altezza in termini di prestazioni. Questo è un grosso problema per quanto riguarda il Web: se le persone vedono un sito rallentare, passeranno rapidamente a un prodotto diverso per soddisfare la stessa esigenza, perché è davvero difficile vedere la differenza tra lento e rotto. Questo tipo di lavoro richiede in genere Z giorni (ottimizza le modifiche al DB per la velocità, il refactor e ottimizza il codice per la velocità)

Eviterei qualsiasi preventivo inferiore a mezza giornata. Dovranno fidarsi, ad un certo livello, di sapere di cosa stai parlando. E se pensano davvero che saranno solo 2 ore, quindi invitali a sedersi con te per 2 ore mentre li percorri esattamente come appaiono 2 ore nella vita di uno sviluppatore SW - quindi fai una lezione di codice 101 per circa 2 ore, per mostrare esattamente cosa bisogna considerare per iniziare a risolvere il problema.

Più importanti sono le seguenti cose:

• Acquista parlando principalmente della percezione dei clienti e dell'utilizzo del prodotto, stai arrivando parzialmente a parlare la loro lingua - la lingua di $$ - il punto è che se il codice viene hackerato insieme in modo scadente, alla fine perderai gli affari su questa funzionalità, quindi su alcune funzionalità successive quando pratiche di sviluppo scadenti hanno reso impossibile l'estensione del codice.
• Crea una sequenza di eventi. La prossima domanda non tecnica sarà "se avessimo più sviluppatori di te, succederebbe più velocemente? In tal caso, se ci vorranno 40 ore per farlo, 40 persone possono farlo oggi pomeriggio?" La risposta, ovviamente, è "NO! SEI FUORI DELLA TUA MENTE ??". Ma non è il migliore. Il migliore è che c'è una sequenza logica di passaggi qui. La cosa B non può essere fatta fino a quando la cosa A non è a posto (se non hai scritto alcun codice, non puoi davvero ottimizzarlo o testarlo ...). Le cose A e A 'potrebbero essere fatte insieme, quindi se potessero risparmiare quel ragazzo intelligente laggiù potresti radere il tempo da una settimana a 4 giorni e se possono garantire il fantastico supporto di test, allora probabilmente potresti arrivare a 3 giorni. Là'
• Concentrati sul rischio e preparati a sentirti dire che in questo momento ne valgono la pena. Questo è ciò per cui gli uomini d'affari vengono pagati un sacco di soldi per capire quali sono i rischi che vale la pena correre. Ad esempio, se la velocità di immissione sul mercato pesa prestazioni scadenti perché la tua azienda ha abbastanza denaro in mano per mettere in scena un numero ridicolo di server a breve termine, allora ti potrebbe essere detto di saltare tutta quella roba nel passaggio 4 (l'ottimizzazione del codice / database ). È il loro diritto - è solo il tuo lavoro spiegare i rischi inerenti a quella decisione.
• Tuttavia, se non ti fidi di queste persone, ottieni una conferma per iscritto - non deve essere conflittuale, solo una breve e-mail che dice "ecco cosa penso che abbiamo discusso, ecco cosa non sto facendo, ecco il rischio. Lo farò ora, quindi fatemi sapere se non siete d'accordo ... se non ho notizie, supporrò che questo sia il modo giusto di procedere ". Dato che la gestione del prodotto può essere il centro per la perdita di memoria a breve termine, questo è piuttosto utile per tutti.

C'è un detto: "Non puoi mettere dieci libbre di (merda) in un sacco da cinque libbre". Il tuo compito è quello di dimostrare che il compito è di dieci sterline e stanno chiedendo di averlo in un lasso di tempo di cinque sterline.

L'unica cosa che ti manca sono le stime del tempo. Metti una stima del tempo su ogni attività e mostra come tutte queste cose si sommano alla stima che fornisci. Non consentire che un preventivo superi le 4 ore. Se hai un'attività in cui dici "un giorno" o "10 ore", suddividilo in attività secondarie più piccole.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

Ora hai una fattura dettagliata dei costi. Tutto sommato, questo ammonta a un massimo di 27 ore di lavoro.

Ora puoi mostrarlo al tuo cliente e dire "Queste sono le cose che devono essere fatte, con il costo di ciascuna". Usa la parola "costo", perché il tempo è un costo e la direzione comprende i costi. Spiega che potresti eventualmente abbandonare le due attività di ottimizzazione alla fine, ma avranno un effetto negativo lungo la strada e rappresentano solo il 15% della stima totale.

Assicurati inoltre di spiegare realisticamente quali sono le tue ore / giorno. Ad esempio, se sei chiamato a fare supporto tecnico o a mantenere database o altro, calcola questo nel tuo preventivo. Non dire "Beh, posso fare 7,5 ore al giorno di buona programmazione" perché probabilmente non puoi. Probabilmente è più simile a 5 o 6.

Quindi, soprattutto, traccia i tuoi progressi. Supponi che puoi fare 5 ore al giorno di programmazione. Quindi dovresti essere in grado di interrompere le prime due attività (nel mio esempio) lunedì, terminare la terza e iniziare la quarta martedì, e così via. Fai una lista di controllo che lo mostri, in modo da poterli mostrare mercoledì quando arrivano e dire "Come va ancora a finire entro venerdì?"

Guarda le mie diapositive per il mio discorso Prevenire la crisi: stima del progetto e monitoraggio che funziona che ho tenuto all'OSCON qualche anno fa. Guarda la diapositiva 21, "Pianificazione della settimana". C'è anche un diagramma di velocità di esempio .

Chiediglielo:

Come lo faresti? Quali moduli cambieresti? Quante righe di codice? Quali sono le implicazioni per la sicurezza? Eventuali modifiche allo schema del database? Se si apportano modifiche al DB, quanti file sono interessati? Quanto tempo ci è voluto per aggiungere l'ultimo modulo? Qual è la media (media aritmetica) per l'aggiunta di un modulo? Qual è stata la più lunga? Stimerò che ci vorrà un minuto in meno del più lungo. Se non sai quanto tempo ci è voluto per aggiungere le ultime N forme, allora questa stima è garantita per essere accurata solo per un ordine di grandezza.

Potrei dirti di spiegare loro che il loro software è come una macchina da 100 tonnellate con 10.000 parti diverse, molte delle quali collegate in modo complicato. Montare un pezzo da 1 pollice in questa macchina richiede un po 'di ingegneria, in modo che non si rompa la macchina, MA la risposta migliore è:

Se tu avessi una migliore architettura del codice, ciò semplificherebbe le attività come questa? E la risposta è che la maggior parte dei team di software non sono bravi architetti (perché semplicemente non hanno accumulato tonnellate di modelli generici, architettonici o non sono padroni del dominio problematico per anticipare ogni problema) e non sono sempre bravi ingegneri , quindi non si sentono sicuri nel dare stime o fare promesse.

Proprio come ci è voluto il 20 ° secolo per accumulare una buona architettura e l'ingegneria per la costruzione di grandi edifici, gli strumenti per l'ingegneria del software non sono arrivati ​​al mainstream. Si stanno sviluppando: ci vuole una nuova mentalità. Vedi il codice Zen su wiki.hackerspaces.org/Hacking_with_the_Tao.