プロダクトの基礎 · 入門
作らないものを選ぶ
一行でいうと: 「ノー」と言える力こそが、出荷されたプロダクトと永遠に開発中のプロダクトを分ける。
なぜこれほど難しいのか
個々のリクエストは単独では合理的に聞こえる。問題は単一の機能ではなく積み重ねだ。追加のたびに、保守すべきコード、学ぶべき画面、そして半年後に他の何かを壊すエッジケースが生まれる。機能のコストは開発の一週間ではなく、その後の全ての年月である。
三つのフィルター問い
誰が要求したか。声の大きな一人の顧客は市場ではない。一週間で何人のユーザーがこれに触るかを聞け。
なくてどうなるか。答えが「少し不便」なら、最初のバージョンには入れない。
何を置き換えるか。タスクリストの長さが固定なら、何かを入れるには何かを出す必要がある。「これも追加しよう」より健全な会話だ。
断り方
「ノー」は理由と場所を伴う。「このバージョンではやらない。追っている指標はハンドリング時間であり、これはそれに影響しない。最初の計測の後で再検討する。」優先順位を理解した人は議論をやめる。
却下リストを見える場所に置け。繰り返しの質問を防ぎ、時間が空いたときの最初の参照先になる。
さらに深く
完璧に動く十の機能を持って出荷されたプロダクトは、四十の凡庸な機能を持つプロダクトに勝る。コードでも同じだ:論理の分岐はテストすべきパスを増やす。スコープを削ることはビジネスの決断だけでなく、最も安いアーキテクチャの決断でもある。