未知の分野で短期間で製品を0から1にする方法

過去半月の間に、私は 2 つの新しい製品タスクを引き継ぎましたが、どちらも私にとってあまり馴染みのない分野でした。当初の要求は漠然としたもので、リーダーから伝えられただけのものだったが、何の準備もなく私に届いた。そうは言っても、プロダクトマネージャーがキャリアの中で、厳しいスケジュール、重いタスク、手がかりのなさ、馴染みのない分野を伴う新製品に遭遇する確率は高いです。逆に、教科書通りの製品設計プロセスを全員が最後までスムーズに実行し、最終的に勝利を収めて、全員で祝杯を挙げるというケースはほとんどありません。この記事が同じ問題に直面している友人の役に立つことを願っています。 3つのキーワード：短時間、未知、0対1 1. ニーズを理解する 「○○さんがこんな商品を作りたいそうです。ちょっと見て整理してください。あと数日後に資料を持ってきて連絡してください。」聞き覚えがありますか?はい、特にユーザーが大企業や機関であり、最初は直接コミュニケーションを取るのが不便な場合は、そのようないわゆる「需要」に遭遇する可能性があります。今回も例外ではありませんでした。この2つの新製品のうち1つはリーダーから直接口頭で伝えられ、もう1つはマーケティングスタッフが疑問符だらけの業務マニュアルを読んでから転送してきたものでした。時間制限が厳しいため、研究に十分な時間を残すことは不可能ですが、それでも、情報源から次の 3 つの最も基本的な質問を理解することは必要です。 1. ユーザーは誰ですか? 2. どのような問題を解決したいですか? 3. コアシナリオ 次に、検索プラットフォームまたはアプリマーケットのキーワードに基づいて類似製品を除外します。新しい需要や新製品の場合、95% 以上の製品にはすでに類似製品が存在するため、通常は車輪の再発明は必要ありません (ただし、国有企業内のカスタマイズされた製品など例外もあり、少なくともインターネット上では同様のプラットフォームはまれです)。典型的な機能、ページ、プロセスなどに関する断片的な情報を素早く収集し (私は OneNote の使用に慣れています)、広範囲に網を張り、ふるいにかけた後、最も代表的な同質製品を 10 個以下選択し、ターゲットを絞った詳細な分類を開始する準備をします。詳細分析プロセスでは、頻繁に出現するモジュールと機能ポイントをすばやくリストします。これは全体の概要を説明する段階に過ぎないため、まだ個別に分類しないでください。まず、おおよその機能範囲を定義する必要があります。 2. 製品構造を整理する これは一般に「製品機能フレームワーク」の構築として知られています。私は個人的に、マインドマッピングまたは Execl、あるいはその両方を使用して、製品のコアモジュールと機能ポイントを分類および整理し、予備的な製品概要を作成します。注意すべき点が 2 つあります。 1. 高頻度使用シナリオ機能をキャプチャする 2. コアユーザーグループの視点から このプロセスは、家を建てるときに杭を打つようなものです。最初のポイントは、基礎の中心となる杭を見つけるのと似ていて、簡単に理解できます。シナリオ分析は、製品の価値を直接決定する、製品マネージャーの考え方であると同時に、設計プロセスに不可欠なものです。製品に複数のユーザーロールがある場合は、2 番目のポイントを考慮する必要があります。例えば、商品が不動産コミュニティの場合、商品構成を整理する際には、オーナークライアント→不動産クライアント→不動産管理背景の順にニーズを整理します。次に、これらのユーザーグループの視点から、最も緊急に解決したい問題は何かを検討し、それらの問題を 1 つずつ解決できる機能ポイントにマッピングします。これは、大きく幅広い問題を小さく正確な機能ポイントに変換する、大まかに言えばツリー構造の考え方です。ちなみに、モバイル製品を整理する際には、管理バックエンドも同時に設計する必要があることがよくあります。バックエンドの設計は通常、フロントエンドが基本的に完成した後に開始されます。理由は簡単です。バックエンドはフロントエンドにサービスを提供して、フロントエンドによって表示されるコンテンツに応じて、バックエンドが出力するデータの種類が決定されます。そのため、管理バックグラウンドは通常、さまざまな種類のデータの集約と分類、ビジネスフローの処理、権限ロール、データ辞書などのサポート機能で構成されます。また、製品構造ドキュメントとしてマインドマップや EXECL が選ばれる理由は、言葉は表ほど優れておらず、表は画像ほど優れていないからです。視覚的なコンテンツは人々に比較的受け入れられやすいものです。最初の製品出力では、表現に役立たず、その後のコミュニケーションや調整に不便となるため、長いテキストを多用しないようにしてください。 3. ユーザーと話し合い、細かい調整を行う このように、短期間（3日、24時間未満）で、基本的にはそれほど大げさではない製品構造図を作成することができます。同時に、前の2つのステップを通じて、製品の使用シナリオと典型的な機能を基本的に理解することができます。しかし、これはあくまでも「形が似ている」というだけであり、本当に使えるものにするためには、最も根本的な需要元とコミュニケーションをとり、確認し、常に修正、調整、改良を重ねていく必要があります。製品 A のユーザーと直接コミュニケーションをとったところ、彼らはこのプラットフォームを包括的かつプロフェッショナルな建設管理プラットフォームとして位置付けていることがわかりました。市場関係者が報告したプラットフォームの規模とは大きな乖離があります。同時に、相手側も、多くの機能が欲しいが、現時点で緊急に必要なのはいくつかのモジュールだけだと説明しました。これを基に、製品成形工程における実施優先順位が大まかに明確化されます。製品 B の発起者は情報サービスプロバイダーです。担当者のパートナーは、この分野で 1 年近く調査とデータ収集を行ってきました。これは、当社が「当たり前」の道にどんどん迷い込まないように、製品を改善し、実用性を高めるための重要な参考資料となります。ユーザーのニーズについてコミュニケーションをとったり、調査を実施したりするときは、たとえその時点では表面的なものであっても、まずは自分のアイデアを持ち込むのが最善です。時間が許せば、2 つ以上の解決策を用意してください。記述式の質問よりも、選択式の質問の方が答えやすく、問題に集中しやすくなります。 4. 製品の設計、コミュニケーション、調整 ユーザーとの対面コミュニケーションから得た重要な情報を基に、以前の製品構造図を調整し、機能リストを洗練させ、最もよく使用されるコア機能ページから製品のプロトタイプの作成を開始します（フローチャートなど、初期段階のさまざまなサポート作業については詳しく説明しません）。たとえば、製品階層が 4、5、6、7 レベルの場合、これらのサブレベルページのコンテンツについては気にする必要はありません。まず、ユーザーの前に頻繁に表示されるページを設計します。ボタンの外観、配置場所、スライドジェスチャなどの詳細についてはあまり心配しないでください (これは、あまり時間をかけないという意味であり、まったく考慮する必要がないという意味ではありません)。家にどのような窓を設置するかを検討する前に、必ずしっかりとした基礎を築く必要があります。主要なプロトタイプ図面を数ページ素早く作成したら、要求側に確認します。承認された場合は、これに基づいて改良を続けます。その後、コミュニケーションを取り、調整し、また改良し……商品ページのプロトタイプを一つずつ改良し、枝分かれさせていきます。これは、外側から内側へ、浅いところから深いところへという反復的なプロセスです。 5. 出力バージョン1.0 独自の PRD を作成するということは、実際には Axure を使用して、ページジャンプなどのインタラクションを追加せずに、プロトタイプに対応するインタラクション指示、機能注釈、さまざまなルールなどを記述し、ページ階層に従ってプロトタイプディレクトリに名前を付けることを意味します。まず、アニメーションを追加するには多くの時間が必要であり、その後の変更で消費されるエネルギーは指数関数的に大きくなります。次に、開発者はどのボタンにインタラクティブなアクションがあるかわからないことが多く、ボタンを 1 つずつクリックするように要求するのは非現実的です。契約締結を伴う場合は、契約書類の一つとして要件仕様書のWORD版も作成します。実際の製品開発プロセスでは、プログラマーは当然プロトタイプを見ることを好みます (実際、UI レンダリングを見ることを好む可能性が高くなります)。プロダクトマネージャーにとってドキュメントを書くのは難しいとは思わないでください。実際、読者にとっても難しいのです... プロダクトマネージャーがPRDを出力した後、要件レビュー会議が開催されます。レビュー会議後、会議で議論された意見に基づいて要件が修正され、SVNにアップロードされ、このバージョンの要件がプラットフォーム上に公開されます。その後、プロジェクトマネージャーは要件を具体的なタスクに変換して各メンバーに割り当て、技術的な詳細を管理します。現在チームが使用しているプロジェクト管理プラットフォームはZENTAOです（以前はJIRAなどを使用していました）。小規模チームにも適した、クロスプラットフォームで軽量なタスク管理ソフトウェアは数多くあります。製品のバージョン 1.0 は通常、単なるデモであり、ユーザー側とチーム内で小規模に試用する必要があります。その後、PRD の修正、開発、テスト、バージョンのリリースが何度も繰り返され、製品の実際の外観が概説されます。 話題から外れた発言 まず、上記の製品プロセスは決して標準的な「0 から 1 へ」のテンプレートではないことを指摘しておく必要があります。何が標準とみなされますか?この本では、一般的に次のように説明されています。まず、需要調査、実現可能性レポート、プロジェクトキックオフミーティング、需要分析、製品設計、UI/UE設計、テストケース、研究開発などが行われます。しかし、多くの場合、理想化されたプロセスでは道路の様子が説明されるだけで、道路にいくつの穴があるかはわかりません。たくさんの本やチュートリアルを読み、熱意で顔を赤くした後、明日は次のようなタスクを与えられるかもしれません。「なあ、市場では大口顧客がXXシステムを作りたいって言ってるんだ。早く製品企画書を設計しろよ！あ、そういえば明日必要だわ」（笑顔で両手を広げて）まあ、私は多くの真実を聞いてきましたが、それでも良い人生を送ることはできません。企業チームによって運用モデルは大きく異なり、遭遇する製品形態はさらに奇妙です。「エマ、あなたの製品プロセスは間違っています！」と言う必要はありません。正しいことはすべて教科書に載っています。製品の場合、方法のみがあり、答えはないので、決まりきった製品開発方法はありません。私たちは、将来同じ問題に遭遇したときに再び陥らないようにするために、数多くの設計プロセス、考え方、実際の操作、さまざまな原則や教訓を学びました。もちろん、これは学習が無駄だということではありません。結局のところ、判断力を学べば間違いは少なくなります。間違いが少なければ少ないほど、成功に近づくでしょう。

モバイルアプリケーション製品プロモーションサービス： APPプロモーションサービス清瓜メディア情報フロー

この記事は@柯临由(APP Top Promotion)が編集・公開したものです。転載の際は著者情報と出典を明記してください。

<<: 2020年の修士課程入学者数の拡大は何を意味するのでしょうか？拡大の理由は何ですか?関連するポリシーを添付します。

>>: 不動産市場では4つの大きな現象が起きている。2020年の住宅価格下落は必然なのか？ 2020年の全国住宅価格動向に関する新情報