みなさんこんにちは！ 私の名前はEgorです。AvitoのApp Platformクラスターを率いています。 私のチームは主に内部製品、ツール、プロセスの開発に従事しています。これは一般にプラットフォーム開発と呼ばれています。

1年前、このブログでパフォーマンスレビューの実装方法と使用方法について話しました。 それから、私たちはそれを個々の人が会社にもたらす利益の指標として見ていると言いました。 これを理解することは重要で役立ちます。 これは、「VasyaとPetyaの比較」という質問に答えるのに役立ち、誰にどのボーナスを支払うかを決定するのに役立ちます。 しかし、チームレベルに移行すると、すべてがより興味深いものになります。 チームの特定の結果と、それが会社の成功に与える影響を評価することが重要です。 すべてのチームメンバーの平均パフォーマンスが高いということは、必ずしもチームが素晴らしい結果を達成したということではありません。 ある程度の相関関係は確かに存在しますが、このツールを使用して、会社の成功に対するチームの実際の貢献度を評価することはできません。

これと他の多くの問題を解決するために、AvitoではOKRメソッド-目的と主要な結果を使用します。 会社全体で理解可能で簡単に測定可能な目標のツリーを設定し、さまざまなチームの結果を相互にリンクして、望ましい結果を達成することができます。

私たちは現在、ほぼ3年間OKRと暮らしています。 1つのチームから始めて、プロセスを130の異なる構造（個々のユニット、垂直、クラスター、機能）に拡大しました。 この記事では、OKRを使用してそれを活用する方法に関する実用的な手法に焦点を当てます。

教育プログラム

始めるために、OKRがどのように機能し、どのような問題を解決するかを簡単に見てみましょう。 ここでは新しい秘密を明かしませんが、もしあなたがOKRについて表面的にしか聞いていなければ、それは役に立ちます。 OKRは目標設定システムであり、戦略レベルから始まり、個々の構造単位で終わる組織全体の目標ツリーを構築できます。 ツリーは、非常に単純な構造から始まり、数十レベルのネストで終わる、好きなように分岐できます。

目的は、主要なビジネス価値を定義します。 彼らは「何？」という質問に答え、時には「なぜ？」と答えます。 主要な結果はすでに「どのように？」という質問に対する答えです。 多くの場合、目標が抽象的なスローガンである場合、重要な結果は、水を許容しない最大の特異性です。 例を見てみましょう。

これは、OKR方法論に従ってレイアウトされた抽象的な掲示板の目標の1つに見えるかもしれません。 これは非常に高いレベルの目標です。 これは、成長のための最も重要な戦略目標の1つを直接反映しています。

主要な指標は、目標を測定するための明確で理解可能な方法を提供します。そうでなければ、着実な成長の下で何でも打ち負かすことができます。メインアカウントで始まり、メインページのjavascriptの重みで終わるからです。

さらに、企業レベルで設定された目標は、下位レベル（たとえば、機能、部門、または垂直）に下がります。 この例では、子会社の1つが自動市場であり、市場シェアの拡大を望んでいます。

重要な結果も狭まっています。 これらは特定の数値を中心に展開するだけでなく、これらの結果を達成する必要がある領域を設定します。

3番目の部分は、特定のチームの目標です。 さらに興味深いことに、彼はユーザーへの価値の提供を促進するために働くインフラストラクチャチームの例を挙げました。 これらの目標は上記から直接継承されませんが、長期的にはそれらに影響を与えます。

これらの主要なメカニズムに加えて、OKRには数十の原則があり、そのうちいくつかの主要な原則を特定しました。

OKRの原則

