Come scegliere un partner per lo sviluppo software

Una società di software che scrive una guida su come scegliere una società di software ha un evidente conflitto di interessi: cominciamo quindi dalla credenziale che conta davvero. Una parte consistente del nostro lavoro consiste nell’ereditare progetti andati storti altrove. Salvataggi, riscritture, modernizzazione di sistemi vecchi di tre anni e già legacy. Vediamo dall’interno che aspetto ha la scelta sbagliata, diciotto mesi dopo la firma del contratto - e lo schema è notevolmente costante. Quasi mai il committente ha scelto male per disattenzione. Ha scelto male perché il processo di valutazione standard misura le cose sbagliate.

Viste da fuori, le società di sviluppo sono quasi indistinguibili. I siti mostrano gli stessi casi studio, gli stessi loghi, le stesse affermazioni su ingegneri senior e consegna agile. Il nostro compreso. E gli strumenti a cui ricorre chi compra per sciogliere il dubbio - portfolio, referenze, listini - sono esattamente gli strumenti che ogni società lucida da anni. Questa è una checklist per guardare oltre.

Perché referenze e portfolio ingannano

Un portfolio è una raccolta dei momenti migliori. Ogni società mostra i suoi tre progetti migliori, e quella selezione non dice nulla sulla collaborazione mediana: un portfolio è distorsione da sopravvivenza per costruzione. I progetti finiti con un anno di ritardo, quelli consegnati e poi abbandonati in silenzio, quelli finiti in contenzioso non sono sul sito, e la riservatezza offre a ogni società una ragione rispettabile per i vuoti. Leggere un portfolio dice qual è il tetto di una società. Si convive però con la sua mediana.

Le referenze hanno lo stesso difetto con un volto più amichevole: le sceglie la società. Le verranno dati i tre clienti più soddisfatti degli ultimi cinque anni, e non le verrà mai dato il numero di quello il cui progetto è stato abbandonato. Anche una referenza sinceramente entusiasta è una prova debole, perché il risultato dipendeva dal team specifico assegnato in quell’anno - e le persone che hanno costruito il caso studio di punta potrebbero nel frattempo aver cambiato lavoro due volte.

Vale comunque la pena chiamarle: bisogna solo fare domande diverse. Non «siete stati contenti», che invita a un sì imparato a memoria, ma «mi racconti il mese peggiore del progetto, e che cosa hanno fatto per rimediare». Ogni collaborazione di una certa dimensione ha un mese brutto. Se la società ha portato il problema allo scoperto per tempo, ha rivisto il prezzo con onestà e ha risolto - oppure è sparita e ha continuato a fatturare - è l’informazione più utile che una referenza possa dare.

Che cosa rende valido un partner di ingegneria del software: quattro segnali

Il primo è come stimano. Una società che dà un numero prima di aver capito la sua operatività sta dicendo come lavora. Una stima vera viene dopo domande vere - sui suoi flussi di lavoro, sui suoi dati, sui sistemi che già utilizza, sulle eccezioni che rendono la sua azienda quella che è. Se il prezzo arriva prima di quelle domande, non è stato ricavato dal suo progetto: è stato fissato per vincerlo, e la differenza tra quei due numeri riemergerà più avanti, travestita da richieste di variazione. Se vuole un punto di riferimento prima della prima call, ecco che cosa determina davvero il costo del software su misura.

Il modo di stimare prevede il modo di consegnare. Una società che tira a indovinare sul prezzo tirerà a indovinare anche sulla realizzazione.

Il secondo è a che cosa dicono di no. Lo chieda direttamente: quali progetti avete rifiutato, e perché? Una società che non sa citarne nemmeno uno o accetta tutto ciò che paga - e allora il suo progetto sarà seguito da chi è libero, non da chi è adatto - oppure non ha mai riflettuto seriamente su dove è davvero brava. La forma dei rifiuti di una società è la mappa più onesta della sua competenza che si possa ottenere in un processo commerciale.

Il terzo è chi scrive il codice. Le persone che incontra nei primi tre appuntamenti di solito non sono quelle che costruiranno il suo sistema. Chieda di conoscere il tech lead che seguirebbe il suo progetto - l’ingegnere vero, non il responsabile della delivery - e gli ponga domande tecniche sul suo problema. Una società che ha fiducia nei propri ingegneri li mette davanti al cliente senza esitare. Una società che la tiene al livello commerciale sta gestendo un’impressione.

Il quarto è com’è fatto il passaggio di consegne. La fine di una collaborazione è il punto in cui gli incentivi divergono di più: tutto ciò che viene prima il fornitore ha interesse a farlo bene; documentazione, passaggio di consegne e la sua indipendenza sono le parti che gli costano soltanto. Chieda quindi delle prove - un documento di architettura anonimizzato, un runbook o un pacchetto di consegna di un progetto concluso. Una società che riesce a produrlo l’ha già fatto e si aspetta che lei possa proseguire senza di loro. Una società che parla di partnership invece di mostrare un documento sta descrivendo con garbo un lock-in.

Sono questi quattro segnali a distinguere un partner di ingegneria del software da un fornitore che vende ore: il primo risponde del risultato, il secondo del timesheet.

Campanelli d’allarme per cui vale la pena andarsene

La seniority come esca è il più comune. Gli ingegneri senior conducono la presentazione e la discovery; dal secondo mese la cronologia dei commit racconta un’altra storia. Ci si protegge in modo strutturale, non con la fiducia: persone indicate per nome nel contratto, il diritto di conoscere qualsiasi sostituto prima che entri nel team e uno sguardo a chi si presenta davvero agli standup.

