アジャイルXXXLサイズ内でチームとチームリードを生き残る方法

Sergey Rogachevは、ロシアで2つのトピックを開発しています。ScaledAgileFramework（SAFe）とObjectives and Key Results（OKR）であり、「Agile in Russia」（サンプルには1,500人の回答者が含まれています）の調査も行っています。彼のおかげで、私たちはすでに国として体系的に、「どの業界でアジャイルが機能するのか、どこで機能しないのか、そしてそれがどのような結果をもたらすのか」という質問に対する答えに近づいています。統計に基づいて、会社がどこにあるか、アジャイルが必要かどうか、その理由、そしてそれを使って何を達成できるかを理解できます。



今年のTeamLeadで、Sergeyは、Agileがどのように大規模な組織に変化しているのか、それに応じて、環境（チームリーダーとチーム）がどのように変化しているのか、リーダーとしてどのような新しい要件が課されているのかについて話しました。そして、彼はアジャイルプロセス全体を写真で示しました。

アジャイル入門

すでにアジャイルをお持ちの場合、どのように決めましたか？このプロセス（スクラムまたはカンバン）に必要なものと、問題の解決に役立つものを自分で意識的に決定しましたか？アジャイルとの最初の知り合いはこんな感じでしたか？







...またはこれは起こりましたか？







大規模な組織では、通常の話はリーダーが来るときです。「それだけです、明日はみんなスクラム！それを理解する時間はありません-あなたはスクラムマスターまたはプロダクトオーナーです。」さらに、「ロシアの敏捷性」の研究から、数字は次のことを示しています。規模が大きいほど、この話が頻繁に発生します。しかし、どのようにアジャイルに参加したとしても、どこにたどり着いたのか、この環境とは何か、そしてそれがあなたとあなたのチームにどのような要件を課すのかを理解しましょう。これに対処しないと、Agileの実装が機能のファクトリになることがよくあります。



過去には、開発者はJiraからチケットを受け取りました。今では同じことをしますが、現在はバックログと呼ばれているものから取得します。バックログはあなたにロールアップされ、あなたはそれから取得します-そしてコンベヤーは進みます。同時に、どこかで、あなたの製品はユーザーに最終的に起こったことを紹介します：ユーザーと製品、キス！







本当にアジャイルですか？私たちはそのためにそれをしませんでした。

アジャイルとは何ですか？なぜですか？

アジャイルは、大きな不確実性に直面してプロジェクトを実行する方法へのアプローチであることをご存知でしょう。これはステイシーの混乱マトリックスです。







アジャイルは、2つの大きな不確実性がある状況でうまく機能します。

• 彼らがあなたの会社と製品にお金で投票するためにあなたがあなたの消費者のために何をする必要があるか;

または

• これを実装するためのテクノロジーがわからない、

次に、提供される複雑な環境にいることに気づきます。

• ユーザーが何を必要としているかを知っているという意見をあきらめます。
• 仮説を立てる。
• 一連の実験を実施します。
• エンドユーザーからフィードバックを得る（最初は不満であり、将来的には彼の問題を解決する方法を見つけたいと考えています）。

その結果、チームと一般的には組織全体に2つの焦点があります。

• 顧客価値とは何ですか？顧客の価値を体系的に扱うことによって、それを測定する方法を学ぶ必要があります。
• 早くやってください。チームのタフネスは、単位時間あたりにテストされた仮説の数によって測定されると言われることがあります。

これをすべて私たちの現実に着陸させる方法は？

リーダーの仕事は何ですか？

システムには、リードとしてのあなたとあなたのチームの2人のアクターがいます。簡単な例を考えてみましょう。チームは製品を作りますが、顧客は不満を持っています。私たちはリードとして何をすべきですか、この物語での私たちの仕事は何ですか？もちろん、問題が何であるかを理解してください。あなたは専門家として、それを理解しに行きます。開発チームが最終日にテストを提出したため、膨大な数の問題がユーザーに届いたとします。次に何をしますか？



私たちはすでに問題が何であるかを知っています、私たちはそれを特定しました。今やるのが最も簡単なことは、チームに来てこう言うことです。「聞いてください、皆さん、あなたは今これをやっています。そうしないでください！正しくやりましょう。」これは通常、子供を対象に行われます。私は7歳の息子に「ウラジク、これをしないでください！」と言います。そして、これは、ちなみに、実際に機能します-彼はそれをやめます。確かに、私の妻は後で私に、彼は私の前でこれをしないだけだと言います。そして、私が仕事をしているときは、すべてが以前と同じように続きます。



