The Old Intense Minimalism

The coolest stuff is done by small teams without ton of resources

Scoble oggi scrive:

Note that it wasn’t a team of 100 people who did it. Two guys with a supporting cast of maybe a dozen. I’ve noticed a trend at Microsoft: that the coolest stuff is done by small teams without a ton of resources.

Ora, maccheccazzo. E’ concepibile che quello che è uno dei ‘guru’ in rete, seguito dai più e con opinioni anche valide e sensate (mileage may vary) se ne esce con una frase così?
Si accorge ora che non servono 100 persone? Tanto da farlo notare nel post!

Voglio dire, vive negli USA, ed esempi simili dovrebbe averne a migliaia sotto gli occhi. Google non è stato creato da DUE persone? E Microsoft, non erano DUE persone?

E non si parla solo di startup. Google separa internamente i suoi team in gruppi di lavoro che hanno mediamente 5 persone: “most projects in the Googleplex are implemented using team sizes of 3-5 developers”.

Voglio dire, è un campo che sto ancora studiando e riserverò sicuramente spazio più avanti, ma diamine. Più il gruppo cresce, più comunicare diventa un problema, diminuisce la sincronizzazione e quindi l’efficienza.

Certo, non possono essere gruppi casuali: su 5 persone tutte fanno la differenza e quindi se si uniscono persone poco competenti è evidente che non potranno concludere niente di innovativo.
Le persone devono essere in buoni rapporti, integrate e complementari.

Non solo: è anche evidente che oltre alle 5 persone deve esistere una infrastruttura che li lasci liberi di concentrarsi: burocrazia, marketing, etc, devono essere cose che non pesano direttamente su di loro. Pensate a Google: le 5 persone sono tutte concentrate a fare il progetto. Qualcun altro peneserà al resto. Pensate anche a Microsoft Research di cui sopra, uguale.

Ovviamente non è affatto escluso che ad esempio la parte marketing sia organizzata in un altro gruppo del tutto analogo.

Sia ben chiaro, qui parlo di gruppi formati da persone estremamente qualificate, ma il vantaggio anche se in misura minore si avrebbe comunque anche in altre situazioni, anche solo per il puro fattore di comunicazione fra le persone che oltre una certa cifra diventa difficile. E’ banale: se c’è una cena, andare oltre le 8 persone diventa disgregante perché per semplici motivi spaziali si formeranno gruppetti dettati solamente dall’adiacenza.

Spesso si solleva il problema della scala come controtesi: “si, ma se il progetto cresce in dimensioni e complessità, diventa ingestibile con un team piccolo”.
Questo è evidentemente un problema, ma se si è consci di cosa si sta costruendo si può riuscire ad evitare o comunque minimizzare.
La soluzione infatti è quella del divide et impera, ove si spezza il progetto in più parti in modo da creare una serie di gruppi di lavoro distinti e focalizzati, tutti efficenti.

Un gruppo ad esempiò può semplicemente lavorare sull’infrastruttura, mentre un altro sul progetto. Per prendere un esempio tecnico, è come avere una parte che lavora su Ruby on Rails e un altro gruppo che usa questo framework per creare il prodotto effettivo.
L’esempio è generalizzabile: se io, oggi, sono in grado di creare un piccolo sito in pochi giorni è solo perché qualcuno ha lavorato sui livelli di astrazione inferiori, quindi io non ho bisogno di collegare internet, inventare il protocollo, inventare l’HTML, inventare il browser, creare il linguaggio di programmazione, creare il framework e creare la pagina. Tutte queste cose sono state gestite da altre persone e io posso costruire sopra.

Anche progetti enormi, come per esempio Firefox che stavo studiando recentemente, hanno le competenze separate in modo che vi siano gruppi più piccoli e separati. Prendo la cosa che osservavo da vicino: la nuova theme per Mac è stata progettata da due persone, viene realizzata da altre due. I contributi poi son di tutti, ma il team è piccolo. Molto piccolo. E focalizzato.

Quindi, caro Scoble, l’acqua calda, esiste già da un bel po’.