チームのデータに基づいたエクスペリエンスレビューを実施する

著者はこの記事を3つの部分に分けています。著者がデータ駆動型開発を始めたきっかけや、少し前の自社のデータ駆動型開発の振り返り、データ駆動型人材の探し方、そして最終的にKPI指標の導入方法について考えます。一緒に見ましょう。

チームがどのようにデータ駆動型開発を行っているかについての別の体験レビューについてお話しします。内容の一部は前回触れられなかったため補足されており、また一部は最近のコンサルティングからの新たな知見やレビューとなっています。そこでこの記事が生まれました。

私はコンサルタント的な役割を担っていますが、チームの一員であり、組織をデータ駆動型にするのに十分な管理権限を持っている場合は、この側面に沿って考えることができます。

この記事は3つの部分に分かれています。データ駆動型開発を始めたきっかけと、私が入社した頃のこの会社のデータ駆動型開発の振り返りです。 2つ目は、データドリブンな人材をいかに見つけるか、3つ目は、最終的にKPI指標をいかに実行するかです。組織分業、人材採用、経営KPIの3つについて詳しく解説します。

前回取り上げなかったいくつかの角度があり、それは非常に重要なので、そうでなければ別の記事を書く必要はありませんでした。これは繰り返しではなく、新しい視点であることに注意してください。もちろん、これらの視点のいくつかは継続的なデータ駆動型開発に活用できます。

また、練習の機会を与えてくださったスノー先生とヴィンセント先生にも感謝したいと思います。そうでなければ、続編の記事は書けなかったでしょう。

また、信頼が取引の実現可能性に与える影響についても理解できました。端午節に、私はナバルが書いた「ナバルの法典」を読みました。そこには、「造営者」、「第四の運」、「責任と名誉」という3つの観点が述べられていました。私は彼らから深い影響を受けました。

今の仕事経験から、意識的に自分から離れて仕事に向き合ってみます。結局、どれだけ有能な人でも、ビジネス活動を完遂するにはチームに頼る必要があるので、私はこれを「ゲームの設定」または「勢いをつける」と呼んでいます。環境が適切であれば、その環境によって育まれたビジネスは徐々に良くなっていきます（良い軌道に乗っていることが条件です）。組織構造、権限と責任のインセンティブ、業務プロセスの最適化により、個人が力ずくで行うよりもはるかに大きなビジネス成長が実現できると信じています。

もちろん、方向性や目標の設定、組織構造の調整、仕事の整理だけに注力すればよいというわけではありません。つまり、入力と出力を考慮し、どの点に注意を払う必要があるか、どの点に組織内で人材を育成する必要があるか、どの点に組織構造を調整することで影響を与えることができるかを検討する必要があるということです。これは、「ビルダー」として、大規模な構造調整を行うだけでよいという意味ではありません。中間のトレードオフ、境界の決定、およびモデル調整には練習が必要です。

あるいは、作業が進むにつれて、方法論を徐々にまとめていくことになるかもしれません。現在、私は常に、プロダクトマネージャーのトレードオフシステムから得た、意思決定を判断するための参照システムを持っています。根本的にはすべては一つです。

そこで2019年からは、いわゆる組織の成長という方向に意識的に動いてきました。システムはビジネスの成長を可能にします。これは、Naval が「Naval's Book」で言及している「ビルダー」です。複雑なシステムの提供を完了できる人材はさらに不足していると彼は考えています。だから、自分でビジネスを運営する機会を与えてくれたスノーとヴィンセントには感謝しています。でも、彼らには私がどれほど感謝しているか分かっていないかもしれません。

ちなみに、組織成長について相談したい場合は、いつでもご連絡ください。私のWeChat IDは記事の下部にあります。

2 つ目は、Naval 氏が著書で述べている「第 4 の幸運」です。つまり、ある分野で評判があり、他の誰も提供できないスキルを提供できる場合は、さらに幸運が訪れるということです。彼が挙げた例は、あなたが最も深く潜ったダイバーだということです。引き揚げ業者が、あなただけが潜れる宝の難破船を発見した場合、引き揚げ業者はあなたに頼らなければならないため、あなたも利益の一部を得ることができます。