• OKRの結果は、経済的動機から完全に切り離されるべきですが 、これは直感に反します。 最大ボーナスにチームが達成した目標の割合を掛けたいという願望は理解していますが、これは決して必要ではありません。 OKR-正直さについて。 目標を達成するための指標とアカウントのバランスの間に直接的な相関関係があるとすぐに、これらの指標はチームによってすぐに過小評価され始め、不正行為と方法論を破る試みが現れます。 誠実さの代わりに、ミクロ管理と疑念の文化が作用します。 これは、OKRで運営されている会社では、ボーナスが禁止されているという意味ではありません。 それらは単に目標に直接結びついていません。
• 目標は野心的で達成可能でなければなりません 。 意欲は、主要な指標が実装において選択された指標であるという事実にあり、その実施においてチームは完全に確信を持っていません。 システム全体は、チームが最大限に機能し、すべてを最大限に提供する場合、その指標の約60〜70％を達成できるように形成されます。 このアプローチにより、一定の課題、選択された目標への集中、チームの能力と才能の成長が保証されます。 それは、疲れ果てて絶えず働くことではなく、健全な複雑さについてです。
• 例で示したように、 重要な結果はすべて測定可能です。 よく知られたSMARTテクニックによると、抽象的な「うまく機能する」ものはありません。
• 目標と主要な結果は問題を特定し、いくつかの指標で説明しますが、 特定の解決策を指示するものではありません 。 これにより、チームに演習の余地が与えられます。仮説の1つが不十分な場合、他のソリューションを実装する時間を常に確保できます。
• すでに示したように、 目標はリンクする必要があります 。 この接続は、企業レベルから特定のチームまで、垂直に行うことができます。 また、チーム間で大きな結果を達成するために、異なるチームで相互依存の目標を設定する場合、水平にすることもできます。
• OKRは、主に分散型の組織構造を対象としています。 -垂直的なつながりにもかかわらず、ほとんどの目標はチームの責任範囲、重要なトリック、ユーザーの苦痛に対する理解に基づいて、チーム自身が設定します。 要するに、 チーム自身が何をすべきかを決定し 、同じOKRの形でそれを策定します。
• そして最後の重要な原則は宣伝です。 全員が会社のあらゆる部分のOKRを確認し、完璧な選挙について質問したりコメントしたりできるはずです。 秘密のプロジェクトには例外がありますが、これらは詳細です。 同様に、結果は誰でも利用できます。

しかし、これはすべて美しい理論であり、他のすべての理論と同様に、純粋な形ではかなりひどく機能します。 OKRに取り組んできた3年間で、これらの各原則を揺るがすことができました。 いくつかのケースでは、彼らは非常に燃えていました、そして、いくつかでは、それどころか、彼らはよりよく働き始めました。 そして今、このセクションに続くのはOKR理論ではなく、科学的アプローチの結果です！

開始方法

フレームワークの場合と同様に、OKRは指をクリックするだけですぐに組織全体に展開されるべきではありません。 文化がこれらすべての原則をどのように統合し、それらから利益を得始めるかを徐々に確認してください。

単一のコマンドでOKRの実装を開始するのが最善です。 たとえば、Avitoでは、まさにそれを行いました。 私たちのCPOであるEugene Emelyanovは、3年前にプロのユーザー（自動車ディーラーや不動産業者）向けのツールを開発したチームの製品でした。 彼は先駆者になりました。 最も関連性の高いアドバイスを得るために、彼はGoogleに行きました。Googleはすべての部門で積極的にOKRを使用しています。 受け取った洞察を使用して、ZhenyaはOKRを実装するために私たちに戻ってきました。 媒体での方法についての彼の投稿です。

彼のチームの例では、運用上の目標設定の方法としてOKRを使用することの利点が明らかになりました。 以前は非常に荒れ狂っていたチームは、作業の結果を測定し、その重要性を理解し、集中力を維持することを学びました。 数四半期後、近隣チームのスケーリングが開始され、可能であれば関連する目標が設定されました。 そしてさらに、いくつかのチームがOKRに完全に取り組んでいたとき、垂直接続に取り組み始め、会社レベル、部門、機能、およびその他のエンティティで目標を設定しました。

自宅で同じパスを繰り返すことができます。 可能な限り戦場に近い1つの構造ユニットを選択することから始めます。 会社レベルですぐに始めるべきではありません。目標を設定することはできますが、目標を達成する人はいません。 この段階でのタスクは、「敵対的な」環境で方法論をテストすることです。したがって、パイロットチームを賢く選択してください。

