Fissionイベント企画・プロモーション企画！

要件を検討する際、私たちは皆、自分たちが設計した機能が上司から賞賛され、同僚から認められることを望みます。しかし、製品を設計するときに自分の考えが明確でなければ、説得力がなく、他の人の質問に困惑してしまう可能性があります。ここで、核分裂活動の機能を計画する際の私自身の経験を皆さんと共有したいと思います。

1. プロジェクトの背景と目的を決定する

入社後最初に担当したプロジェクトは、パブリッククラスの分裂関数の設計でした。

特定のプロジェクトを取得した後、最初に知っておく必要があるのは、なぜそのようなプロジェクトを立ち上げるべきかということです。プロジェクトの背景と目的は何ですか?

このプロジェクトの背景は、同社の現在のトラフィック獲得コストが非常に高く、製品の成長がボトルネックになっていることです。会社のトラフィック獲得コストを削減するために、この製品バージョンの反復に小さな分裂機能を追加する必要があります。プロジェクトの目標は、核分裂名刺の数を増やすことです。

2. 目標を細分化して明確にする

目標を細分化することで、不明確なタスクが明確になり、物事を行う際により多くのアイデアと方向性が得られます。

図: プロジェクト目標の内訳

プロジェクトの目標を細分化した結果から判断すると、共有者の数、共有頻度、共有先の人数、コンバージョン率などは、いずれも設計の出発点や意思決定の要素として活用できます。シナリオを整理する過程では、これらの出発点に着目する必要があります。

3. 核分裂シナリオを整理し、機会を探す

実際のビジネスシーンにおけるトラフィック変換プロセスの詳細を整理した後、調査事実に基づいて対応するシナリオと共有者のニーズをブレインストーミングし、ニーズの優先順位をランク付けし、詳細な設計のために最も優先度の高いニーズを選択する必要があります。

今回、主にトライアルコース受講者などの新規ユーザーの分裂に焦点を当てた理由は、以下の2つです。

1. 同社には現在、このタイプのユーザーが多数存在しますが、十分に活用できていません。
2. 販売前の現地調査は実施しましたが、販売後の現地調査はまだ実施していないため、体験クラスを受講した生徒と正規料金のクラスに事前登録した生徒についてはある程度把握していますが、正規料金のクラスの生徒の授業プロセスについては完全には把握していません。

共有シナリオは次のようにまとめられます。

図: 核分裂シナリオを整理するための思考ガイド

図では、ユーザーシナリオ需要機会ポイントに従ってブランチが分類され、整理されています。まず、考えを発散させ続け、以前のアイデアを急いで否定しないでください。次のステップは、整理して収束することです。核分裂シナリオの機会ポイントは赤でマークされています。

4. 優先順位をつけて最初に行うシーンを選択する

イベント共有者の視点からシナリオを整理した後、特定のニーズの優先順位付けを開始します。優先順位付けの方法は、次の側面から始まります。

• 需要の頻度と共有する人数。
• 開発の難しさと効果
• 意欲の強さを共有する。

次元比率スコア: 1 ～ 5 ポイント、各次元スコア: 1 ～ 5 ポイント。

合計スコア = 次元比率スコア * 各次元のスコア。

最後に、結果を参照して、どのシナリオを最初に実行するかを検討します。

結果は次のように直感的な表にまとめられます。

表を完成すると、比較的客観的な評価基準が得られました。

実際、ここで厳密な表をリストすることの利点は、要件を確認するときに、なぜこの要件を最初に行うことを選択したかを理由と論理で説明できるため、より説得力があることです。ただし、表の優先順位に完全に従う必要はなく、実際の状況に基づいてシナリオを選別する必要があります。

最後に、最初のバージョンを「1 つ買うと 1 つ無料」プロモーションの対象に選びました。つまり、有料のオープン コースを購入したユーザーは、それを友人に無料で提供できる機会が得られます。一般的に言えば、このアクティビティ シナリオは最大数の参加者を対象としています。最初は完璧さを求めないでください。効果をテストするためのアクティビティをすぐに開始し、その後、将来的にセグメント化された各シナリオをカバーするようにアクティビティを徐々に拡張します。

5. フローチャートとプロトタイプ

1. フローチャート