3番目のポイントは信頼です。組織の変化に関しては、リーダーたちが当面は明確に見通せない部分もあるだろうが、スノーとヴィンセントは私を信じてくれるつもりだ。結局のところ、ヴィンセントと私は3年以上の友人であり、この件で自分の評判を落とすつもりはありません。もちろん、これは、聴衆にふさわしいものとなるよう、私が他の人と共有するたびに同じことを繰り返さない理由でもあります。話題に戻ります。

私は最近、この会社にコンサルティングを行い、データ駆動型開発の立ち上げを支援したため、あまり正確ではなかった以前の判断も見直しました。これは私自身の問題であると同時に、組織の問題でもあります。これら3つのことを再検討するきっかけになりました。

1. データ駆動型を始めるタイミング

データ駆動型ワークフローを開始する場合、または開始するための条件を決める場合は、まずどこから開始するかを明確にする必要があります。 1 つ目は、需要実現プロセス、運用戦略、市場投入戦略など、高頻度の日常業務を開始する必要があることです。2 つ目は、計画や年間計画などの中低頻度の業務です。 3 つ目は、各従業員の目標と独自の ToDo リストであり、これもデータに基づく必要があります。

次に、データ駆動型開発をいつ開始するかについて説明します。上記のプロセスが明確な内容ですでに固められており、それらすべてがテンプレートに抽象化されている場合は、すぐにデータ駆動型開発を開始できます。なお、プロセスの固化と標準プロセスを同期させるために、参考用にバージョンをここに用意しています。

2 番目の状況は、これらのプロセスが存在しない、またはあまり標準的ではなく明確ではないことです。この場合、最初に行うべきことは、プロセスを実行してテンプレートを作成し、全員がテンプレートの内容とロジックに精通できるようにすることです。

まず、方向性や OKR をガイドとして使用し、最初にデータを定量化せず、目標と OKR のみをガイドとして使用します。はっきり言ってしまえば、まずは定性的な目標とOKRを設定し、それを数値化せず、徐々にデジタル化していく必要があります。通常、この場合、人員の能力モデルは現在、多少緊張状態にあります。非常に高い集中力と、プロセスとデータの両方を処理する必要性により、チーム メンバーは対応できず、抵抗することになります。各反復には 1 つの目標のみがあり、チームは明確です。

まとめると、私が提供しているプロセスのように、明確な需要レビュー、製品内部監査、その他のリンクを備えた需要実現プロセスがあり、それが固まり、安定して実行できる場合は、プロセス内でデータ化を直接実装できます。まずプロセスを構築し、その後徐々にデータ駆動型の開発を開始しないといけません。

1. 製品データ化が基盤

まず第一に、インターネット企業は製品を通じてビジネスを自動化したり、徐々に自動化したりすることを望んでいます。製品部門の需要の定量化をコントロールすることは、ビジネスのほぼ半分のデータ駆動型開発をコントロールすることと同じです。第二に、ROIが非常に高い下流製品が多数あります。製品部門独自の製品設計、UI 設計、研究開発、テストが関与し、上流の需要を制御して、すべての下流リンクの効率を一度に向上させます。制御要件実装プロセスの中核は、制御要件のレビューと製品の内部監査を必要とする 2 つの黄色のボックスです。

第二に、製品部門が要件の見直しを始めると、ビジネス側に徐々にデータ駆動型になるよう求めることができます。もちろん、これは段階的な調整プロセスです。多くの企業のビジネス部門では製品思考は持っているものの、製品の観点から要件を説明できないのはわかっています。このとき、プロダクトマネージャーが介入し、まず要件を伝え、ビジネス側が要件ドキュメントを作成するのを支援する必要があります。

したがって、要件定義書を作成するのがビジネス側であっても、プロダクトマネージャーであっても、このステップは絶対に不可欠です。それは誰がそれをするかという問題です。機能モデルが最初に開始されることを考慮すると、このステップは最初に製品によって実装できます。このセクションの目的は次のとおりです。

• 需要背景やユーザー層など、ビジネス側のニーズを明確にします。
• ビジネス側のニーズの機能範囲を明確にします。
• 事業の方向性によって達成すべき目標を明確にします。

最初の項目は、プロダクトマネージャーにビジネス側の理由や本来の要求を理解させることであり、ユーザーグループを分析する必要があります。これは、前に述べたセグメント、つまり階層化された動作、つまりどのユーザー グループを対象に作業しているかに相当します。 2 番目の項目は境界を定義することです。関数は大きくすることも小さくすることもできます。最後はビジネス面で目標を達成することです。多くの場合、ビジネス側は必ずしも目標を明確に把握しているわけではありません。目標が明確になれば、それが商業的価値があるのか​​、ユーザー価値があるのか​​がわかります。