したがって、それは機能しません。それではどうしますか？私たちはプロセスを変更し、悪いことをしないように何ができるかについてチームに質問します。基本的に、リーダーとしてできることは、チームの行動を決定する環境をカスタマイズすることだけです。私たちは、否定的な行動を不可能にし、人々が異なる行動をとるように動機付ける環境を作ります。







たとえば、スクラムを実装しているとします。今後、少なくとも2週間に1回は結果を出さないことはできなくなります。いいえ、開発者はそれを行うことができますが、リーダーとしてスプリントをレビューするように人々を招待すると、彼らは動機付けと刺激的なフィードバックを受け取ります。スプリントは、表現に躊躇することなく、製品について考えるすべてのことを言います。徐々に、何らかの理由で、彼は毎日同じタスクをドラッグすることを少し恥ずかしくなります-毎日、彼は昨日何をしたか、今日何をするか、そして「スプリントゴール内」でさえ邪悪な追加でデイリースクラムに答えなければなりません。



つまり、人々の考え方が徐々に変化する環境を作り、人々の行動が異なります。私たちの仕事は、環境の設定方法を常に考えることです。この意味で、私たちは人のリーダーではなく、システムを構築するためのメカニズムになります。システムを想像してみてください-歯車-ボルトはそれ自体で回転し（これらは私たちの賢いスペシャリストです）、それらの間には摩擦があります。あなたはオイル缶を持って走り回り、何かが割れ始めるところを追加します-あなたはそれ自身で働くシステムをセットアップします。



そして、私たちの最もクールな人は、何らかの理由でシステムがそれ自体を開発し始めるようにそれを作ります。たとえば、チームが自分の作業の結果を確認し、彼らが言うように、自分自身を指導できる環境を作成します。さらにクールになるために他に何ができるでしょうか。確かに、そのようなシステムを設定した場合、それはあなたにとって厄介なことであり、悲しみ（または喜び）です。このシステムは（少なくとも日常的には）必要なくなり、システムはそれ自体で開発を開始します。これはいわゆる自己組織化されたチームです。



しかし、これはどのように達成できますか？

スクラムチームは何を担当していますか？

下から上に行きましょう-まだスケールがない、1つのスクラムチームを取るだけです。あなたへの質問：スプリントの終わりに責任があるチームは何ですか？スプリントが終わったとき、あなたは彼らを何のために叱りますか？







通常の答えは機能です。チームが機能ファクトリである場合、機能はどのように相互に関連していますか？なぜこれらの機能を実行し、他の機能は実行しないのですか？これらの質問に対する答えはありません-そのような環境はまだ作成されていません。典型的な例は、約2。5年前のAvitoのチームの取締役会です。スプリントの終わりに、多くのタスクがまだ完了していないことがわかります-準備ができているのは約40％だけです：







問題が何であるかを理解しましょう。最初の最も一般的な問題の1つは、チームが評価方法を知らないことです。ストーリーポイントとは何か、チームにバッキングやフロントなどがある場合に正しくアプローチする方法を教える必要があります。例を挙げてこれを行う方法を示します。



別の問題があります-彼らはそれをすべて行うことができますが、彼らは焦点を合わせていません。次に、チームを振り返り、「あなたの仕事の目的は何でしたか」と尋ねます。それに応じて、ヤギはボタンのアコーディオンを見て、「スプリントの目標は何ですか？」という質問をします。さて、ここ2週間やってきたことを大きな箱に入れましょう。彼らは聞こえます、あなたは書きます。その後、全員が匿名でステッカーに評価を付けます。「チームとして、これらのスプリントの目標をどこまで達成しましたか？」つまり、チームは質問に答えて、行われたすべてのことを確認







する必要があります。例を見てみましょう。

スプリントゴール-8

本質的に、これらは一般的なタスクです。また、社員一人ひとりが自分の目標（課題）を持っていることを示す環境を作りました。そして、別の人が答えたとき、私は別の色のマーカーを取りました：







誰もが自分の仕事をしていたことがわかります。そして、私たちがどのように目標を達成したかについてのチームの理解は完全に異なります。その後、通常、「私たちはチームはいくらですか？」という質問があります。誰もが自分の作品だけを見たように見えるからです。おそらく、2を与えた男は本当に難しい仕事を続けていて、誰も彼を助けなかったようです。9人との同志は特に助けにはならなかった-彼は自分の仕事を減らし、おそらくスプリントの終わりに自己開発に従事したが、チームの他の部分では爆撃があり、助けが必要だった。

スプリントゴール-6個

これは別のチームですが、状況は同じです。現実の理解はすでに8-9に近いですが、6つあります。これはまさにチームリーダーです-彼は誰よりも彼らが目標にどれだけ近いかをよく理解していました：

