データ駆動型になるための6つのステップ

この記事の著者は、データ駆動型チームの 6 つのステップを客観的に分析し、詳しく説明しています。ぜひご覧になってみてください。

運用を行う際には、成長戦略の学習に重点を置くべきでしょうか、それとも潜在的なターゲットの学習に重点を置くべきでしょうか?

これは私に多くのことを思い出させます。深く考えた後に得られる結果は、世間の認識とは異なることがよくあります。私たちは一般的に成長戦略が非常に重要であると考えています。

于俊教授は希少性の問題について講演しました。プロダクトマネージャーを探すときは、厳格なロジックを持つ人を探す必要があります。厳格なロジックを持つ人は比較的少ないからです。

比較的、基本的な製品知識は習得しやすいです。したがって、同じ論理に従えば、面接の際には、ほとんどの人が運用戦略と分析を理解している人材を探すことになります。なぜなら、そのような人はさらに稀だからです。

しかし、ここでは暗黙の前提があります。それは、データを取得するための環境も良好であるということです。したがって、優れた成長戦略を実行するには、データを収集して分析し続け、優れた戦略を継続的に生み出す必要があります。

多くのマネージャーは、優秀な戦略アナリスト（それ自体が不足している）を採用すれば、データ主導型になれると考えています。しかし、すべてはチームによって達成されます。優秀なアナリストは氷山の一角にすぎません。組織チェーン全体がデータ駆動型になり、ビジネス担当者に継続的に権限を与える場合にのみ、継続的な戦略的成果が保証されます。

優れた成長戦略オペレーションを採用することは、データ主導のオペレーションの始まりにすぎません。

なぜなら、私が最近コンサルティングした企業は、これらの要因により、多かれ少なかれデータ駆動型になることが不可能だからです。この抵抗の一般的な理由は、データ駆動では解決できない特定のスライスの問題や特定のノードの問題しか認識していないことです。しかし、前回の記事で書いたように、大きく考え、小さく始めましょう。

私たちがよく見つける解決策は、原因ではなく症状を治療することです。チームを本当にデータ駆動型チームに変えたいのであれば、チームがデータ駆動型になるのを妨げている全体的な問題を整理する必要があります。このプロセスは、非常に絡まった糸の束を解くことに非常に似ています。まず全体を整理し、それから一つずつ解いていく必要があります。他に方法はありません。

第二に、どのチームの改革も段階的なプロセスです。利益の問題はさておき、チームメンバーの能力モデル、作業プロセス、作業習慣はすべて徐々に指導される必要があります。軽率な行動は集団からの拒絶につながる（組織を有機体とみなす場合）

そこで、チェックリストをお渡しし、このロジックに従って、氷山の「水面下」にある成長の原動力に影響を与える要因を見つけたいと思います。

あなたの組織もデータ駆動型のプロセスに移行できることを願っています。

データの取得は、チーム全体と複数のシステムによるビジネスの継続的な強化であり、通常はデータ アナリストのみが担当します。

1. データ駆動型ビジネスを始める前に考えるべきこと

1.1 なぜデータ駆動なのか

アメリカの科学者たちは思考実験を行った。彼らはルービックキューブを混ぜ合わせ、それを目の見えない人に渡して復元してもらうという実験だ。盲人が不死であり、休む必要がなく、キューブを 1 秒に 1 回回転させると仮定すると、理論的にはルービック キューブを元に戻すのにどのくらいの時間がかかりますか?

答えは数十億年です。つまり、ビッグバンから現在までに、これが実現するにはさらに数十億年かかることになります。

変数が追加された場合、つまりルービック キューブを回すたびに、誰かがフィードバックを与えて、ゴールに近づいているか、それともゴールから遠ざかっているかを伝える場合、視覚障害者がルービック キューブを元に戻すのにどれくらいの時間がかかるでしょうか。答えは2.5点です！

この思考実験は、反復的なフィードバックが強力な普遍的な法則であるという秘密を明らかにします。

データをデジタル化する目的は、すべての戦略を可視化し、結果を定量化することです。つまり、ルービック キューブを回すたびに、正しく回したか間違って回したかがわかるので、反復の速度を上げることができます。

1.2 データ駆動で何ができるのか?

データ駆動型とは、結果を定量化でき、ビジネス全体を定量化できることを意味します。データは現状を伝えることしかできません。患者が治療のために病院に行き、医師から高血圧であると告げられても、降圧剤を処方することはできないのと同じです。人体をビジネスに例えると、データ駆動型ではビジネスの現状しかわかりませんが、その状況の理由まではわかりません。