優れたプロダクトマネージャーは、問題の発見と需要のバランスに少なくとも 50% の時間を費やす必要があります。 80%の時間を費やしても大したことではないと思います。さらに20%～50%のエネルギーが需要実現に費やされます。

悪いプロダクトマネージャーは、時間の 80% を製品要件の実装に費やし、問題の洞察の発見と需要のトレードオフには 10% しか費やさないことがあります。

なぜなら、優先順位のバランスが取れないと、やるべきことがたくさんあり、製品設計など、やるべきことがたくさんになってしまうからです。あなたがビジー状態の場合、ダウンストリームもビジー状態になります。これは、1 つの要求を実現するには 4 つのダウンストリーム リンクが必要になるためです。

長期的には、チームはただ物事を行うだけのプロセスに迷い、ビジネス目標に応じてビジネスプレッシャーを徐々に解放することができなくなり、ビジネス側と研究開発側の間の対立が激化します。ビジネス側は、多くの要求に対応するには忙しすぎると考えており、一方、R＆D側は、毎回緊急すぎて成果が得られないと考えています。実際、それは要件がプロセスに従って完全に実装されておらず、ビジネスへの影響が最初に明確に説明されておらず、オンライン化後にデータのフィードバックがなかったためです。長期的には、チームはただ忙しいというだけの状態に陥ってしまいます。

Yu Jun氏が言ったように、Zhihuでプロダクトマネージャーが排除されるかどうかを尋ねる人の多くは、需要の実現だけを行う人々です。製品の場合、需要を満たすことは基本的なスキルですが、実際には、目に見えない需要のトレードオフの方が難しいのです。プロダクトマネージャーにとって最も難しいのはトレードオフモデルです。したがって、現時点で何が最も重要 (洞察) で何が最も緊急 (トレードオフ) であるかを見つけるには、練習が必要です。しかし、ほとんどのスタートアップはこれにあまり注意を払っていません。ビジネス側もこう言うでしょう。「一体何なんだ！」早くやれよ！用事は急ぎです！実際のところ、彼ら自身も、この目標をどの程度達成したのか、またビジネスのどの分野でこの需要が改善するのかについては明確にしていません。

2. プロセス標準は管理に役立つ

プロセス標準とデータ駆動型には、主に 4 つの利点があります。 1 つ目は、ビジネス同期の部分に示されているように、企業が通常省略するデータ駆動型です。これは実際にはスキップできないリンクです。もちろん、必ずしもビジネス側が実行する必要はなく、プロダクトマネージャーが実行することも可能です。関数が起動されると、その結果はどうなるか、その後のデータの変更はあるかどうか。これは関数の最終的な起動のためのクローズド ループです。

2 つ目のメリットは、これにより、R&D とビジネス関係者間の対立を徐々に緩和し、製品とビジネスの影響力を徐々に高めることができることです。良い結果は研究開発チームのモチベーションを高め、彼らの仕事の価値を明確にするからです。

3つ目のメリットは、要求側のビジネス能力を長期的に評価できることです。これは、要件ドキュメントを、要件を提案した特定の人物に細分化する必要がある理由も説明しています。多くの企業のビジネス関係者は要件を提案できないか、ビジネス ボスに代わって要件を提案するよう依頼することになります。ただし、要件が信頼できるかどうかは、最終的には要件を最初に提案した人によって決まります。なぜなら、要件のソースは、要件を提案した人だからです。需要の源泉がすべて事業主としてマークされている場合、長期的に需要を形成する能力を分析および評価する方法はありません。

集計されたデータはすべてゴミなので、セグメント化しないと死滅する———Google アナリティクス Avinash Kaushik

集約されたデータはすべて無意味なので、分割するか、破棄するかのどちらかです。

4 番目の利点は、すべてのコンテンツがホワイトボックス化されている場合にのみ、新規参入者の参入障壁を大幅に下げることができることです。新製品が承認されると、需要が生まれます。需要の背景、対象者、目標をすぐに理解できるため、検討や設計などが容易になります。

3. コンサルティングサービス会社に対する私のレビュー

最後に、この会社に相談するにあたり、自分の問題点と相手の問題点を見つめ直しました。自社のデータも活用したい場合には、このチェックリストも実行する必要があります。もちろん、CEOであれば、このチェックリストも作成する必要がありますが、CEOの主な責任は、私が個人的に行うのではなく、どのように行うか、誰に任せるかを考えることです。