スプリントゴール-5個

目標の圧縮。おもしろいですが、すでに正常な分布があります。3-4-5と7-8-9は、チーム内の3人の2つのサブチームであり、一緒に1つの仕事を引きずり、多かれ少なかれ成功しました。3-4-5の人たちは難しい特徴を持っていました、彼らは対処しませんでした。しかし、彼らは彼らが不平を言ったことをほぼ同じように理解しています。スリーシックスは、両方の部分でジュンを助けたので、何が起こっているのかを最もよく理解している先輩です。

スプリントの目標-2〜3個

つまんだらどうしますか？スプリントの目標が少なければ少ないほど、現実の理解が深まり、実際に何をしたか、どれだけ達成したかが人々の頭の中で一致し始めます。







なぜこれをすべて示したのでしょうか。チームに1つの目標があるのに、なぜクールなのですか？

アジャイルにおける目的の重要性

アジャイルはこの点でクラシックとは異なります。







クラシックでは、一連の機能を約束し、開発にさらにリソースを投資するか、期限を売ります。ボリューム全体を実行する必要があるため、これら2つのパラメーターのみがあります。



アジャイルでは、私たちは不確実な領域にあり、消費者が本当に必要とする機能のセットを知らないことを事前に理解しています：私たちは仮説を持っているだけです。時々彼らは幻覚を言います、そしてそれらの最大の専門家は私たちのプロダクトオーナーです。彼は2つの制限内で幻覚を起こします。リソースがコミットされ（フルタイムのチーム、すべて100％割り当てられます）、スプリントは終了時に正確に終了します。早くも遅くもありません。両方のパラメーターは固定されており、スコープをフローティングにする必要があります。これは悪いことではありません。これはすばらしい機能です。スコープを変更し、フィードバックを受け取ることができるようにしたいと考えています。それを行っているかどうかは関係ありません。しかし、メーターが必要です-これが目標です。ターゲットは他にいつ撃ちますか？

スプリントレビューの目的は何ですか？

スプリントレビューを実施するには2つのオプションがあります。



チームは、スプリントの最後に製品の所有者に作業中の製品を示します。彼が彼をどのように見ているかを見てください。最も重要な質問をしました。「プロダクトオーナー、フィードバックをお寄せください。スプリントの目標をどこまで達成できましたか？そして、どのようにしてさらなるバックログを変更する必要がありますか？」プロダクトオーナーは閉じたポーズをとっています。「ここで何を言えますか？はい、ボタンは機能しているようです。」戸惑いが生じます：フィールドでどのように機能するかについての実際の情報がない場合、つまりエンドユーザーからのフィードバックがない場合、製品所有者はどのように作業ボタンについてフィードバックを与えることができますか：







2番目のオプションはAvitoチームの1つの私のお気に入りの話です。また約2年。このチームは、メッセンジャーの売り手と買い手を結び付けます。 2つの主要な指標があります。

• , , , ..
• , .

スプリント内のチームは、平凡な機能を実装しました。これは、ラインの反対側で買い手または売り手がオンラインになっていることを示す丸い部分です。すばやく書くことができ、彼はすぐに答えます。スプリントレビュー中に、彼らはA / Bテストの結果を示し、限られた数の顧客向けに機能を本番環境に展開し、これら2つのメトリックと実際に相関するかどうかを確認しました。明らかな相関関係はなく、チームはデータを取得して理解するためにさらに1週間を要求しました。この機能がまだ必要な場合は、どのように変更するのですか？



これらは2つの異なるオプションです。目標は、スローガンとしてだけでなく、測定可能なメトリックで定式化されたときに機能します。そうでなければ、それは再び冒涜です。

スプリントの目標は何ですか？

マイルストーンに基づいて目標を設定できます。たとえば、そのような日付までにリリースを行うなどです。ここでもほとんど情報がありません。これが消費者が望んでいるものであることをどのように測定しますか？



OKRは、異なるアプローチを提供します。メトリックに基づいて、顧客固有の目標を設定します。顧客はあなたの製品とどのように相互作用しますか？これは、彼が問題をより速く、より良く、より良く解決するという事実にどのように影響しますか。お金であなたのビジネスに投票する準備はできていますか？したがって、メーターが必要です。



OKRが言うように、目標の特性の1つは、野心のレベルでなければなりません。つまり、スプリントのクライアントの生活を向上させるだけでなく、最大80％、52％などを向上させたいと考えています。これはジャンプしたいメーターです：

結論：どのような環境を作成していますか？

