Ogni tanto, i team di ingegneria si mettono nei guai per una serie di ragioni. A volte, una crescita esplosiva coglie il team di sorpresa. Oppure, la reperibilità è andata fuori controllo, con avvisi che scattano ogni cinque minuti. Oppure, i team di sviluppo e le operazioni hanno semplicemente smesso di vederci chiaro. Indipendentemente dal motivo, il team si trova in una brutta situazione e bisogna fare qualcosa per risolverla.
Se si tratta di un nuovo problema, la soluzione potrebbe essere facile: aggiungere qualche altro server, tornare a una versione nota dell’applicazione o riunirsi tutti insieme davanti a una pizza e una birra per chiarire la situazione. Spesso, tuttavia, il problema si insinua nel tempo e improvvisamente il buco è così profondo che non si riesce a trovare una via d’uscita. Su LinkedIn, un team che è arrivato a questo punto dichiarerà spesso uno stato noto come “Codice Giallo”.
Allarme Giallo
Alcuni pensano che il nome Codice Giallo sia basato sui semafori, ma più precisamente – e con un tocco più geek – è in realtà dalla vostra serie preferita di “Star Trek”. Più precisamente, è il modo in cui l’equipaggio della nave stellare Enterprise indica la sua attuale condizione di difesa. In entrambi i casi, la definizione è chiara: qualcosa non va, e dobbiamo andare avanti con cautela. Fedeli ad entrambe le metafore, abbiamo anche un Codice Rosso. Questo è meglio descritto come una crisi immediata, con tutti che lavorano 24 ore al giorno fino a quando non è risolta. Il Codice Giallo è leggermente più rilassato: È l’attenzione principale di tutti, ma solo durante le ore di lavoro. Il Codice Giallo tende anche a durare sull’ordine dei mesi, mentre un Codice Rosso dovrebbe durare sull’ordine dei giorni.
Altre aziende possono usare un termine diverso dal Codice Giallo, ma l’effetto è lo stesso: il team sta comunicando al resto dell’azienda che hanno identificato un problema serio che è una priorità da risolvere per garantire il successo del team e, quindi, dell’azienda. La capacità di fare questo è un aspetto importante della comunicazione aperta e onesta, un valore che è fondamentale per una cultura sana e che spesso può essere trascurato. Parlare dei nostri problemi è altrettanto importante, se non di più, che celebrare i nostri successi. Le squadre possono imparare di più risolvendo un problema che da un successo totale.
Questo non è un fallimento
Il primo passo per iniziare un Codice Giallo è capire che questo non è un fallimento. Non c’è vergogna nell’ammettere che la squadra ha un problema che deve essere risolto. I bug accadono, nonostante i nostri migliori sforzi per evitarli. L’unica cosa che possiamo fare è diagnosticare il problema e porvi rimedio. L’unica volta che falliamo è quando chiudiamo un occhio su questi problemi. Questo si applica al modo in cui i nostri team di ingegneri interagiscono tra loro tanto quanto al software e ai sistemi che produciamo ed eseguiamo.
È fondamentale, tuttavia, che vengano affrontati i problemi giusti. La maggior parte delle volte, siamo arrivati alla situazione attuale a causa di un lento ribollire – debito tecnico crescente, molti piccoli problemi o guasti in un processo – che alla fine si è accumulato in una crisi. L’obiettivo del Codice Giallo deve essere non solo rimediare ai problemi attuali (una componente reattiva), ma anche assicurarsi che non si ripetano in futuro (la componente proattiva).
Pianificazione per un Codice Giallo di successo
Ci sono diversi componenti richiesti per un Codice Giallo di successo, così come pezzi necessari per ottenere il buy-in dal resto dell’organizzazione:
- Dichiarazione del problema: Ci deve essere una dichiarazione chiara e concordata dei problemi che la squadra deve affrontare e che hanno portato al Codice Giallo. Questo dovrebbe includere non solo quali sono i problemi attuali, ma anche quale è la comprensione attuale della loro causa principale.
- Criteri di uscita: Successivamente, è necessario avere obiettivi specifici che la squadra lavorerà per uscire dal Codice Giallo. Questi dovrebbero essere i tradizionali obiettivi SMART: specifici, misurabili, raggiungibili, rilevanti e legati al tempo. Questi obiettivi sono ciò che rende possibile al team di entrare in un Codice Giallo in primo luogo, in quanto copre un ambito fisso e non è a tempo indeterminato.
- Comunicazione: Tutte le informazioni sul Codice Giallo, compreso l’annuncio (che include la dichiarazione del problema e i criteri di uscita), la conclusione positiva e gli aggiornamenti periodici dello stato dovrebbero essere inviati all’organizzazione più grande. Questo può essere il tuo dipartimento, o può essere l’intera organizzazione di ingegneria. Può anche essere l’intera azienda, a seconda della natura dei problemi.
- Gestione del progetto: Come tutti i grandi progetti, ci deve essere qualcuno responsabile dell’organizzazione del lavoro e della comunicazione delle informazioni. Siccome questo rappresenta uno scenario “a tutto campo” per la squadra colpita, di solito è utile avere un project manager (PM) dedicato che aiuti in questo. Questo è tipicamente un PM che ha conoscenza del team e del lavoro, ma non è direttamente coinvolto nell’esecuzione. Questo libera i manager e i singoli collaboratori per concentrarsi sul lavoro a portata di mano.
Una volta che ognuno di questi aspetti è stato pensato, e la decisione è stata presa per entrare nel Codice Giallo, il primo atto del team è quello di riorganizzare le loro priorità intorno ai criteri di uscita. Questo spesso significa mettere da parte gli obiettivi trimestrali. Può anche essere necessario stabilire una riunione dedicata alla discussione dello stato dei criteri di uscita.
Space to Breathe
Va bene che una squadra entri in codice giallo e lavori con un unico obiettivo sugli obiettivi che sono stati fissati per sistemare le cose, ma questo non è sufficiente per il successo della squadra. Per il vero successo, tutti quelli che circondano il team devono capire la situazione e dargli lo spazio per fare il loro lavoro. Questo è il luogo dove una sana cultura ingegneristica si alza per affrontare la sfida.
- Aspettatevi ritardi: Il modo più comune in cui un team tangenziale sarà colpito è attraverso i ritardi. Devono aspettarsi che qualsiasi richiesta fatta al team colpito possa essere ritardata se non rientra nell’ambito dei criteri di uscita. Il Codice Giallo implica, nel suo nucleo, un riordino delle priorità per affrontare il problema dichiarato. I team esterni devono tenerne conto e capire che le loro scadenze di progetto possono aver bisogno di essere aggiustate.
- Minimizzare le nuove richieste: Gli altri team dovrebbero anche astenersi dal chiedere al team colpito nuove cose che sono al di fuori dell’ambito dei criteri di uscita definiti. Minimizzare queste richieste, oltre ad accettare ritardi su qualsiasi richiesta esistente, permette al team colpito di spendere le sue limitate ore di ingegneria per arrivare all’altro lato del Codice Giallo.
- Richieste di assistenza da altri team: Il team in codice giallo può scoprire di aver bisogno di aiuto esterno per raggiungere i propri obiettivi. Per esempio, se c’è una crescita improvvisa ed esplosiva del traffico, potrebbero aver bisogno di accelerare l’approvvigionamento di nuovo hardware. Trovarsi a ricevere una richiesta come questa può richiedere di spostare le proprie priorità. Ricordate sempre che la squadra fa parte della stessa azienda, e come tale, tutti hanno successo o falliscono insieme.
Le squadre di ingegneri raramente stanno in piedi da sole, ed è importante che tutti capiscano il valore di avere queste squadre che lavorano bene, e lavorano bene insieme. Un piccolo ritardo temporaneo negli obiettivi per assicurare che sia così ne vale la pena.
Luce alla fine del tunnel
Il codice giallo rappresenta una quantità significativa di lavoro ad alta priorità e lavorare attraverso di esso sarà spesso stressante per il team. Dire “no” ai colleghi che stanno facendo una richiesta ragionevole è difficile, e il lavoro che è nello scopo raramente implica spendere tempo su nuove funzionalità interessanti. Inoltre, se i problemi da affrontare includono problemi di comunicazione tra i gruppi, ci saranno alcune conversazioni difficili da fare. Tuttavia, man mano che la squadra si avvicina alla fine del lavoro, sarà molto più facile vedere cosa c’è dall’altra parte dei criteri di uscita.
L’obiettivo finale del Codice Giallo è quello di far uscire la squadra da una modalità reattiva in cui stanno correndo da una crisi all’altra e in uno stato proattivo in cui sono in grado di lavorare sui grandi progetti giusti. Raggiungere i criteri di uscita significa che gli ingegneri sono più efficaci e in grado di lavorare in modo proattivo. Questo è un team più forte – gli ingegneri sono più felici perché non sono sotto un pesante stress di lavoro operativo, il team sta lavorando bene perché stanno parlando tra di loro in modo efficace, e i clienti sono soddisfatti perché le richieste sono gestite attraverso l’automazione o in un tempo ragionevole.
La vostra azienda ha un processo interno che è simile a come LinkedIn fa un Codice Giallo?
– Todd Palino