Comment expliquer les devops aux managers non-techy?

Je suis totalement excité par DevOps. Je sais que DevOps est la méthodologie qui nous amènera à construire une infrastructure informatique qui rationalisera et fera avancer notre entreprise.
Mais comment puis-je vendre cela à mes patrons, en particulier les patrons non techniques?

Nous allons mettre en œuvre un projet d'automatisation qui comprendra un déploiement automatisé, une cloudification des infrastructures, un processus d'intégration continue .. nous devons absolument persuader nos patrons d'investir à des niveaux plus élevés dans ce domaine.

Remarque : nous avons commencé à améliorer notre processus en automatisant les tests, les versions et la supervision, c'est une étape vers l'adoption de devOps mais le projet d'automatisation lui-même est en attente car nous avons besoin de plus d'investissement.

Etant consultant je suis contractuellement obligé de répondre, "ça dépend". Cela étant, je peux répondre à votre question.

De quoi cela dépend-il? Eh bien, cela pourrait se résumer à ce que votre patron pense de DevOps:

1. Si votre patron a entendu parler du terme, peut-être par son obsession de CIO.com , demandez-lui ce qu'il pense. À partir de là, déterminez quelle est la différence et si leur point de vue est compatible. Identifiez un projet approprié pour tester les DevOps et proposez-leur. N'oubliez pas que DevOps est au cœur de la culture, alors réfléchissez à la manière dont cela pourrait être appliqué à un projet.

2. Si votre patron n'a jamais entendu parler du terme, établissez une analyse de rentabilisation pour DevOps. Utilisez l' état de DevOps de Puppet Labs et le matériel de livres tels que The Phoenix Project pour rédiger l'analyse de rentabilisation. Trouvez un problème rencontré par votre patron et DevOps pourrait le résoudre et l'utiliser comme déclencheur de conversation. Comme kenchew a dit que vous n'avez pas à mentionner DevOps, vous pourriez par exemple suggérer que les opérations soient plus impliquées dans un projet ou plus d'automatisation des tests à planifier dans le cadre de la livraison du projet.

3. Si votre patron pense que DevOps n'est qu'un autre mot à la mode, effectuez l'une des actions ci-dessus mais ne mentionnez absolument pas DevOps, regardez d'autres modèles similaires tels que Site Reliability Engineering, Platform Engineering ou Continuous Deployment et découvrez comment ils pourraient résoudre le problème.

La clé est de se concentrer sur la compréhension de ce qui motive votre patron, puis de vous donner un peu de temps, d'argent et de personnes pour prendre des mesures tangibles pour résoudre ce problème.

Je recommande fortement le livre To Sell Is Human de Daniel H. Pink , fondamentalement Daniel Pink parle de la façon dont vendre quelque chose est une chose très humaine à faire, tout ce que nous devons faire est de puiser dans les besoins et d'aligner notre "argument" en proposant un solution qui répond à ces besoins.

Non.

Malgré votre enthousiasme pour DevOps, les chefs non techniques ne partagent pas vraiment votre fascination pour le jargon technique.

Tout d'abord, montrez à vos patrons les avantages d'un petit projet pilote que vous avez réalisé. Collectez quelques points de données utiles pour prouver votre cas. (Vous avez trouvé cette question qui pourrait vous aider: quelles sont les méthodes pour mesurer le retour sur investissement pour DevOps? )

Ensuite, dites à vos patrons que vous avez un projet qui pourrait apporter plus d'avantages mais a besoin d'un petit investissement. (Essayez de trouver un projet qui ne laisse pas vos patrons tomber du fauteuil. Vous devriez avoir une idée de ce qu'est ce chiffre si vous travaillez avec vos patrons depuis un certain temps.)

Une fois que vous avez obtenu l'investissement, faites un excellent travail pour atteindre l'objectif. Mieux encore, dépassez-le sauvagement!

Maintenant, quand finalement les patrons vous demandent "Alors qu'est-ce que vous avez fait qui nous a apporté tant d'avantages?"

C'est le moment que vous proclamez:

"DevOps"

Et demandez plus d'investissement pour votre prochain projet Devops.

Toute initiative commerciale gagnerait du terrain si vous montriez sa pertinence par rapport au sommet ou à la ligne de fond de l'organisation.

Les initiatives internes telles que devops ne peuvent affecter que le résultat net. Vous devez identifier les coûts des travaux récurrents effectués par les individus et comment l'automatisation réduirait ces dépenses.

Même si les gestionnaires non techniques ne comprennent pas la différence entre choisir le chef plutôt que la marionnette, ils ont une certaine compréhension des tendances de l'industrie. Vous pouvez les informer des coûts des retards dus aux builds non disponibles, des coûts des problèmes de régression et de la façon dont votre approche peut réduire ces coûts. Si vous pouvez montrer un plan tangible pour l'amélioration de la ligne de fond, et si c'est mieux que les autres éléments d'action dans leur assiette, vous obtiendrez un feu vert.

Mon raisonnement de base pour les personnes qui ne connaissent pas (ou qui se trompent) sur le terme de DevOps se résume à «fournir plus fréquemment de la valeur commerciale». D'après mon expérience, c'est quelque chose auquel très peu de gestionnaires sont en mesure de s'opposer. Ils l'obtiennent.

S'ils disent quelque chose comme "nous avons juste besoin de quelqu'un pour redresser nos devops, probablement juste quelques semaines de travail; il y a donc une limite sur combien nous allons investir dans les devops en ce moment" J'essaie juste d'expliquer que c'est comme dire "nous ne voulons pas que notre entreprise fournisse trop de valeur commerciale. nous avons juste besoin d'un peu plus, mais c'est tout".

C'est juste de la rhétorique, bien sûr, mais je trouve que c'est efficace, bien plus que de leur dire de lire un livre sur Toyota.

Tout dans les réponses précédentes est vrai, mais je pense qu'il manque des éléments pour obtenir l'approbation et l'engagement de vos patrons (BTW: la plupart des gens n'ont qu'un patron au maximum ...).

Tôt ou tard, M. Murphy viendra (= Tout ce qui peut aller mal, va mal, et ça va mal quand ça ne devrait pas aller mal ). Et à ce stade, certains patrons voudront obtenir des réponses à des questions comme celle-ci:

Que s'est-il passé quand et pourquoi, et quel utilisateur autorisé l'a effectivement approuvé ... dès le départ?

Et à ce moment-là, vous obtiendrez le véritable retour sur investissement des pratiques DevOps que vous aurez mises en place ... Et / ou tout d'un coup, obtenez toutes sortes d'approbations budgétaires énormes pour mettre en œuvre ce que vous semblez rechercher.

Même si Murphy mettrait trop de temps à arriver, votre entreprise pourrait également se heurter à des exigences telles que celles décrites par Richard dans la question « Quels processus ou outils permettent la séparation des tâches lorsque les ingénieurs déploient et exécutent du code? » (Ce type de les exigences font peur aux CxO ...).

Mais, si jamais vous devez présenter "DevOps" à quelqu'un qui est nouveau, cela peut les aider à "les avertir" dès le départ comme " OK, donc vous voulez commencer les pratiques DevOps, super! Mais sachez que c'est comme passer à une autre religion ... "