• これらは、自分の仕事の意味とビジネスの目標をよく理解しているかなり成熟した人でなければなりません。 彼らはアウトではなくアウトサムに注目することの重要性を説明する必要はありません。 そして、ビジネス目標を達成することからのバズは、そのようなチームは、通常の財産所有者よりもはるかに多くを受け取ります。
• チームはプレイされなければならない 。 彼らは上から出された問題を解決できるだけでなく、自分自身でそれを見つけることができるべきです。 この品質は、彼らが目標設定段階で積極的な立場を取り、独自にOKRを選択して策定するのに役立ちます。これはボトムアップを設定する原理の良い内訳になります。
• チームは 、OKRの達成が依存するシステムのあらゆる部分に貢献できる必要があります。 ここで機能チームをつなぐのは悪い考えです。バックエンダーのために、またはフロントのために別々に、彼らは他の人の助けなしに彼らの目標を独立して達成することができないためです。 そして、目標を達成する可能性は、チームの外部依存関係の数に反比例します。
• チームはOKRを実装することで解決される問題を理解する必要があります。 理想的には、デフォーカス、理解可能な目標の欠如、責任の侵食または他の同様の問題にすでに苦しんでいる場合。 これは、OKRが適切に機能する場合に、彼らがより楽しくなるのに役立ちます。 チーム全体がこのアイデアに火をつけ、官僚主義や形式主義として認識しないようにする必要があります。

あなたの人生を簡素化するために、私たちはOKRテンプレートを探し回ることにしました。 Googleテーブルは、ほとんどのニーズに対応しています。 テンプレートの横にあるリンクを使用して、それを操作するための指示を使用します。

先に進む前に、OKRを実装するための一般的なチェックリストを思い出させてください 。

• OKRを実装して、達成する目標を決定します。
• 成熟基準を満たすチームを選択し、OKRを販売します。
• 4分の1後に、さらにいくつかの近隣チームを接続します。
• 次に、ピラミッドの上部-会社のOKRを追加し、目標設定を完了します。
• そして、必要に応じて、他の中間体と新しいチームを接続します。

目標を設定し、結果を策定します

組織のレベルや実装の段階は関係ありません。 しかし、目標と主要な結果を正しく策定し、それらと協力することを学ぶことは非常に重要です。 OKR方法論は、製品チームに最適です。 それらとは、特定のバリューストリームを中心にグループ化されたスタンドアロンのクロスファンクショナルコマンドを意味します。 製品のこの部分での成功は、完全にそれらにかかっています。 目標設定についてさらに説明するときは、このタイプに焦点を当てます。 組織構造と方法論の考えられるすべての組み合わせを検討するわけではありませんが、多くのプラクティスは私たち以外の状況にも適用できると考えています。

チームアイデンティティについて

あなたがチームリーダーであると想像してみましょう。 OKRを設定する問題に明確にアプローチするには、まず会社での自分の居場所を明確に定義し、長期的にチームが達成すべきことを理解する必要があります。 私はこのプロセスを自分自身のアイデンティティの検索と呼び、その理解の欠如は実存的危機と呼ばれます。 これにはいくつかのツールが役立ちます。

• チームの使命は、チームが何のために存在するかを簡単かつ包括的に定義することです。
• 長期的なビジネス目標 。 チームが1〜2年以内に正確に達成すべきこと。
• 仕事の方向 。 ミッションや目標を定式化できない場合、作業の正確な方向を理解することは、不確実性に直面してもナビゲートするのに役立ちます。

OKRを設定するプロセスにアプローチするには、これらの側面の少なくとも1つ、またはそれ以上の理解が必要です。 このようなコンパスがなければ、チームが選択した方向がビジネスのニーズにどのように対応するかを理解できません-あなたは内部で無限に効果的であり、一見クールな結果を達成できますが、最終的には何の利益ももたらしません。

目標を設定します

これを理解し、問題がないと仮定します。 以下に進みます-私たちは自分でOKRを策定します。 目標から始めましょう。 目標を策定するには、いくつかの簡単なルールに従う必要があります。 それらは、私たちが今議論したこと、ミッション、戦略、仕事の分野に関連している必要があります。

• どこからでもチームに目標が現れるべきではありません 。 「なぜこれを行うのですか？」という質問は提起されるべきではありません。そうでなければ、何か間違ったことをしました。 OKRは重要なことに焦点を合わせています。 たとえば、同じAvitoでカスタマーエクスペリエンスを担当するチームがあります。 「広告の品質を向上させる」という目標は理解できるものです。コンテンツの改善、ユーザーエクスペリエンスの向上です。 しかし、「人気を高める」という目標には多くの疑問が投げかけられています。一般的に起草されたチームはこれを行うべきでしょうか？

• 言語は定量的ではなく定性的でなければなりません 。 いいえ。「コンバージョンを0.5パーセント増やします。」 目標は、パスの長さではなく、移動の方向を設定します。 良い目標は、モノリスの存在を減らすことです。 具体的にどの程度削減するかを示すものではなく、測定スケールを指定するものではありません。 作業の方向を示しているだけです。 しかし、5つのマイクロサービスを削減するという話は、はるかに悪いものです-それは、厳格に枠組みし始めます。