もちろん、データベースが非常に大きい場合は、いくつかの戦略を立てて、いくつかの変更と反復を行うことで、戦略と結果の相関関係を見つけることができます。しかし、私たちはこれを実行することを依然として推奨しません。データに基づいてユーザー調査やニーズ分析を行う方が良いでしょう。

つまり、データ駆動型では物事を正しく実行することしかできないのです。ルービックキューブを正しく回してください。

実際、私たちの仕事はルービック キューブを回すよりもはるかに複雑です。なぜなら、ルービック キューブを回すという暗黙の前提は、間違った情報と正しい情報のフィードバック自体に戦略的な解決策が含まれているということだからです。つまり、ルービックキューブを間違った方向に回転させなければ、必ず正しい方向に回転することになります。

しかし、実際のほとんどの状況では、実際のステータス フィードバックでは直接的な解決策が得られません。 （このようなエッジの変化の複雑さについては、別の記事で書きます。）

しかし、長期的に正しいことを行うことで、正しいことを行う可能性が大幅に高まります。

私たちの最終的な目標は物事を正しく行うことですが、これはデータ主導のビジネスの必然的な結果ではありません。データ駆動型ビジネスは、正しいことを行うための基礎です。

1.3 あなたのビジネスはデータ主導型ですか?

データ駆動型開発を始める前に、ビジネスがデータ駆動型になるかどうかを確認するために、3 つの質問について考える必要があることを理解する必要があります。

これが第 2 章の「データに基づく 3 つの質問」につながります。

• 最初の質問は、あなたの業界は成長業界ですか?
• 2 番目の質問は、ビジネスに多数のユーザーと商業的価値があるかどうか、そしてデータ主導の価値がチームのコストに見合うかどうかです。
• 3 番目の質問は、ビジネスを複数の独立した小さな閉じたループに分割できるかどうかです。

2. データ駆動型開発が満たすべき条件

2.1 成長が戦略を生む

質問 1: あなたの業界は成長産業ですか?

ユーザー数とデータ数は戦略の結果ではなく、戦略の原因です。

多くの経営者は、現在のビジネスは成長していないと考えています。成長人材を探せば問題は解決するでしょうか？頭が痛いときは頭を治療し、足が痛いときは足も治療するというのはそういうことです。

最初に考えるべきことは、業界が成長しているかどうかです。張小龍を教育業界に置いたとしても、彼が成長するのは難しいだろう。張小龍は言うまでもなく、ブルース・リーやリー・シェンロンが来ても無駄だろう。

つまり、成長の要点は、既存のチャネルを通じて、またはユーザーを変換するための新しいチャネルを見つけることによって、ビジネスが成長できたということです。

本来の意図は、ユーザーにはニーズがあるが、それを発見するチャネルが不足している、あるいは外部環境によってユーザーがますます増えている、というものです。成長の第一の上限は、市場におけるユーザー数です。しかし、多くの上司は全体像の論理を熟考していません。顧客を獲得できる人を見つけてください。戦略さえあれば、ユーザーはいると思います。

この例によると、張小龍を招待すれば成長はあるだろうが、確実ではない。

2.2 組織構造は価値がある場合にのみ存在する

質問 2: あなたのビジネスには大規模なユーザー ベースと商業的価値があり、データ主導の価値はチームのコストに見合う価値がありますか?

次に、最初の説明は、この業界にどれくらいのユーザーがいるかを推定することです。ユーザー数が増えれば増えるほど、最適化を通じて生み出される価値が大きくなり、提供できる給与やポジションも増えます。

企業の規模によって組織構造が決まります。毎日何千万人ものユーザーがいる場合は、データ駆動型のアルゴリズムと戦略を開発すると価値があります。 ARPU 値を 1% 増加させると、非常に大きなユーザー ベースが得られます。 1 年間に生み出す価値は、アルゴリズム エンジニアを支えるのに十分であり、彼らが生み出す収益は彼らの給与をはるかに上回る場合があります (通常、これは大規模な取引量を持つ企業に当てはまります)。ビジネスの上限が小さく、多数のユーザーを獲得する可能性がない場合は、データ駆動型である必要はありません。このチームと才能では価値を生み出せず、ビジネスではそのようなチームをサポートできないからです。

まだ疑問がある場合は、この記事をお読みください：非組み込み分析ツールGrowing IOに適した企業の種類

2.3 ビジネスは独立した閉ループの反復に分割できる

質問 3: あなたのビジネスは、複数の独立した小さな閉じたループに分割できるものですか?

データは常にビジネスに役立っています。従来の企業は財務データと長期的な業績データを使用してビジネス分析を行っていますが、これもまたデータによるビジネスへの貢献です。したがって、この観点からビジネスを見ると、従来の企業がデータ主導ではないということではありません。