製品のバックログは、単なる一連の仮説です。私たちは、このシステムの仕組みとして、チームレベルで、バックログに対する人々の態度を精神的に変える必要があります。バックログに幻覚があります。したがって、必ず製品の所有者や事業者などに質問してください。 -なぜこれをしているのですか？これが私たちのクライアントが必要としているものであると確信しているのはなぜですか？よくわからない場合は、これが本当に彼らが望んでいるものであることをどのように測定できますか？チームとビジネス顧客の両方の考え方を変えて、事前にすべてを知っているという感覚を一緒に放棄します。



チームはスプリントの目標に取り組んでいます。スコーピングについてチームからのコミットメントをとらないでください。あなたはそれをスクラムと呼んでいますが、これはあなたが本質的にそれらを滝に押し込む方法です。スプリントのすべての機能を実行することではありません。いいえ、スクラムプロセスのスプリント内のチームは、1週間前に幻覚を起こしたものが目標に近づくものではないことに突然気付いた場合、製品のバックログを変更することもできます。もちろん、2週間は短い期間であり、最終的にはあまり変わらないかもしれません。それにもかかわらず、精神的に変化します-規模で、この問題はそのすべての栄光で出てきます。



製品とスプリントのバックログは、目標を達成するための単なる計画です。計画は定期的に結果と照合し、拒否された場合は変更する必要があります。デイリースクラムでは、毎日質問する必要があることはすでに述べました。「一般的に、目標とは何をしているのですか？」徐々に、範囲よりも目標について考えるように人々を訓練します。しかし、最初に、これを数回繰り返す必要があります。そうすれば、人々は最終的になぜこれを行うのかを理解できます。



焦点は、納期の予測可能性よりも最終結果にあります。機能を取り込むだけでなく、いくつかのメトリックを変更することに重点を置いています。一部の機能を完了しない可能性もあります。スプリントバックログの2/3を完了することで、クライアントの主要な指標が改善され、2つの機能が完了していなくても問題はなくなります。目標は別のものです。



スプリントレビュー-顧客のフィードバックに基づいて、目標に向けた進捗状況を評価します。また、実際のお客様から。これは、チームが使用するエンジニアリングプラクティス（継続的な統合、継続的な展開など）に関連するすべての従業員にとっての課題です。これは、アジャイルが適用しようとしている他の業界で現在急増しているものです。



たとえば、餃子を製造しているNovosibirskのSiberian Gurman社は、不確実性の領域で実験することを決定しました：餃子またはラッパーのフレーバーフィリングを変更した場合、これは製品の購入力にどのように影響しますか？涼しい！ -今、私たちは実験を行い、フィードバックを受け取ります。しかし、実験とはどういう意味ですか？彼らは新しい餃子のフォーマットで小売業者にやって来ますが、小売業者は少量の購入を望んでおらず、6か月間大量の供給を提供しています-これが実験が1年続く方法です。その結果、Sibirskiy Gurmanは、すぐにフィードバックを得ることができる独自のストアをオープンしましたが、そのストアはプロジェクトの完全にコストのかかる部分です。



ITでは、ご覧のとおり、すべてが単純です。すべてがすでに発明されています。そして他の業界では、人々はできるだけ早くフィードバックを得るために創造的です。しかし、それは誰にとっても起こります。

スケールで何が起こりますか？

写真のどこかにあなたのチームがいます。そして、それは始まります。各チームには独自のバックログ、独自の目標があり、クライアントが誰であるかを理解していますが、何らかの理由で、あなたから何か他のものを求めている多くの人々（請負業者、利害関係者など）があなたに駆け寄ります（たとえば、幻覚をバックログに貼り付けます）、何らかの理由でそれらも実行する必要があります。







最終的な症状のレベルでは、次のようになります。

• 膨大な数の依存関係。
• 誰に依存しているのかを事前に知らないことがよくあります。これは、一部の機能を展開するために誰と交渉する必要があるかについての透明性が低いことです。スプリント内でそれを開始すると、その瞬間に次のことがわかります。APIを自分で変更することはできないため、APIを実行する必要があります。ただし、ここでは、規制、情報セキュリティなどに同意する必要があります。つまり、誰に走るかは事前にわかっていません。
• , . , . , . .
• — . - , , ? , , , . .
• — . : « , ! !» — « ?» .

これらすべてが大規模にどこから来ているのか、そしてなぜそれが発生するのですか？これらすべての依存関係が銀行で発生する、ローンを取得する典型的な例の例を考えてみましょう。



銀行が最初にすべきことは、高品質、高速など、優れたローン条件があることを人々に伝えることです。実際、クライアントとの協力はマーケティングから始まります。その後、ローンが完全に終了するまで、査定、登録などが行われます。同社には、クライアントに直接サービスを提供し、クライアントと通信する運用サービスがあります。







