什么是软件项目的成功

成功的（Successful） “按时完成，费用不超出预算，并且全部特性和功能都符合原先的设计规格。” 不太成功的（Challenged） “已完成并且能够运行，但费用超出了预算，没有如期完成，[拥有]的特性和功能少于原先的设计规格” 失败的（Impaired） “在开发周期的某个时刻项目被取消了” 尽管很是流行，这些定义仍是有问题的。某些项目即便一分钱也没赚到，它仍然多是成功的。另外一些项目即便带来了数百万美圆的收入也仍然不算很成功。 CIO杂志对这种古怪的情形做了以下评论： 那些知足了全部传统成功标准——时间、预算和设计规格——的项目，最后仍然多是失败的，由于它们不能吸引目标用户，或者由于它们最终不能带来更多的商业价值。 ……一样，按照传统的IT标准被认为失败的项目最终却可能反败为胜，缘由是：尽管存在费用、时间和规格方面的问题，但系统最后却被目标用户所喜好，或者带来了预想不到的价值。举个例子，曾有一家金融服务公司，开发一套新系统时工期延迟了六个月，费用也超出了原来预算的两倍多（最终的花费达570万美圆）。但这一项目最终却造就了一家适应性更强的组织（在13个月以后），于是被认定为一个至关成功的项目——这家公司经过帐户冲销节省了3300万美圆，并且下降了时间价值比，提升了容量，从而使生产环境中并发收集策略的测试数增加了50%。* 成功不仅是如期完成对于成功来说，除了如期完成，应该还有更多的要素……但它们是什么呢？ 我小时候很是喜欢玩耍。后来我喜欢上了编程所带来的挑战。当我使一个程序成功运行，就会有一种胜利的感受。回想那时，即便是一个不能工做的程序，也仍然是一种成功，只要我从编写它的过程当中得到了乐趣。这时我对成功的定义主要围绕着我的回报。 随着经验不断增加，个人软件变得更加复杂，我经常没法全面跟踪它到底是如何工做的。我不得不在完成某些程序以前结束它们。我开始相信可维护性是成功的关键——这一思想在我参加工做并与其它的开发团队一块儿工做时获得了验证。我为本身能写出优雅的、可维护的代码而感到自豪。此时，成功对我来讲意味着技术优秀。 某些项目的代码尽管写得很好，但项目仍是失败了。即便执行过程无懈可击的项目也仍然会让用户打呵欠。我开始认识到个人项目组是一个更大的生态系统的一部分，这个系统包含几十个，几百个甚至几千我的。个人项目须要知足那些……尤为是为薪水支票签字的人。实际上，对于那些为工做提供资金的人来讲，软件的价值必需超过它的成本。因而，成功意味着向组织机构交付价值。 这些定义并不矛盾。三种类型的成功都很重要（见图1-1）。没有我的的成功，你将很难为本身及其余员工提供激励。没有技术上的成功，你的代码最终将被它自身的重量压跨。没有组织的成功，你的团队可能发现公司再也不想要它了。 组织成功的重要性 软件开发团队更喜欢容易得到的技术和我的成功，所以组织成功经常被他们忽视。然而毫无疑问的是：即便你并不为组织的成功负责，更大的组织仍然会从这个层面上来评价你的团队。行政和高管不太会关心你的软件是否优雅、可维护，甚至也不会关心它是否被用户所喜好；他们关心的是结果。那是他们项目投入的回报。若是你不能达到这种类型的成功，他们会设法让你达到。 不幸的是，高级经理人员一般并无时间和精力去为每一个项目分别实施一套有细微差异的方案。他们挥舞的是大刀，而不是解剖刀。他们但愿由项目团队去关注各类细节。 当团队开发的结果不能让经理们知足，就是挥舞大刀的时候了。成本就是最明显的目标。砍掉成本有两种最简单的方法：设置很是紧迫的交付期限来缩减开发时间，或者将工做外包给一个劳动力成本更低廉的国家。或者两种方法同时运用。 这些都是笨拙的方法。过于紧迫的交付期限最终将延缓进度，而不是加快进度[McConnell 1996]（220页），而离岸外包则拥有隐性成本[Overby]。 紧迫的期限和外包的威胁听起来是否是很熟悉？若是是，那就说明你的团队到了从新为成功负起责任的时候了：不只仅是我的和技术的成功，还有组织的成功。 图1-1 成功的类型： 组织最重视的是什么？ 尽管某些项目的价值直接来自于销售，但组织的价值却不只在于销售收入。项目能够经过多种方式来提供价值，并且你不能永远使用金钱来衡量这些价值。 除了收入和成本节约，价值还会来自如下方面：* · 竞争优点差别（Competitive differentiation） · 品牌影响（Brand projection） · 提升客户忠诚度 · 知足监管要求（regulatory requirements） · 原创性研究（original research） · 策略性信息（strategic information） * 本文摘自《敏捷开发的艺术》一书。