インターネット ビジネスの本質はオンラインにあります。今日のインターネット ビジネスはデータ主導です。根本的な変化は、ビジネスの主なプロセスがオンラインになり、ビジネスアクションがオンラインになったことです。これにより、迅速な反復やトラフィックの重視などの新しい特性が生まれました。すべてのユーザー行動は「オンラインのクローズドループ」であるためです。次に、ビジネスをサポートするシステムがすべてオンラインになっていて、ビジネスを独立したクローズドループに分割できるのが最適です。ユーザー数以外にも、次の 3 つの要素を考慮する必要があります。

1. SKU 数が多い:簡単に言えば、SKU 数が多いということは、コンテンツの配信と戦略の推奨を意味します。あなたのビジネスの内容が非常に小さい場合は、その内容について。データ化の意義を見出すのは、さらに困難です。効率的なマッチング取引を通じてレバレッジが生成される主な理由は、データ化によるものです。コンテンツもべき乗分布に従うことを知っておく必要があります。カテゴリー管理とコンテンツ供給は「グロースハック」において非常に重要な部分です。
2. 取引頻度が高い:取引価格は取引頻度に反比例します。価格が高くなるほど、取引する人は少なくなり、頻度も低くなります。営業チームへの依存度が高まります。取引頻度が高くなるほど、ユーザーからのフィードバックも増えます。真のユーザー価値 = アクティブ ユーザー数 * アカウントの平均取引量。
3. 供給側と生産側のフィードバック サイクルは短いです。つまり、需要を満たすための供給も迅速に反復できなければなりません。サプライ チェーンの反復速度によって、提供できる「コンテンツ」とユーザー価値が決まるからです。これが、迅速に反復してより大きな価値を生み出す唯一の方法です。

3. チームがデータ駆動型でスタートできるようにする方法

全体として、データ、ワークフロー、製品アーキテクチャ、組織分業、組織モビライゼーションの 5 つの側面から段階的に説明し、データ駆動型を実現できるようにします。まず、ビジネスの短期的なニーズをデータ主導にする方法を説明します。複数のビジネス関係者が関与します。

読者が、複数の事業部門を同時に推進することに発言力がないと感じる場合は、社内チームをデータ駆動型にする方法について説明します。

3.1 コアロジックはマトリックス分業である

ビジネスを複数の独立した反復的な小さなクローズドループに分割できるため、コア指標を多数の独立した小さな指標に分割して各チームに送信できます。これが還元主義の論理です。私の大きなシステムは小さなシステムに分割できます。私の小さなシステムをまとめると、大きなシステムと同じになります。小さなシステムが成長すれば、大きなシステムも成長します。

それでは、以下に示すように、1 つの指標だけを見てみましょう。

Facebookは事業を200以上の独立したクローズドループ反復チームに分割した。

単一の指標に分割した後、この指標にチームが割り当てられます。一部のソフトウェア開発システムはこれらのエンジニアによって開発されていないことを考慮して、このチームは通常、外部の反復に依存しません。

しかし、独自に要求を行うことは確かに可能です。この指標にはデータ アナリスト、エンジニア、プロダクト マネージャー、デザイナーが含まれていることがわかります。これらのメンバーは、需要を受け取ったときに独自の需要評価を行ったり、需要を自ら繰り返したりすることができます。 「外部リソース」に頼るのではなく。協力的な関係者が増えるほど、データ駆動型の失敗の可能性が高まります。

複数の指標のチーム マトリックスを見てみましょう。

指標、役割、部門間の関係

複数の指標をチームに配布すると、指標と管理のマトリックスが形成されます。

各指標は水平位置によって駆動され、成長を促進します。

ここで話しているのはポジションであることに注意してください。指標が多数ある場合、自然人が十分でない可能性がありますが、ポジションは指標に応じて設計する必要があります。ビジネスが十分に大きく、各指標がチームをサポートできる場合は、各ポジションの下に 1 つの指標が存在します。

それは上で述べたのと同じ問題です。ユーザー数とユーザー価値によって、チームをサポートするために必要な人数が決まります。

これを読んでも、どのように分割すればよいのか分からないかもしれません。指標に応じて水平方向に分業役割を構築し、垂直方向に管理できることを知っておくだけで十分です。セグメンテーションには他にも多くのソリューションがありますが、それについては後続の記事で回答します。

3.2 成功した人にとっての最優先事項は、代わりの人材を見つけることである

どれだけデータドリブンを目指しても、上記のような小さなチームのメンバーは不可欠です。適切な人材を見つけることができれば、その部署や部門で良い仕事をすることができます。結局のところ、マネージャーは袖をまくってすべてを自分で行うことはできません。退屈な日常生活で疲れ果てています。したがって、適切な人を見つけることが非常に重要です。第二に、それは私が昨日言ったことです。