次に、サポート、加速、自動化を行うITシステムがあります。一般的には、クライアントがクールかつ迅速にローンを取得できるようにします。これは私たちの人々と私たちの組織構造が現れる場所です。不自然な例を次に示します。モスクワのIT部門に310人の開発者、エストニアに30人、アメリカに別のベンダー（150人）がいます。







私についての本当の例。お気に入りの銀行で3番目の住宅ローンを取得していたとき、ステージ2（申請の迅速な評価）で拒否されました。同じ日の夕方、私のVIPマネージャーは、古典的な質問で私に電話をかけました。「セルゲイ、私たちの銀行ですべてがうまくいっていますか？多分私は何かであなたを助けることができますか？」もちろん、私は彼に出くわします。「おい、どうしたの？私はあなたのVIPクライアントです。すべてが順調だったのに、なぜ私の住宅ローンが拒否されたのですか？」彼はタイムアウトを要求し、夕方に私に電話をかけました。彼はCRMを調べたところ、私が申請した情報がまったく表示されなかったため、すぐに質問に答えることができませんでした。



その理由は、当時、この銀行は運用サービスの最初の部分をパートナーに外注していたためです。つまり、入り口で顧客にサービスを提供する親銀行とパートナー銀行がありました。大まかに言えば、私を愛しているのは親銀行ではなく、そのパートナーが私を拒否したのです。ある銀行の責任が別の銀行の責任との合流点で終わったため、統合は崩壊しました。小さな間違いで、親銀行は彼の最愛のクライアントがパートナー銀行によってあまりよく扱われていないことに気づきませんでした。そのようなジャンクションでは、企業は顧客を失い、その結果、お金を失うことがよくあります。



なぜ私はこれをしているのですか？あなたのスクラムチーム（バッキング、フロントなどの点でクロスファンクショナル）がこの構造内のどこかにあると想像してください。重要な質問は、顧客の問題を解決する上で、チームはどの程度機能を超えているかということです。理想的には、クロス機能は、クライアントが会社とのコミュニケーションのライフサイクルのどの段階でも支援できるようなものでなければなりません。たとえば、11人の場合、1つのスクラムチームにいくつのコンピテンシーを収める必要があるか想像できますか？



残念ながら、大規模な場合、これが主な問題です。チームはクライアントに関して機能横断的ではなくなります。解決策は次のとおりです。可能な限り相互機能するチームの大規模なチームをまとめましょう。



これが例です（2つの赤いステッカー）。 「Mortgage」と書かれたステッカーは、住宅ローン部門が表示されるように組織構造を変更していることを意味します（ストリーム、部族、電車など、異なる会社では異なる呼び方です）。ビジネス（住宅ローンを発行するための財務指標を担当）とチーム（モスクワとエストニアに住んでいます）を組み合わせて、このストリームの最初の部分でシステムを開発し、統合エラーなどを修正します。







私の話では、ベンダーをこのトピックに引きずり込むことはできませんでした。彼らは言った：「私たちにTORを書いてください、私たちはすべてをします。」しかし、いずれにせよ、あなたはそのクライアントを可能な限り広く見つめる部門を形成します。「顧客に焦点を合わせ、価値を」という乾杯がよくありますが、このユニットが閉じるステップの数を数えます。閉じるほど涼しくなり、正確には徐々に急勾配になり、クライアントのすべての問題を解決できるようになります。



なぜ私はこれを言っているのですか？リードの仕事は、チーム開発のための環境を構築することだけではありません。まず、次のことを理解する必要があります。

• あなたはどのような状況にありますか？
• あなたのチームまたは部門はどのようなステップとクライアントの問題を解決しますか？
• あなたのビジネスは誰ですか？
• あなたのビジネスユニットのエンドカスタマーKPIは何ですか？つまり、チームだけでなく、回路全体で何を改善しますか。

例として、クロスファンクショナルユニットの3つのオプションを紹介します。

オプション1：プラットフォームを使用したチャネルごと

それらの1つは、基本的にWebフィード全体であり、すべてのWeb開発者がいます。たとえば、銀行の場合、主な指標は魅力の観点からであるため、クライアントはローン計算機を使用してそれを計算し、住宅ローンの借り手になることができます。



アクティベーションとメンテナンスに関連する指標がすでに含まれているモバイルアプリ（iOS、Androidなど）。プラットフォーム部門、つまり、他の部門の消費者であるコンポーネントを作成することもできます。

オプション2：プラットフォームを備えた製品別

