運用データのレビュー（半月でシステムを整理、オペレーターはどのように詳細なレビューを行うべきか？）

半月にわたる体系的な選別を終えた後、オペレーターはどのように詳細なレビューを実施すべきでしょうか?

編集者注: なぜレビューを実施する必要があるのでしょうか?復習作業は、問題をよりよく見つけ、私たち自身の能力の成長を促進するのに役立ちます。では、オペレーターはどのように詳細なレビューを実施すればよいのでしょうか?本稿では、レビューの枠組みとプロセスを包括的に整理しました。ぜひご覧になってみてください。何かインスピレーションが得られるかもしれません。

振り返ってみると、この概念は今では誰もが知っています。先週、インターン生に面接をしていたとき、あるインターン生がこのプロジェクトについて詳細なレビューを行ったと言っているのを耳にしました。

それから私はさらにいくつか質問をしました。「プロセスをどのようにレビューしますか？」彼が私にくれた答えに私は言葉を失った。彼の意見では、プロセスを見直すということは、コミュニティの早期チェックイン データを報告するために取得したデータを要約して記録することを意味します。

私は彼にもう一度尋ねました。「なぜレビューしたいのですか？」

彼は次回はもっとうまくやるためだと言った。

私は彼にもう一度尋ねました。「次回は何をすればいいか知っていますか？」

どもってうまく話せなかったが、インタビューを通じて「レビュー」という概念がすっかり普及していることがわかった。

それで、どうやってゲームをレビューするのでしょうか?レビューを価値あるものにするにはどうすればいいでしょうか?

そこで、「レビュー」という概念を整理して、皆さんと共有したいと思っています。以前は、比較的散発的にしか話していませんでしたが、今回は丸一日かけて考えを整理し、以前共有した PPT と組み合わせて、レビューのフレームワーク、プロセス、真の目標について、より体系的な要約を作成しました。同時に、新たな考えが浮かんだので、それを皆さんと共有したいと思います。

この記事を始める前に、皆さんと次の質問について議論したいと思います。コミュニティを継続的にチェックすることは価値があるのでしょうか?

私の友人の多くは、「アーリーチェックイン」や読書コミュニティに参加していると思います。このようなことを続けることが本当に価値があるのか​​どうかという私の質問に、急いで答えないでください。

早起きしたときに何をしたかよく考えてみて下さい。最近どんな本を読みましたか？あなたにとって特に役に立った議論のポイントは何ですか?

私の質問に素早く明確に答えることができれば、それはあなたが行うすべてのことに計画があり、それを行う目的を理解していることを証明します。

私の2つの質問に明確に答えられない人は、なぜこの質問に対する答えをすぐに反映できないのかを考える必要があります。

気づきましたか？

自分の実践を振り返ることなく、うまくやっているように感じていましたが、何をやっているのかわかりませんでした。最近特に気に入っている言葉は、「忙しければ忙しいほど、目を覚ましていなければならない」です。

私が皆さんに伝えたいのは、なぜレビューする必要があるのか​​ということです。

次に、人の仕事能力レベルを直接反映できる4つの質問をします。これらは、当社の副社長への面接の質問でもありました。

1. どのような定量的な出力指標を担当していますか?
2. 物事を行う「理由」を知っていますか?
3. 優れた仕事の基準とベンチマークは何ですか?
4. 独自の方法論はありますか?

これら 4 つの質問は、職務の範囲内でのあなたの役割、仕事の中で考え、検討する能力、問題を分析し、根本的な問題を見つけ、問題に遭遇したときに解決策を特定できるかどうかを十分に反映します。

したがって、レビューは仕事の蓄積の中核であるだけでなく、成長を促進するものでもあります。

なぜレビューが必要なのでしょうか?ここで、レビューする必要がある理由を説明するために写真を引用します。

引用 知虎何明禄

これが、私たちが問題に遭遇したときの思考の連鎖です。私たちは、独自の知識と経験基盤を活用し、できるだけ早く解決策と計画を見つけます。どのようにして知識と経験の基盤を蓄積していますか?

読んで覚える方法と、要約して復習する方法の 2 つがあり、特に要約して復習する方法は非常に中核的な方法です。