私の主な仕事は、会社の組織構造と業務プロセスをデータ駆動型にすることです。ここで、作業シーケンスにおけるこれまでの混乱を振り返ってみましょう。

会社概要:

• 会社のビジネスプロセスはどのようなものですか?
• 会社の組織体制と人員分担はどうなっていますか？
• 同社の製品構成はどのようなものですか？
• コアユーザープロセスを含む、製品の詳細なプロセスは何ですか。
• 現在の人事ワークフローとコラボレーション ツールは何ですか?

データ部分:

• ビジネスは関連する指標に細分化されていますか?
• トラフィック ソース統計の追跡が完了しているかどうか。
• データ指標を取得する全体的な機能が利用可能かどうか、またどのデータ指標がまだ利用できないか。
• 現在のデータの状況はどのようなものか、後でどのように反復するか、反復プロセスがあるかどうか。
• さまざまな部門間でのデータ同期のプロセスとメカニズムは何ですか?

実装部分:

• データ駆動型の場合、組織内の誰が関与する必要がありますか?
• これらの人々とどのように協力すればいいのでしょうか、そして私の仕事の境界線はどこにあるのでしょうか?
• 現在の組織構造と人事上の役割では、これを実行することができません。
• 現在のワークフローをデータ駆動型開発向けに最適化する必要がありますか?
• 組織的推進力の実現パスは何ですか?いくつの段階を経るのですか?各ステージの目標は何ですか?

ビジネスを理解していない完全な部外者であれば、データドリブンに取り組む際には、少なくとも以下の方向から考える必要があります。最初の部分は主に会社の背景についてです。現在の会社をデータドリブンな状態にしたいと考えているからです。抽象的に考えると、A地点（出発点）からB地点（到着点）に向かうと考えることができるので、現状把握が大切です。 2 つ目はデータ駆動型の部分で、データの取得から配布まで組織内の各役割がどのように実行されるかということです。やり方。 3つ目は実装です。レバレッジを利用して複数の主要な役割を推進し、タスクを実行する方法。

練習中に犯した間違い:

利害関係者からのサポートに対する過度の楽観主義。

私が就任した当初は、すぐに第6段階、つまり事業をさまざまな指標に細分化する作業に取り組みました。インジケーターを使えばデータを抽出できると思いました。このプロセスでは、プロダクトマネージャーがビジネスプロセスと製品の詳細を説明し、プロセス全体を口頭で説明します。分割を終えた後、3つの問題が見つかりました。

最初の問題は、R&D データ スタッフがリクエストへの対応に忙しいため、誰もこのデータ ダッシュボードを実装していないことです。 2 つ目の問題は、私の役割はコンサルティングであるため、それが需要者が必要とするデータ指標であるかどうかを確認するために誰を探せばよいかわからないことです。 3 番目の問題は、多くの企業で組織内に対応する役職がないことです。だから、誰に指標を見せればいいのか分からないんです。

名前が正しくなければ、言葉は流れていきません。言葉が流れてこなければ、物事を成し遂げることは難しくなります。

私の中核的な位置付けは依然としてコンサルティングであり、方向性と目標を設定し、それを実行する適切な人材を見つけ、彼らが行うプロセスと結果をコントロールすることです。全体として、データはシステムを動かしますが、上流の需要から製品に至るまで、システムはデータ駆動型である必要があります。製品の下流は主に実行を目的としており、それほどデータ主導ではありません。これには複数のビジネス関係者が関与します。

当初、部門の業務を整理していたとき、各部門の責任者が私と調整してくれた方が、ROIの観点から見ていくつかの基本的なプロセスを進めやすかったです。しかし、当時は私の役職が確定していなかったため、彼らに行動を起こさせることが難しかったのです。あるいは、会社によっては、部署が急成長していて、明確な責任者がいないため、一緒に働く人たちが社内で物事を進めるのが難しいということもあります。

質問することで自分が欲しいコンテンツをどのように得られるかが分からないし、分業化されているため、誰に質問すればいいのか分からない。