• 目標は記憶に残るものでなければなりません 。 これは、チームが努力を分散させず、彼らが仕事をしていることを念頭に置くことを可能にする別の焦点ツールです。 そして、記憶されるためには、目標を簡潔に表現し、通常の主題言語を使用し、チームにとって重要な何かに圧力をかけなければなりません。 「クレイグリストを破る」-大声で記憶し、やる気を起こさせます。 「重要なリードを達成する」ことは欠かせないことであり、そのような目標は明らかに格言に入ることはありません。 つまり、彼女はそうではありません。

• でたらめや官僚主義は 、そうでなければ意味が失われます。 通常の音声と同じ言語、同じ速度を使用します。 最小限の一般的なあいまいな言葉。

• 目標は、四半期の終わりにその進歩を誇りに思うように設定されるべきです 。 わずか2年で客観的に市場のリーダーになることができれば、第1四半期からチームにそのような目標を設定する必要はありません。進歩がなければ肯定的な補強は消えてしまうからです。

• 開発者からCEOまで、 目標は全員に明確でなければなりません 。 目標をあまりにも複雑にし、あまり知られていない詳細に基づいて残すと、透明度係数が失われます。 一方では、すべてのOCDは一方のファイルにあり、他方では、すべて同じで、誰も何も理解していません。

• 多くの目標はないはずです。 理想は、チームごとに2〜3です。 適切な最大値-約5。 すべてがテクスチャに依存することは明らかですが、ここでも、焦点と強調の必要性を忘れないでください。

主要な結果を策定します

次のステップは、主要な結果の定式化です。 目標を設定するのに比べて、これはより難しいタスクです。 それらの定式化のほとんどすべての慣行は、側に大きな逸脱を許します。

• KRの重要な考え方は、定性的なものを定量的なものに変換することです。これは、具体的な測定可能な量における同じ感動的な目標です。 そして、ここに重要なポイントがあります。主要な結果は、何らかの形で共通の目標に関連するだけでなく、測定可能なカテゴリに変換する必要があります。 実際、もちろん、それは違って判明します。時には、目標はそれ自体の中でいくつかの別々のストリームを結合する傘の方向として機能することができます。 たとえば、私のチームの目標は「ユーザーへの機能の配信速度を上げる」ことです。 この目標は、数四半期にわたって私たちと共に生きてきました。KR（リリース頻度）を直接説明することに加えて、カナリアのリリース数やテストスタンドの安定化などの指標が該当します。 直接それらは配達の速度の増加につながりませんが、間接的に影響します。 セッションの長さを増やすというチームの目標があることを想像してみましょう。 良いKRは目標を明らかにし、セッションの長さをどれだけ正確に増やす必要があるか、そしてどの式によって結果が考慮されるかを示します。 しかし、悪い例では、サードパーティのイニシアチブが示されています-広告の画像の品質はセッションの長さに確実に影響しますが、直接は影響しません。

• 悪いキーの結果の1つの例は「プロジェクトが実行中」です。実行されていない場合は0、実行されている場合は1です。 この測定アプローチの主な問題は、四半期中にチームが目標に近づいているかどうかが一般的に見えないことです。 彼女は良いと恐ろしいことができます。 しかし、メトリックはこれを示していません。 現実の世界では、そのようなことを常に回避できるとは限らず、時にはそれらは必要な悪として受け入れられます。 この場合、 そのような結果を一連の小さなステップに分解しようとしますが、それでも中間結果が反映されます 。 しかし、一般的に、 理想的なケースは、メトリックが連続的である場合です （たとえば、リリース数、コンバージョン率などが同じです。選択したスケールに関係なく、重要な結果を可能な限り頻繁に測定できることが重要です。リリーススピード "私たちが望む特定のリリースの数を示す重要な結果は良いことです。しかし、やはり説明が不十分な特定のイニシアチブに固執することは間違いなく悪いことです。

