Come posso convincere gli sviluppatori del mio team ad abbracciare "Lo costruisci, lo esegui"?

Come posso convincere gli sviluppatori del mio team ad abbracciare "Lo costruisci, lo esegui"? Con ciò, ho in mente questa citazione di Werner Vogels :

Assegnare agli sviluppatori responsabilità operative ha notevolmente migliorato la qualità dei servizi, sia dal punto di vista del cliente che dal punto di vista tecnologico. Il modello tradizionale è che porti il ​​tuo software al muro che separa lo sviluppo e le operazioni, lo butti e poi lo dimentichi. Non su Amazon. Lo costruisci, lo esegui. Questo mette gli sviluppatori in contatto con le operazioni quotidiane del loro software. Li mette inoltre in contatto quotidiano con il cliente. Questo circuito di feedback dei clienti è essenziale per migliorare la qualità del servizio.

Sto pensando specificamente a un insieme di sviluppatori che:

• Sono stati assunti in un ruolo di sviluppatore, con poca / nessuna menzione di attività relative alle operazioni.
• Tradizionalmente hanno "lanciato il codice oltre il muro" per un team operativo.
• Tradizionalmente hanno un programma di lavoro 9-5 e sono attivamente ostili all'idea di "dovere cercapersone", partecipando al ripristino di emergenza, scrivendo post mortem, ecc., Specialmente al di fuori del normale orario lavorativo. (Nota: ho in mente solo interruzioni molto rare per questo; non sto proponendo di aggiungere il supporto clienti post-orario al carico di lavoro di questo team.)
• Al momento non sono responsabili della scrittura / supporto del monitoraggio o degli avvisi sulle loro applicazioni.

Supponiamo che ci sia un team che sta rapidamente sviluppando nuovi micro-servizi cloud con un profilo che sta diventando tale che il trasferimento di questi servizi a un team operativo non è ottimale perché non riescono a tenere il passo per quanto riguarda l'acquisizione di una profonda conoscenza di i servizi necessari per gestirli e monitorarli efficacemente. "Lo costruisci, lo esegui" funzionerebbe meglio per questo team perché le attività potevano essere delegate a ciascun membro del team responsabile. Quindi questo team inizierà a prendere parte alla progettazione dell'infrastruttura, al monitoraggio / allerta degli strumenti per i servizi e (molto raramente) alla risposta agli eventi di interruzione.

Sono particolarmente interessato alle metodologie, supportate da esempi del mondo reale. Come è stato implementato con successo in altri luoghi di lavoro e se ci sono dei passaggi canonici da seguire durante l'implementazione? Qualsiasi collegamento a scritture in grado di supportare le risposte sarebbe molto utile.

Penso che il modo più semplice sia quello di cambiare i loro obiettivi prestazionali in modo che siano basati sull'affidabilità e sulla consegna del codice. Vendilo perché la società non può avere successo senza entrambi, quindi perché gli sviluppatori dovrebbero essere misurati solo su uno? Il modo migliore per loro di raggiungere i propri obiettivi prestazionali è essere coinvolti nelle operazioni.

In definitiva, devi convincerli che questo è il modo migliore per avere successo nell'azienda e quindi per avere successo. È difficile e non puoi aspettarti che siano a bordo dall'inizio. Devono essere venduti anche sul valore.

Quando si tratta di influenzare la cultura aziendale, il modo migliore è probabilmente attraverso il noto metodo "bollire la rana". Devi presentare questi compiti agli sviluppatori lentamente, perché so che io stesso (come dev) mi sarei rifiutato di avere tutte queste nuove responsabilità contemporaneamente.

Innanzitutto, inizia introducendo una o due nuove attività da eseguire solo durante il normale orario di lavoro. Devono imparare a fare devops che potrebbe essere piuttosto il processo di apprendimento per uno sviluppatore (fino a questo punto) solo in codice e potrebbe richiedere una certa supervisione. Probabilmente saranno anche ostili all'idea di cambiare il loro equilibrio tra lavoro e vita privata dal momento che dici che sono abituati al 9-5. A questo punto, registra i dati sui nuovi processi per utilizzarli in seguito (chiedi loro di scrivere questo codice, i dati sono sempre utili).

Più tardi, mentre stai esaurendo le nuove attività di devops-y da introdurre (quindi il primo, il secondo e il quarto punto elenco sono quasi completi), porta le prime attività che hai presentato come candidati da svolgere al di fuori dell'orario di lavoro standard . Potresti vedere un po 'di contraccolpo in questo e potresti persino vedere un po' di logoramento a seconda di quanto fortemente spingi questo e di quanto fortemente sia radicata la cultura del lavoro a cinque punte. Per difendersi da ciò, si spera che i tuoi dati supportino l'idea che il lavoro oltre l'orario standard sia raro, si verifichino solo in situazioni estreme e andranno a beneficio sia dell'azienda che del cliente. Se i tuoi dati non lo supportano, è meglio che tu sia pronto a gestire le conseguenze di questa scelta.

