イベント運営：イベントプロジェクトレビュープロセスを完備！

過去の出来事を振り返ることは、オペレーションに欠かせないスキルです。食料品の買い物体験のような小さなことでも、数百億、数千億の投資プロジェクトのような大きなことでも、過去の出来事を振り返ることでパターンをまとめ、レベルアップすることができます。

簡単に言えば、復習によって得られる効果は次の 2 つです。

1. 弱点を最適化し、強みを強化する
2. 自分の価値と仕事の価値を明確にする

では、レビューはどのように行うのでしょうか?言い換えれば、良いレビューを行うためのより効率的で実用的な方法はあるのでしょうか?いくつかの。

以下の内容は、私の仕事上の考えに基づいており、Liu Chuanzhi のレビュー方法論も参照して、完全かつ実用的なプロジェクト レビュー プロセスを提示することを目的としています。

1. レビューの根底にある論理

レビューで最初にすべきことは、事実を述べることです。効果的な AAR (事後レビュー) は、「確かな事実」に基づく必要があります。現実を明確に述べて合意に達することが難しい場合、レビューの進行は遅くなったり、深く掘り下げることができなかったりします。

事実が確立されると、違いの理由を診断および分析し、成功または失敗の根本原因を見つけ出し、パターンをまとめ始めます。成功がなぜ起こったのか、どの主要な行動が機能したのか、これらの行動は適用可能だったのか、そして、その後の行動の成功率を向上させる上で価値があるのか​​どうかを理解します。

したがって、目標のレビュー、結果の説明、プロセス分析、ルールの要約という4 つのステップを含む完全なレビューが生まれました。

1. 目標の見直し

その行動の本来の意図や目的は何でしたか?

イベント/アクションは何を達成しようとしているのでしょうか?

私たちは何をするつもりですか?

事前に計画された計画とは何ですか?

何が起こると予想されていましたか?

1. 結果ステートメント

実際に何が起こったのでしょうか?

どのような状況ですか?どうやってそうなった？

目標と比較してうまくいっている点は何ですか?期待に応えられなかった点は何ですか?

1. プロセス分析

実際の状況と予想に違いはありますか？

もしそうなら、なぜこのような違いが生じるのでしょうか?期待した目標を達成できなかった原因は何ですか?

失敗の根本的な原因は何ですか?

失敗がないなら、成功への鍵となる要素は何でしょうか?

1. ルールの概要

このプロセスからどんな新しいことを学びましたか?

もし誰かが同じ行動をとったら、私はどんなアドバイスをするでしょうか?

次は何をすればいいでしょうか？

私たちが直接できることは何でしょうか?

2. プロジェクトレビューの段階

プロジェクトには基本的に、目標、要件、設計、開発、テスト、リリースといういくつかの主要な段階が含まれます。各段階の具体的な作業を細分化することによってのみ、各タスクの進行が順調かどうか、どこに問題があるか、そしてそれをどのように最適化すればよいかを分析できます。

プロジェクトレビューのためのちょっとしたヒント：プロジェクト実行タイムラインに従って作業日誌をつけましょう。

毎日書く必要はありませんが、活動プロセス全体を明確に把握できるように、重要な時点ごとに作業記録を残す必要があります。振り返るときは、日記のこの部分にもう一度目を通し、実際の作業のスケジュールをリストアップし、計画で予定したスケジュールと比較し、作業のどの部分が進んでいるか、どの部分が遅れているか、どの部分が一時的に追加されたか、そして完了度合いを確認するだけで済みます。

たとえば、最初のステップはプロジェクトの目標を見直すことです。質の高いプロジェクトには、明確な目標があらかじめ設定されていることがよくあります。目標自体が不合理であれば、見直しから得られる結論に説得力はほとんどありません。そのため、見直しの際には、目標設定の合理性や、そもそもどのような状況で目標が設定されたのかということも考慮することになります。

プロジェクト全体の目標が大きい場合は、目標を細分化し、プロジェクト実施のマイルストーンを決定し、目標の測定とフォローアップを容易にするためにサブ目標または段階的な目標を設定することをお勧めします。電子商取引のイベント計画を例にとると、取引量に影響を与えるサブ目標には、トラフィック、コンバージョン率、平均注文額、再購入率などがあります。

後続の手順は同じです。継続的な分解を通じて、プロジェクト プロセス全体の完全かつ定量化可能な分析が行われ、プロジェクト指標の実際と予想される比較が理解されます。

3. 製品プロジェクトをレビューするにはどうすればよいですか?

レビューの最も重要な 2 つの側面は、過去の解釈とレビューの最適化です。これにより、逸脱の理由を明確にし、的を絞った提案を行うことができます。

1. プロジェクト目標のレビュー

1.1 プロジェクト進捗レビュー