• チームは、選択した結果に影響を与えるためにフル活用する必要があります 。 これは、彼女がすべての必要な能力を持っているか、短期間でそれらを受け取ることを保証できることを意味します。 他のチームが結果の達成に重大な影響を与える可能性がある場合、非常にリスクが高くなります。 しかし、これはクロスゴールを設定することの禁忌と見なすことはできません。各チームの責任の境界を明確に記述し、合意を修正し、バックアップ計画を立てるだけです。 私の記憶では、チームの1つがその部分に対処できず、2番目のチームがそれを引き受けた場合がかなりありました。 典型的な例はNPSです。 私たちは、非常に慣性的であるため、四半期ごとのOKRでは使用できないことを私たち自身の経験から学びました。 何らかの改善を実施してからNPSへの影響を評価するまでに、さらに時間がかかる場合があります。 ただし、同じ保持は、はるかに簡単に測定できるパラメータであり、影響を与えることができます。

• 重要な結果のセットは、状況が可能な限り幸運である場合にのみ100％満たすことができるように選択する必要があります。 これは、個々のKRがチームの信頼レベルをわずかに上回るという事実によって最も簡単に達成されます。 したがって、通常、結果は0.6〜0.8の範囲になります。 クールな財務予測のある会社で働いていると想像してください。 予算執行の97〜102パーセントの規模が適切に見えます。 100％完了した場合、これはわずか0.6です。 そして、そのためには健康的な挑戦が必要です。 悪い考えは、バーを高くしすぎて、目標を非現実的に野心的にすることです。それはチームをやる気にさせます。

• 選択する測定スケールは、それを達成するためのステップではなく、結果を正確に示す必要があります 。 これは重要で便利なルールですが、結果を取得するためには、まず何らかの大規模プロジェクトを開発する必要があるという事実によって、しばしば細分化されます。 繰り返しになりますが、半四半期が経過しましたが、チームはまだ何も言うことがありません。 そのため、このようなKRをいくつかのコンポーネントに分割することがよくあります。 それらの1つは開発の進捗状況を示し、2つ目はその使用結果を示します。 KRは、発売予定の新製品の数を伝える必要はありません。これらは特定の結果を達成するための単なる手順です。 良い例では、明示的に記述されています-これはDAUの増加です。

停止しないでください！

起こりうる最大の間違いは、これらすべての原則を厳守することの純度に焦点を当てることです。 実生活では、残念ながら、多くの場合、妥協する必要があり、場合によっては、原則の1つを別の原則のために犠牲にする必要があります。 これが行われない場合、紙上では見た目が良いが、運用管理にはほとんど役に立たない合成物が得られます。

一般に、さまざまなチームで目標を設定する作業をしながら、さまざまな神話や認知の歪みに出会い、最終的に克服することができました。 その1つは、四半期ごとに目標を変更する必要があるというチームの自信です。そうしないと、チームは弱いチームと見なされます。 これは、多くの方向が放棄されたという事実に退化し、終わりに至っていません。 実際、これはまだ真実ではありません。

OCDでの目標の継続は大歓迎です。 目標が数四半期にわたって保持される場合、心配する必要はありません。常に具体的な目標を達成することが重要です。

別の例。 チームはすでに何をしたいのか、どのプロジェクトを切り詰めるのかを正確に決定しており、その下で目標と指標を適合させようとしています。

これが直接的なアンチパターンだとは言えません。 実際、チームはグローバルな業務分野で前進する方法について素晴らしいアイデアを持っています。 方法論にうまく適合しないという理由だけでそれを考慮しないのは愚かです。 しかし、一方で、そのようなプロジェクトがまだチームの目標と指標に実際にない場合は、おそらくこれはオフトピックです。

多くの場合、私はOKRがストーリーとバグとの戦いをサポートするまで、チームが行うすべてのことを一般的に記述する必要があるという確信に出会います。

私はこれに同意しません。 OSを共有し、新しい価値を創造し、目標に向かって進んでいくのは理にかなっています。 OKRは、私たちが注力したいもの、ビジネスにとって本当に重要な目標を引き出す必要があります。

そして、これはばかげた例です。 第1四半期に、AvitoがOKRによる生活を学んでいたとき、「何かを測定することを学ぶ」という注目すべき目標はチームからチームへと移りました。 そのフレームワーク内で、メトリック、ダッシュボードが構築され、分析が接続され、他の同様のことが行われました。

これが非常に悪いとは言えません。 チームが作業の測定基準と測定値について考えたことがない場合、チームは実際に測定方法を学ぶために四半期全体を学ぶことができます。 もう1つの質問は、OKRレベルにする価値があるのか​​、それとも範囲外にする価値があるのか​​ということです。 明確な答えはありません。状況を見なければなりません。