さて、この記事の冒頭で私が残した穴を埋めたいと思います。私が整理した「レビュー」は、具体的にどのようなものなのでしょうか?私がまとめた写真をご覧下さい。

レビューには、レビュー フレームワーク、レビュー プロセス、レビューの真の目的という 3 つの中核部分があると思います。

私の友人の多くは、レビューの仕方に関する記事を読んだことがあると思います。この記事を書く前に、参考のために多くの記事を読むことにも時間を費やしました。しかし、「真の北を見直す」という概念については、多くの人が言及しませんでした。なぜここで真の北を再確認することについて話すのでしょうか?

True North という言葉は文字通り本当の北を意味し、広義にはあなたの鍵と核心を意味します。なぜなら、比較的単純なタスクをレビューする場合、核となる重要なポイントを忘れてしまうからです。多くの友人が 1 年間の作業や大規模なプロジェクトをレビューする場合も同様です。しかし、レビューを行う際に「True North」を忘れると、レビューの価値と意味が失われます。

ここまで言っておきましたが、レビューの方法についてはまだ書き始めていません。皆さんがレビューをよりよく理解し、今後の仕事や生活に応用できるように、この記事では主にレビューの枠組みとレビューの本当の意味について説明します。これらは比較的概念的で非現実的に思えるかもしれませんが、これらを読み終えてレビューのプロセスを見ると、素晴らしいつながりが見つかります。

再び物理学の公式を例として使います。公式の背後にある論理と原理を理解していないと、比較的難しい問題に遭遇したときに、それをどのように使用すればよいか分からなくなってしまいます。

レビューのフレームワークは 5 つのステップで構成されており、これら 5 つのステップが完了した場合にのみ、完全なレビューとみなされます。

1. 目標を見直してください。そもそもこの目標を設定することの意義は何でしたか?今設定すべき目標は正しいでしょうか?
2. 違いを見つける: 当初の予想結果との違いは何ですか?ハイライトは何ですか?欠陥は何ですか?
3. 問題を見つける: なぜそのような欠点があるのでしょうか?なぜこのような違いがあるのでしょうか?利点を考慮する背後にある考え方は何ですか?
4. 結論を導き出す: 問題の根本原因を分析した後、客観的な結論を導き出します。
5. 解決策: 客観的な結論に基づいて、今回発生した問題を最適化し、次回は問題を回避するための解決策を策定します。

一般的に言えば、②と③は適切に統合することができます。複雑な問題は分離する必要があります。それほど複雑でない場合は、結合することができます。 5ステップでなければならないかどうかは気にする必要はなく、うまく適用するだけです。

レビューの真の目標は、レビューの中核であり重要なポイントです。これをレビュー プロセスと完全に組み合わせる必要があり、レビュー プロセスはレビューの真の目標の要件に従って柔軟に適用され、厳密に遵守される必要があります。

1) 北極星を忘れない

目標を見直すときは、それが正しいかどうかを考えましょう。目標は明確ですか？目標は妥当でしょうか?

このとき忘れてはならないのは、あなたの北極星とは何でしょうか?まるで、トラフィックを誘導するためにフラッシュ モブ グループを作成したが、このグループの活動に非常に高い目標を設定したかのようです。この目標は本当に North Star Metric に影響を与えるでしょうか?

したがって、慎重に考える必要があります。最速かつ最短のリンクは、転換グループのアクティビティよりも優れているのでしょうか。

2) 最も細かい粒度に絞り込む

問題を最も細かいレベルまで分析しなければ、問題の本質を知ることはできず、根本的な問題を見つけることもできず、ましてや根本的な問題を解決することはできないと思います。たとえば、あなたが企画したアクティビティがあまり効果的でなかったため、それをレビューして、アクティビティで使用された素材が魅力的でなかったことが原因であると判断した場合、このレビューの粒度は粗すぎます。

では、どうやってそれを改良するかが問題です。

皆さんが理解しやすくするために、ここに写真を載せます。そして、何度も自分自身に問いかけてください。なぜこの素材は魅力的ではないのでしょうか?それは素材自体のせいでしょうか、それともパッケージのせいでしょうか?