設計する特定のシナリオを選択した後、フローチャートの描画は最も重要であり、省略してはなりません。フローチャートが整理されて初めて、その後の試作や需要検討が容易になるからです。また、フローチャートを使用すると、参加者はビジネスの仕組みを明確に理解できます。

フローチャートを描く前に、次の要素を整理する必要があります。

• ユーザー: 何種類のユーザーが参加しますか?システムは参加者として機能することもできます。
• タスク: これらのユーザーが達成したいことは何ですか?
• データ: このプロセスではデータはどのように流れますか?
• 特別ステータス: 問題が発生した場合はどうすればよいですか?

図:フローチャート

実際のところ、どのフローチャートを表示するかについては、あまり決まったルールはありません。実際のプロジェクトに基づいて判断する必要があります。たとえば、現在取り組んでいる分裂ツールの場合、分裂したトラフィックをどのように保存するか、販売前にどのようにフォローアップするかが、プロセスにおける重要な考慮事項です。しかし、電子商取引製品の場合は、さまざまな特殊な状況にどのように対処するかについて、さらに検討する必要があります。

フローチャートの最終的な目標は、この目標が達成される限り、開発者とのより良いコミュニケーションを可能にすることです。

2. プロトタイプ

フローチャートがスムーズに整理されると、プロトタイプ図は非常にシンプルになります。フローチャート内でプロトタイプ化する必要のあるページの数を具体的に数えます。フローチャートは、ビジネス プロセスと一致し、ページ構造が明確で、インターフェイスが統一されている必要があります。

ここではプロトタイプ設計の詳細についてはあまり詳しく説明しません。この記事の焦点は、新製品の機能設計の基本的なプロセス ルーチンにあります。

6. PRD文書

フローチャートとプロトタイプ図が完成したら、それらを PRD ドキュメントに書き込む必要があります。

PRD ドキュメントは製品要件ドキュメントであり、主に技術者が読むためのドキュメントです。技術者は、製品の視覚的な設計と開発のためにこのドキュメントを参照する必要があります。したがって、PRD ドキュメントの最も核となる部分は機能部分の説明であり、さまざまな異常な状況と製品の詳細を考慮する必要があります。考慮すればするほど、開発はより速く、より高品質になります。

ドキュメントは各企業やチームの状況によって若干異なります。ただし、一般的に、完全な PRD ドキュメントには通常、次の部分が含まれます。

• 需要紹介（需要背景、製品特徴）
• 機能詳細（製品機能構造図、業務プロセス図、ページフロー図、主要機能の説明）
• パフォーマンス要件。
• 製品運用計画。

前述したように、機能詳細の説明は PRD ドキュメントの中核であり、最も大きな部分を占めます。非常にシンプルな審査基準は単語数です。単語の数が増えれば増えるほど、考慮しなければならない状況も増えます。ここでは、次のタイプの説明をまとめます。

1. 値の選択ルール: つまり、製品のフロントエンドのフィールドは対応するフィールドを取得します。
2. 制限: 表示範囲、制限値、形式、並べ替えなど。
3. ステータス: デフォルト ステータス、共通ステータス、特別ステータス。
4. 操作: 一般的な操作、特殊な操作、誤った操作。
5. フィードバック: プロンプト、ジャンプ、インタラクションなどを含む。

要件ドキュメントの作成を初めて開始すると、常にすべての点を考慮しておらず、作成したドキュメントがすべての関係者から批判されることがよくあることに気付くでしょう。これは非常に一般的な状況です。このような状況に遭遇しても落胆しないでください。これは試行錯誤を続け、急速に成長するためのチャンスだからです。すべての関係者の意見に耳を傾け、自分自身で新しいレビュー文書を作成し、すべての問題をタイムリーに書き留めて、次回同じ問題を回避するようにしてください。

初めて書いたレビュー文書は本当に問題が多いことがわかりますね〜でも、成長するためにはこのプロセスを通過する必要があります〜

図: 私のレビュー文書

VII. 結論

新人として、私は新製品開発者が初めてその仕事を任されたときに感じる混乱を十分に理解できます。

この時、すぐに仕事を始めてはいけません。自分の考えを整理し、段階的な計画をリストアップし、頭の中で物事を行うための枠組みを作り、この枠組みを常に振り返り、要約し、最適化する必要があります。このようにしてのみ、効率がどんどん上がっていきます。

著者: キティ・ウェン

出典: 小猫文