Yammer: La struttura tradizionale delle aziende di sviluppo è morta

Kris Gale, Vice President of Engineering presso Yammer, sostiene che i team piccoli siano la chiave per uno sviluppo rapido dei prodotti nelle grandi aziende. Esplora le sfumature della costruzione di organizzazioni nello sviluppo prodotto e spiega come prendere decisioni consapevoli durante una fase di crescita possa assicurare che non si perdano le qualità che rendono una startup unica e speciale. In definitiva, è compito di un direttore tecnico capire come organizzare e ottimizzare lo sviluppo software.

Team più piccoli consegnano più velocemente

Inizialmente, il team di Yammer seguiva un approccio piuttosto semplice. Ci si concentrava principalmente sul prodotto in sé e non ci si preoccupava troppo dell'organico durante la crescita dell'organizzazione. Man mano che l'azienda cresceva, però, si accorsero che l'incremento marginale di produttività con ogni nuovo sviluppatore diminuiva a causa di un maggiore overhead.

Allo stesso tempo, il resto del mondo si rendeva conto che Yammer stava creando qualcosa di grande. Ovunque, le startup cercavano di copiare il prodotto, e persino le grandi aziende lanciavano prodotti concorrenti. Da Yammer sapevano che poteva esserci solo un'unica azienda dominante sul mercato e che, se non fossero stati abbastanza agili, quella sarebbe stata un'altra. Le applicazioni web moderne devono essere agili e adattabili.

Per poter consegnare più velocemente, Yammer adottò l'approccio dei team piccoli. Ma questo significa molto più che semplicemente dividere un'azienda in piccoli team. Se questi team sono in qualche modo limitati nell'implementazione del codice, sono inutili. Devono avere la libertà di poter svolgere attività anche al di fuori dell'organizzazione.

Specializzazione nei team piccoli

All'inizio, le nuove feature di Yammer venivano suddivise tra i tre sviluppatori in base alla specializzazione. Non si era particolarmente rigidi. Quindi, se c'era molto lavoro con Rails, Gale poteva dare una mano, anche se Rails non era il suo punto forte. L'obiettivo dovrebbe essere creare gruppi simili, piccoli e specializzati, ma non puri silos, perché problemi diversi richiedono competenze diverse (e esperienze diverse).

Processi seriali e grandi aziende tecnologiche

Questo approccio funzionava davvero bene con tre sviluppatori. Quando il team di Yammer si ingrandì, però, si passò a un modello più tradizionale per le organizzazioni di sviluppo software, con una suddivisione per competenze tecniche. C'era un team di back-end, un team di front-end, un team mobile, ecc. Alla fine del 2010, non erano più solo tre sviluppatori a lavorare sulle feature, ma circa 30. Ma erano dieci volte più veloci? No.

Secondo la legge di Amdahl sull'esecuzione parallela dei programmi, l'incremento di velocità di un programma nell'uso di processori multipli è limitato principalmente dalla porzione sequenziale del problema [poiché il suo tempo di esecuzione non può essere ridotto tramite parallelizzazione]. Esempio: se hai un programma di cui puoi parallelizzare solo la metà, potresti raddoppiare la velocità anche con 100 processori. Con altri 100 processori non cambierebbe molto. Il tempo per la parte seriale del lavoro complessivo rimane quindi sempre lo stesso.

Le persone assumono erroneamente che nello sviluppo software il codice venga scritto in base alle specifiche – ma non è così. Le decisioni tecniche sono altrettanto importanti – e nessuno può costruire un'organizzazione di sviluppo se crede il contrario.

In una tipica organizzazione di sviluppo software medio-grande, si ha forse un team di front-end, un team di back-end e eventualmente un team di middleware. Questi team hanno la propria codebase e un proprio manager che riporta a un superiore. Il punto è che l'organizzazione e l'architettura del codice dovrebbero essere allineate.