1. 彼はビジネスで何をしているのですか？
2. 協力の境界はどこにあるのでしょうか?
3. この人の能力の限界はどこにあるのでしょうか？
4. この人物はどのような観点から評価されるべきでしょうか?
5. この人が有能かどうかをどうやって判断すればいいのでしょうか？

これらの問題については、よく検討する必要があります。ですので、代わりの人を見つけることが一番重要なので、まずは人探しから始めましょう。

3.3 データ駆動型ビジネスを始めるためのポイント

私たちは、データに基づいた業務を遂行する人材の採用を考えています。それで、新入社員は何をすべきでしょうか?以下の6つの領域についてまとめました。データ、ワークフロー、製品アーキテクチャ、組織的な分業まで、これら 4 つの側面が適切に実行されて初めて、データ駆動型開発を実現できます。

3.3.1 データの可用性

データを取得する能力はデータ駆動型の基礎です。どのビジネス ディメンションでもデータを取得できない場合、そのビジネス ディメンションはデータ駆動型にはなりません。通常、業界ではこのチームをデータ ウェアハウス チームと呼びます。データ ウェアハウス チームの主な焦点は、「データ主導の意思決定の強化」と「データ主導の製品の成長」です。

データを取得する機能は、単に読み取って表示するだけではなく、データを取得するためのシステムアーキテクチャです。多くのマネージャーは、データを取得するために SQL を記述できる人を見つけられることを当然のことと考えています。

ただし、これにより、将来のある時点でデータ取得にボトルネックが発生することになります。ビジネスの発展が速ければ速いほど、このボトルネックも早く発生します。私の提案は、データ ストレージ システムのセットアップと初期の軽量データ抽出作業に専念する人を配置することです。

初期の起動フェーズでも、データ取得のニーズを満たすための対応するデータ アーキテクチャが必要です。 「データ収集」「伝送」「保存」「処理」「応用」の6つの側面から、ビジネス側の究極のエンパワーメントを考えます。初期チームのデータ エンパワーメント アーキテクチャがあり、データ エンパワーメント アーキテクチャ全体がこれらの 6 つの側面から徐々に強化されます。

データ取得のコスト、範囲、カテゴリは、データ システムに大きく依存します。

私たちのほとんどは、データ分析のコストが高すぎると感じています。大体において、これは氷山理論です。実際、水面下のデータ収集アーキテクチャは十分に行われておらず、低コストのデータ収集ソリューションを提供することはできません。

初期データチームが行う作業

事業開始当初は、レポートの形でさらに情報を提供します。たとえば、データ ウェアハウス チームが設立されたばかりのときは、ビジネスは初期開発段階にあり、開発の初期段階にあります。人員構成は慣らし期間にあり、事業は実際には探索期間にあります。したがって、データ ウェアハウス チームは実際にはさらに多くのレポートを提供します。

たとえば、最初はトラフィック データとビジネス データ、およびそれらの関係にのみ焦点を当てる必要がある場合があります。まず、トラフィックとリテンションをリンクして、トラフィックの価値と現在の製品リテンション状況を把握します。ビジネスが一定の段階まで発展すると、セキュリティ体験に関するデータを徐々に構築し始めます。

実際、ビジネスの発展とともに徐々に繰り返されています。全体の焦点にも変化があり、データウェアハウス全体の構築も徐々に反復されることになります。したがって、主要なビジネスに集中する必要があります。ある段階で、その主要事業は何でしょうか?

これは私たちの主要なデータ ソースに対応します。何が必要かがわかれば、何を収集すればよいかがわかるからです。例えば、製品や研究開発用のテーブルは数万個あり、そのすべてを「データウェアハウス」に収集することはできないため、一定の範囲を設定する必要があります。したがって、ここでは実際に主要なビジネスを出発点として使用し、対応する主要なデータ ソースを収集します。

このとき、メタデータの標準化された管理も行う必要があります。データ ウェアハウスがテーブルを生成し、テーブルのコメント (各フィールドの説明) が空または不正確であり、テーブルの特性も不正確です。したがって、データ アナリストや関連する学生がこれを使用すると、その出力にはあまり価値がないことがわかります。

データ全体があまり標準化されておらず、誰もが理解できるわけではないからです。たとえば、注文に名前を付ける方法は多数あり、多くのビジネス ラインにレコードがあり、多くのテーブルにこのフィールドの名前があります。フィールドは 5 つまたは 6 つありますが、どれが注文フィールドであるかは誰にもわかりません。実は、これは非常に痛い点なので、データウェアハウスの初期段階でメタデータの正規化を行わなければなりません。

