Studio di 2 o agenzia di 30: da cosa dipende la qualità di un SaaS

La qualità di un SaaS è la quota di ciò che un team rilascia che funziona per gli utenti al primo colpo, e i due indicatori che la prevedono meglio sono quante persone toccano ogni parte del codice e se ogni parte ha un responsabile. Il numero di dipendenti scritto sul sito del fornitore non prevede né l'una né l'altra cosa. Uno studio di due persone e un'agenzia di trenta possono consegnare entrambi un prodotto che si guasta ogni settimana. E possono consegnarne entrambi uno che funziona.

Questo articolo è per il founder o il CTO che ha sul tavolo due preventivi, uno di un piccolo studio e uno di una grande agenzia, con una differenza di prezzo che chiede una spiegazione. La spiegazione più frequente è la qualità: un team grande fa pensare a competenze, revisioni e riserve, uno piccolo fa pensare a un rischio. La ricerca sui difetti del software misura qualcosa di più preciso, e lo puoi verificare su entrambi i fornitori prima di firmare. Se la domanda è quale perimetro di lavoro si addice a quale dimensione, parti dal nostro confronto tra piccolo studio e grande agenzia. Qui si parla solo di qualità.

Cosa dicono i dati su dimensione del team e difetti?

QSM, società di stima del software che raccoglie dati su progetti conclusi dal 1978, ha studiato la dimensione dei team più volte. Nel 2012 Kate Armel ha confrontato 1.060 progetti IT chiusi tra il 2005 e il 2011, divisi in team fino a 4 persone a tempo pieno (mediana 2,1) e team da 5 in su (mediana 8,5). Sui progetti piccoli i team più grandi sono costati 3 volte tanto e hanno prodotto il doppio dei difetti. Sui progetti grandi sono costati 4 volte tanto, con il triplo dei difetti. Il tempo guadagnato con le persone in più è stato poco.

Il risultato torna in tutti i campioni di QSM. Lo studio di Doug Putnam del 1997 su 491 progetti indicava come ottimali, per sistemi di medie dimensioni, team da 3 a 7 persone. Un campione successivo di 390 applicazioni ha messo a confronto team con meno di 4 persone e team da 9 in su: quelli più grandi hanno accorciato i tempi di circa il 30%, ma il costo è salito del 350% e i difetti da correggere in fase di test del 500%, secondo la sintesi di QSM dei suoi quattro studi sulla dimensione dei team.

C'è un'avvertenza che cambia la lettura di tutti questi numeri. QSM ha misurato il team sul progetto, non la dimensione dell'azienda per cui lavorava. Un'agenzia di 30 persone può mettere 4 persone sul tuo prodotto. Uno studio di 2 può chiamare collaboratori esterni finché nel repository non scrivono in 9. Il numero che conta è quello del team che tocca il codice, e nella prima pagina di un preventivo compare di rado.

Perché il numero di dipendenti è il numero sbagliato da confrontare?

Si legge in fretta, ma risponde a un'altra domanda: quanto lavoro un fornitore riesce a portare avanti nello stesso momento. La qualità dipende da come quel lavoro viene diviso. Melvin Conway ha descritto il meccanismo nel 1968, in How Do Committees Invent?: le organizzazioni che progettano sistemi sono costrette a produrre copie delle proprie strutture di comunicazione.

Un prodotto fatto da un reparto design, un team frontend e un team backend tende a mostrare le cuciture dove quei team si incontrano. Un prodotto fatto da due persone le mostra dove quelle due persone hanno smesso di parlarsi. La dimensione sposta le cuciture; ogni team ne lascia qualcuna, e i cinque punti che seguono dicono dove finiranno le tue.

Cinque cose da cui dipende la qualità di un SaaS

1. Quante persone toccano ogni parte del codice

Nel 2008 Nachiappan Nagappan, Brendan Murphy e Victor Basili hanno studiato 3.404 binari di Windows Vista, oltre 50 milioni di righe di codice, per capire quali misure prevedessero i binari che si sarebbero guastati dopo il rilascio. Otto misure organizzative, come il numero di ingegneri che avevano modificato un binario e la loro distanza nella catena gerarchica, hanno individuato i binari a rischio con una precisione dell'86,2% e un richiamo dell'84,0%. Le modifiche al codice (churn) si sono fermate al 78,6% e al 79,9%. La complessità del codice al 79,3% e al 66,0%. La copertura dei test ha raggiunto l'83,8% di precisione, ma solo il 54,4% di richiamo. Il modo in cui erano organizzate le persone diceva dove sarebbero comparsi i guasti più di qualunque proprietà del codice.

2. Se ogni parte ha un solo responsabile

Nel 2011 Christian Bird e i colleghi di Microsoft Research hanno proseguito con Don't Touch My Code, su Windows Vista e Windows 7. Hanno diviso chi contribuiva a ogni binario in contributori principali, con almeno il 5% delle modifiche, e contributori minori, sotto quella soglia. In Vista il numero di contributori minori era correlato ai guasti prima del rilascio con un coefficiente di 0,86 e a quelli dopo il rilascio con 0,70. La quota di modifiche del responsabile principale aveva una correlazione negativa, meno 0,49 in entrambi i casi. I componenti toccati poco da tante persone si guastavano di più. Quelli con un responsabile chiaro, di meno.