しかし、本当にアンチパターン。 何らかの理由で、目標は四半期の半ばに無関係になりましたが、慣性チームはそれを引き続けています。

できません アクティビティの結果が役に立たない場合、チームもその顧客もそれを必要とせず、時間を費やすのは愚かです。 コミットを修正し、関係者に通知し、他の目標に進む必要があります。

しかし、物語は多くの人が出没する0.6-0.8に関するものです。 最初に失敗を申し込むという事実に我慢するのは非常に困難です。

あなたはただそれを異なって見る必要があります。 第一に、目標はまだ達成可能でなければなりません。 直接対処できないものを前もって取っておけば、それをする必要はありません。 第二に、どんな場合でも成功するために自分自身を準備し、あなたの目標を達成する方法を見つけ出そうとする必要があります。 その時、OKRが提供する従業員とチームの成長の顕著な効果が明らかになりました。

ここの製品は一般的な名詞です。 それによって、あなたが発明した目標を下げるリーダーシップを意味することができます。 OKRはそのようには動作しません。 OKRは、サブスクライブするチーム全体の一般的なコメントです。 チームメンバーが準備に参加しない場合、チームメンバーはこのコミットを受け入れますが、受け入れません。 目標は異質であり、それらを達成する動機ははるかに少ない。 すべての所有権が失われます。

リズミカルな目標設定プロセスの構築

OKRを設定するプロセスは、私たちが望むほど簡単でも単純でもありません。 2四半期の合流点でこれを行うには、平均して約1か月かかります。 これはフルタイムの仕事ではなく、チームから週に数時間を食い尽くすことは明らかです。 Avitoでは、OKRを設定するプロセスは次のようにプラスまたはマイナスで構成されています。

四半期の終わりの3週間前のどこかで、チームは最初の会議に集まります。 次のようになります。

• 最初に、チーム、会社、およびその他の関連エンティティの長期目標のレビューが行われます。
• 次の段階は、これらの長期的な目標を近づけるか、チームの責任範囲に入るのに役立つ新しい目標、指標、イニシアチブのブレーンストーミングです。
• さて、その後、古典では-結果はクラスター化され、すべてがデジタル化されます。

次に、最も困難な段階が始まります。ドラフトOKRの周期的な作業です。 ブレインストーミングの結果は、目標と主要な結果の形で提示されます。 そして、リストの各アイテムは、実行者と利害関係者の両方の異なる位置からチームが挑戦し始めます。 目標の優先順位、選択されたパスの正確性、選択されたメトリックの正確性、その他多くの質問があります。 このパートの主な目標は、すべてのチームメンバーが選択した目標をサブスクライブし、この特定の方法を実行する必要があることを確認することです。 これと並行して、一般ドラフトのレベルまたは個々の会議で、他のチームとの同期プロセスがあります。 これは、クロスチームプロジェクトに関する合意が表示される場所です。

そして最後の部分は、予備的な目標のグルーミングとロードマップの編集です。 はい、方法論によれば、チームは目標をどのように達成するかを知りませんが、これにより、評価に合理的にアプローチし、主要なイニシアチブのバックログを作成することを妨げません。

最終的に、ドラフトが完成して共通ファイルに入力され、他のコマンドと同時に凍結されます。 この時点で、メトリックは最終的に選択され、それらを測定する方法が決定され、チームで合意に達しました。

そして、プロセスに関するいくつかの追加のヒント。

• すべてのチームは、計画の開始と終了の日付がほぼ同じである単一のリズムで作業する必要があります。 これにより、必要なレベルの透明性が提供され、通常、プロセスが時間とともに広がることはありません。
• チーム間の同期を必ず行ってください。 OKR , , .
• , . -, « , » - . .

.

, OKR, , . , .

, OKR . , — . - , .

, - . — - , - . : OKR , .

, .

, OKR Review. 5-6 , 10 : , , , . — , , .

OKR, . , OKR , .

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

. : , , , . , , , ( ) — Action Items, . , .

• - . , . , .
• , , . , . KR — , .
• . , . , ? OKR — .

, , OKR.

• , . , — , . : , , , , .
• OKR , , . , , - , .
• . OKR , , , . , , .

OKR ?

, OKR . , OKR .

: , . , , . : R&D , . , . OKR , .

Data-driven

. , , . OKR .

— . , , , , . . OKR, , .

合計

OKR — , . , , . OKR , . , 4 OKR. , .

, OKR , . , .