"You build it, you run it" - è applicabile sempre?

Questo principio, formulato inizialmente nel 2006 dal CTO di Amazon Werner Vogels, suggerisce che il team che sviluppa un prodotto deve anche essere quello che ne gestisce la messa in opera e il suo funzionamento dai clienti.

Molte aziende software invece si trovano spesso nella situazione di avere un team che sviluppa un prodotto o una piattaforma, che poi altri team dell’azienda stessa si occupano di installare, configurare ed eventualmente estendere per soddisfare le esigenze dei singoli clienti. Questi secondi team si occupano di gestire una commessa.

Aziende siffatte però violano il principio. 

Che fare? Va bene? Va male? Che conseguenze negative ci si deve aspettare? 

Vediamo di sviscerare insieme la questione.

Il principio “You build it, you run it” è motivato dal fatto che l’attribuire agli sviluppatori del prodotto responsabilità operative migliora di molto la qualità del servizio offerto al cliente, sia come tecnologia erogata che come gestione del cliente. Infatti, uno sviluppatore che sa che potrebbe essere chiamato d’urgenza all’una di notte per risolvere un problema urgente ci pensa due volte prima di rilasciare una certa modifica. Un altro fattore importante è il canale diretto di comunicazione tra sviluppatori e utenti e clienti, che velocizza e migliora il flusso di informazioni.

A tutti gli effetti, l’applicazione del principio - intrinseco negli approcci DevOps - rompe dei silos.

Quindi, a parte le difficoltà di persuadere la gente a cambiare le proprie abitudini, sembrerebbe che non ci siano ragioni per non adottare il principio. 

Potrebbe non essere così.

Infatti il team si carica anche di altre responsabilità, oltre a quelle di far evolvere il prodotto e mantenerlo in produzione. Un esempio di nuova responsabilità è la gestione degli incidenti, nei casi in cui anomalie importanti vengono rilevate da qualche cliente. Il management dell’azienda vuole giustamente disporre di rapporti e metriche relativi a questi incidenti (ad es. coi tempi effettivi di risoluzione, con la frequenza di occorrenza, etc.). Questi rapporti e la gestione dei dati che alimentano le metriche sono a carico del team.

Inoltre, nei casi in cui ogni cliente usa il prodotto in maniera diversa e richiede delle estensioni specifiche, estensioni che sono realizzate e gestite dal team di prodotto, viene richiesto che venga definita una visione e perseguita una roadmap della commessa. Questo, seppur con un ritmo più lento del prodotto, comunque è un processo che va gestito nel tempo, dato che raramente la commessa è statica. Si tratta di un’altra responsabilità che viene presa in carico dal team di prodotto. Anzi, una responsabilità per ogni diverso cliente in certi casi. 

Quindi si arriva spesso a una situazione in cui il carico cognitivo che viene richiesto al team di prodotto si aggrava notevolmente, e spesso in direzioni divergenti. Non solo il team deve perseguire la vision del prodotto, ma anche le varie vision delle commesse e la gestione giornaliera del rapporto col cliente e di eventuali incidenti. Ed è questa la ragione per cui si introducono 2 o più team.

La conclusione a cui siamo arrivati è che in certi casi l’adozione del principio potrebbe portare a disfunzioni organizzative.

Ma se refutassimo quel principio e decidessimo di non ottemperarlo, saremmo costretti a ritornare alla casella di partenza, quella con un team di prodotto (i privilegiati che fanno le cose belle e divertenti senza stress) e uno o più team di commessa (quelli che sono ogni giorno in trincea e “combattono” col cliente)?

Non è detto.

Infatti, la relazione tra il team di prodotto e il o i team di commessa deve essere di “fornitore”. Il team che sviluppa il prodotto deve essere il fornitore al team che fa la commessa.

Il team di commessa:

• deve poter disporre di un prodotto funzionante come da specifiche
• deve poterlo installare, fare degli upgrade e downgrade, configurarlo, estenderlo secondo quanto previsto dalla commessa stessa, e in completa autonomia
• deve avere supporto dal team del prodotto, potenzialmente 24/7
• deve poter avvantaggiarsi di SLA (Service Level Agreement) concordati, sia per bug, che per richieste di supporto e aiuto
• prevede che il prodotto evolva con una roadmap di incrementi concordati con il team di prodotto.

Il team di prodotto da parte sua:

• lo sviluppa secondo una roadmap, anche in base a input fornito dai suoi “clienti” che sono costituiti soprattutto dai team di commessa
• lo rilascia con cadenze concordate
• lo documenta in modo da rendere più autonomo possibile il team di commessa
• documenta anche come configurare ed estendere il prodotto
• lo arricchisce di telemetria e tracing per consentire a tutti (il team di commessa e il team di prodotto) di monitorare il funzionamento e l’utilizzo del prodotto presso il cliente e in laboratorio
• lo arricchisce di strumenti per facilitare il testing in laboratorio delle eventuali estensioni
• funge in maniera pro-attiva da facilitatore in modo da consentire al team di commessa di diventare produttivo prima possibile per ogni rilascio del prodotto
• garantisce una elevata Developer User Experience relativamente al prodotto (che va caratterizzata con opportuni KPI).

Quindi la vita a bordo del team di prodotto non è rosa e fiori: se è vero che i suoi membri non sono in trincea di fronte al cliente, è altrettanto vero che i suoi membri sono in trincea di fronte ai membri dei team di commessa e potenzialmente di tutta l’azienda. Se il team di prodotto non mantiene le promesse, o consegna un prodotto carente, i suoi membri vengono chiamati nell’ufficio di un dirigente a giustificarlo. 

È importante impostare queste “penalità” all’inizio, in modo che non siano viste come una delazione da parte del team di commessa, ma come un processo concordato di gestione delle anomalie.

Nel vostro caso, come funziona? Funziona davvero?

Pubblicato originariamente come Articolo LinkedIn.