Far comprendere ai non programmatori il processo di sviluppo

Quando si avvia un progetto per una società che non è principalmente una società di programmazione, una delle aspettative è che alla fine c'è un prodotto finito privo di bug e fa tutto il necessario immediatamente. Tuttavia, raramente è così.

Quali sono alcuni modi per gestire le aspettative e spiegare ai non programmatori come lo sviluppo del software differisce dagli altri tipi di sviluppo del prodotto?

Praticamente tutti con un computer hanno incontrato il concetto di "bug" in questi giorni, quindi potresti iniziare da lì. "Qual è il modo più fastidioso che un'applicazione non abbia mai fallito? Moltiplicalo per dieci e avrai l'esperienza dei nostri utenti se non dedichiamo risorse sufficienti a test e manutenzione."

E non sottovalutare il valore di stabilire un buon rapporto di lavoro con i non programmatori. Se riesci a stabilire che il tuo giudizio può essere attendibile, ti prenderanno sul serio quando suonerai l'allarme che X sta per fallire in modo spettacolare se non fai Y pronto, anche se non comprendono completamente il tuo ragionamento.

Un approccio che ho trovato di successo è questo:

Sappiamo tutti che un computer fa solo ed esattamente ciò che gli viene detto di fare.

La programmazione è il modo in cui raccontiamo un computer ora ciò che ciò che facciamo tardi .

Ciò significa che il modo in cui il tuo comportamento si comporta ora è dovuto alle intenzioni combinate di tutti coloro che hanno scritto il codice in esecuzione sul tuo computer. Se si considera la complessità del sistema operativo, dei driver, dell'ambiente di programmazione, delle librerie e così via, è facile vedere che nella maggior parte dei sistemi ci devono essere oltre 20k persone coinvolte e che potrebbero esserci oltre 100k.

Il codice scritto da ogni persona riflette la propria comprensione, motivazione, intenzione e capacità. Dato che il funzionamento impeccabile del sistema richiede che tutto il codice scritto da queste 20k persone interagisca senza errori - che tutto il codice debba concordare sul significato e sull'interpretazione del comportamento richiesto, il fatto sorprendente non è che abbiamo bug, ma che ne abbiamo così pochi.

IMO, ho scoperto che la trasparenza offerta da processi agili (ad esempio Scrum, Crystal, ecc.) Fa molta strada nel mostrare come lo sviluppo funziona per gli stakeholder medi.

La spiegazione della metafora è un'astrazione che perde, ma qui ci sono alcune idee che spesso funzionano per me:

Nota che nessuna di queste spiegazioni scusa il lavoro sciatto.

Pensa a un programma per computer come a una macchina, in cui ogni variabile è una parte mobile. Ciò rende anche un programma banale una macchina composta da centinaia di parti mobili.

Quando fallisce, ripiego sul fatto che mentre è matematicamente possibile dimostrare che un programma non ha errori, ci vuole molto tempo e non ne varrà la pena.

Infine, chiedo se Intel e Microsoft non sono in grado di evitare i bug, come si aspettano che noi?

Ho risposto a una domanda simile in modo più dettagliato , ma l'essenza è "Programmare è come costruire una fabbrica o una catena di montaggio".

Il modo tradizionale di affermarlo è il triangolo di gestione del progetto: i tre criteri concorrenti di portata, costo e programma; tipicamente espresso come "economico, veloce, buono - scegli due".

Alla fine di un processo di progettazione, sviluppo e distribuzione, l'aspettativa che un prodotto sia relativamente privo di difetti di progettazione e funzioni con una funzionalità specificata è perfettamente ragionevole. La stessa aspettativa è completamente irragionevole rispetto a un progetto, processo o professione.

Quale professionista basato sulle scienze, duro o morbido, non passa attraverso un processo di esplorazione, formando concettualizzazioni imprecise e imprecise, seguendo tattiche tutt'altro che ottimali (o semplicemente sbagliate), scoprendo cosa funziona attraverso prove ed errori e ripetendo il elaborare ripetutamente fino a quando non si esauriscono le risorse o si raggiunge un livello sufficiente di prestazioni?