Fatturazione a ore senza disciplina di perimetro. Lavorare a ore non è sbagliato di per sé - ma le ore senza milestone, senza un perimetro messo per iscritto e senza una definizione di «fatto» significano che il fornitore guadagna di più quanto più il progetto dura, e nella struttura non c’è nulla che si opponga. La domanda da fare non è «a ore o a prezzo fisso» ma «di chi è la responsabilità della stima». Se la risposta è «sua», allora la disciplina di perimetro è lei. (L’alternativa l’abbiamo descritta in perché il software a prezzo fisso fallisce e come lo risolve la fatturazione a milestone.)

«Possiamo partire lunedì.» Una società che ha l’intero team disponibile da domani sta dicendo qualcosa sulla domanda per il proprio lavoro. Le finestre libere esistono davvero - un progetto finisce, una data di avvio slitta - ma un intero team senior fermo in panchina è raro in qualsiasi società che valga la pena scegliere. Tratti la disponibilità immediata su larga scala come tratterebbe un chirurgo senza lista d’attesa.

Nessuna opinione sulle parti noiose del suo settore. Ogni dominio ha la sua meccanica poco affascinante - riconciliazione, casi limite normativi, eccezioni di prezzo, regole di pianificazione - ed è lì che i progetti affondano davvero. Un partner non ha bisogno di esperienza pregressa nel suo settore, ma deve accendersi sulle parti noiose, perché è lì che passerà la maggior parte del progetto. Se la conversazione continua a scivolare sulla superficie entusiasmante del prodotto, i nove decimi noiosi verranno imparati a sue spese.

Otto domande per la prima call

I segnali si leggono più facilmente quando li si chiede direttamente. Vale la pena porre queste domande alla lettera, più o meno in quest’ordine.

Ascolti cercando concretezza e un lieve disagio. Le risposte buone citano progetti reali, errori reali e vincoli reali; quelle cattive sono levigate, generiche e immediatamente compiacenti. La sesta domanda mette alla prova il giudizio sul perimetro: il partner giusto sosterrà una prima versione mirata in 2-3 mesi invece di una piattaforma in un anno, e le dirà quali parti del brief possono aspettare. La settima è il test del lock-in: un partner che conta di guadagnarsi il rinnovo rende economico andarsene - i suoi repository, la sua infrastruttura, la documentazione come risultato consegnabile - mentre un fornitore che punta a possederla diventerà vago.

Quando cambiare il suo partner per lo sviluppo software

Molti lettori di questa checklist non stanno scegliendo un primo partner: stanno decidendo se sostituire quello attuale. I segnali d’allarme raramente sono un unico disastro. Sono una deriva: scadenze mancate che smettono di arrivare con una spiegazione, un sistema che solo il fornitore sa rilasciare, richieste di modifica che costano di più ogni trimestre e un team che ruota più in fretta di quanto documenti. Se due di questi segnali sono veri, applichi la checklist qui sopra al suo partner attuale come se lo incontrasse per la prima volta.

Se decide di cambiare, l’ordine conta più del nuovo fornitore. Metta al sicuro per primi i repository, gli account dell’infrastruttura e le credenziali; si faccia consegnare la documentazione che esiste, per quanto scarna; e passi le consegne per gradi invece che con un taglio netto. Ereditare sistemi in questo modo è una parte importante di ciò che facciamo - veda come cambiare partner per lo sviluppo software senza perdere il progetto e modernizzare i sistemi legacy senza la grande riscrittura.

Ridurre il rischio della decisione: cominciare più in piccolo del contratto

Il problema più profondo nella scelta del partner non è un singolo segnale: è che il processo standard chiede di decidere tutto in una volta - due call, una proposta, un impegno a sei cifre. Nessun colloquio porta alla certezza su come si comporta una società in condizioni reali, ma se ne può comprare un piccolo campione. Invece di firmare il contratto grande, si comincia con una breve collaborazione diagnostica: una o due settimane dentro un solo flusso di lavoro, che finisce con una stima, uno schizzo di architettura e un calcolo del rientro che restano suoi qualunque cosa accada dopo.

Una diagnosi trasforma ogni segnale di questo articolo da affermazione in osservazione. Si guarda come stimano invece di chiederlo. Si conoscono gli ingegneri che costruirebbero davvero, perché una diagnosi è lavoro tecnico che il team commerciale non può fare. E alla fine si ha in mano un documento che si può portare a un’altra società - ed è questa la prova del nove. Se il risultato è utile solo nel caso in cui li si assuma, era un documento di vendita pettinato da risultato consegnabile. Alcune società lo fanno pagare, altre ne offrono una versione gratuita - noi lo facciamo, ed è così che comincia ogni nostra collaborazione - ma pagata o gratuita conta meno della forma: piccola, delimitata e con un risultato che sopravvive alla relazione.

È anche il modo più economico per scoprire che una società non fa per lei - la nostra compresa. Applichi questa checklist come si deve e potrebbe benissimo concludere che un altro partner è più adatto al suo progetto di quanto lo siamo noi. Non è un fallimento della checklist: è la checklist che funziona. Il senso di cominciare in piccolo è che quella conclusione, comunque vada, costa due settimane invece di due trimestri.

La versione compressa: ignori la vetrina dei momenti migliori e legga la società attraverso il suo comportamento. Il partner che le serve fa il prezzo solo dopo aver capito, sa dire che cosa rifiuta, le mette davanti gli ingegneri, le mostra un vero documento di passaggio di consegne e struttura la collaborazione in modo che andarsene sia facile. Perché il modo in cui una società si comporta prima del contratto - mentre sta ancora cercando di conquistarla - è il tetto del modo in cui si comporterà dopo.

Domande frequenti