Prima che i dirigenti possano suddividere e delegare il lavoro, devono prima decidere cosa esattamente costruire. Poi emergono domande come: "Su cosa lavorerà il team di back-end?" e "Come si collega con il team di front-end?"

Se i lavori vengono però suddivisi e delegati dai livelli dirigenziali superiori, come appena descritto, le cose vanno storte. Pensaci un momento. Se infatti chi deve implementare il codice trova un problema nelle specifiche, deve inviare una proposta di miglioramento fino al livello dirigenziale, che poi deve essere restituita verso il basso. Questo processo rallenta un prodotto e alla fine lo porta al blocco. Inoltre, gli sviluppatori in altre parti dell'organizzazione lo vedono come un disturbo, poiché non lavorano a stretto contatto con lo sviluppatore che ha proposto la modifica. Semplicemente non comprendono il motivo del cambiamento.

Da Yammer non volevano questo.

Il management non dovrebbe prendere decisioni di sviluppo

Si dovrebbero sempre assumere persone più brave e intelligenti di se stessi. Se si segue questo consiglio, non si dovrebbero forse affidare a queste persone le decisioni che altrimenti si sarebbero prese da soli? In definitiva, è compito del direttore tecnico costruire e promuovere un'organizzazione. Probabilmente dovrai concentrarti prima del previsto non più solo sulla scrittura del codice, ma orientare il tuo focus sull'organizzazione stessa.

Non credo che dovresti costruire un prodotto. Credo che dovresti costruire un'organizzazione che costruisce un prodotto.

Sii estremamente cauto nel fidarti dei manager per le decisioni di sviluppo. In realtà, dovresti delegare tutte queste decisioni verso il basso, alle persone che devono implementarle. È un chiaro segnale di allarme quando i manager sono gli unici a prendere decisioni per più di 30-40 persone.

Come si dovrebbero costruire le feature?

Quando in Yammer si costruisce una feature, si mira sempre a migliorare una delle tre metriche principali:

• Viralità
• Engagement
• Monetizzazione

Fondamentalmente, Yammer vuole costruire feature che attraggano clienti, li trattengano e che questi acquistino. Anche se i tuoi indicatori chiave possono essere diversi, dovresti sicuramente iniziare a comunicare alcuni obiettivi principali a tutta l'organizzazione. Altrimenti non puoi abilitare tutti i dipendenti della tua azienda a prendere buone decisioni.

Nelle organizzazioni tradizionali, i project manager scrivono le specifiche secondo le proprie idee. Da Yammer è diverso. Invece di scrivere una specifica rigida su cosa costruire, la specifica viene vista come punto di partenza per un team interfunzionale, che poi può elaborarla. Se la specifica è già troppo lunga o prescrive troppo, bisogna stare attenti. Gli sviluppatori coinvolti devono poter comprendere le decisioni relative a una feature, in modo da implementare il codice nel modo più efficiente ed efficace possibile.

La regola del "Due e Dieci"

La regola empirica più importante di Yammer è: da due a dieci persone, da due a dieci settimane. Non ci sono quindi progetti più grandi o complicati. Esiste un rapporto non lineare tra la complessità di un progetto e la fase finale di integrazione. Per tutto ciò che dura più di dieci settimane, la durata della fase finale diventa sproporzionata.

Se si rispetta questa regola, si è inoltre costretti a rilasciare più frequentemente, testare le ipotesi e non preoccuparsi troppo degli errori. È simile al Lean Startup e se vuoi provarlo, devi codificarlo nella tua azienda.

Devi sviluppare un senso di urgenza. I progetti molto lunghi sono spesso la causa per cui gli sviluppatori perdono di vista l'obiettivo reale. È come un'escursione. Quando parti, sei ancora pieno di energia, ti godi l'escursione e avanzi abbastanza velocemente. Con il tempo, però, il corpo si stanca e non riesci più a vedere dove sei partito o dove stai andando. Quando arrivi a quel punto, hai bisogno di una forte volontà per motivarti a continuare. Sfortunatamente, molte organizzazioni hanno messo i propri sviluppatori esattamente in questa fase intermedia per la maggior parte dei loro compiti.

