実際に出せる初回リリースのスコープの決め方
たいていの初版が遅れるのは、チームの速度ではなく、そこに何を入れたかのせいです。私たちが使う削り方と、決して削るべきでない三つのもの。
八か月かかった初版は、チームが遅かったせいであることはめったにありません。ほぼ必ず、最初から生き残れないスコープが、削ることが悲観に見える部屋で合意されたせいです。
スコープを決めるのは技能であり、その大半は「全員がまだ楽観的なうちに、何をつくらないかを決める」技能です。
ひとつのループから始める
どのプロダクトにも中核のループがあります。ユーザーが繰り返し、価値を届ける一連の動作です。辞書なら検索し、読み、理解する。マーケットプレイスなら出品し、発見し、取引する。
自分のループを一文で書いてください。そのうえで、提案されたすべての機能を二つの山に分けます。ループが成立するのに必須のものと、それ以外すべて。
二つ目の山は、たいてい想定の四、五倍あり、そこにスケジュールが消えています。それらの機能が悪いからではなく、どれも構造を支えていないのに、どれも日程に入っていたからです。
「MVP」はもう意味を持たない
この語はいま、相容れない二つを覆っています。意図的に小さく、しかし一つの仕事で本当に良いプロダクト。そして広いが雑につくられたプロダクト。多くのチームが実際に出すのは後者で、それが失敗するのは、ユーザーは狭いプロダクトを許しても、壊れたプロダクトは許さないからです。
より使える言い方は狭く、そして完成しているです。数は少なく、それぞれをきちんと、エラー状態と空状態まで含めて。一つの仕事を最後までやる初版は、次のリリースの資格を得ます。八つの仕事を 60% でやる初版は得ません。
削るのはスコープであって、品質ではありません。品質を削ると計画書では見えず、ユーザーには非常によく見えます。
たいてい削ってよいもの
必須に見えて、ほぼ常に待てるもの：
- アカウント。価値がそれなしで成立するなら。 登録は多くのファネルで最大の離脱点です。まず使わせて、保存する価値のある状態ができてから足しましょう。
- 管理画面。 あなたはユーザーではありません。データベースクライアントかスクリプトで数か月はもちます。
- 設定項目。 設定ひとつは、実装もテストも要る分岐です。妥当な既定値を選び、要望が出たらトグルを足しましょう。
- オンボーディング。 ツアーはたいてい、わかりにくい画面への絆創膏です。まず画面を直しましょう。
- 二つ目のプラットフォーム。 Web のあとモバイル、あるいは片方のモバイル OS のあとにもう片方。同時にやると作業量は倍以上になり、フィードバックの速度は半分になります。
- 多言語対応。 特定の市場がローンチ市場である場合を除いて。形が変わり続けるプロダクトの翻訳は、翻訳し直しを意味します。
削ってはいけない三つ
これらを削るのは速度に見えて、高金利の負債です。
1. うまくいかない経路
エラー状態、空状態、ローディング、オフライン。作業量のおよそ五分の一で、体感品質の大半です。失敗を上品に扱うプロダクトは、小さくても堅実に感じられます。問題が起きると白い画面になるプロダクトは、順調な経路がどれだけ良くても壊れて感じられます。
2. 計測
解析なしで出すと、初版は何も教えてくれません。どこが使われ、どこで人が止まり、ループが閉じているかがわかりません。データウェアハウスは要りません。中核ループが完了するか、どこで切れるかがわかれば十分です。
3. すばやくデプロイできること
修正を出すのに手作業で一日かかるなら、修正を出す回数は減ります。そしてローンチ直後の数週間こそ、修正がいちばん効く時期です。基本的なパイプラインは数日の作業で、最初の二週間で元が取れます。
レイヤーではなくユーザー体験で切る
最も多い計画ミスは水平に作ることです。データモデルを全部、次に API を全部、次に画面を全部。すべてが動くまで何も動かず、最後まで何も学べません。
代わりに垂直に切ってください。薄くても本物の経路を端から端まで一本つくり、それから広げる。二週目には触れるものができます。それは「プロダクトを想像する」会話を「それに反応する」会話に変え、有用なフィードバックは後者にあります。
現実的な形
絞り込んだ初回リリースなら、おおよそ：
| フェーズ | 期間 | 成果物 |
|---|---|---|
| ディスカバリー | 1〜3 週 | ループ・スコープ・リスクの合意、クリッカブルプロトタイプ |
| 開発 | 6〜12 週 | 2 週サイクル、各サイクルで動くソフトウェア |
| ローンチ | 1〜2 週 | ストア審査、監視、注視した最初の一週間 |
狭く完成したもので合計 8〜16 週。広いものを 6 週でと書いてある計画なら、間違っているのは見積もりではなくスコープです。
削ったものを書き留める
コストゼロで、繰り返す議論を防ぐ習慣：「v1 に入れないもの」の一覧を明示的に、全員に見える形で、各項目に一行の理由をつけて保つこと。
これは「忘れていた」を「決めた」に変え、同じ機能が毎月蒸し返されるのを止め、そしてそのまま v2 のバックログになります。しかも、文脈がいちばん揃っていたときの議論で並び替え済みの状態で。
良いスコープの検査
二つの質問。両方に「はい」が必要です。
- これだけつくったら、誰か使いますか。 いいえなら、構造を支えるものを削っています。
- いまある時間で、うまくいかない経路まで含めてきちんとつくれますか。 いいえなら、もっと削ってください。
たいていの計画は二つ目で落ちますが、10 週目まで誰もそれを口にしません。