1 つの問題は、理解する必要があるこれらの大きな部分を、ビジネス側に尋ねる質問に素早く分解する方法がわからないことです。これは当然技術的な仕事であり、なぜこのコンテンツが欲しいのか、また、依頼する目的や意義は何かということを相手に理解してもらう必要もあります。結局のところ、彼らはすでに現在の作業方法に慣れています。変化、習慣を変えることは、多くの場合非常に困難です。

組織や人々に対する過度に楽観的な評価。

当初の計画では、データ取得可視化システムを段階的に構築し、組織業務のデータ化を直接推進する予定でした。今ではそれはかなり難しいことが分かっています。製品部門を調査したところ、スタッフには目標理解力やデータ抽出洞察力がなく、需要プロセスも依然として比較的広範囲にわたることが判明しました。さらに、給与面では、プロダクト部門はマーケティングやオペレーション部門に比べて給与が比較的高いポジションです。

製品に目的志向の意識がなければ、他の部門に目的志向の意識を持たせることは難しいでしょう。つまり、元の 1 ステップのプロセスを 2 ステップに分割する必要がある場合があります。ワークフローが確立されていない段階です。まずは組織に自らの業務と目標の関係性を理解させ、OKR指導を行い、徐々にデータを数値化していく必要があります。

パートナーの質問:

作業内容情報はデータドライブに対応しておりません。

残念ながら、私が着任した当時、その会社には事業の全体像を理解できる人材がいなかったのです。分業に関しては社長が説明してくれるわけではないので、組織体制や業務分業の背景がわかりませんでした。これにより、私は「ウォークラフト」プレイヤーのような状態になり、各ステップを踏んだ後に次の数ステップしか見えなくなり、いくつかの状況を理解するたびに、それに続く状況があることに気付きました。もちろん、相手側にも適切な文書がないという問題があります。

相手側の組織構造がデータ駆動をサポートしていない。

組織や役割の面では、従来のソフトウェア開発会社に似ています。第二に、各部門に担当者がいない。もちろん、昇進という観点で言うと、各部署の人を私が直接昇進させることは効率面で難しいので、組織体制や人事判断、担当者の改善などが必要です。

プロセス環境はデータ駆動をサポートしていません。

ビジネス側のデータ抽出ニーズを一貫してデータ ダッシュボードに変換できるデータ サポート チームはありません。データ抽出は体系的なプロジェクトであるため、チームからの長期的な権限付与が必要です。もちろん、まず症状を治療することもできますが、データ駆動型のビジネスの場合は、体系的なデータ システムを早期に構築し、データ取得コストを継続的に削減することを検討することをお勧めします。

人事モデルもデータ駆動型ではありません。

製品部門を調査した結果、全体的な焦点は依然として物事を成し遂げることにあり、ただそれを成し遂げるためだけに物事を行っていることがわかりました。彼らはまだ、自分たちの仕事がビジネスや目標にどのような影響を与えるのかを明確に説明できていません。定量分析のためのさまざまな影響を見つけることは言うまでもありません。また、関連するワークフローは標準化されていません。そのような認識はありません。幸いなことに、チーム内には常にこの認識を持つ人が 1 人か 2 人います。この意識を持っている人は、モデルを作ることができれば模倣は容易ですが、自分で0から1までを模索するのは難しいです。

2. チームのデータ思考を育成する方法

まず、現在どの企業でも採用できる人材は、現在採用できる最高の人材だと思います。私が現在勤めている会社のプロダクトマネージャーが挙げた例えは非常に適切だと思います。

現在、ビジネス部門が継続的にデータを提供できるシステムがなく、ワークフローや組織の役割も一部欠けています。たとえば、レストランには良い調理器具や高級な包丁がなかったり、高級シェフが慣れている調理法がなかったりします。

この時、あなたは高級シェフを見つけます。すべての雇用関係を取引に例えることができます。高級シェフが来たら何が欲しいのでしょうか?彼はプロの料理の腕を磨くことができなければなりません。まず調理器具を買って包丁を研ぐように頼みます。レストランが潰れれば、大規模なレストランでは調理環境が整っており、シェフは調理にエネルギーを費やすだけでよいため、新しい会社で彼の経験を生かすことはできない。

ですから、若いときに非常にハイエンドな人々を探さないでください。彼らに匹敵することはできないからです。なぜなら、たとえ彼が来ても、才能を発揮できないからです。あなたは調理環境を整えており、彼はあなたに料理の腕を磨くことを要求しています。読者の皆さん、ジョセフ・ツァイを理由に私を反論しないでください。それに、私たちはジャック・マーではありません。自己紹介でも述べたように、確率論を使って世界を説明すると、ジャック・マーは低確率の出来事です。