Nessun processo è mai privo di difetti, sebbene possa avvicinarsi asintoticamente a livelli di qualità più elevati.

Questo è vero per la professione medica in cui le tattiche spesso implicano congetture e protocolli e gran parte dell'attività consiste essenzialmente nel debug di una macchina principalmente wetware. È vero per l'ingegneria civile e l'architettura in cui le applicazioni di nuovi materiali ingegnerizzati devono essere validate sul campo e possono fallire bruscamente dopo anni di servizio nonostante il rigoroso rispetto degli standard. È vero per il settore automobilistico in cui l'età e i cambiamenti nelle condizioni operative influiscono comunemente sulle prestazioni fino al punto di guasto, senza colpa dei servizi tecnici o di riparazione applicati. Lo sviluppo del software non è fondamentalmente diverso da queste professioni sotto tali aspetti, ha solo una parte maggiore della sua attenzione coinvolta nella creazione di macchine innovative e mirate.

Se hai familiarità con lo sviluppo di software hi-rel, come per il controllo di reattori nucleari, comunicazioni nello spazio profondo o dispositivi per impianti medici (ecc.), Potresti spiegare come il costo e la struttura dei tempi di consegna per quel livello di gestione dei progetti e QA potrebbe essere di dimensioni superiori a quelle che le normali aziende possono permettersi per i loro progetti software.

È possibile confrontarlo con qualcosa che possono vedere e, se possibile, utilizzare ogni giorno.

Ad esempio, l'automobile. Le auto hanno avviato dispositivi meno raffinati e affidabili di quelli che abbiamo oggi. Mentre le auto sono state prodotte per oltre 100 anni, ma probabilmente il software è circa la metà di quello. Le auto sono disponibili con personalizzazioni significative, alcune incluse nel prezzo (come la scelta del colore), altre come dimensioni del motore, tipo di trasmissione, ruota / pneumatico, livello di allestimento sono fattori di costo significativi.

Ci sono molti driver di funzionalità, qualità e costi per auto e software. Quindi puoi discutere di come la tecnologia del software, la disponibilità di competenze, forse anche dove è costruita, farà la differenza. Cicli di sviluppo appropriati (ad esempio, modelli annuali con piccoli cambiamenti, cambi corpo / motore / piattaforma ogni tre anni) sono guidati da una combinazione di esigenze del cliente e un processo di progettazione complesso. Alcuni prodotti iniziano a sembrare piccoli e difficili (si pensi alla Honda Accord), ma vengono migliorati ogni anno fino a quando non vengono classificati come migliori.

Le auto hanno richiami (spesso molto più costosi degli aggiornamenti del software) e miglioramenti incrementali sotto forma di modifiche apportate ai loro elenchi delle parti (pensa a correzioni di bug) e spesso hanno bisogno di supporto a lungo termine (pensa alla compatibilità con le versioni precedenti / successive). Gran parte del costo della tua auto viene dopo che la porti a casa. Gran parte del costo del software arriva dopo il rilascio iniziale del prodotto durante l'aggiornamento e l'aggiornamento dei clienti.

In alcuni casi, è possibile fare riferimento a prodotti noti che includono software o altri prodotti software. Ad esempio, i telefoni hanno un ciclo di rilascio e aggiornamenti e metodi per aggiungere funzionalità dopo la vendita iniziale per aumentare le entrate. I telefoni sono un ottimo esempio di compatibilità con le versioni precedenti. Troppo, e la gente non scaricherà il vecchio per comprarne uno nuovo. Troppo poco, e i clienti cercano disperatamente di avere un telefono che non odieranno prima che il suo contratto sia scaduto.

Prodotti come Windows, Microsoft Office, browser Web e pagine Web sono tutti software che possono essere utilizzati nelle discussioni. Sono stati aggiornati su cicli annuali o triennali, ma possono avere aggiornamenti automatici più frequentemente. Hanno bug e falle nella sicurezza che colpiscono i clienti a vari livelli, ma fanno parte del panorama nonostante i nostri migliori sforzi. I clienti possono ottenere correzioni gratuitamente, ma generalmente pagano per i miglioramenti, spesso come un pacchetto, a volte come un singolo modulo o tramite una chiave di licenza.