ビジネス マップ: データ ウェアハウス チームは、対応するデータ構築とインジケーター構築を行う前に、まずビジネスを理解する必要があります。たとえば、最初に注文を行うときは、まず注文の発行と受領から支払いプロセス全体の完了まで、主要な取引プロセス全体を実行します。メインリンク全体を整理し、各メインリンクに含まれる具体的なビジネスプロセスは何でしょうか。実際、これはデータ ウェアハウス チームがビジネス ダイアグラム全体を整理する方法であり、ここでのみ重要なポイントを抽出できます。

これがビジネスコーディネーションです。実際、データ ウェアハウスの学生はこのレベルを通じて、ビジネスをより深く理解し、ビジネスとユーザーの観点からデータが何を実現できるかを理解できるようになります。

次に需要制御を統一します。これは実は初期段階では非常に重要です。

誰もが煙突式の建築について話します。実際、煙突式の建築は2つの側面から見る必要があります。特に事業展開の初期段階では、煙突式の建築が悪いというわけではありません。検証スタイルの構築では、標準化全体と多くのプロセスが実際に問題ない場合、実際に反復して迅速に開発できます。

実際、煙突式の建築はまだ制御可能な範囲内ですが、このレベルでは全体的な需要を制御する必要があります。実際、現時点では関連データの質が不確かであり、企業側もその質がどの程度なのか明確ではないため、ある程度の適切な冗長性があっても問題ありません。実際、私たちも探索の過程にあります。

これには統一された指標システムが必要です。統一されたインジケーター システムは、すべてのデータ チーム、またはユーザーにとって非常に厄介な点です。実際、それについては後で話します。

したがって、この初期段階では、これらのコンテンツが開発段階、つまりコレクション チームの開発段階に達したときに、これらのコンテンツに重点が置かれます。当時、私たちの収集チームは、人々の能力とチーム全体の連携に注目していました。すでに一定の暗黙の了解があり、同時に事業の発展において一定の沈殿と蓄積もありました。そこで、ここでは、ユーザーが対応する分析を実行し、アプリケーションタイプの製品を適用できるように支援します。

したがって、このレベルでは、たとえば初期段階では、ユーザーがデータをすばやく表示して意思決定を行えるようにすることに重点を置いているため、主にコア レポートとダッシュボードに基づいています。開発段階に達すると、ユーザーはいくつかの洗練された操作を実行する必要があるため、ここで関連する分析製品をいくつか提供する必要があります。ああ、戦略的な診断行動や評価製品もありますね。

3.3.2 指標分解機能

ビジネスを理解し、経営陣にフィードバックを提供し、利益を計算し、ニーズを評価できる

データを取得し、ユーザー、トランザクション、顧客獲得チャネルの基本的な分析を行う能力があれば、ビジネスの指標を細分化する必要があります。チャネル側では、各チャネルのトラフィックデータが明確である必要があり、GMVなど、各チャネルがもたらすビジネスデータも含め、チャネルの価値を評価できるデータが必要です。

トランザクション側では、保持、アクティベーション、アクティブな構成、トランザクション カテゴリを確認できます。ユーザー側では、価値の高いユーザーを確認できます。

このプロセスには、ビジネス指標を細分化できる能力のある人が必要です。ただし、コア管理者は分解してみることをお勧めします。あるいは、逆アセンブリロジックをすぐに理解できる能力があるかもしれません。指標を細分化する目的は、例えば感情的なものではなく、コアビジネスに影響を与える主な要因を合理的なデータと「投与量」で理解することです。感情的なものではなく、コアビジネスに影響を与える主な要因を「投与量」で理解することで、それが大きな影響を与えることがわかります。

これにより、リーダーはビジネスをより明確に把握できるようになります。同時に、私自身の仕事経験から、多くのリーダーは数字を見たいが、実際には前のリンクを理解していない、つまり、どの指標を見るべきか、それが何を反映するかについて、リーダー自身があまり明確ではないことがわかりました。その結果、私たちがデータを提供するたびに、彼らはそれが十分ではないと感じてしまいます。しかし、それが何の強化なのかは分かりません。

最後のロジックは、データを取得したら、関数の変換率を評価できるということです。収益を計算し、データ評価によってこの需要を満たすユーザーを推定できます。収益見積もりとユーザー価値に基づいて、需要の優先順位を判断できます。つまり、基本的なデータ駆動型環境が整いました。

3.3.3 要件開発プロセス

すべては源から始まります。インターネット企業の中核的な価値のほとんどは、オンライン製品やソフトウェア製品を通じてユーザーに伝えられます。そして、需要の定量的な管理こそが、データ駆動型の本当の始まりなのです。

