うまくいくかどうかを知るために、まず存在させなければならないアイデアがありますか？
構想から、実際のユーザーの前に置ける公開済みの初版へ。ウェブアプリケーション、管理パネル、地図ベースの製品、モバイルアプリを、学べるだけ小さく保って作ります。
課題
アイデアはたいてい明確です。明確でないのは、そのどの部分が重要かです。チームは、すべてを一度に作って誰も触っていない製品を遅れて公開するか、あまりに薄いプロトタイプを作ってアイデアではなくプロトタイプそのものへの意見を集めてしまうかのどちらかになりがちです。どちらも、この段階で唯一重要な資源を浪費します。速くて正直な答えです。
取り組み方
初版が答えるべき一つの問いを定め、それに答えるために必要なものだけを作ります。ただし、きちんと作ります。本物のアカウント、本物のデータ、答えがイエスだったときに恥ずかしくないインフラへのデプロイ。それ以外はすべて削るか、公然と仮置きにします。答えが意見ではなく利用実態から出るように製品を計測し、第二版は初版が使われてから初めて計画します。私たちはこのやり方で、最初のコミットから公開された1.0まで、唯一の開発者として製品を出荷してきました。答えがノーだったために、その時点で終わらせた製品もあります。一年かけて作ることに比べれば、安い結末です。
事例
地理情報システム、パネルも地図も含めて
四年間にわたり地理情報製品を作ってきて、この種のプロジェクトがどこで止まるかを学びました。地図は目に見える部分で、製品はその裏のパネルに宿ります。現在進行中のウェブGISでは、ユーザーと役割の管理から地図に供給するワークフローまで、管理パネル全体を私たちだけで構築し、地図上で図形を描き、検索し、編集できる地図操作を実装しました。あるモバイル製品は逆の道をたどりました。三人の共同創業者、一人の開発者、そして実際のユーザーに公開されたバージョン1.0。そのユーザーの行動を根拠に、ほどなく終了しました。それこそが初版の役割です。
納品物
- 初版の文書化された範囲。何を削り、なぜ削ったかを含む
- 本物のアカウント、本物のデータ、利用計測を備えたデプロイ済みの製品
- 最初の数週間を経た後の、平易な言葉で書かれた短い利用レポート
- 文書化され、そのまま引き継げるコードベースとインフラ