2番目のオプションはよりクールです。各ユニットがチャネルに関して機能横断的になるように組織構造を変更します。クレジットで何かを修正する必要があります。これは、デビットカードの場合と同じように、Webチャネルと携帯電話の両方で行います。部門はすべてのチャネルを完全に変更できます。ただし、部門が同じコードベースに変更を加えることができることを確認する必要があります。



これはより複雑ですが、よりクールなオプションです。デビットストリームが稼いでいるので、ビジネスは本当にそれを気に入っています。私たちがどれだけ稼いでいるかを理解でき、さらに開発チームに給与があります。結果として、収益とコストを組み合わせることになります。あなたの部門は、独自のP＆Lを持っており、小規模組織としてのあなたの効果を確認できるため、巨大な部門の中で小さな会社になります。

オプション3：ステップバイステップの値ストリーム

複雑なケースには膨大な数のユニットがあり、それぞれが一連のメトリックを担当します。大規模な組織では、これが最も一般的なオプションです。

大規模にどのような環境を作りますか？

大規模に、1つのチームのレベルと同じ環境を作成します。それは実際には同じことをしますが、私たちはクライアントの旅全体にわたって機能横断的に成長しています。したがって、困難の海があります：ビジネス、他のチームとのコミュニケーション、より複雑なサイクル（2週間ではなく四半期ごと）：

四半期目標計画の共有：OKR計画（PI計画）

はい。あなたのチームは、あなたがすべての段階であなたのクライアントを助けることができないことをすでに理解しています。しかし、顧客の指標を変更することを計画する必要があるビジネスがあることを理解しています。ほら、まだたくさんの人がいます：約150人の他のスペシャリスト（10-12チーム）。そして、あなたが彼らに依存しているので、誰と通信しなければならないようです、そして彼らはあなたに依存しています。



コミュニケーションの仕方は？すべてのアプローチで、アジャイルは簡単なレシピを提供します：「ただ話してください：あなたは誰かと中毒を持っています、行って彼と話してください。」開発者、特に他の人よりもモニターとのコミュニケーションを好む人は、「まあ、それはできません。どうすれば話せますか？」と言います。したがって、すべてのフレームワークで通信が強制されます。「わかりました。通信できません。これで通信しますが、次のアルゴリズムに従います。」



共同OKR計画（PI計画と呼ばれる別のアプローチ）が人気を集めています。アイデアは、私たちが長い間（4分の1）、群衆全体とともに、私たちのビジネスが誰であるか、そして内部の依存関係を理解し​​、共通の目標を計画するというものです。これは2日間のイベントですが、チームがすでに相互に通信することを学んでいる場合、何とか1日で開催できる人もいます。大まかに言えば、これは次のような2日間の促進された質疑応答イベントです。

-私たちは誰に依存していますか？

-今四半期は何をしていますか？

-どのような財務指標を取得したいですか？ビジネス、答えてください。

つまり、四半期の終わりまでに、全員が全員と合意に達し、実行したい場所を決定するようにします。これらは、3年前にSberbankが最初にそのようなイベントを開始しようとしたときの実際の写真です。







共同OKR計画またはPI計画は段階的に実行されます。

ブリーフィング

最初に、ブリーフィングが必要です。ビジネスはこう言うべきです：「四半期の終わりまでにそれを見たいです...」そして、例えば、ここに3年前のSberbankがあり、下に-GameDev-ロサンゼルスのXsolla社があります。ちなみに、アメリカ人は、新しいクライアントをアクティブ化するのに問題はないという簡単な話をしました。アクティブ化のメトリックですべてがクールです。しかし、繰り返し購入には問題があります。何らかの理由で、繰り返し購入の割合が非常に低くなっています。そして2番目の問題は、何らかの理由で追加のサービスを購入しないため、平均チェックが低いことです。そして、ビジネスは尋ねました：「お願いします、この四半期のすべての機能は、繰り返し購入と平均チェック（追加サービス）の増加を目的としています」：







これは、優れたビジョンがどのように見えるかという方法の1つです。つまり、ビジネスコンテキストと財務指標について話すときです。しかし、四半期に何が行われるかは事前にわかりません。次は何が起こる？

建築家のスピーチ

IT企業では、間違いなくアーキテクトの話を聞いています。彼にとって面白い話です！-環境も変化しています。そのようなセッションで、アーキテクトは最終的に顧客が誰であるかを理解します（ほとんどの企業アーキテクトはこれがビジネスだと考えています）：







このアーキテクトはSberbankの「ひどい」風景についてすばやく報告し、逃げ出したいと考えました。さらに、彼は50〜100ページの概念的なアーキテクチャを提供しました。ここで他に何ができますか？まだ理解できますが、どちらかといえば-電話してください。」しかし、プレゼンテーションの後、チームリーダーの1人が彼に質問をしました。