Anche con i dati, può essere ancora più facile avere gli sviluppatori a scrivere il monitoraggio / alerting codice (in modo che diventino dev ops ma ancora principalmente dev) e mantenere la squadra si alternano ops come il supporto di prima linea (come pochi altri hanno suggerito). Come ho detto, piccole modifiche sono importanti per evitare contraccolpi. Integrare il lavoro per gli sviluppatori oltre le ore standard sarà una sfida, poiché potrebbero sapere che possono cercare altrove un lavoro se non gli piace poiché il mercato degli sviluppatori è forte in questo momento, specialmente se avevano già competenze di sviluppo. Caveat emptor!

Guardando al di fuori di DevOps in particolare, se stai parlando di ambienti aziendali di grandi dimensioni, la metodologia SAFe ha un modo abbastanza buono di incoraggiare questo tipo di comportamento.

In sostanza si riduce ad alcune fasi chiave:

• i progetti iniziano come treni di rilascio. L'intento (e l'aspettativa di chi lo finanzia) è che durerà a lungo. Sto parlando da anni, niente di tutto questo "fare squadra per 3 mesi e poi farli crollare".

• nel corso di un progetto, il treno di rilascio accumulerà inevitabilmente un numero maggiore di persone in quanto più sia nuovi requisiti di progetto basati su opportunità commerciali appena realizzate, sia le imposte in corso sul lavoro in stile manutenzione.

• Vedo quasi sempre che i treni eseguono il loro primo incremento come team di progetto / cambio al 100%, mentre il secondo incremento assegna una percentuale di tempo al lavoro Run. La terza gestione dell'incremento si rende conto che stanno per avere un problema e iniziano ad aggiungere team per provare a gestire l'overflow Run per dare ai loro sviluppatori e ingegneri ormai esperti il ​​tempo di continuare a lavorare su nuovi requisiti.

• se viene raggiunto il giusto equilibrio tra i team di progetto in grado di continuare a fornire i risultati del progetto senza impantanarsi troppo nei lavori di manutenzione e i nuovi team che si uniscono al treno non si aspettano immediatamente di essere solo team di supporto al 100%, ma invece assumono un buona parte del lavoro di modifica che avrebbe dovuto essere gestito, poi si finisce con i team di consegna che possiedono i prodotti che stanno costruendo per impostazione predefinita, non è necessario trovarli tutti in una volta che ora sono un team Run, invece si integra lentamente nelle loro attività quotidiane.

Laddove questo modello presenta ovviamente alcuni punti deboli è il prezzo di un'azienda. Generalmente mi aspetto di pagare molto di più per una risorsa di cambiamento rispetto a una risorsa di esecuzione, di solito i contratti con i principali fornitori sono a prezzo fisso e l'intento è quello di fare soldi con un miglioramento continuo e quindi un risparmio sui costi.

Detto questo, non è poi così difficile considerare che i team di cambiamento si sono alzati come parte di un treno di rilascio per fornire semplicemente miglioramenti continui. Se c'è qualcosa che possono costruire o fare che migliorerà la loro capacità di concentrarsi sulle consegne di nuovi progetti ed essere meno preoccupati del lavoro "business as consueto", che dovrebbe essere backlog e prioritario in base ai benefici percepiti da chi detiene i soldi per il rilascio treno.

IMHO You build it, you run itnon dovrebbe essere preso alla lettera. Per cominciare - sembra quasi una punizione;)

Nessuna singola persona o anche un piccolo team di sviluppatori può ragionevolmente supportare uno strumento o un set di strumenti utilizzati nel processo di sviluppo del software (cioè nella produzione!) Per lunghi periodi di tempo. Ci sono stato, fatto :)

Le mansioni di supporto tendono ad espandersi con l'aumentare della base clienti di strumenti (set). Se assumesse tali compiti esclusivamente, il team di sviluppo potrebbe finire per fare principalmente supporto, con poco / nessun tempo per lo sviluppo lungo la strada. In effetti un vicolo cieco: quanti sviluppatori vorrebbero rimanere in un ambiente simile?

Avere un team di supporto di prima linea professionale è fondamentale per prevenire la frustrazione, lo stress e altri effetti dell'esposizione a lungo termine alle funzioni di supporto sui membri del team di sviluppo.

Il team di supporto di prima linea, ovviamente, ricorrerebbe al team di sviluppatori (di nuovo, team, non a persona singola!) Per problemi che non possono affrontare direttamente. Sì, all'inizio potrebbe essere difficile, ma le cose andranno meglio. Dovrebbe essere una collaborazione, che fa parte di ciò che riguarda DevOps.

Ciò dipende in definitiva dalle dimensioni e dalla struttura dell'azienda. Ci sono davvero tre fasi in cui la tua azienda può trovarsi:

