Dovresti promettere di offrire una funzionalità di cui non sei sicuro che sia implementabile?

In un articolo di HN , mi sono imbattuto nel seguente consiglio:

Dì sempre al tuo cliente / utente "sì", anche se non sei sicuro. Il 90% delle volte, troverai un modo per farlo. Il 10% delle volte, tornerai indietro e ti scuserai. Piccolo prezzo da pagare per la grande crescita personale

Ma ho sempre pensato che si dovrebbe fare un'analisi di fattibilità prima di fare qualsiasi tipo di promessa a un cliente / utente, in modo che non vengano fuorviati in nessun momento. In quali circostanze, quindi, dovrebbe essere applicabile il consiglio di cui sopra?

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

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

• Non usare mai uscite anticipate.
  Questa è la regola "singolo punto di entrata / singolo punto di uscita". È una patch per il vero problema, che è che uscire presto potrebbe lasciare un casino. La regola giusta è "ripulisci il tuo pasticcio". Una regola ancora migliore è quella di utilizzare costrutti di dati che ripuliscono dopo se stessi in modo che il programmatore non debba preoccuparsi di ripulire il proprio 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 consiglio incredibilmente negativo.

A volte il tuo cliente deve sentirsi dire di no, o "in quale millennio lo vuoi?" Non promettere qualcosa che distruggerà la tua architettura, che costerà molto più di quanto il cliente è disposto a spendere o che non hai idea di come raggiungerla. Conosci la tecnologia, non il cliente. Se non sai come farlo, non dire che puoi farlo. Se non si è sicuri, dire che è necessario del tempo per cercare se è possibile. È meglio essere onesti e ti terrà fuori dai guai.

I clienti diventano rapidamente ex clienti se non riesci a mantenere le promesse. Un tasso di fallimento del 10% può sembrare piccolo, 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, assicurarsi di mantenere una promessa può farti fallire, impazzire o perdere il coniuge perché lavori 18 ore al giorno. Neanche tu lo vuoi.

Pensala in questo modo: cosa pensi che succederebbe al settore aereo se il 90% di tutti gli atterraggi di aerei avessero successo? Pensi che tornare indietro e scusarsi per il 10% che si è schiantato avrebbe risolto qualcosa?

Sarebbe meglio dire "Penso che si possa fare". o "Controllerò e tornerò da te". Ho avuto momenti in cui ho detto di no o di aver proposto qualcosa. Se il cliente desidera "un'applicazione basata su browser che funzioni senza essere mai connesso a Internet e utilizzi il feedback tattile", probabilmente è possibile. Ma è costoso e sarebbe più utile discutere di quali siano le reali esigenze.

Il cliente ti rispetterà se sei onesto. Nel consiglio nella domanda, la persona ha torto il 10% delle volte. Se lavoro con qualcuno che sbaglia di routine uno su dieci, non mi fiderò affatto di lui. È una storia orribile.

Promettere la luna e consegnare una roccia è una sorta di approccio da uomo di vendita che non dovrebbe essere tollerato. Se non sai se è possibile, cercalo. Oppure, dai loro un preventivo sulla quantità di tempo che dovrai dedicare per esaminarlo. In questo modo non stai promettendo nulla che non puoi consegnare, ma vieni pagato per il tempo che ti serve per esaminarlo.

Questa domanda è stata studiata formalmente e viene affrontata dal Codice etico IEEE Computer Society / ACM .

2.01. Fornire un servizio nelle loro aree di competenza, essendo onesto e schietto su eventuali limiti della loro esperienza e istruzione.

3.04. Garantire che siano qualificati per qualsiasi progetto su cui lavorano o propongono di lavorare con una combinazione appropriata di istruzione e formazione ed esperienza.

3.09. Garantire stime quantitative realistiche di costi, programmazione, personale, qualità e risultati su qualsiasi progetto su cui lavorano o propongono di lavorare e fornire una valutazione dell'incertezza di tali stime.

5.05. Garantire stime quantitative realistiche di costi, programmazione, personale, qualità e risultati su qualsiasi progetto su cui lavorano o propongono di lavorare e fornire una valutazione dell'incertezza di tali stime.

Ci sono certamente implicazioni commerciali e legali sulla promessa di qualcosa che non puoi offrire. Di solito questi provengono da clienti che vanno altrove, rifiutano di pagare o fanno causa alla tua azienda. Se sei in partnership con altri, questi possono fare causa per danni se la tua parte non viene consegnata. Le cause legali possono persino provenire da concorrenti.