In un team piccolo la responsabilità viene quasi da sé, perché ci sono poche persone con cui dividerla. Un team grande può averla lo stesso, se la progetta: un responsabile con nome e cognome per ogni modulo, e ogni modifica che arriva da fuori rivista da quella persona.

3. Chi se ne va prima della fine

Tra le misure di Nagappan c'era anche il numero di ingegneri che avevano toccato un binario e poi avevano lasciato l'azienda. Chi eredita codice scritto da altri non sa perché è stato scritto così, e quei vuoti diventano difetti. Questo rischio non premia nessuna delle due dimensioni. In uno studio di due persone, un'uscita si porta via metà delle conoscenze. In una grande agenzia le persone passano da un cliente all'altro quando partono nuovi progetti, e lasciare il tuo progetto equivale a lasciare il tuo codice. Chiedi a entrambi i fornitori come gestiscono questi passaggi, e fai mettere la risposta nel contratto.

4. Quanti passaggi di mano separano il design approvato dalla schermata online

Ogni passaggio è un punto in cui qualcuno riformula una decisione che non ha preso. Il designer passa il file a chi sviluppa il frontend, che passa una richiesta di API a chi sviluppa il backend, che passa una build a chi fa QA. Ogni passaggio può essere fatto bene. Ognuno è anche un'occasione in più perché la schermata in produzione si allontani da quella che hai approvato. Conta i passaggi nel processo di ogni preventivo e chiedi a cosa serve ciascuno.

5. Chi scrive il codice e chi lo rivede

Le persone presentate in fase di vendita non sono sempre quelle che scrivono il codice. Vale per qualunque fornitore che venda più lavoro di quanto i suoi senior riescano a fare di persona, piccolo o grande che sia. È nella revisione che l'esperienza arriva al codice: un revisore senior su ogni modifica a pagamenti, autenticazione e accesso ai dati intercetta i difetti che costano di più da correggere dopo. Chiedi chi rivede, su quali parti del prodotto, e se una modifica può entrare senza quella revisione.

Dove non arriva un team di due persone?

La ricerca che premia i team piccoli ne segna anche i limiti. Due persone non portano avanti quattro filoni di lavoro insieme: un lancio con web app, due app native e una pipeline di dati alla stessa data richiede più mani. Due persone di rado coprono a fondo ogni specializzazione: un penetration test, un audit di accessibilità formale o una reperibilità 24 ore su 24 arrivano quasi sempre da fuori. E una responsabilità concentrata su due persone è anche un rischio concentrato su due persone. Un piccolo studio che prende sul serio la qualità dice quali specialisti coinvolge e cosa succede al tuo prodotto se una delle sue persone si ferma.

Quando un team di trenta persone vale la sua dimensione?

Una grande agenzia giustifica il suo organico quando il lavoro si divide in filoni paralleli, ciascuno guidato da un team piccolo con il proprio responsabile. Trenta persone organizzate in cinque team da sei si comportano, stando ai dati visti sopra, come cinque team piccoli con un costo di coordinamento in più. Trenta persone tenute in un unico gruppo e assegnate a ciò che è urgente questa settimana si comportano come i team grandi dei dati QSM. Il preventivo non ti dice quale delle due stai comprando. Le domande qui sotto sì.

Come verificare la qualità di un fornitore prima di firmare?

1. Fatti dire chi scriverà nel repository. Nomi e ruoli, e se quei nomi entrano nel contratto.
2. Chiedi la mappa delle responsabilità. Chi segue pagamenti, autenticazione, modello dei dati e design system? Un nome per ciascuno.
3. Chiedi la regola di revisione. Quali modifiche richiedono un secondo revisore, e chi è.
4. Chiedi cosa succede quando qualcuno lascia il progetto. Preavviso, periodo di affiancamento, passaggio di consegne scritto. Le clausole da cercare sono nel nostro articolo sulle otto clausole da controllare nei contratti.
5. Chiedi quali numeri di rilascio tengono sotto controllo. DORA, il programma di ricerca sul rilascio del software attivo da anni, misura l'instabilità con due rapporti: il change fail rate, la quota di rilasci che richiedono un intervento immediato, e il deployment rework rate, la quota di rilasci non pianificati causati da un incidente in produzione. Un fornitore che misura almeno uno dei due ti può mostrare un andamento. Uno che non ne misura nessuno stima la propria qualità a sensazione.
6. Chiedi di vedere lo storico di un progetto simile. Anche con i nomi nascosti, un log dei commit mostra quante persone hanno toccato ogni modulo e quanto spesso un rilascio è stato seguito da correzioni.

Una breve fase di discovery a pagamento è il modo più economico per vedere queste risposte all'opera prima del contratto principale. Le domande per la prima call sono nella nostra guida su come scegliere uno studio di product engineering.

Come la vediamo noi

Siamo un piccolo studio, quindi leggi questa sezione tenendone conto. I dati premiano un team sul codice piccolo, stabile e con responsabili chiari, chiunque sia a pagarlo, e un piccolo studio può mancare questo obiettivo tanto quanto una grande agenzia. Quando un progetto chiede più filoni paralleli di quanti un team piccolo ne possa seguire, lo diciamo alla prima call.