1. La fase di avvio (meno di 150 ingegneri). Naturalmente, gli sviluppatori devono eseguire il proprio software. Tutti lo fanno in una startup. Potresti anche non avere un team operativo per cominciare, ma anche se lo fai, è piccolo e la velocità dei progressi è così veloce che non c'è modo di passare le conoscenze necessarie per eseguirlo con successo su un altro team abbastanza velocemente da consentire loro di riuscire.

2. Il business di medie dimensioni (oltre 150 ingegneri, ma un solo team operativo). A questo punto la sfortuna nell'azienda inizia ad essere troppo elevata, gli ingegneri che costruiscono software non si attengono necessariamente anche per eseguirlo. Non conosci più tutti ed è difficile comunicare in modo efficace affinché tutti siano operativi. Inizierebbe a trasformarsi in caos. A questo punto vuoi passare al modello di Google, in cui ogni squadra deve rendere operativo il proprio software, ma non necessariamente farlo funzionare. Lo faranno funzionare all'inizio, ma una grande parte della creazione di software consiste nel ridurre i costi di gestione fino a un certo punto, in cui il carico è abbastanza piccolo da consentire al team operativo di accedervi eseguendolo. Solo allora è considerato fatto.

3. Grande impresa con più business unit (dove ognuna ha il proprio team operativo): in questa fase è possibile tornare al modello Amazon, in cui ogni team essenziale sviluppa e gestisce i propri servizi. Ciascuna delle unità aziendali deve essere abbastanza piccola da consentire a tutti di conoscersi, quindi con circa 150 ingegneri e ciascuna di esse opera essenzialmente come una startup. Amazon ha ogni servizio AWS che opera più o meno separatamente e funziona per loro.

Devi capire in quale fase è la tua azienda e / o entrare e agire di conseguenza. Non esiste una soluzione "taglia unica".

La mia opinione su questo (se mi trovassi di fronte a un tale comando, o come lo chiameresti), sarebbe qualcosa del tipo " What else would you expect?!?!". Perché, per caso:

• Non sarei nemmeno in grado di vivere senza di essa, e
• Adoro mangiare il mio cibo (per cani).

Lasciami spiegare un po 'di più ...

La mia attività / hobby / passione è scm , in particolare in ambienti mainframe . E ovunque io vada (per mettere a punto le cose per soddisfare le esigenze dei clienti), il primo requisito che impongo (nel mio contratto), è che qualsiasi messa a punto effettuata sul sistema che implementiamo, è attraverso lo stesso sistema. E così facendo (vero, ci vogliono alcune ore, diciamo mezza giornata al massimo), ne otteniamo questi benefici (elenco incompleto):

• Non documento quasi nulla di ciò che ho fatto per far funzionare il sistema. Se vengono poste domande, eseguo semplicemente una query sul sistema (e insegno al cliente come eseguire una query sul sistema senza il mio aiuto).
• Se venissi chiamato tra X mesi / anni (per passare a una nuova versione?), Voglio sapere (ricordi) cosa ho fatto prima "(e l'unica cosa di cui mi fido è ciò che il sistema mi dice, aka mi ricorda).
• Ho solo bisogno di chiedere una volta al cliente come fare cose specifiche nel loro sito (le convenzioni di denominazione sono difficili da ricordare), o per convincerli a concedere le autorizzazioni necessarie al "sistema" (non a me ...).
• Stai continuouslytestando il QA del tuo sistema ... in produzione. È probabile che si verifichino bug, errori logici o funzionalità mancanti (e cosa no) da soli. E quelli sono estremamente motivanti per affrontarli al più presto ... ad esempio per diventare più produttivi.
• ... e se vuoi, posso aggiungere un'altra dozzina di motivi ...

Tuttavia, prima di provare questo a casa da solo, fai attenzione ad alcune insidie ​​per evitare:

• vuoi che tutti si uniscano alla festa (usi il sistema), perché solo 1 "eccezione" (alias il manager / proprietario della compagnia?) può rovinare la festa (pensi che puoi fidarti del tuo sistema, ma poi qualcuno ha fatto qualcosa senza chiedere / utilizzare il sistema). Quei casi potrebbero costarti giorni per scoprire ...
• i nuovi utenti potrebbero lamentarsi del fatto che utilizzando questo (nuovo) sistema, impiegano molto più tempo a svolgere il proprio lavoro (rispetto a qualsiasi cosa abbiano usato prima). E ovunque abbia senso, lo useranno come una scusa per cui sono in ritardo per completare il loro lavoro. A quel punto, è meglio che ti occupino i vertici, perché altrimenti il ​​tuo progetto / sistema potrebbe avere la colpa.
• assicurati di conoscere il tuo sistema e come configurarlo per adattarlo alle tue esigenze. Come esempio (nel mio caso): vuoi configurare il sistema in modo da utilizzare l'ambiente operativo per consegnare al tuo ambiente sperimentale, e non viceversa ... Ho visto che succedeva in passato ... usare (abusare) del sistema di test per consegnare in ambienti altamente protetti.