Verso la fine dell'escursione, però, puoi di nuovo vedere la tua meta e la motivazione torna. Con ogni passo, l'obiettivo si avvicina un po'. È importante che i tuoi sviluppatori si trovino in questa fase, dove possono misurare e visualizzare i propri progressi. Solo così si possono mantenere l'urgenza e il morale lavorativo.

Code Ownership

Attenzione alla Code Ownership – quando le persone hanno la propria codebase, questo può creare molti incentivi sbagliati che andrebbero evitati. Da Yammer l'organizzazione è suddivisa in aree specialistiche. Gli sviluppatori sono davvero intelligenti e motivati e se possono orientarsi all'obiettivo aziendale, possono realizzare cose straordinarie (e persino in modo completamente autonomo).

Definire come appare un team operativo

Prima di creare un team di prodotto per una feature, si esamina attentamente la specifica. Più precisamente, si cerca di stimare l'impegno necessario per la feature.

Prendiamo il Prodotto X. È una feature immaginaria che aumenta la viralità rendendo possibile invitare amici durante il processo di registrazione. In questo esempio, il focus è sul front-end, il che significa che potrebbero servire due persone per l'interfaccia utente. E poiché probabilmente bisognerà modificare anche qualcosa nel processo di registrazione, servirà sicuramente anche qualcuno dal team Rails per scrivere il codice.

Una volta che il team di prodotto si è accordato su una priorità per il progetto, basta aspettare che gli sviluppatori siano disponibili (in questo caso due per il front-end e uno per Rails). Da Yammer c'è una grande lavagna con griglia chiamata "Big Board". Da un lato vengono elencati i progetti, dall'altro tutti gli sviluppatori che lavorano sulle feature. Naturalmente, uno sviluppatore può lavorare solo a un progetto alla volta. Il Big Board crea inoltre una buona trasparenza delle priorità. Tutto ciò che viene completato durante lo sviluppo viene menzionato lì e così il CEO può dare un'occhiata in qualsiasi momento e constatare: "Ecco su cosa stanno lavorando gli sviluppatori."

Se riesci ad assicurare il focus su un singolo progetto, la tua azienda sarà già molto più veloce. È sorprendente che nessuno lo renda una condizione nella propria organizzazione – eppure praticamente tutti sanno quanto sia costoso un cambio di contesto. Con un focus assoluto si costruisce una cosa, la si consegna e poi ci si può dedicare a qualcos'altro.

Ma chi si occupa dei bug?

Se tutti lavorano sulle feature, chi si occupa dei bug? Da Yammer ci sono semplicemente più team interfunzionali. Si prendono alcune persone dal team Rails, dal team front-end e dal team mobile ecc. e si dice loro: "Il vostro compito è correggere i bug e lavorare sulla nostra lista." Questa è solo una situazione temporanea (come tutti i gruppi orientati ai progetti) e le persone si alternano. Questa struttura organizzativa rende possibile occuparsi del supporto senza compromettere lo sviluppo delle feature.

Inoltre, non si crea così una seconda classe di sviluppatori. Non si assegnano semplicemente alcuni sviluppatori junior per correggere i bug; anche gli sviluppatori senior vengono coinvolti. E questo è intenzionale, perché quando si devono correggere i bug, non si vogliono coprire, ma risolvere la causa alla radice. Alle persone più esperte dovrebbe essere permesso, se necessario, di fare refactoring del codice. Questo sistema porta inoltre a un ciclo di feedback tra chi costruisce le feature e chi corregge i bug. Conoscere la frequenza e il tipo di bug è un'informazione importante per le decisioni che possono guidare lo sviluppo del prodotto.

Questo testo proviene dal blog di First Round ed è stato tradotto in italiano.