前の 2 つのステップ、つまりデータ機能の獲得とデータ機能の分解が家の掃除のようなものだとすると、データ主導のニーズ定量化から始めることは、まさにゲストを迎えるようなものです。

つまり、優先順位を定量的に評価して、どの機能を最初に開発し、どの機能を後で開発するかを決定することで、その後の新しい要件が決定されます。そうすることで、真にデータ主導となり、定量化を通じて優先順位を効果的に評価し、ビジネス上のプレッシャーを徐々に軽減できるようになります。

同時に、開発者のモチベーションを大幅に高め、ビジネス面を逆に管理することもできます。ここでは、ビジネス側が要件を提示し、要件ドキュメントを作成する必要がある理由を説明したいと思います。私は以前、小さな会社で働いていました。これらの企業では、要件が 1 文だけであることが多く、これは完全な要件ドキュメントとは異なります。違いは単語の数ではなく、問題を明確にすることにあります。ドキュメントを作成することには次のような利点があると考えています。

1. 需要内容を整理することはビジネス側にとって役立ちます。書くこと自体が思考と逆のアウトプットの一形態であるため、書くことのプロセスはビジネス関係者のアイデアを整理するのに役立ちます。需要背景、ターゲットユーザー、現状、問題点、したがって開発する機能、解決する問題、予想されるメリットがすべて適切に整理され、検討されています。
2. ビジネス側が需要の範囲を定義することは役に立ちます。通常、ビジネス側では要件が頻繁に変更されます。両者が何を望んでいるのかを整理していないことに加え、要件の範囲についても両者が合意に達していないのが通常の状況です。ソリューションの機能範囲に関して、ビジネス側と製品側の間に不一致があります。したがって、プロセス、一般的なルール、機能を書き留めておくと、製品マネージャーとビジネス関係者が認識について迅速に合意に達するのに役立ちます。
3. 製品マネージャーがビジネス側のニーズを理解するのに役立ちます。ビジネス側が望むものを決定したとしても、時間の経過とともに逸脱が生じる可能性があります。また、要件が口頭で述べられた場合、製品マネージャーはそれを覚えておく必要があります。このようなコミュニケーションは非常に非効率的です。
4. ドキュメント自体は価値があります。可決されるかどうかに関わらず、要求は満たされます。承認された要件を引き継いだ後、後続の製品マネージャーは、以前にどのような状況でどのような要件が反復されたかを把握します。同時に、需要側も、どのユーザーのニーズがどの程度満たされたかを把握することができます。新規参入者は、過去にどの要求が拒否されたか、なぜ拒否されたか、そして条件が現在満たされていないかどうかを知っているので、再度要求を提起して時間を無駄にする必要はありません。また、条件が変わった場合には、当初拒否した要求を再考することもできます。

多くの人は、ビジネス側は要件文書を書くには忙しすぎると主張するでしょう。私の見解では、要件が開始されると、製品、設計、研究開発、テスト、データなどの担当者が関与する複数の段階を経る必要があり、これらの担当者の時間が費やされます。これらの人員のコストと比較すると、要件を明確に記述し、それを定量化することが、実際には効率を向上させる方法です。

間違った要求をする人は、依然として資源を浪費するので、要求をまったくしないほうがよいという格言があります。そのような人々に何かを頼むよりも、お金を払って何もしないほうが良いでしょう。

第二に、要件を書く価値がなければ、基本的に開発する価値はありません。要件ドキュメントから製品要件ドキュメント、そしてコードへと、各ノードの記述量が指数関数的に増加するためです。

最後に、ビジネス側に要求文書の定量化をすぐに求めることはお勧めできません。製品アナリストやデータアナリストの支援を受けるのがベストです。執筆ではなく支援であることに注意してください。製品アナリストとデータアナリストが要件を完全に理解した後、データ抽出や要件をサポートするために使用するデータに関する提案など、固定ドキュメント形式に関するいくつかのライティング提案をビジネス側に提供できます。最終的な目標は、ビジネス側がデータ抽出の検証を独自に完了し、要件ドキュメントを独自に作成できるようにすることです。

3.3.4 製品および研究開発の売却

最初の 3 つの項目が基本的に満たされている場合、4 番目の項目は論理的に必然的な結果になります。需要者が自らの要求を定量化できれば、その要求を定量的に評価できます。評価後には、要求を満たす製品や開発が必ず行われ、同時に、これらの要求のデータ監視も適切に行われる必要があります。

したがって、データ駆動型にしたい場合は、組織構造に対応する変更を加えるのが最善です。中心となる考え方は、運用とビジネスのニーズ、そして長期的なユーザー価値のニーズを 2 つのスタックに通すことです。研究開発側での小規模なクローズドループ分業を段階的に実現します。