2 つ目は、優秀な人材は他の求人に簡単に惹かれてしまうことです。私はかつて従業員約400人の会社で働いていました。当時は人材を集めるのは容易ではありませんでした。一流の大企業は、オファーを出した後、そのオファーを1つ減らすでしょう。

それは私が今大企業でやっていることと同じです。私が常に伝えたいのは、採用する人材は現時点で採用できる最高の人材であるということです。大企業も問題を抱えています。私たちがオファーを送るたびに、アリババ、テンセント、バイトダンスからオファーが送られてくるのではないかと恐れています。 Douyin、Tik Tok、WeChat などの製品だけが、自分たちが送信したオファーを誰も受け入れないのではないかとあまり心配していません。

3つ目に、当時インターネット金融会社で働いていた同僚たちは、最終的には快手、Ctrip、JD.com、百度などに就職し、中にはO2O事業のプロダクトディレクターになった人もいました。だから今私が反省しているのは、不十分なのはこれらの人々なのか、それとも会社なのかということです。なぜ同じグループの人々がより良い企業に行くのでしょうか?これは、彼らには問題がなく、大企業の中核となる人材として育成できることを証明しています。

では、当時の指導者たちはなぜ彼らに満足しなかったのでしょうか?それは会社が十分良くなかったからだと思います。会社には人材を育てる環境がなかった。人は、ある一定の基準を超えると、実は会社の環境によって能力が大きく左右されるのです。もちろん、人々の基本的な資質は一定の基準を超えなければなりません。

まとめると、企業の採用担当者は特に優秀な人材を採用しようとすべきではないということです。取引の観点から言えば、そのような人を採用するには市場価格よりもはるかに高い金額を支払う必要があります。プロジェクトの失敗のリスクなどの隠れたコストを考慮して、30％多く支払うと、彼は来ないでしょう。ビジネスを次のレベルに引き上げ、次のレベルで影響力を獲得して初めて、次のレベルに吸収できる人材を採用できるようになります。

これは松下幸之助の「松下の一番大事な仕事は人を育てることだ」という言葉を思い出させます。どんなビジネスも人がやるものですから、良い人材を育てれば、ビジネスは自然に次の段階へと進み、より優秀な人材が生まれてくるでしょう。また、ほとんどの場合、人材の育成スピードは会社の育成スピードよりも速いです。これは、当社のインターネット金融会社の製品担当者が全員大企業に配属される理由も説明しています。

人材育成について、さらにいくつか意見を述べたいと思います。私は以前、会社のリーダーが何の原則もなくチームの人々を擁護していたので、そのリーダーを嫌っていました。無原則なえこひいきは、チーム内の人々に対する溺愛の一種だと私は思います。もちろんこれは経営理念の違いです。しかし、彼のある行動が、彼に対する私の考えを大きく変えるきっかけとなりました。彼は自分の部署の人たちを組織して勉強させました。

ほとんどの企業は従業員の成長にお金をかけていないことを知っておくべきです。このような成長とトレーニングには長期的な投資が必要であり、多くの企業がその価値がないと感じています。彼らは従業員を単なる消耗品として扱っています。しかし、あなたが勤めている会社がまだあなたを訓練する意思があるなら、それはあなたの会社が少なくともあなたの長期的な成長のための計画を持っていることの証明であり、あなたはその会社に感謝するべきです。なぜなら、そのような会社は本当に多くないからです。

通常、人材の成長にとって最も基本的な要素は事業の成長率ですが、これはあくまでも基本に過ぎません。ただし、スタッフが事業とともに成長できるかどうかは、スタッフの成長率に依存します。成長スピードを上げる第一の秘訣はモチベーションであり、第二の秘訣は方法です。動機には、どのような専門家になりたいか、ビジネスにどのような変化をもたらしたいかなどが含まれます。そしてその方法は、優れた思考モデルを持つ必要があるということです。

あなたはおそらく、何かを専門的に行う方法を知っています。つまり、大量の仕事量は人が成長するための必要条件なのです。必要かつ十分な条件というよりは。彼は専門的な方法論を読み、専門的な方法で物事を行う必要があります。第二に、練習の過程で継続的に消化し、吸収し、考える必要があります。そこでユ・ジュンは、読むこと、考えること、実践すること、この3つの中で最も低いレベルが、自分の上限を決めるのだと言いました。