したがって、問題の粒度を細かく調整する最良の方法は、一般的に次の 4 つの段階に分けることができます。

3) 正直に責任を社内に帰属させる

正直であることは、実は自分にとって最も反人間的なことです。なぜなら、人は自分が間違っていることや問題を抱えていることを認めようとしないからです。彼らは皆、責任を負うよりも責任を転嫁することを好む。しかし、状況を見直すのは、自分を責めるためではなく、内省するためです。

問題を避けたり言い訳をしたりせずに、物事を客観的に見て、自分の問題を発見し、自分と和解し、自分自身を理解しましょう。

では、具体的にはどのようにすればよいのでしょうか?

これは同僚が行ったことであり、あなたが彼に代わってレビューしているものとして扱うことができると思います。別の視点から考えてみましょう。実際、常に成功することよりも、自分自身の問題に立ち向かい、失敗を許容する心構えを持つことの方が重要です。

4) 明確で簡潔な結論

結論が明確かつ簡潔でない場合、その結論に基づいてどのように解決策を導き出すことができるでしょうか?

言い換えれば、結論が明確かつ簡潔であるかどうかわからない場合は、結論が客観的なものなのか、それとも主観的なものなのかを考え、いくつかのデータから共通点をつなぎ合わせる必要があります。

たとえば、運営しているアプリの翌日のユーザー維持率が非常に低いことに気づき、ユーザー維持率が低い理由を考えずに、あらゆる改善方法を試し始めたとします。ライブ クラス アプリの場合、ユーザーが登録してクラスにサインアップした後、クラスが始まる前にユーザーがアプリを開くのはなぜでしょうか?この観点から見ると、これは結論ではなく現象であることがすぐにわかります。逆に言えば、その価値と重要性を確認するには、より長い期間にわたって保持率を調べる必要があります。

5) 実行可能な解決策

ここでの解決策は実行可能でなければなりません。論理的に一貫性がなく、次のプロセスに適用できない場合、このソリューションは無意味です。したがって、計画を策定する際には、それをより良く実行するために、計画の定量的な基準と時間的なリズムがどうあるべきかを明確にする必要があります。

上記は私の個人的なレビューの枠組みとレビューの背後にある真実です。現在のロジックは十分に厳密ではないかもしれませんが、徐々に考えていくことで、徐々に形になり、より完全なものになるでしょう。お役に立てれば幸いです。今後、レビューに対する理解が深まったら、再度更新したり、覆したりする予定です。実際、このプロセスで認知能力は成長します。

私は知識は流動的であると常に信じてきました。私たちが今見たり聞いたりするいわゆる新しい知識でさえ、ずっと昔に提案されたものです。本をたくさん読むと、さまざまな視点が互いに引用し、検証し合いますが、学んだことや活用したことは、ある程度あなたの人生に役立ちます。これが知識の全体的な意味です。

なぜなら、レビューには5つのセクションがあり、各主要セクションは直接関連していますが、各主要セクションの内容は互いに独立しているため、マインドマップの形式でレビューするのが最も便利だと思います。

これにより、思考が広がるだけでなく、問題をより深く掘り下げることにも役立ちます。

レビューの始めに、まずは多角的に考え、自分のプロジェクトの背景を見直します。目標は何ですか?何が悪かったのでしょうか?どうすれば解決できるでしょうか?最終的な効果は何ですか?

それでは、散らばっているポイントをすべてリストアップします。熟練すればこれらのリンクを脳内で操作できますが、最初はペンと紙で書き留めていました。

これらの散らばった点を書き出したあと、レビューの枠組みに沿って散らばった内容を埋めていくと、リンク全体に抜けている部分が多いことに気づくでしょう。なぜなら、すぐに思い出せるのは、最も印象に残ったこと、多大な努力を払ったこと、無視しなかったことだからです。私たちのレビューは、実際には私が考慮せず見落としていた場所を見つけることです。

最初のセクションから始めて、このプロジェクトに設定した目標を確認しましょう。

1) まず、この目標が正しく設定されているかどうかを確認しましょう。

毎月 3,000 件の注文を獲得することが目標である場合、この注文量目標は私たちが行っているプロジェクト全体にとって適切なものなのでしょうか?