指標、機能、対応する開発は関連していると考えています。もちろん絶対的なものではありません。ただし、それらを独立した閉ループに分割するように最善を尽くす必要があります (一部の接続がある場合もありますが)。ただし、一般的な傾向は独立しています。

全体的なセグメンテーション ロジックはセクション 3.1 で説明されており、その中核となるロジックはマトリックス分業です。別の観点から発言したいと思います。基本的な考え方としては、ランディングページツール、運用エンジン、配信エンジン、メッセージリーチセンターなど、運用や販売に重点を置いたマーケティング指向の機能を、成長製品の研究開発チームに統合することです。もう 1 つのカテゴリは、ユーザー価値の長期的な構築に重点が置かれます。電子商取引を例に挙げると、カテゴリー、製品、店舗管理など、よりコアバリューに傾くものは別の研究開発チームが担当することになります。

もちろん、このプロセスで最も重要なことは、R&D リーダーと製品リーダーと一緒に製品アーキテクチャ図を計画することです。アーキテクチャ図によってのみ、どの機能を統合して同様の開発チームと製品チームに割り当てることができるかがわかるからです。

データドリブンの観点からは、ビジネス需要者が関与するニーズの範囲は通常限られているため、ビジネスニーズとそれがオンライン化された後の成果を定量化することを優先することが核心です。

もちろん、長期的なユーザー価値を重視した要求も提示されるでしょう。著書『The Light of Operation: My Internet Operation Methodology and Confession』の中で、著者は次のように述べています。「製品チームは長期的なユーザー価値を定義し、提供する責任があります。」一方、運用チームは短期的なユーザー価値の創出と製品の長期的価値の向上を支援する責任を負います。チーム分けの観点で言うと、ビジネス側の短期的な反復に対する要求は基本的にはるかに高くなります。

3.3.5 チームコラボレーションツール

チームが協力して需要実現を推進する方法。

最初の 4 つの項目が満たされると、ビジネス側はデータを使用して要求を定量化する意欲が高まり、製品開発側もこれらの要求に積極的に取り組むようになります。残りの質問は、システムを介して最初から最後まで需要の同期にどのように送信されるか、およびチーム間で情報がどのように同期されるかです。これには、チームコラボレーションのためのツールが含まれます。これには、以下を含みませんが、これらに限定されません。

需要管理ツール：主にビジネスパーティーが提案した需要文書を記録する責任があります。その後、要件が開始された後の要件のステータスが含まれています。

ドキュメントの同期：プロダクトマネージャーの要件ドキュメント、R＆Dドキュメント、データドキュメントなど。

IMツール、電子メールツール、R＆D需要のフォローアップツール、テスト管理ツールなどについては詳しく説明しません。要するに、管理ツールは最小限の可用性の原則に従う必要があります。第二に、チームは、同様のシステムを使用して可能な限り通信し、可能であればそれらをマージする必要があります。

私が以前に働いていた中規模の会社では、会社の一部の人々がQQの使用に慣れていること、一部はDingTalkの使用に慣れていたことがあり、一部はWeChatの使用に慣れていたため、チームメンバーはお互いを見つけることができませんでした。需要UIはタワーで維持され、一部の人々はExcelで製品を維持し、一部の人々はZentaoでそれを維持しています。要求は散らばっているので、もちろん統一されたレビューを達成することは不可能です。

したがって、データ駆動型により、すべての人の情報が可能な限り一貫している可能性があります。同時に、要件の定量化と優れたレビュープロセスは、チームの仕事の効率を向上させることができます。このプロセスベースのアプローチは非効率的だとは思わないでください。これは、ビジネス側の直接的な製品とR＆D開発よりもはるかに効率的です。しかし、このプロセスは、貴重な要件を最初に開発し続けることができるようにすることができます。

速く歩くよりも、正確かつ着実に歩くことが重要です。

プロセスが整ったら、チーム全体がプロセスに精通して迅速かつ着実に移動できます。

3.3.6組織機能

データ駆動型開発には多くの部門が含まれており、非常に高い組織の動員能力が必要です

最後に、データ駆動型のチームを促進するには、需要側から製品、UI、R＆D、データエンジニア、アナリストへの協力が必要であることがわかります。したがって、論理的には、マトリックス管理方法に従って、この人は需要側から製品、UI、R＆D、データエンジニア、アナリスト、その他多くの部門に影響を与えたり管理したりする必要があることがわかります。これは、位置が高いほど、この問題を促進することが容易になることを意味します。

これは、各ディレクターの下のグループから一部の担当者を分離して、成長またはビジネスのために独立した小さな閉ループを形成できるために行うことができます。