-親愛なる建築家！右上のキューブから3番目-このシステムがまだ稼働していないことをご存知ですか？

-もちろんです。私自身がこれらの立方体を描きました。

-半年で試運転されることをご存知ですか？

- はい、もちろん。

-今、私たちは四半期目標の計画セッションにあり、ビジネスは私たちに機能を求めていることを思い出してください。これは理論的にはこのシステムを通過するはずです。

ここで、建築家は質問が何であるかを理解しています。そして、チームは彼に彼らと一緒にいるように頼みました。そうすれば、彼らが彼らの機能を計画するとき、彼らは不適切な決定をする方法を一緒に考えるでしょう。

スウォーミング（ターゲット生成）

その後、チームは無料の水泳に出発しました。彼らには3時間あり、四半期ごとに責任を負うことをいとわない目標を生成する必要があります。これはスウォーミング（スウォーミング、ブーンという音）と呼ばれます。これは一種のネットワーキングですが、作業の枠組みの中で：







もちろん、すべてがそれほど単純なわけではありません。彼らには、四半期にどのような適切な目標を達成できるかを達成するためのアルゴリズムが与えられます。彼らは、4分の1先の推定スプリントバックログを示すフリップチャートシートを作成します。これは、可用性を考慮して、バックログを大まかに埋め、他の依存関係チーム（誰に、誰に、何をするか、何をしないか）と話し合った後、次の質問をするために必要です。達成する目標と、達成度を測定できる尺度（メトリック）は何ですか？」



つまり、作業のバックログを計画し、それらの目標を策定した後、これらのバックログを拒否します。これは、適切な目標設定に到達するためのテクニックにすぎません。いかなる状況においても、この四半期の一連の作業に全員がコミットしているとは思わないでください。

-チーム、目標を考えてください！

- ... それでおしまい！

-本当に届きますか？

-いいえ、あなたはただ思いつくように頼みました。

いいえ、私たちは促進しています。つまり、多かれ少なかれ適切な目標を達成するのに役立ちます。

写真では、通信を余儀なくされたチームの代表者。彼らは時々、「はい、私たちは何をしようとしているのか理解しています。先週彼らと話をしたので、他のチームへの依存関係さえ知っているようです」と感じてこのセッションに来ます。しかし、チームが今四半期に何をするかを直接私に尋ねると、依存関係が最終的に明らかになります。







私たちは彼らにツールを提供し、彼らの依存症について話し合った後、彼らがそれらを表示し、誰が誰に依存しているかを確認できるようにします。垂直スキップはブロック内のスプリントであり、水平スキップはチームです。交差点で、チームはそれがどのような機能を実行するかを示し、赤い矢印でそれを作成します。「しかし、APIの前にスプリントを実行することを約束したので、前面にボタンを作成します。」これは、私たちがあなた、誰、誰に、いつ、何に同意したかという合意のプロトコルです。

プロダクトオーナーのプレゼンテーション

さらにプレゼンテーションでは、製品の所有者がチームの結果を示し







ます。エンドツーエンドのシナリオがどのように機能するかを頭の中で接着しようとしているのはビジネスだけです。タイプの開始時のプロダクトオーナーへの質問：「どのエンドツーエンドシナリオが機能しますか？」-多くの場合、未回答のままです：「待ってください。私たちはこのコンポーネントに責任があります。それは私たちのために働くでしょう、あなたの質問は私たちのためではありません。弾丸が私たちの側から飛んだ、あなたの質問への答えを他のチームで探してください。」当初、企業は何も理解していませんが、この絵を頭の中でくっつけようとしています。

外部依存関係

Xsollaには、TechOpsの最後から2番目のラインがあります。チーム内の環境のサポートをもたらすには、それぞれDevOpsに参加する必要があることを彼らはすでに理解しています。しかし、当時（6か月前）は外部ユニットでした。オペレーションマネージャーもプレゼンテーションを行いました。彼は赤いステッカーの上を歩いて確認しました。「はい、そのような環境を展開する必要があることをここに押し付けました。私は責任を負います、私たちはそれをします」：







彼が1つのステッカーで彼らが何をするかを言ったとき、彼のチームが訂正したことは興味深いです：

-待って、おい、私たちはあなたにこれを尋ねなかったが、何か他のもの。とった？

- とった。

- あなたはそれをします？

- 私はそれをやる。

- OK。

