Dovresti promettere di fornire una funzionalità che non sei sicuro se sia implementabile?

Questa è la seconda domanda in rapida successione innescata da quell'articolo.

• Buon programmatore: ottimizzo il codice. Programmatore migliore: strutturo i dati. Miglior programmatore: qual è la differenza?
  C'è un altro nome per questo: ottimizzazione prematura.

• Non utilizzare mai le prime uscite.
  Questa è la regola "single point of entry / single point of exit". È una patch sul vero problema, che è che uscire presto potrebbe lasciare un casino. La regola giusta è "ripulisci il tuo casino". Una regola ancora migliore è usare i costrutti di dati che puliscono da soli, così il programmatore non deve preoccuparsi di ripulire il loro casino.

• E ora, Dì sempre al tuo cliente / utente "sì", anche se non sei sicuro. Il 90% delle volte troverai un modo per farlo.
  Anche questo è un pessimo consiglio.

A volte il tuo cliente ha bisogno di sentirsi dire no, o "in quale millennio vuoi questo?" Non promettere qualcosa che distruggerà la tua architettura, che costerà molto più di quanto il cliente è disposto a spendere, o che non hai la minima idea su come ottenerlo. Conosci la tecnologia, non il cliente. Se non sai come farlo, non dire che puoi farlo. Se non sei sicuro, dì che hai bisogno di tempo per cercare se è possibile. È meglio essere onesti e ti terrà lontano dai guai.

I clienti diventano rapidamente ex-clienti se non è possibile mantenere le promesse. Una percentuale di errore del 10% potrebbe sembrare piccola, ma è il 10% su cui i tuoi clienti si concentreranno. A volte fanno causa quando non riesci a mantenere ciò che hai promesso. Davvero non lo vuoi. Altre volte, assicurarti di essere in grado di mantenere una promessa può farti andare in bancarotta, impazzire o perdere il coniuge perché lavori per 18 ore al giorno. Non vuoi neanche quello.

Pensa in questo modo: cosa pensi che succederebbe all'industria aerea se il 90% di tutti gli atterraggi di aeroplani avesse successo? Pensi che tornare indietro e scusarti per il 10% che si è schiantato avrebbe riparato qualcosa?

Sarebbe meglio dire "penso che si possa fare". o "controllerò e torno a te". Ho avuto occasioni in cui ho detto di no o di contro proporre qualcosa. Se il cliente desidera "un'applicazione basata su browser che funzioni senza mai essere connessa a Internet e utilizzi un feedback tattile", probabilmente è possibile. Ma è costoso e sarebbe più utile discutere di quali siano i bisogni effettivi.

Il cliente ti rispetterà se sei onesto. Nel consiglio nella domanda, la persona sbaglia il 10% delle volte. Se lavoro con qualcuno che sbaglia regolarmente uno ogni dieci volte, non mi fiderò affatto di lui / lei. È un record orribile.

Promettere la luna e liberare una roccia è una sorta di approccio da venditore che non dovrebbe essere tollerato. Se non sai se è possibile, fai una ricerca. Oppure, dai loro una citazione sulla quantità di tempo che dovrai prendere per esaminarla. In questo modo non prometti nulla che non puoi consegnare, ma ti viene pagato per il tempo necessario a esaminarlo.

Questa domanda è stata studiata formalmente ed è indirizzata dal IEEE Computer Society / ACM prodotto congiuntamente Codice etico .

2.01. Fornire un servizio nelle proprie aree di competenza, essere onesti e schietti su eventuali limitazioni della propria esperienza e formazione.

3.04. Garantire che siano qualificati per qualsiasi progetto sul quale lavorano o propongono di lavorare con un'appropriata combinazione di istruzione, formazione ed esperienza.

3.09. Garantire stime quantitative realistiche di costi, programmazione, personale, qualità e risultati su qualsiasi progetto sul quale lavorano o si propone di lavorare e fornire una valutazione dell'incertezza di queste stime.

5.05. Garantire stime quantitative realistiche di costi, programmazione, personale, qualità e risultati su qualsiasi progetto sul quale lavorano o si propone di lavorare e fornire una valutazione dell'incertezza di queste stime.

Ci sono certamente implicazioni commerciali e legali sulla promessa di qualcosa che non puoi offrire. Di solito questi vengono dal cliente che va altrove, rifiutando di pagare o facendo causa alla sua compagnia. Se si è in una partnership con altri, possono chiedere i danni se la parte non viene consegnata. Le cause legali possono arrivare anche dai concorrenti.

C'è una storia dai primi tempi dei supercomputer dove Seymour Cray e un team di Control Data Corporation erano vicini al lancio di un prodotto, e un'altra azienda di computer molto grande ha comunicato ai suoi clienti che era anche vicino al lancio. La bugia costava molto alla CDC e si trasformava in una causa in cui la grande compagnia non poteva mostrare alcuna prova credibile per le sue affermazioni. Il risultato fu quello che all'epoca era un grande insediamento del valore di $ 80 milioni di dollari nel 1970 (circa $ 223 milioni nel 2012, aggiustato per l'inflazione). Puoi leggerlo qui:

link

Dato abbastanza tempo, risorse e flessibilità intorno alla definizione del successo tutto è possibile. L'esempio della x-massa bianca è facile se desideri solo una precisione superiore al 50% e hai la posizione geografica dell'utente e un po 'di dati statistici.

La vera prima domanda nella maggior parte dei progetti non è se qualcosa è possibile, ma se è ragionevole dato un certo insieme di circostanze.

La funzione aggiunge abbastanza valore da giustificare la spesa del tentativo?

Anche se l'idea sarebbe davvero fantastica, se richiedesse un lungo periodo di sviluppo o l'acquisizione di un hardware più esotico sarebbe meglio che il cliente lo sapesse in anticipo e poi riportasse la conversazione a obiettivi più ragionevoli in la maggior parte dei casi.

Se qualcuno è abbastanza pazzo da darti un assegno in bianco e nessun termine, allora dì loro assolutamente tutto è possibile, fai solo sapere loro che devi inventare e amp; distribuire molte delle tecnologie coinvolte nel raggiungere l'obiettivo lungo la strada.

D'altra parte, quando si tratta di clienti ragionevoli con risorse ragionevoli a volte non c'è niente di peggio che dire al cliente che alcune funzionalità devono essere tagliate dopo che l'hai accettata perché potrebbero essere già scappate e aver speso tempo / denaro / risorse che lo promuovono o documentano e che il 10% potrebbe essere stato l'elemento che ha reso il progetto greenlit in primo luogo. Sali su queste situazioni e hai appena perso un cliente, e più che probabilmente hai avuto un brutto riferimento verbale in un intero mercato.

Come difendere il diavolo

Essendo di una mentalità analitica, i tecnici tendono a presumere che le loro prestazioni saranno giudicate principalmente sulla base di una scorecard di richieste completate o confermate, ma in pratica non è così netto.

Prima che inizi anche lo sviluppo, i clienti iniziano a formarsi opinioni sulle prestazioni di una squadra in base al loro livello di fiducia e disponibilità a impegnarsi.

Parte della ragione di ciò è che i clienti possono avere difficoltà a valutare se l'esitazione di un appaltatore a impegnarsi è dovuta alla semplice difficoltà della richiesta o alla mancanza di capacità del contraente.

Poiché non esistono criteri assoluti per misurare la difficoltà di una richiesta, spesso ciò che è più importante per il cliente è la fiducia che il contraente sta dando il 100% di impegno, piuttosto che il 90% o il 100% delle richieste sono soddisfatte.

Supponiamo che il cliente debba scegliere tra due scenari:

Contractor A :

• Fiduciosi che possono fornire su tutte le richieste
• Risultato: 90% delle richieste consegnate
• Il cliente è soddisfatto che il contraente ha dato il 100% di impegno
• Il cliente percepisce che le richieste non completate erano dovute a problemi imprevisti, che probabilmente al di fuori degli appaltatori controllavano

Contraente B :

• Si impegna a consegnare il 90% delle richieste. Non è sicuro di poter consegnare il restante 10%
• Risultato: 90% delle richieste consegnate
• Il cliente è deluso dal fatto che il contraente non abbia provato a completare l'altro 10% delle sue richieste
• Il cliente presume che il 10% delle richieste non completate siano dovute a mancanza di sforzi o capacità del contraente

In entrambi gli scenari, è stato consegnato lo stesso numero di richieste; tuttavia, il cliente ha ritenuto che l'appaltatore A "overcommitting" stava dando il 100% di sforzo e lo ha usato per convalidare che le restanti richieste erano davvero difficili, per il credito dell'Appaltatore A.

Il rovescio della medaglia, il cliente si sentiva come l'appaltatore B non stava dando il 100% sforzo e la sua incapacità di completare tutte le richieste era dovuto alla mancanza di sforzo o abilità del contraente B.

Disclaimer: non sto sostenendo l'overcommitment come strategia; questa è solo un'osservazione di una possibile situazione del mondo reale in cui l'overcommitment potrebbe avere risultati positivi.

Dovresti dire loro di darti il tempo di creare una "soluzione spike" .

Una soluzione spike è un piccolo programma che, nel codificarlo, ti permette di capire come fare, o anche se è possibile, qualcosa che sta creando incertezza in un progetto.

Ad esempio, supponiamo di non aver mai inviato SMS a livello di programmazione, ma in qualche modo sai che è possibile. Una soluzione spike sarebbe quella di creare un piccolo programma che invia un SMS. In questo modo non è più un'incertezza e puoi fare ulteriori stime sulla fattibilità.

Ecco cosa la documentazione di programmazione eXtreme dice su di essa:

Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate. When a technical difficulty threatens to hold up the system's development put a pair of developers on the problem for a week or two and reduce the potential risk.

Secondo la mia esperienza, quando un utente richiede qualcosa, dovresti chiedere loro una specifica dettagliata di ciò che l'utente desidera o di cui ha realmente bisogno. Più spesso, non sentirai mai più la richiesta.