次に、このような優れた管理力を持っていないが、チームがデータ駆動型になるように影響を与えたい場合、またはより鈍くするために、より専門的になり、少なくとも職場の価値を改善するためにデータを定量化したい場合に何が起こるかについて話しましょう。 2人のサポート、または1人だけのサポートが必要です。

次に、定量的ニーズを受け入れるエンジニアと、データの抽出を支援するデータアナリストのみが必要です。

ただし、この環境が実現可能かどうかは、チームとの関係と、チーム管理者がそのようなスペースを持っているかどうかに大きく依存します。極端な場合、データアナリストがいない場合、エンジニアがうまく協力している場合、彼はあなたがいくつかのビジネスデータを取得するのを手伝うことができます。ただし、問題は、追跡ツールがないため、新規顧客の需要を定量化できないことです。

ただし、最初に製品のユーザーを分析できます。同時に、ツールを追跡しないと、行動とビジネスデータの関係を分析できない可能性があることを考慮してください。この状況に対処する最良の方法は、データ分析スキルを学び、この小さなチームを通じていくつかの結果を生み出し、できるだけ早く成熟した会社に切り替えることです。

最後に、チームがデータ駆動型にならない6つの理由を要約しましょう。それらは論理的に関連しています。会社チームがデータ駆動型にならない場合、成長担当者またはアナリストを見つけるだけでチームをデータ駆動させることはできません。それは体系的な問題です。すべてのリンクがデータによって権限を与えられた場合にのみ、最終的なビジネスをデータトラックに配置できます。

このプロセスは、スレッドのボールを解くようなものです。問題の核心全体を見る必要があり、次に、最初にどのスレッドを解くか、後でどのスレッドを解くかを理解する必要があります。はさみを直接使用したり、最大のスレッド（最大のデータ駆動型のスティックポイント）を解くことは役に立たない！

困難は、パスを計画し、段階的に分解することにあります。すべての結果は大義によって生成され、この原因は前の原因によって生成されると信じなければなりません。原因層をレイヤーごとに見つけて、段階的に解決する必要があります。したがって、以下のロジックに従ってデータを駆動します。

• ステップ1 ：データがあり、データを表示できる必要があります。これは、データ駆動型開発の基礎です。データ収集と視覚化機能を継続的に維持するには、データウェアハウスの同僚が必要です。
• ステップ2 ：データを取得したら、どのデータを確認するデータ、変更の意味、およびそれらの間の関係が何であるかを徐々に理解する必要があります。これらは、初期段階で成長プロダクトマネージャーまたはプロダクトマネージャーによって分解され、後の段階でアナリストが維持することができます。もちろん、最初からデータアナリストがいる場合も素晴らしいことですが、データアナリストを雇う前にデータウェアハウスが基本的に構築されるまで待つ必要があります。
• 3番目のステップ：オンラインになった後、徐々に要求と効果を定量化する必要があります。定量化された要求に基づいて、定量化を通じて需要の優先順位を評価し、リソースをスケジュールします。そのため、要件を中央に確認および管理する必要があります。
• ステップ4 ：要件がレビューされ、承認された後にビジネス側に迅速に対応するには、ビジネス側のニーズに対応するために別のスタックが必要です。これにより、ニーズの定量化と効果を迅速に達成できます。第二に、結局のところ、ビジネスパーティーはドキュメントを書くために一生懸命働いており、スケジュールを待つように彼に伝えることは、全体的な原動力を大きく損なうことになります。
• ステップ5 ：このプロセスで誰もがどのように機能しますか？最初から最後まで需要を管理するためのツールなど、需要を開始する前に、誰もが情報に協力するためのツールをレイアウトする必要があります。これらの5つのステップを完了した後、基本的にビジネス側から定量的要件を受信できます。

ただし、これらはすべて、リーダーがデータの定量化の重要性を真に認識しており、この問題を上から下に促進する意思があるという事実に基づいている必要があります。あまりにも多くの部門が関与しているため、トップダウンの進歩は最速です。

これらの5つのステップは、原因と結果から論理的に推定されます。次のレイヤーが処理しなければならないすべての要件は、前のレイヤーのロジックによって引き起こされます。これはステッチを取り除くボールのように見えませんか？これらすべてが解決された場合にのみ、データを駆動できます。

光の速度を持つ2台の車が私たちに向かっている場合、相対速度に応じて光の速度の2倍になるはずですが、光の速度を超える速度はありません。

私はこの考えを引用して、論理的に物事の推論は避けられないと説明します。チームのデータ駆動型になるには、論理的な派生の良い仕事をする必要があります。

著者: Arun's Growth Research Institute

WeChatの公式アカウント：Arun's Growth Study Club（ID：Arungrowth365）