Come funziona la gestione dei progetti a Google?

Da quello che ho visto, i progetti software costruiti dai team di ingegneria a Google sono principalmente gestiti dai team responsabili, settimana per settimana. I team capiscono cosa devono costruire, e in quale ordine, per raggiungere i loro obiettivi a medio e lungo termine. Teniamo traccia dei compiti (di solito come bug nel nostro database dei bug, anche se ho visto team usare fogli di calcolo, tavole stile kanban coperte di post-it, e per un po' è stato popolare Pivotal Tracker). Li cancelliamo (o strappiamo la story card, per i team Kent Beck della vecchia scuola) quando abbiamo finito.

Il tracciamento dei compiti è la parte meno importante del problema.

Capire che quello che stai costruendo è la cosa giusta da costruire è l'aspetto più difficile e più importante di questo: non importa quando finisci il tuo compito se alla fine hai costruito qualcosa che non fa quello che è necessario. Diverse persone nella gerarchia manageriale hanno la responsabilità primaria per diversi aspetti di questo problema: gli ingegneri si assicurano che quello che stanno costruendo si adatti al disegno generale del sistema, i program manager si assicurano che il sistema che viene costruito sia effettivamente quello che serve, i direttori si assicurano che il lavoro non sia ridondante e che soddisfi le carte dei loro dipartimenti, e così via.

Il fatto è che lo sviluppo del software è quasi sempre esplorativo. Hai un piano, e molte persone hanno guardato il tuo piano per assicurarsi che stai facendo la cosa giusta nel modo giusto, e poi mentre costruisci la cosa scopri che le cose non funzionano come pensavi, per un'infinità di ragioni. Quindi c'è una grande quantità di comunicazione verso l'alto quando dici al tuo management cosa hai scoperto e quali sono le sue implicazioni.

Uno dei grandi vantaggi di lavorare a Google è che posso andare in una riunione con il manager del manager del mio manager e parlare di un problema che abbiamo scoperto, in dettaglio, ed essere capito. In ogni altro posto dove ho lavorato, dovevi controllare il flusso di informazioni verso l'alto perché avrebbe raggiunto qualcuno che non capiva la serietà (o non serietà) di ogni nuovo problema, e che avrebbe preso decisioni terribili come conseguenza. A Google, i manager tendono ad essere essi stessi ingegneri - il rischio quando si porta un problema alla loro attenzione è più che altro che comincino a lavorare per risolverlo loro stessi, che non è il loro lavoro.

C'è molta varianza con quello che sto descrivendo. Per esempio, Google ha lo stesso problema con i progetti su larga scala che ha chiunque altro nel software: più grande è un progetto, più difficile è controllare lo scopo e i confini del lavoro, e tenere conto dei diversi stili di lavoro tra i diversi gruppi. Questi sono problemi davvero difficili, specialmente perché nessuna persona sa abbastanza per sapere quale sia il modo giusto per conciliare questi problemi. In alcuni casi, il meglio che si può fare è indovinare.

Un altro problema è la velocità, e in particolare le scadenze. I team possono sempre muoversi più velocemente di quanto lo siano. Ma quello che si vuole è che vadano il più veloce possibile senza danneggiare se stessi e il loro prodotto di lavoro. Anche senza una scadenza, è difficile sapere come impostare correttamente quel quadrante. Il team si muove lentamente perché ci sono problemi tecnici? C'è un problema di morale? Non sono all'altezza? Sono annoiati? Sono distratti da problemi di minore priorità? La risposta a tutte queste domande è sempre "sì"; quello che non si sa è quanto, cosa si può fare per risolverlo, e se si dovrebbe farlo.

Inoltre, è difficile misurare la velocità. Quanto veloce sta effettivamente andando la squadra? Come si può dire? Abbiamo alcune metodologie interne che sono molto buone in questo, per alcuni tipi di team e alcuni tipi di progetti. Abbiamo anche team che giocano a poker di pianificazione per un po' e poi dicono al diavolo, porteremo a termine il nostro lavoro.

Quando c'è una scadenza, le cose diventano più rischiose, perché l'unico modo per portare a termine un software entro una scadenza è accettare dei vincoli. Lo faremo per allora, ma non farà tutto quello che volete. O non sarà all'altezza del livello di qualità di cui gli utenti saranno felici. O bruceremo i membri del team e si sposteranno su altri progetti o si licenzieranno.

Le scadenze significano anche che non solo il prodotto del team sarà soggetto a vincoli, ma il fatto che dobbiamo spendere così tanto del nostro tempo a lavorare per definire questi vincoli significa che avremo ancora più vincoli, perché il tempo che stiamo spendendo per negoziare un nuovo set di funzionalità è tempo che non stiamo spendendo per costruire funzionalità. Inoltre non avremo finito quando avremo finito, perché dovremo continuare a fornire funzionalità anche dopo il lancio. ("Abbiamo detto che avremmo lanciato nel Q2, e l'abbiamo fatto. Abbiamo lanciato il 73 giugno")

Questo suona piuttosto vago, e non sembra affatto un processo. Ma è davvero in linea con i principi generali della gestione dei progetti software. Niente nella Software Project Survival Guide di Steve McConnell è fuori luogo in Google, eccetto che il suo modello presuppone che il senior management non capisca lo sviluppo del software.

Relativamente a quello che ho osservato nel resto dell'industria, i progetti software di Google falliscono ad un tasso molto più basso. O meglio, falliscono presto, prima che il fallimento diventi doloroso e costoso. Due di noi passano una settimana a pianificare un progetto, a costruire un prototipo e a fare un po' di conti, e capiamo che "questo non funzionerà", e mentre ad un certo livello quel progetto è fallito, ad un altro è un grande successo, perché dieci di noi non hanno speso un trimestre per fare la cosa che non funziona.

Devo dire che questo approccio spesso non funziona così bene come la gente vorrebbe.

I più grandi "fallimenti" del software di Google sono successi incompleti, progetti costruiti da grandi team che arrivano al traguardo e poi devono essere fatti a pezzi e ricostruiti perché il loro design non era giusto, o perché il set di funzionalità non corrisponde ai requisiti reali, o il mondo è cambiato durante i diciotto mesi in cui il team stava lavorando alla loro cosa. Ci sono team a Google che sono assegnati a spazi di problemi critici per il business che sono così brutti e spinosi che anche quando hanno successo sembra agli esterni che devono aver fatto tutto sbagliato. Questo è davvero doloroso (soprattutto perché quei team stavano probabilmente lavorando anche sotto scadenza, con tutti i problemi che ho descritto sopra). Ma è anche un risultato inevitabile a volte. Guardi l'autopsia di progetti come questo e ti chiedi "dove hanno sbagliato?" ed è davvero difficile vedere come avrebbe potuto essere diverso.