你是否需要知道，报价给你的系统是不是正确的那个？
在资金投入之前，对架构、成本、范围和供应商方案进行评审。独立、具体、落在纸面上。
问题
一份方案到来，带着自信的架构图、一个价格和一份时间表，而必须批准它的人分辨不出它是否正确。供应商没有撒谎，但他们回答的是自己知道怎么回答的问题。常见结果是：一个比问题大三倍的系统，一个恰好在业务增长时变贵的许可模式，或者一个悄悄假设困难部分以后再处理的设计。
我们的做法
我们对照方案本应解决的问题来读它，而不是对照抽象的最佳实践。我们核对数字：用户、数据、吞吐量、五年的成本。我们核对那些没有写下来的假设。哪里有错，我们就说出错在哪里、为什么错，以及应该改要什么。方案好，我们也照实说。价值在于一个清楚的答案，而不在于挑毛病。如果还没有方案，我们就把同样的工作提前一步来做：分析需要构建什么，并写出合同所依据的范围。
实际案例
在第一行代码之前写好的合同
一家公共机构的下属部门，希望把管理其日常工作的应用交给一家由我们担任顾问的广告公司来开发。软件并不是这家广告公司的本行，因此在任何人签字之前，究竟买的是什么、卖的是什么这个问题就来到了我们这里。我们分析了整项工作：该部门需要的每一个模块，其中的角色和审批环节，必须保存的数据，系统运行在哪里，以及上线之后需要支持什么。然后我们把这份分析变成了合同本身：交付什么、如何验收，什么不在范围之内，以及系统上线后谁对什么负责。最终得到的是一份双方都可以据以约束对方的文件。广告公司清楚自己承诺了什么，该部门也清楚自己付钱买的是什么。
你将得到
- 对照您的实际问题和数字，对方案的书面评审；如果还没有方案，则是一份书面的范围
- 一份具体的风险、缺口和未定价假设的清单
- 可以带回给供应商的具体问题和修改要求
- 一份可以据以行动的建议，包括建议按报价原样推进的情况