C'è una storia fin dai primi giorni di supercomputer in cui Seymour Cray e un team di Control Data Corporation erano vicini al lancio di un prodotto, e un'altra grande società di computer ha detto ai suoi clienti che era anche vicino al lancio. La menzogna è costata molto a CDC e si è trasformata in una causa in cui la grande azienda non ha potuto 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 1970 (circa $ 223 milioni nel 2012, adeguati all'inflazione). Puoi leggerlo qui:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

Dato tutto il tempo, le risorse e la flessibilità necessarie per definire il successo, tutto è possibile. L'esempio della massa x bianca è semplice se si desidera solo una precisione superiore al 50% e si ha 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 per giustificare le spese del tentativo?

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

Se qualcuno è abbastanza pazzo da darti un assegno in bianco e nessuna scadenza, allora digli che tutto è possibile, fai solo sapere loro che devi inventare e distribuire diverse delle tecnologie coinvolte nel raggiungimento dell'obiettivo lungo la strada.

D'altra parte, quando si ha a che fare con clienti ragionevoli con risorse ragionevoli, a volte non c'è niente di peggio che dire al cliente che alcune funzionalità devono essere tagliate dopo averlo accettato perché potrebbero essere già scappate e aver speso tempo / denaro / risorse per la documentandolo e che il 10% avrebbe potuto essere la cosa che ha dato il via libera al progetto in primo luogo. Caduta in quelle situazioni e hai appena perso un cliente, e molto probabilmente hai guadagnato una brutta referenza verbale in un intero mercato.

Interpretando l'avvocato del diavolo

Essendo di mentalità analitica, le persone tecniche possono tendenzialmente presumere che le loro prestazioni saranno giudicate principalmente sulla base di una scorecard di richieste completate vs impegnate, ma in pratica non è così semplice.

Prima ancora che inizi lo sviluppo, i clienti iniziano a formarsi opinioni sulle prestazioni di un team in base al loro livello di fiducia e volontà di impegnarsi.

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

Poiché non vi sono criteri assoluti per misurare la difficoltà di una richiesta, spesso ciò che è più importante per il cliente è la fiducia che l'appaltatore stia dando il 100% dello sforzo, piuttosto che se il 90% o il 100% delle richieste sono soddisfatte.

Supponiamo che il cliente debba scegliere tra due scenari:

Contraente A :

• Sicuro di poter consegnare su tutte le richieste
• Risultato: 90% delle richieste consegnate
• Il cliente è lieto che l'imprenditore abbia dato uno sforzo del 100%
• Il cliente percepisce che le richieste non completate erano dovute a problemi imprevisti, che probabilmente al di fuori del controllo degli appaltatori

Contraente B :

• Si impegna a consegnare il 90% delle richieste. Non sono sicuro di poter offrire il restante 10%
• Risultato: 90% delle richieste consegnate
• Il cliente è deluso dal fatto che l'appaltatore non abbia tentato di completare l'altro 10% delle sue richieste
• Il cliente presume che il 10% incompleto delle richieste fosse dovuto alla mancanza di sforzo o alla capacità del contraente

In entrambi gli scenari, è stato consegnato lo stesso numero di richieste; tuttavia, il cliente ha ritenuto che l'appaltatore A "ipercomprato" stia dando uno sforzo del 100% e lo ha utilizzato per confermare che le restanti richieste erano veramente difficili, a credito del contraente A.

D'altro canto, il cliente ha ritenuto che l'appaltatore B non stia dando il 100% di sforzo e che la sua incapacità di completare tutte le richieste fosse dovuta alla mancanza di sforzo o abilità del contraente B.

Disclaimer: non sto sostenendo l'eccessivo impegno come strategia; questa è solo un'osservazione di una possibile situazione del mondo reale in cui un eccesso di impegno 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 consente 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 codice, 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 dice la documentazione di programmazione di eXtreme :

Crea soluzioni di spike per capire le risposte a difficili problemi tecnici o di progettazione. Una soluzione spike è un programma molto semplice per esplorare potenziali soluzioni. Costruisci il picco per risolvere solo il problema in esame e ignora tutte le altre preoccupazioni. La maggior parte dei picchi non sono abbastanza buoni da mantenere, quindi aspettati di buttarli via. L'obiettivo è ridurre il rischio di un problema tecnico o aumentare l'affidabilità della stima di una user story. Quando una difficoltà tecnica minaccia di ostacolare lo sviluppo del sistema, mettere un paio di sviluppatori sul problema per una settimana o due e ridurre il rischio potenziale.

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