本节书摘来自华章计算机《需求设计：构建用户想要和需要的产品》一书中的第3章，第3.4节,作者： [英] 克里斯·布里顿（Chris Britton） 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.4 成本估算问题
IT项目，尤其是大型IT项目，可能会面临一个比较严重的问题，那就是项目的时间会超过预定的工期、开销也会突破预算，而且超出的幅度通常还比较大。有可能正是这个原因，所以业务经理对IT应用程序的开发工作所发的脾气，要比对其他事情更大。说得直白一些，要想把重要的业务决策做好，就必须知道各种方案所花的成本。
当前的IT界在估算项目所要投入的精力时，一般的做法是采用功能点（function point）机制。这套估算机制的基本思路，是选取一个工作单元，计算用户输入的次数、输出给用户的次数，以及与外部数据源有关的输入和输出次数（换句话说，就是要统计读取及更新数据库表格的次数，或是读取及写入其他文件的次数），然后把统计结果乘以一个系数，该系数是根据工作单元的复杂程度合理推测而来的。有两份资料[17, 18]提供了一些数据，可以帮我们大概了解从前的一些项目究竟花了多长时间来实现。此外，各个IT组织也都应该对自己从前做过的项目有所统计，从而可以判断出其他项目所表现出来的平均记录，与本组织的情况是否相符。
现在假设你要开始做一个项目，并且在心中对其成本与完成时间已经有了猜测。那么根据笔者的经验来看，在目前这个时间点上，项目的开发成本看上去似乎不会太高。等到做了情境设计，你才会意识到业务的复杂程度，进而会对项目的成本和时间有着更高的估值。你总是会在设计的过程中感觉这个项目越来越复杂，而不是越来越简单，之所以会这样，可能是因为有很多复杂的问题都潜藏在对错误和偶发事件的处理之中，而这些处理事项会在你深入思考应用程序的过程中逐渐变得明确。与其他设计方式相比，我认为从情境设计之中更容易估算出功能点的数量，此外，如果我们还对情境设计已经做了一致性与完备性的分析，那么与其他设计方式相比，我们更有机会发现设计之中的各种复杂问题。因此，我们可以从情境设计之中，初步估算实现项目所需的精力，并且认为它会随着情境设计的大小而增长。
情境设计可以帮助我们很好地对项目做出估计，然而有了用户界面设计与数据设计之后，我们还能估算得更为准确。这样估算出来的结果，与单单通过情境设计所估算的结果相比，不会有太大差距，顶多就是几个百分点的出入。
有一篇名为Software Estimating Rules of Thumb的文章[19]，我们通过那篇文章之中的表格，可以看到应用程序的代码总行数，与开发每一行代码所需的平均时间之间的关系。对于大型项目来说，编写一行代码所耗费的时间，要比小型项目长得多，前者至少是后者的两倍。这是怎么回事呢？
其中一项原因在于，大型项目通常有着很多的技术需求，这会影响解决方案的技术复杂度。假设我们要研发一款Web应用程序。最为简单的做法是采用PHP或Ruby这样的产品，把它实现成一个开销较低而且效果较好的Web应用程序，而最为复杂的做法，则是将其实现为多层的Java应用程序，并且用一些例程来进行安全监控、故障检测以及备份机制的切换等工作。对于这些复杂的系统来说，由于其中的任务实现起来比较困难，因此耗时也会比较长，不仅如此，而且在项目设立之初，还必须付出一笔较大的固定开销，以便研发相关的环境、设定测试本系统所用的系统、设定生产系统并执行性能及可用性测试。
换句话说，技术设计所体现出的复杂度，并不是简单地令项目的预期成本增大，而是会以某个系数，令其成倍地增长。因此，在情境设计与技术设计没有双双完工之前，你对项目开销的估算值，应该会持续增加，等到二者完工之后，这个估值才会渐渐稳定下来。因此，我们必须等情境设计与技术设计确定下来之后，才能对项目做出准确的估算，如图3-1所示。
要实现的功能点越多，每个功能点所耗的成本也就越大，这种现象难道仅仅是由技术复杂度造成的吗？有一种解释是说，功能点变多之后，功能之间就会彼此发生纠缠，这使得设计方案的各个元素之间形成了更多的关系。这种解释对于情境驱动设计来说，似乎不太适用，因为我们在情境设计阶段，应该就已经把元素之间的关系理解清楚并设计好了。还有一种解释，认为项目进入实现阶段的月份数量越大，项目后期对设计所做的修改也就越多（Capers Jones估计，软件方面的需求，平均每月会增加1%～2%[19]）。情境设计虽然没办法阻止业务经理改变他们的主意，但至少应该可以使人提前发现缺陷，而不会等到项目进展了很久之后才发现缺陷。综上所述，我们应该可以使每个功能点所需的成本，尽量不要与功能点的数量之间形成依赖关系，而最理想的状况，当然是使前者完全不依赖于后者。
成本估算会随着时间而发生变化，这并不是IT项目独有的特色。对于大型的工程项目，例如，伦敦奥运会（London Olympics）以及从伦敦到海底隧道的铁路（London to Channel Tunnel railway line）等项目，其初始的估算值也有可能错得相当离谱。例如，申办2012年奥运会时，预计的成本是24亿英镑。伦敦赢得主办权之后，组织者又进行了一些详细的规划及设计，然后估算出了新的值，这次是92.8亿英镑。整个项目完工之后的最终值，是89.21亿英镑。这些项目与典型的IT项目相比，其区别在于：一旦项目动工，很快就能估算出最终的花销。为了估算得更为准确，他们当然会做一些详细的设计，换句话说，也就是会执行设计细化这一步骤。此外，整个设计方案的概要，虽然对于奥委会的评审工作来说，已经相当细致了，但要想据此估算出成本，则显然是不够的。尽管如此，但他们只要把详细的设计做好，基本上就可以估算出正确的开销。笔者个人认为，那些工程师其实已经很尽力地完成了他们应该做的工作。第一次给出的估算值确实不够准确，但他们采取了某些措施，并于稍后提出了较为准确的估算值。即使项目当时取消，也不会造成太多浪费（当然对于奥运会这样的项目来说，是不会随便取消的）。
由此可见，成本估量问题在某种程度上，与我们对期望的管理有关。只有等到情境设计与技术设计都做好的时候，我们对项目的成本估算才会变得比较准确。如果这两种设计尚未完工，那么笔者认为，我们是无法准确估算出成本的。无论如何，笔者都觉得奥运会那个例子具有典型意义，也就是说，我们第一次估计出来的值，可能与准确值之间有着4倍的偏差，而且基于某些原因，一般都是低估而不是高估，我们的估值基本上总是真实值的1/4左右。等到技术设计完工之后，我们应该能估计得更加准确一些（前提是我们对过去的项目做了良好的记录，从而可以据此估算出开发工作所需投入的精力）。此外我们也要记住，总成本不仅包含开发成本，而且还包含软件及硬件产品的采购成本、运作成本、培训成本以及在整个公司内展示产品所需的其他一些成本。等到用户界面设计与数据库设计做好之后，我们对成本的估算还能变得更加准确。
把前面所讲的这些话综合起来，我们就可以找到在项目规划过程中进行重要审核的最佳时机，如图3-2所示。该图是随着时间的推移，从左向右绘制的。从图中可以看出，对项目成本所做的首次预算审核，应该发生在情境设计与集成设计完工之后，而对项目成本所做的详细预算审核，则应该等到细节设计做好之后再进行。我们当然也可以做得稍微灵活一些，例如，对系统管理界面所做的编程工作，应该是技术设计的一部分，但我们可以把这部分内容放到详细的评估审核之后再去做，使它与主要的实现阶段有所重叠。另外，我们还可以把用户界面的设计移入应用程序所在的方框里面，这意味着每个应用程序都有其自身的用户界面，这些界面是各自独立的。即便我们采用了上面这两种变通的做法，整个项目的设计也依然是稳固的，不太可能出现由于设计问题而导致项目必须大幅修改的情况。应用程序可能会逐阶段地推进，某些应用程序也有可能显得比其他应用程序更为重要，因此，我们应该灵活地估算项目的成本。如果我们能够理解估算项目成本所依据的基础，那么就可以在风险可控的前提下，采取一些变通的措施。
笔者刚才说过，只有等技术设计做好之后，我们才能精确地估算出项目的成本，这意味着在技术设计完工后，需要对项目做一次重要的预算审核。根据这次审核的结果，我们有可能要对前面的内容进行返工，甚至取消这个项目。