• 配達は当初予定されていた配達時間通りに行われましたか?
• 当初計画された需要ポイントのうち、達成されたものはいくつありますか?どの需要ポイントが計画どおりに満たされなかったのでしょうか?
• 各需要ポイントの遅延の理由は何ですか?
• どのマイルストーンが遅れているのですか、またその理由は何ですか?

1.2 プロジェクト結果のレビュー

• プロジェクト中にどのような予期せぬ出来事が発生しましたか?なぜこのような事故が起こるのでしょうか?
• 新しい機能に対するユーザーの受け入れはプロジェクト計画と一致していますか?

1. 需要フェーズのレビュー

• 完全な需要出力が提供されていますか? プロトタイプ、MRD、PRD、UML などが含まれます。
• 要件はデザイナー、インタラクション デザイナー、開発者にとって明確ですか?要件が不明確な場合、プロジェクトの進行と品質に重大な影響を及ぼします。
• 典型的なユーザーと使用シナリオが明確に説明されていますか?

1. 設計フェーズのレビュー

• ビジュアルデザインの最終レビュー担当者は特定されていますか?
• UI デザインの出力は統一された標準を満たしていますか?
• 設計作業は開発作業の進行に影響しますか?衝撃の原因は何ですか?
• 製品設計作業はいつ、誰が行うのですか?

1. 開発フェーズのレビュー

4.1 プロジェクト期間評価レビュー

• 開発が実施される前に期間を見積もるのに十分な時間がありますか?期間見積りは、一方ではプロジェクトメンバーがプロジェクトの全体的な進行に備えることを可能にし、他方ではプロジェクトの要件を詳細に整理するプロセスです。
• 想定工期と実際の開発期間に差異があるかどうか、また、差異の理由。

4.2 開発文書のレビュー

• 開発ドキュメントはありますか?
• 開発ドキュメントは仕様に準拠していますか?

4.3 緊急事態の検討

• 需要に応えられない状況はありますか？理由は何ですか？
• チームメンバーに変更はありますか？メンバーの変更にはどのように対処しますか?後でそれを避けるにはどうすればいいでしょうか?
• 要件を満たしていない機能モジュールはありますか?理由は何ですか？

1. テストフェーズのレビュー

5.1 テスト計画のレビュー

• 完全かつ正確なテストケースはありますか?
• テスト計画はありますか?このような計画は効果的でしょうか?
• チームは製品開発の有効性をどのようにテストし、追跡しますか?

5.2 テストツールのレビュー

• テストを支援するためにどのようなテスト ツールが使用されましたか?継続して使用できますか？
• テストに十分な時間、人員、ソフトウェア/ハードウェア リソースがありますか?

5.3 テスト結果のレビュー

• どの機能モジュールが最も多くのバグを生成しますか? またその理由は何ですか?
• どのバグがロールバックされましたか? その理由は何ですか? (ロールバック: プログラム バージョンのロールバック。重大なバグが発生すると、プログラムは 1.1 から 1.0 にロールバックされます。反復後、バグがいっぱいになり、修復コストが高くなります)。

1. 立ち上げフェーズのレビュー

6.1 受入レビュー

• 正式なオンライン承認は実施されましたか?
• 正式リリース中に何か問題が発生しましたか?今後これを避けるにはどうすればいいでしょうか?
• オンライン化する前に、運営側やコピーライターと十分にコミュニケーションを取りましたか?
• データ収集ポイントを確認しましたか? それらは運用要件を満たしていますか?

6.2 発売後の効果の検討

• 発売後に大きなバグは発生しましたか? テスト段階で発見されなかったのはなぜですか?
• 製品の発売後の問題に対するフィードバック チャネルはプロセスですか?
• 製品の発売後、どのようなフィードバックが集まりましたか?どんな種類がありますか？どうすれば改善できますか?

すべてのプロジェクトレビューは自己検査と調整です。反復的な製品の場合、3 つのバージョンごとにレビューが行われます。一般的にリリースのペースは1ヶ月に1バージョンなので、3ヶ月のペースでレビューをすることができます。

レビューが完了したら、できるだけ早くレビュー会議を開催する必要があります。これにより、多くのアクティビティの実行詳細とユーザーフィードバックが鮮明に記憶され、レビューの信頼性が比較的高くなります。

彼らは責任を逃れることも自らを卑下することもなく、お互いに率直に問題を分析し、完​​全かつ真実のプロジェクトプロセスを提示するために最善を尽くしました。すべての参加者は平等に発言権を持ち、自分の考えを正直に表現することができます。

時間管理と要点の記録に専念する人が必要です。会議で最悪なのは、目的もなく長くて退屈なことです。各パートの時間を管理することが重要です。また、要点を記録することは会議の結果の一種のアウトプットでもあり、経験を要約して次のステップに進むのに役立ちます。

著者: スティーヴ

出典: スティーヴ