Come spiegare gli sviluppatori ai gestori non tecnici?

Sono totalmente entusiasta di DevOps. So che DevOps è la metodologia che ci spingerà a costruire un'infrastruttura IT che razionalizzerà e farà progredire la nostra azienda.
Ma come posso venderlo ai miei capi, in particolare ai capi non tecnici?

Stiamo per implementare un progetto di automazione che includerà, implementazione automatizzata, cloudizzazione dell'infrastruttura, processo di integrazione continua .. abbiamo sicuramente bisogno di convincere i nostri capi ad investire a livelli più alti in questo.

Nota : abbiamo iniziato a migliorare il nostro processo automatizzando test, rilasci e supervisione, è un passo verso l'adozione di devOps ma il progetto di automazione stesso è in attesa poiché abbiamo bisogno di maggiori investimenti.

Essendo un consulente sono contrattualmente obbligato a rispondere, "dipende". Detto questo, posso davvero rispondere alla tua domanda.

Da cosa dipende? Bene, questo potrebbe dipendere da cosa pensa il tuo capo di DevOps:

1. Se il tuo capo ha sentito parlare del termine, forse attraverso la sua ossessione per CIO.com , allora chiedi loro cosa pensano che significhi. Da lì capire qual è la differenza e se la loro visione è compatibile. Identifica un progetto adatto per provare DevOps e lanciarlo a loro. Ricorda che al centro DevOps è la cultura, quindi considera come potrebbe essere applicato a un progetto.

2. Se il tuo capo non ha mai sentito parlare del termine, crea un business case per DevOps. Usa il Puppet Labs State of DevOps e il materiale di libri come The Phoenix Project per scrivere il business case. Trova un problema che il tuo capo ha e DevOps potrebbe risolverlo e usalo come antipasto di conversazione. Come kenchew ha affermato che non è necessario menzionare DevOps, è possibile, ad esempio, suggerire che le operazioni siano maggiormente coinvolte in un progetto o che l'automazione del test venga pianificata come parte della consegna del progetto.

3. Se il tuo capo pensa che DevOps sia solo un'altra parola d'ordine, fai una delle precedenti, ma assolutamente non menzionare DevOps, guarda altri modelli simili come Ingegneria dell'affidabilità del sito, Ingegneria della piattaforma o Distribuzione continua e scopri come potrebbero risolvere il problema.

La chiave è concentrarsi sulla comprensione di ciò che il tuo capo è motivato, quindi ritagliare un po 'di tempo, denaro e persone per fare passi concreti per risolvere quel problema.

Consiglio vivamente il libro To Sell Is Human di Daniel H. Pink , fondamentalmente Daniel Pink parla di come vendere qualcosa è una cosa molto umana da fare, tutto ciò che dobbiamo fare è toccare i bisogni e allineare il nostro "passo" proponendo un soluzione che soddisfa tali esigenze.

Non

Nonostante il tuo entusiasmo per DevOps, i boss non tecnologici non condividono davvero il tuo fascino con il gergo tecnico.

Innanzitutto, mostra ai tuoi capi il vantaggio di un piccolo progetto pilota che hai realizzato. Raccogli alcuni punti dati utili per dimostrare il tuo caso. ( Hai trovato questa domanda che potrebbe aiutare: quali sono alcuni metodi per misurare il ROI per DevOps? )

Successivamente, dì ai tuoi capi che hai un progetto che potrebbe portare più vantaggi ma necessita di un piccolo investimento. (Cerca di capire un progetto che non lasci cadere i tuoi capi dalla sedia. Dovresti avere un'idea di cosa sia questa figura se hai lavorato con i tuoi capi per un po '.)

Una volta ottenuto l'investimento, fai un ottimo lavoro per raggiungere l'obiettivo. Meglio ancora, superarlo selvaggiamente!

Ora, quando finalmente i capi ti chiedono "Allora, cosa hai fatto che ci ha portato così tanti benefici?"

Questo è il momento in cui proclami:

"DevOps"

E chiedi maggiori investimenti per il tuo prossimo progetto devops.

Qualsiasi iniziativa commerciale otterrebbe una trazione se mostrassi la sua pertinenza alla linea superiore o inferiore dell'organizzazione.

Iniziative interne come devops possono influenzare solo la linea di fondo. È necessario identificare i costi del lavoro ricorrente svolto dagli individui e come l'automazione ridurrebbe tali spese.

Anche se i manager non tecnologici potrebbero non capire la differenza tra la scelta dello chef rispetto al burattino, hanno una certa comprensione delle tendenze del settore. Puoi renderli consapevoli dei costi dei ritardi dovuti alla mancata disponibilità di build, ai costi dei problemi di regressione e al modo in cui il tuo approccio può ridurre tali costi. Se riesci a mostrare un piano tangibile di miglioramento nella linea di fondo, e se è migliore degli altri oggetti azione sul loro piatto, otterrai un via libera.

Il mio ragionamento privilegiato per le persone che non hanno familiarità (o semplicemente si sbagliano) sul termine "DevOps" si riduce a "fornire valore commerciale più frequentemente". Questo, nella mia esperienza, è qualcosa a cui pochi manager sono in grado di obiettare. Lo capiscono.

Se dicono qualcosa del tipo "abbiamo solo bisogno di qualcuno per raddrizzare i nostri devops, probabilmente solo poche settimane di lavoro; quindi c'è un limite a quanto investiremo in devops in questo momento" Cerco solo di spiegare che è come dire "non vogliamo che la nostra azienda offra troppo valore commerciale. Abbiamo solo bisogno di un po 'di più, ma il gioco è fatto".

È solo retorica, ovviamente, ma trovo che sia efficace, molto più che dire loro di leggere un libro sulla Toyota.

Tutto nelle risposte precedenti è vero, ma penso che manchino alcune cose per ottenere l'approvazione e l'impegno dei tuoi capi (A proposito: la maggior parte delle persone ha solo 1 capo al massimo ...).

Prima o poi arriverà il signor Murphy (= Tutto ciò che può andare storto, andrà storto, e andrà storto quando non dovrebbe andare storto ). E a quel punto alcuni boss vorranno ottenere risposte a domande come questa:

Che cosa è successo quando e perché e quale utente autorizzato l'ha effettivamente approvato ... in anticipo?

E a quel punto otterrai il vero ROI dalle pratiche DevOps che avrai in atto ... E / o all'improvviso ottieni tutti i tipi di enormi approvazioni di budget per implementare ciò che sembra stia cercando.

Anche se ci sarebbe voluto troppo tempo perché Murphy arrivasse, la tua azienda potrebbe anche soddisfare requisiti come quello che Richard ha descritto nella domanda " Quali processi o strumenti consentono la segregazione dei compiti quando gli ingegneri implementano ed eseguono il codice? " (Questo tipo di requisiti spaventare CxOs ...).

Ma, se mai dovessi presentare "DevOps" a qualcuno che è nuovo, potrebbe aiutarli a "avvertirli" in anticipo come " OK, quindi vuoi iniziare le pratiche DevOps, fantastico! Ma tieni presente che è come passare a un'altra religione ... "