私が最近コンサルティングした両社とも、社員は非常に多忙でしたが、どちらの会社も改善が見られませんでした。彼らは低い次元で繰り返し訓練しますが、重要な点は、彼らはより高い次元が何であるかを知らないということです。彼らは自分が知らないことを知らない、それが怖いのです。興味があれば、私の別の記事を読んでみてください: より良い思考モデルをマスターして職場で目立つ

例えば、プロダクトマネージャーにとっては、最初は要件を満たすだけで問題はないように思えますが、要件を満たすだけを続けていくと、何の価値もなくなります。彼がやったことはすべて積み重なっても、何の価値もないだろう。

なぜなら、より価値があるのは、ニーズの優先順位を比較検討し、どれを最初に行い、どれを後で行うかを把握し、その後に需要計画を立て、将来何をすべきかを把握し、その計画に基づいて実行し、計画をどのように実行するかを把握することだからです。これにより、プロダクトマネージャーは仕事の難易度と複雑さを継続的に高めていく必要があります。

同じ論理がすべての業界に当てはまります。プロダクトマネージャーが要求を繰り返し、基本的な要件を満たすだけでは、成長しません。時々、非常に忙しくて計画がないのは良いことではありません。

明確にしておく必要があるのは、ここでの読書は本を読むことを意味するのではなく、専門的な方法を取得し、思考モデルを改善するためのチャネルを指すということです。専門家とチャットすることも可能ですが、そのようなリソースを持っていない人もいます。例えば、于俊氏はかつて、上級上司が急速に成長するのは、各分野の専門家とコミュニケーションをとり、彼らから学ぶことができるため、自然に成長が早いからだと述べました。しかし、レベルの低い奴らにはこのような機会はない。彼らには巨匠たちと話す機会はありませんが、巨匠たちが書いた本から学ぶことはできます。

3. KPIに関するいくつかの見解

ワークフローと組織構造がデータ駆動型でない場合、KPI によって直接駆動することはできません。たとえば、データダッシュボードがなく、継続的にデータを取得するプロセスがなければ、プロセスを監視することは不可能です。プロセスが適切に行われず、制御できない場合、結果をどのように制御できるでしょうか?指標を発行することしかできず、データを通じて最適化することはできないため、指標を通じてビジネスを推進しても意味がありません。

ワークフローが安定していてデータ駆動型の場合、データ量が少なすぎると推定値が不正確になるため、指標を計算するには一定量のデータが必要です。 KPI ターゲットはあまり意味がありません。データ量を推定できる場合は、KPI をどのように割り当てるかという問題が発生します。

まず最初に申し上げたいのは、KPI に動かされること自体は何も悪いことではないが、将来の目標達成にはある程度の不確実性と予測不可能性があるため、KPI に頼って動かされるのではなく、いくつかの点に注意する必要があるということです。インデックスを作成すると、インデックスを達成するために実行されるアクションが歪む可能性があります。この点を説明するために、私の前回の記事を取り上げます。あるコーヒーショップが次の四半期のGMVを見積もりました。この GMV が妥当であるとどうやって確認できるのでしょうか?知る由もなかった。

しかし、これは人員過剰につながります。たとえば、私がコーヒーを飲みに行くと、店員は私のニーズを気にせず、高価な商品だけを勧めてきます。これは彼の KPI 達成に役立ちますが、この短期的な KPI 達成は長期的にはビジネスに悪影響を及ぼします。

ここでの1つの方法は、Facebookが使用する50％のメカニズムです。つまり、誰もがKPIを送信できます。各ビジネス、各四半期、または半年を評価して、インジケータを完成させたかどうかを確認します。あなたがそれを完了したかどうかは関係ありませんが、長期的にはあなたのインジケーターは半分の時間を完了し、半分の時間を完了しないでください。インジケータが常に完了している場合、KPIが低すぎることを証明します。

KPIを実装する別の方法は、信頼レベルを調べることです。ほとんどの企業は自然な成長を遂げているため、デルタの価値を高めることに自信があります。たとえば、10％の増加の信頼レベルは、80％の増加の信頼レベルとは異なります。信頼レベルが異なるパフォーマンスのために、バッチでインセンティブを与えることができます。

著者: Arun's Growth Research Institute

出典：WeChat公開アカウント「Arun's Growth Research Institute（ID：arungrowth365）」