devopsを非技術系マネージャーに説明する方法は？

私はDevOpsに完全に興奮しています。DevOpsは、当社を合理化し、前進させるITインフラストラクチャを構築するための方法論であることを知っています。
しかし、どうやってこれを上司、特に非技術的な上司に売るのですか？

私たちは、自動化された展開、インフラストラクチャのクラウド化、継続的インテグレーションプロセスを含む自動化プロジェクトを実装する予定です。上司にこれにより高いレベルで投資するように説得する必要があります。

注：テスト、リリース、および監視を自動化することでプロセスの改善を開始しました。これはdevOpsの採用に向けたステップですが、自動化プロジェクト自体はより多くの投資が必要なため待機しています。

コンサルタントである私は、契約により「依存する」と答える義務があります。これで、あなたの質問に実際に答えることができます。

何に依存していますか？まあ、それはあなたの上司がDevOpsについて考えることになるかもしれません：

1. 上司がCIO.comへの執着でこの用語を聞いたことがあるなら、それがどういう意味であるかを尋ねてください。そこから違いが何であるか、そしてそれらの見解に互換性があるかどうかを調べます。DevOpsを試用するのに適したプロジェクトを特定し、彼らに提案します。DevOpsの中核は文化であるため、それをプロジェクトに適用する方法を検討してください。

2. 上司がこの用語を聞いたことがない場合は、DevOpsのビジネスケースを作成してください。Puppet LabsのDevOpsの状態と、The Phoenix Projectなどの書籍の資料を使用して、ビジネスケースを作成します。上司が抱えている問題を見つけ、DevOpsがそれを解決し、会話の出発点として使用します。kenchewがDevOpsについて言及する必要はないと言ったように、たとえば、Operationsをプロジェクトにもっと関与させるか、プロジェクトの提供の一部として計画するより多くのテスト自動化を提案することができます。

3. 上司がDevOpsを単なるバズワードだと考えている場合は、上記のいずれかを実行しますが、DevOpsについては絶対に言及せず、サイト信頼性エンジニアリング、プラットフォームエンジニアリング、継続的展開などの他の同様のモデルを見て、問題を解決する方法を見つけます。

重要なのは、上司の動機を理解することに焦点を合わせ、その問題を解決するための具体的な手順を実行するために、少しの時間、お金、人々を掘り下げることです。

ダニエルH.ピンクの「To Sell Is Human」という本を強くお勧めします。基本的に、Daniel Pinkは何かを販売することは非常に人間的なことであり、私たちがする必要があるのは、提案をして「ピッチ」を調整することですそれらのニーズに応えるソリューション。

あなたはしません。

DevOpsに対するあなたの熱意にもかかわらず、非技術系のボスは技術専門用語にあなたの魅力を実際に共有していません。

最初に、上司に自分が行った小規模なパイロットプロジェクトの利点を示します。いくつかの有用なデータポイントを収集して、ケースを証明します。（DevOpsのROIを測定するいくつかの方法は何ですか？）

次に、上司に、より多くの利益をもたらす可能性があるが、少額の投資が必要なプロジェクトがあることを伝えます。（上司が椅子から落ちないようにするプロジェクトを考えてみてください。しばらく上司と仕事をしている場合は、この図が何であるかを感じる必要があります。）

投資が得られたら、目標を達成する素晴らしい仕事をしてください。さらに良いのは、それを大幅に超えることです！

さて、ついに上司があなたに尋ねたとき、「それであなたは何をして私たちにそんなに多くの利益をもたらしましたか？

これはあなたが宣言する時間です：

「DevOps」

そして、あなたの次のdevopsプロジェクトにもっと投資してください。

組織のトップラインまたはボトムラインのいずれかとの関連性を示すと、あらゆるビジネスイニシアチブが牽引力になります。

devopsなどの内部イニシアチブは、最終結果にのみ影響します。個人が実行する繰り返し作業のコストと、自動化によってその支出を削減する方法を特定する必要があります。

技術に詳しくないマネージャーは、人形よりもシェフを選ぶことの違いを理解していないかもしれませんが、業界のトレンドについてはある程度理解しています。ビルドが利用できないことによる遅延のコスト、リグレッションの問題のコスト、およびアプローチがそれらのコストをどのように削減できるかを彼らに知らせることができます。改善のための具体的な計画をボトムラインで示すことができ、プレート上の他のアクションアイテムよりも優れている場合、先に進むでしょう。

DevOpsが沸騰するという用語になじみのない（または単に誤解している）人々のための私が行った推論の行は、「ビジネス価値をより頻繁に提供する」ことにかかっています。私の経験では、これは非常に少数のマネージャーが異議を唱えることができるものです。彼らはそれを得る。

「devopsを整理するために誰かが必要です。おそらく数週間の作業です。したがって、devopsに今すぐ投資する金額には制限があります」 「私たちの会社があまりにも多くのビジネス価値を提供したくはありません。もう少し必要なのですが、それだけです」。

もちろん、単なるレトリックですが、効果的で、トヨタについての本を読むように言うよりもはるかに効果的だと思います。

前の回答のすべては真実ですが、上司から実際に承認とコミットメントを得るために欠けているものがあると思います（ところで：ほとんどの人は最大で1人のボスしか持っていません...）。

遅かれ早かれ、Mr。マーフィー氏が登場します（= うまくいかないものはすべて、うまくいかないはずです。そしてその時点で、上司は次のような質問への回答を求めます。

いつ、なぜ、そしてどの許可ユーザーが実際にそれを承認したのか...前もって？

そして、その時点で、DevOps-practicesから実際のROIを取得します...そして/または突然、あらゆる種類の巨大な予算承認を取得して、探していると思われるものを実装します。

マーフィーが手に入れるのに時間がかかりすぎたとしても、リチャードが「エンジニアがコードをデプロイして実行するときに職務の分離を可能にするプロセスまたはツールは何ですか？」（要件はCxOを怖がらせます...）。

ただし、「DevOps」を初めて使用する人に紹介する必要がある場合は、「OK」のように前もって「警告」するのに役立つ場合があります。別の宗教への切り替え...」