しかし、皮肉なことに、リーダーシップは他に何も知らず、断固として知りたくなかった。 賢者の指示に従わなかった悪人としての評判を獲得しないように、私は自分自身を乗り越え、愚かにも上司の「要求」に応じなければなりませんでした。
時々、興味深い結果が得られました。 そのようなケースの1つについて説明します。
マネージャーは、チームがスタンドを通過するコンバージョンが3週間連続して減少している理由を見つけるようにIvanに依頼しました。
Ivanの部門には、数十のチームがあり、毎日何百ものディストリビューションのアセンブリを作成し、スタンドでチェックしていました。
変換では、ターゲットスタンドを通過したアセンブリの数に対する、1週間にチームが作成したビルドの数の比率を考慮しました。
甘い指標の主な欠点の1つは、それらから何かを判断することが不可能であることです。 Ivanの長が使用した変換は、典型的な砂糖の指標であることが判明しました。 コンバージョンは低下していましたが、その理由は完全には不明でした。
当然のことながら、すべてのチームが、スタンドのパフォーマンスをあらゆるコストで改善するために、耳を傾けました。 これを行うために、「悪者」のリストを含む別の甘いメトリックが非常に迅速にコンパイルされました。
写真の各列の下に、チームの名前が実際に書かれています。
チームはhowき、彼らに降りかかった新しい不幸から脱却するために苦労し始めました。
チームを追いかけるのにうんざりして、リーダーはイワンにコンバージョンの低下の理由を整理するよう促しました。
そして、それが何をもたらしたのか...
指標の本質を理解する
メトリックを理解する必要があります。 少なくともそれらがどのように考慮されるかを理解してください。 その後、より深く掘り下げて理解することができます。 イヴァンはこうしました：
変換=作成されたビルド/スタンドの合格
式を理解すると、Ivanは最初に変換の2つのコンポーネントをチャートに表示しました。
作成されたビルドの数は実際には変わらないことがすぐに明らかになりましたが、同時に、スタンドを通過したアセンブリの数は減少し、変換が減少し始めた瞬間に減少し始めました。
変換は、作成されたアセンブリの数と過去のスタンドの数の差が大きくなったという事実のために変更されました。 変換は、互いに分割した結果であり、差が大きくなると、変換値も同期的に変化します（減少します）。
グラフ上の値の違いは暗い線です。
つまり グラフの赤と青の列の差の増加は、コンバージョンの自動減少を示しています。
結果を熟考する
Ivanは、調査結果が原因を特定するにはまだ十分ではないことを理解していました。
メトリックに関するこれまでの経験から、彼に1つの重要なアイデアが与えられました。問題の真の根本原因を突き止める必要があります。
DevOps変換の変更の理由は、実際には...人です。 チームの開発者と開発者：最終的にそれらに到達したかったのはまさにIvanでした。
作成中のアセンブリとスタンドを通過するアセンブリとの間の増大する違いを見て、彼は疑問に思った。なぜこれが起こっているのか、そしてスタンドに達していないアセンブリの「生成者」は誰なのか？
読んだ本「Toyota Tao」はヒントを与えました：「在庫残り物」または「進行中の作業」を見る必要があります。
なぜなら アセンブリは複数のスタンドを通過してそこにとどまることができたため、Ivanは1つのスタンドのアセンブリだけでなく、真の「本当のバランス」を確認することにしました。 どのスタンドでもまったく使用されずに放置されたアセンブリの数を数えるには：
暗い線は、初期変換スケジュールで考慮された、ターゲットスタンドを通過したアセンブリの数である黄色の残基数を示しています。
推測する必要すらありませんでした。 2行の明らかな同期移動は、相関を計算することでも確認されました。
アセンブリの残留物が多いほど、望ましい変換は少ないことが判明しました。
根本原因を見つける
最も単純なテーブルを使用して誰が残り物を作成するかを決定することは難しくありませんでした：
左の列には、チームの名前があります。 強調表示された列-このチームによって1週間に作成された残基の数。
TOP-2リーダーはすぐにcい出し、Ivanはすぐに走って彼らを理解しました。
もちろん、理由は平凡であることが判明しました。チームは新しい開発サイクルを開始し、機能を作成して、その正確性を検証するためにアセンブリを作成し始めました。
甘い指標の主な欠点
実際、転換の変化は、周期的な開発プロセスと密接に関係していることが判明し、致命的でも悪くもありませんでした。
変換チャートには、3つの開発波（サイクル）が表示されます。
これは自然なプロセスです。
そして、リーダーと宣誓するチームは完全に正しい：会社が使用している現在の開発プロセスでは、変換の増加は「理解できない」アクションであるだけでなく、プロセスを完全に破壊し、ソフトウェアの供給の大幅な遅延につながる可能性があります。
これは、甘い指標の主な欠点です。肯定的な側面を否定的な側面に変え、状況を明確にするのではなく、混乱させ、悪化させるだけです。
結論
全体的に、この経験はIvanにとって興味深いものでした。そのため、彼は喜びのためにリーダーシップのプレゼンテーションを準備しました。そこで彼は、使用された指標が部門の管理に適していないこと、誤解を招き、大きな問題を引き起こす可能性があることを説明しました。
それだけです
Ivanの経験が興味深いと思われる場合、彼はあなたのフィードバックに非常に感謝します。
ところで、Ivanは今、自分自身と彼の知識を刺激的で焼cen的なプロジェクトに入れたいと思っているので、PMで興味深いオファーを受け入れます。