プロセス指標または結果目標を設定する必要がありますか?

特定のプロセス指標を目標として設定する場合は、サービスのノーススター指標を覚えておく必要があります。

以前私が従事していたパブリックアカウント戦略のポジションと同様に、フロントエンドにはイベント運営パートナーがいて、アクティビティを通じてユーザーにパブリックアカウントのフォローを促します。公開アカウントのメッセージやメニューバーを使用して、このユーザー グループにリーチし、最終的にコンバージョンを形成します。

私のフロントエンドイベント運営パートナーの目標がヒットイベントの作成である場合、彼を評価する指標は新規フォロワーの数であり、私を評価する指標はユーザーの注文数です。フロントエンドのパートナーは、核分裂係数の高い活動を数多く実施しますが、ユーザーグループは明確ではありません。

これらの活動は彼の KPI の達成にはまったく問題はありませんが、私の KPI 評価にはまったく価値がなく、最終的には私の KPI の達成不良につながります。

しかし、論理的には、これは私の問題ではなく、フロントエンド パートナーの目標設定の問題です。フロントエンド パートナーのプロセス目標の設定方法を再検討する必要がありますか?

2) 目標は明確ですか?

正確なデータに基づく KPI 目標の場合、目標が不明確になることは実際には発生しませんが、比較的定性的な目標の場合は、考慮する必要があります。

ランディング ページを最適化することが目標である場合、この目標は明確ですか?

もちろんそれは明らかではありません。最適化は特定の目標を達成するために実行されるアクションであるため、実行者としてこの目標を確認するのは非常に混乱を招きます。では、ランディング ページを最適化する目的は何でしょうか?

ランディング ページを最適化すると効率が向上し、リンクのコンバージョン率が向上します。したがって、この目的から、[ランディング ページの最適化] のアクションでは、ランディング ページのコンバージョン率を向上させることを目標にする必要があります。どうやら私たちはそのような目標をどのように設定すればよいのか分からないようです。

そのためには、業界標準、競合他社、ベンチマーク状況に基づいて具体的な KPI データ目標を策定し、プロセス指標を詳細に細分化して目標を明確にする必要があります。

3) 目標は妥当なものか？

次に、1 か月あたり 3,000 件の注文の量を測定する必要があります。プロジェクトの完了には高すぎますか、それとも低すぎますか?

ここでは、高低を答えるだけでよく、あまり深く掘り下げる必要はありません。次のステップで違いを探すときに、より深い分析を行います。

目標は上記の3つの部分に分かれています。それでは、レビュープロジェクトについて質問を始めたいと思います。

このステップの主な目的は、プロジェクトの完了状況と目標との直接的な違いを見つけることです。

このようにして、問題を最小の粒度に分解し、最終結果を確認することができます。目標を達成できなかった、あるいは目標を上回った理由は何でしょうか?

この方法により、問題を迅速かつ正確に見つけることができ、問題を特定して解決策を開発することが運用の最も得意とするところです。

まず、完了したプロジェクトのステータスをリストする必要があります。ステータスは、データ ステータス、ユーザー エクスペリエンス ステータス、コーディネーター ステータスの 3 つのセクションに分かれています。

なぜこれら 3 つの側面なのでしょうか?主な考慮事項は次のとおりです。

1. 目標は達成されましたか?
2. プロセス全体がユーザーフレンドリーですか?
3. プロジェクトコーディネーターは再度協力する意思がありますか?

これら 3 つの側面から、私たち自身、ユーザー、パートナーにとって達成すべき基準を達成できたかどうかがわかります。

例：

1) たとえば、公開アカウントを運営していたとき、毎週更新することを目標にしていましたか?

今のところ、コンテンツを毎週更新したのは 1 週間だけで、それ以前の週は更新していませんでした。

2) 私の記事を読んでいるファンの要求に応えられているか？

忠実なユーザーに、記事のアクティビティ レベルや意見、提案を確認するよう依頼できます。

以前は、自分の記事では読者を維持できないと感じていましたが、読者を維持できない主な理由はメッセージ機能がなかったことです。そこで、メッセージ機能を有効にする方法について調査しましたが、実際にメッセージ機能を有効化してみると、メッセージを残す読者がまだ非常に少ないことがわかりました。

