提案されたシステムが本当に正しいものか、知る必要がありますか？
資金を投じる前の、アーキテクチャ、コスト、範囲、ベンダー提案のレビュー。独立した立場で、具体的に、文書の形で。
課題
自信に満ちたアーキテクチャ図、価格、スケジュールを添えた提案が届き、承認すべき人たちはそれが正しいかどうか判断できません。ベンダーは嘘をついていませんが、自分が答えられる問いに答えているだけです。よくある結果は、課題の3倍の規模のシステム、事業が成長した途端に高くなるライセンスモデル、難しい部分は後で対処すると暗黙に前提する設計です。
取り組み方
提案を、抽象的なベストプラクティスに照らすのではなく、それが解決すべき問題に照らして読みます。数字を確認します。ユーザー数、データ、スループット、五年間のコスト。書かれていない前提を確認します。何かが間違っていれば、何がなぜ間違っていて、代わりに何を求めるべきかを伝えます。提案が良ければ、それも伝えます。価値は欠点探しではなく、明確な答えにあります。まだ提案が存在しない場合は、同じ仕事を一歩手前で行います。何を構築すべきかを分析し、契約の土台となる範囲を文書にします。
事例
最初の一行のコードより先に書かれた契約
ある公的機関の部局は、日々の業務を管理するアプリケーションを、私たちが顧問を務める広告代理店に作らせたいと考えていました。ソフトウェアは代理店の本業ではなかったため、誰かが署名する前に、正確には何が売られ何が買われるのかという問いが私たちのもとに届きました。私たちは仕事の全体を分析しました。部局が必要とするすべてのモジュール、その中の役割と承認の手順、保持すべきデータ、どこで稼働させるか、そして公開後に何をサポートしなければならないか。次に、その分析を契約そのものに変えました。何を納品し、どう検収するか、何が範囲外か、システムの稼働後に誰が何に責任を負うか。できあがったのは、双方が互いに拠り所にできる文書でした。代理店は自分が何を約束しているのかを知り、部局は何に対して支払うのかを知っていました。
納品物
- 実際の課題と数字に照らした提案の文書レビュー。提案がまだない場合は、文書化された範囲
- 具体的なリスク、欠落、価格付けされていない前提の一覧
- ベンダーに持ち帰るための具体的な質問と変更点
- 行動に移せる推奨。提案どおり進めるべきという結論も含めて