統計によると、平均的な製品の機能の約50％が使用されることはなく、顧客が積極的に使用するオプションはわずか12％です。 これらの12％の機能に常に陥る方法は？ しかし、私自身がこの製品のユーザーではない場合はどうなりますか？ 製品をシンプルで便利にする方法は？ 最後に、私たちの会社はやる価値がありますか？ また、製品が作成される前に市場で需要があるかどうかをどのように理解しますか？
昨日だけすべてが起こったかのように、私はこの日を覚えています。 2014年1月27日月曜日、私は偶然「Spotifyが製品を構築する方法」というドキュメントに偶然出会った。 この小さなマニュアルは、過去3年間の開発、数十件の記事、私の頭の中のよく組織化されたシステムでのいくつかのトレーニングを定めたものです。 マニュアルの全プロセスの図は、投稿タイトルに記載されています。
最短時間で、Spotifyの方法論に従ってプロセスと開発のアプローチを再構築しました。 詳細についてはこちらをご覧ください 。 ちなみに、このドキュメントでは言及していませんが、2番目の重要なステップは共感です（このコンテキストでは、顧客とその問題を深く理解します）。 自分が製品のユーザーでない場合、共感はまさにあなたがする必要があることです。 当初、私たちは私たちが突くつもりだった主題領域で何も理解していませんでした。
そして最後に、Think ITの最初のステップに進みます
- まず第一に、私たち自身がこれらの重要な質問に答えました：なぜこれをしているのですか？ このベンチャーからどのような利益が欲しいですか？ 他の10の製品ではなく、なぜそれだけを行うのでしょうか？
- 次に、当社の製品がお客様のために改善する主要な指標を策定しました。
- また、製品仮説（実際の顧客でテストされる仮定）を策定しました。 主に2つの仮説があります。クライアントの製品価値仮説と成長仮説（この製品の配布方法）です。
すべての準備が整ったら、チーム全体をブレインストーミングしました。 アイデア、たくさんのアイデア、たくさんのアイデアが必要でした。 私たちはそれぞれ、自分自身をバイヤー、管理者、それらとして想像していました。 スペシャリスト。 スクリプトを思いついて、ステッカーにアイデアを書き、さまざまな基準に従ってグループ化しました。 結果は次のとおりです。
その結果、私はライブクライアントとのみコミュニケーションを取りましたが、この段階で既にチーム全体が主題領域に深く没頭していました。
次のステップはプロトタイピングでした。 これは特別な訓練を受けた人ではなく、チームの各メンバーが行いました。 利便性を高めるために、ペーパープロトタイピング用のテンプレートを印刷し（投稿の最後を参照）、3つの標準シナリオを説明しました：バイヤーは製品を選択し、他の顧客のレビューに精通し、店員はレビューをモデレートし、技術スペシャリストはシステムをサイトにインストールします
さらに、私たちはそれぞれ彼のプロトタイプについて話し、最高のソリューションと興味深いアイデアに注目しました。 最終的に、シナリオごとに、すべての人のレイアウトから組み立てられたフランケンシュタインのプロトタイプを入手しました。 鉛筆でさらに30分、紙の試作品の最終バージョンがありました。
理想的には、これらのプロトタイプをクライアントに提供し、この資料を試してもらう必要があります。 この手順をスキップして、すぐにモックアップを作成することにしました。 この目的のために、Bootstrapでテーマを20ドルで購入し、数時間で素敵なモックアップを作成しました。
わずか数時間で、モックアップで存在しない製品のプレゼンテーションが行われ、複数の顧客に送られました。 質問の後：「いつ購入できますか？」および「いくらですか？」-少なくともライブプロトタイプを作成する必要があることが明らかになりました。
合計で、私たちは共感とIT思考のフェーズに約1.5か月を費やしました。 この作業は、会社の中核事業と並行して実施されました。 私は自信を持ってこの時間を過ごしたと言うことができます。 主要な質問に答え、主題分野を掘り下げ、MVPの機能セットを定義し、プロトタイプを準備し、アイデア自体をテストし、15人以上のベータテスターを見つけました。
今何 コーディングを始めましょう（Build IT）！
紙のプロトタイプは優れていますが、開発者に適した形式で発行する必要があります。 私たちはスクラムに取り組んでいるので、最初にやらなければならないことは、プロトタイプからStoryMapを作成することでした。 これを行うために、フリップチャートシートを壁に接着し、紙のプロトタイプを上に貼り付けました。 次に、これらのプロトタイプを目標（青いシート）に、目標をタスク（オレンジシート）に、タスクを最も単純な実装（グリーンシート）に、そして最も単純な実装に機能（黄色のシート）を追加しました。
私たちは初めてチームとしてこれを行い、多くの疑問が生じました。 MVPを行う場合、成長のために製品のプロトタイプ（および、それに応じてStoryMap）を作成する必要がありますか、それともMVPにほぼ入るのに十分ですか？ Tuskyと機能自体をどのくらい詳しく説明する必要がありますか？ 結果のStoryMapをリリースに分割し、リリースを反復する方法は？
本日、4回目のイテレーションを開始し、上記の質問に対する最初の見解が少し変更されました。
1. MVPには、次のオプションのみが含まれています。
- 仮説の検証を許可します。
- その必要性については100％確信しています（クールなアイデアがありましたが、現在の段階ではそれらが機能するかどうかは明確ではありません）。
- それなしでは、製品を使用することは単に不可能であり、パラグラフ1には含まれていません。
2.上の写真を見ると、顧客向けの最初のリリースには、ほぼすべてのタスク（オレンジシート）が含まれています。 私たちのリリースは非常に「フラット」で、非常に広く伸びていました。 このアプローチでは、次の欠点がありました。
- より多くの機会を提供できますが、それらは非常に不便で制限されます。
- 最大のタスクをカバーするために、実際の顧客が製品を使用し始める瞬間を大幅に遅らせます。これは、顧客にとってオプションが不要になるリスクがあることを意味します。
3.クレーム2のリスクを回避し、顧客にすでに機能する製品（まだMVPではない）をできるだけ早く提供するために、リリースの幅を減らし、「深さ」をわずかに増やしました。 はい、ユーザー向けの最初のリリースでは、すべての仮説をテストすることはできませんが、このアプローチの利点ははるかに大きいです！
IT構築ステップ自体の図を以下に示します。 実際、今後1.5か月間に、MVPに近づき、各反復でオープンベータテストを実施します。 私たちの場合、Ship ITステージがライブユーザーを開始するのを待っていません。 Alphaテスターは、すでにITの構築段階にある製品を使用します。
ところで、Think ITステージで説明したすべてのアイデアを別のIdeaLogドキュメントに転送しました。 このドキュメントは.xlsファイルです。最初のページには製品/モジュールのリスト（たとえば、承認、検索など）が含まれ、2番目のページにはJobStory形式のアイデアが含まれています（便利なリンクを参照）。 各アイデアには、作成者、日付、タイプ（JobStory、Epic、Theme）、および参照する製品/モジュールがあります。 このフォームでは、新製品に関するすべてのアイデアを簡単に選択できます。 または、新製品のアイデアを選択します。
おわりに
スクラムを導入したとき、開発速度が大幅に向上しました。 そして、私たちが新しいブタを立てる前に、「私たちはその速度でどんな種類のがらくたをしているのですか？」 このアプローチにより、量を品質に変換することができました。 私たちはまだ始まったばかりですが、結果は驚くべきものです！ 私たちの経験があなたのお役に立てば幸いです。 コメントで質問や個人的なアドバイスをうれしく思います。
トピックに関する役立つリンク：