彼らは弁護士、マーケティング、デザイナーに問題を抱えていました-これらの人たちはアメリカ（ロサンゼルス）にいて、この会議には来ませんでした。したがって、それらへの依存関係はハングしましたが、恐れがありました。おそらく彼らはそれを行うでしょうが、個別に呼び出したり、通信したりする必要があります。この会社の結論は、彼らも次の四半期計画に彼らを招待するということでした。

リスク治療

リスクの処理方法には特定のアルゴリズムがあります。重要なアイデア：トップマネジメントがタスクを設定できる環境を作成します。そしてそれは怖いことすらありません、彼らは彼らを連れて行く準備ができています。彼らは、「ここでアウトソーサーとの契約を修正すれば、私がやりたいことをもっとできることがわかります」と見て、彼らは関与します。

これらは、この会議にすべてが揃っている場合に受け入れることができる問題解決の例です。

指投票

最後のステップは、チームが開発した目標に対して本当に責任を負う準備ができているかどうかを確認することです。指を上げてください。

• 5本の指-まっすぐで、目標に非常に自信があります。
• 1本の指-一般的な目標では、それは問題であり、やり直す必要があります。

あなたは全体像を見て、会社への信頼が低いと感じたら、周りを見回してもらいます。「見て、あなた自身が自分の目標を信じていないようです。あなた自身があなたの計画を信じるようにそれをやり直してください。誰もあなたにそれらを押し込みません（少なくとも彼らは試みます） "：

共同遡及的四半期末：OKRレビュー（検査および適応）

四半期の終わりに、私たちは再び全員を集めます。実際、これは大きな回顧（OKRではOKRレビューと呼ばれます）です







。実際の例を使用して、そこで何が起こっているかを示します。チームがこの四半期に取った目標が書き出されています。彼らは、メトリクス、つまり、ビジネスがチームと会社に望んでいた目標への影響を計画的に評価しています。実際の成果が評価されます：







ここでも撮影：「この機能がおそらく影響を受けたと思う」というだけでなく、いくつかのオプションからA / Bテストから実際のメトリックを収集したビジネスの製品を評価する方法を知っていますか顧客に手を差し伸べる。



別のオプション：チームがまだエンジニアを設定しておらず、クライアントにすばやく連絡する方法がわからない場合、Planning Pokerのように、指だけで評価します。「この目標をこれほど多く達成したようです」：







彼らは基本的に達成率を設定します。チームが四半期に88％に達したことがわかります。アイデアは、そのようなメトリックが示すということです：

• ビジネスで設定した野心的な目標。
• あなたはそれらを運ぶ方法をどれほどスムーズに知っていますか：

最後に、定期的な回顧があり、各チームは別々に作業します。キーポイント：一般的な問題が引き出されます：チームごとに個別にではなく、一度に複数を撃つ問題。通常、基準は3チーム以上にしました。それらに共通の問題がある場合は、ユニット全体のレベルでそれを解決する必要があります。

概要。リーダーの問題は何ですか？

この全体の話の中で私たちにとっての課題は何ですか？何をすべきかは明らかなようです。しかし、あなたはより大きな環境のコンテキストにいます：他のチーム、ビジネス、あなたが顧客の旅のどの部分をどの顧客のために決めるかを理解しています。実際、そのようなリードやチームリードなど、私たちにはたくさんの人







がいます。規模での私たちの要件は何ですか？リーダーの問題は何ですか？サイズが重要であるという事実... :)







大企業の過酷な環境で生き残るために、チェブラシュカはワニに変化しました...言い換えれば、あなたは自分自身を成長させる必要があります。これは痛い言葉ですが、実際、あなたが自分自身を成長させなければ、あなたの下の人々もそれをしません。そして、巨大な会社では、あなたがどのようなリーダーになるべきかについての要求は冷酷です。膨大な数のチームの環境をセットアップできる必要があります。つまり、何倍も積極的に自己開発できる必要があります。

アジャイルで生き残るリーダー

基本的に、人の管理をやめる必要があります。人々が自治する環境を形成する。専門家になるのをやめて、交渉者になりましょう。

これらすべての分野であなたがどれほど急勾配になったかを確認する価値のあるものがあります。

今年は、サンクトペテルブルクで開催されるSaint TeamLead Confの代わりに、モスクワで2回目のTeamLeadConfを開催します。すでに11月16日と17日にライブで会い、この間に何が変わったかについて話し合います。私たちはすでに実際の対面会議を切望しています。ステージでスピーカーのカリスマ性を確認してから、ホールでさらに1時間お願いします。毎月のコーヒーを飲み、あなたが知っているすべてのチームリーダーを一度に見ること。そしてその後さらに1か月間、連絡先、書籍、キーワードを使用してレコードを整理します。



, , , , . : , , -, , .



. . . 2019 .