この観点から見ると、ユーザーのニーズを満たせていないことになります。

3) パブリックアカウントの記事の執筆に関しては、私の協力者は Xiao Liu です。まだ自分の書き方が確立されていないので、毎回磨いてもらう必要があります。彼女が記事の改訂を手伝ってくれたプロセスから、プロセス全体の経験が非常に貧弱であることがはっきりとわかります。タイプミスや支離滅裂な文章、その他小学校レベルの問題がたくさんあります。

そうでない場合は、次のステップに進み、問題がどのカテゴリに属する​​かを確認する必要があります。それは論理的な問題ですか?実行上の問題ですか?それとも外的要因によるものでしょうか?

上記の例を続けて、各セクターの問題を分類し、さらに掘り下げていきます。

毎週のアップデートを完了しなかった理由は何ですか?それは実行の問題ですか?

私は自分の週のスケジュールを細かく分析し、公式アカウントの記事を書くことを週末の重要だが緊急ではない仕事として扱っていたため、緊急なことが発生すると遅れてしまうことに気付きました。

この観点から見ると、それは実行の問題ではなく、リズムの問​​題です。公式アカウントの記事を毎日1つずつ完成させるべきか、それとも一気に全部終わらせるべきか、まだよく考えていません。

それを全部一気に書こうとすると、週末のすべてを記事に費やすことになるので、インターネットワーカーにとっては悲惨すぎるでしょう。彼は外へ遊びに行ったり、本を読んだり、やりたいことをしたりすることができません。

これは、プレッシャーの大きいインターネットの人々にとっては、あまりにも過酷なことです。

これ以上スクロールできません。こうしてみると、記事をセクションに分割して毎日1段落ずつ書き、最後に内容を統合・整理して筋をつなげていくのが、非常に生産性の高い方法だということがわかります。

実行上の問題や外部要因によって生じた問題も、このように分解して分析する必要があります。

例えば、オンライン教育の二重削減政策は、実は典型的な外部要因です。しかし、私の場合、夜更かしすることに慣れてしまっているので、それを変えることはできません。これは外部要因の問題ではなく、実行の問題です。

設定しているフラグがある場合は、コメント セクションで私と話し合ってください。

問題を見つける際には、特に一般的なモデルである PDCA モデル (計画 → 実行 → 確認 → 対策) を使用します。

私たちが探してみると、問題とは何でしょうか?質問の種類は？次に、この問題を解決するために、最小の MVP モデルを使用する必要があります。 PDCA アプローチを使用して MVP モデルを開発するのが最も簡単で迅速です。

上記でメッセージ機能を開設したと書きました。私の核心は、他の人の記事のコメント欄でのやりとりが非常に良好で、活動レベルが非常に高く、伝染性が高く、ユーザーを維持できることがわかったことです。

私の記事のインタラクティブ性、アクティビティ、保持率が低い主な理由は、メッセージ機能がないことにあると私は当然のように考えていました。しかし、実際にメッセージ機能を開いてみると、メッセージの数はそれほど多くありませんでした。

ここで私の論理は間違っていました。この機能があれば、自然とコメントも増えるだろうなと思いました。実際、記事の中でユーザー同士の議論を促し、種を蒔かなければ、読者自身もコメントをしてくれないだろうということは全く考えていませんでした。

それを分解した上で、ユーザーをコメントに誘導することで、自分の記事のアクティビティや公式アカウントの維持率を高めることができるかどうかを検証する計画を立てるべきでしょうか？私は次のようにします:

• P: 記事の最後にディスカッション用の質問、抽選、無料の情報パッケージなどを設けて、読者にコメントを促すことができます。
• D: 次に、先ほど述べた方法をテストします。もちろん、選択したガイダンス形式は記事の内容と一致している必要があります。互換性のないガイダンスにより、ユーザーの正確性とアクティブ性が低下します。
• C: テストの結論を測定するための指標をいくつか開発します。コメント数・読者数・コメントボリュームは評価基準やABテストの手法として活用できます。
• A: 上記のテストを通じて、ユーザーの口調に最も適したフォームを見つけ、最適化と反復を実行します。