Leader del settore come Microsoft, Apple, Google e Amazon offrono agli utenti clienti relativamente economici. Ma hanno enormi spese che hanno permesso quei prodotti. La loro esperienza dimostra che il software è costoso, ma prezioso e redditizio. Spesso scendono a compromessi tra qualità, avere tutte le funzionalità che desiderano e entrare nei mercati quando i tempi sono giusti. Non tutti i prodotti che realizzano sono un successo, e talvolta trasformano i cani in vincitori rinominando, migliorando il marketing e le vendite o tagliando le perdite e usando ciò che hanno appreso nei prodotti successivi.

Forse prova a guidarli, uno contro uno o in piccoli gruppi idealmente, usa i casi di software che devi sviluppare. Mentre descrivono i casi d'uso, identificare i punti nel caso in cui possano accadere cose diverse (casi imprevisti ma non irragionevoli). Inizia a elencarli, chiedi alcuni chiarimenti e illustra tutte le decisioni e le indicazioni che devono essere prese o risolte, e i compromessi in corso. Continua fino a quando non sono sconcertati e non possono darti una risposta. Fagli capire che, quello che stai facendo ora con loro, è esattamente quello che fai tutto il giorno, probabilmente da solo, probabilmente con una direzione molto meno chiara, sia decidendo il corso che scrivendo il codice, per centinaia o migliaia di utilizzare casi che possono o non possono essere neppure definiti da nessuno. E quando c'e ' nel caso in cui non avessi pensato a te stesso, non puoi garantire ciò che farà il programma. Forse fa la cosa "giusta", forse nota. Ed è quello che è un bug. Ed è per questo che scrivere software richiede tempo. Meno tempo hai, meno casi hai avuto la possibilità di considerare e accogliere, e più è probabile che il programma non farà la cosa "giusta" in una circostanza sconosciuta.

Costo e tempo.

Tempo

Stabilisci le aspettative che porteresti X in Y per un periodo di tempo. Non avrà niente di più, niente di meno. Quindi dì loro che cosa avrà la prossima versione in che ora. All'inizio potrebbero essere sorpresi di credere che la costruzione di X richieda una quantità di tempo Y: è qui che spieghi il tempo impiegato e le complessità della costruzione di un software. Se non sono sorpresi, o hai stimato molto meno tempo o sapevano meglio di quanto pensi di costruire software.

Costo

Questo è tratto dal libro Code Compete di Steve McConnel (che cita dalla memoria, quindi scusami se non sono riuscito a trasmetterlo con lo stesso effetto) - È facile per i clienti chiedere nuove funzionalità. Come product manager, non dovresti dire a cosa chiede il cliente. Dovresti stimare quanto impegno e costo sono necessari per creare quella nuova funzionalità. Capiranno lentamente che la nuova funzionalità non vale davvero il denaro / tempo o forse che non ne hanno nemmeno bisogno. Non sto suggerendo di usare questa arma per spaventarle, ma di usarla onestamente e potrebbe aiutare a portare il punto a casa.

Le metafore sono astrazioni che perdono, ma sono piccoli passi che ti avvicinano alla comprensione.

La mia predilezione è che la creazione di software sia spesso come un processo simile all'architettura di una casa. Tuttavia, è più preciso pensarlo come la creazione di un sistema che stampa un progetto personalizzato basato su alcuni parametri e ne crea uno diverso per ciascuno dei suoi utenti. Nei discorsi geek che sono meta-architeting.

Ho scoperto che potrebbe davvero aiutare quando mostri loro cosa significa scrivere codice. Mostra agli stakeholder la base di codice con cui stai lavorando. Anche quando hai scelto una buona variabile e nomi di metodi, la maggior parte delle persone penserà che stai usando una sorta di magia nera. Forse capiranno perché hai bisogno di più di "pochi giorni" per implementare una nuova funzionalità per il loro software.