PDCA 方式を通じて、根本的な問題が何であるかを見つけることができます。分解ロジックが正しければ、数回の調整を経て、問題の本質を見つけ出し、比較的完全な解決策を開発することができます。

もちろん、この段階では多くの友人が混乱するでしょう。上記で問題はすべて解決するのではないでしょうか?なぜ結論や解決策にこだわるのでしょうか?もちろん、単一の問題であれば、上記の手順で実際に問題を解決できます。

比較的大規模なプロジェクトの場合はどうでしょうか?結論はまったく出ません。

たとえば、良いパブリックアカウントを運営したい場合、記事はその一部であり、記事はコンテンツのレイアウト、有効性などの要素によって影響を受けます。上記は、メッセージ機能のガイドの問題のみを解決します。これは、私がメッセージをうまく誘導したからといって、私の記事が必ず広まり、私の公開アカウントが必ず 1000 人以上のフォロワーを獲得するという意味ではありません。

逆に、各セクションで欠点や反復が必要な領域を整理したら、その時点で立ち止まって整理したすべての問題を見て、すぐに解決しなければならない問題、後で解決できる問題、解決しないままでよい問題を確認する必要があると思います。

このようにして、プロジェクト全体についての結論はより価値があり、有意義なものになります。下手に書かれた文書をレビューするのに、これほど多くの時間を費やす人はいないと思います。もちろん、比較的大規模なプロジェクトの場合、レビューはより有意義なものになります。

毎週の更新、メッセージ機能、名刺、プロモーションチャンネルなど、公式アカウントに関する多くの疑問を整理しました。

実際、最近の状況を振り返ってみると、私にとって最も重要なことは、ブログを毎週更新し続けることだと考えています。なので、メッセージ機能などに取り組むのではなく、週次アップデートの問題を早急に解決しなければなりません。

このように細分化することで、明確なレビューが得られ、次のプロジェクトで事前に考慮すべき問題がわかります。

散在する問題やアクションを中核問題にまとめ、中核問題を使用して根本的な問題にドリルダウンし、根本的な問題に基づいて解決策を策定します。

ソリューションが比較的大規模なプロジェクト向けである場合、協力者を集め、要求を論理的に明確に説明し、測定基準を確立し、最終的に時間リズムを調整する必要があります。

例えば、生産・運用業務のセクションでは、製品、技術、需要の関係者と目標を一致させることが多いです。この需要の価値を調整し、最終的に需要がオンラインになった後の戦略と最終的なオンライン スケジュールを決定します。

上記は、大規模なプロジェクトをレビューする際に実施したフルリンクレビューです。普遍性のため、私が書いたフレームワークは比較的一般的なものになります。また、一部の事柄では、それほど完全かつ複雑なレビューが必要ない可能性もあります。

これを実行すると、さらに時間が無駄になる可能性がありますが、手順 123 を省略することはできません。

最後に、レビューは私たちのツールであるということを友人全員に思い出させたいと思います。うまく使えば次元のアップグレードを実現できますが、うまく使えなければ時間の無駄になってしまいます。枠組みはあくまでも枠組みですが、本当の思考と沈殿は私たちの認識の中に微妙に存在します。

レビューのためにレビューしないでください。

しかし、私は仕事、生活、プロジェクトにおける自分の欠点を見つけ、考えていなかった部分を見つけ、自分の論理的な抜け穴を見つけたいと思っています。実際、愛さえも振り返り、反省することができます。この点に関するXiao Liuのレビューは非常に詳細です。

この方法でのみ、あなたのレビューは真の価値を持つことになります。レビューを終えると、夢から覚めて突然何かを悟ったような感覚になります。

この記事は、1 週間毎日 1 段落ずつ書き続けた結果です。読んだ友達はコメント欄で私と交流することができます。過去は変えられないが、未来は追求できると理解して、私はこの文章がとても気に入っており、皆さんと共有したいと思います。

この記事はもともと @萧然 によって Everyone is a Product Manager に掲載されました。無断転載禁止

タイトル画像はCC0ライセンスに基づきPexelsから引用しています