1.1 重新审视项目成功的标准

在预算范围内，按期向客户提交需求范围要求的产品是长期以来IT企业判定项目成功以否的标准。这个著名的项目管理铁三角（需求范围、成本、进度）直到今天仍定义着大部分软件项目的实施目标。多年来我一直觉得这个铁三角有一个致命问题：它们到底是项目追求的终极目标，还是项目实施的约束条件？项目的价值似乎没有在这3个度量指标中明确体现。

我看到很多项目为实现不合理的进度目标辛苦努力，其他很多重要的东西被忽略，特别是没有关注项目要获取的价值，似乎价值这个东西随着进度目标的完成自然就会实现。也有些项目沉迷于具体的需求项，而看不见这些需求项到底给用户带来什么价值。一个令软件业同行不得不面对的事实是超过50%的软件产品功能基本没有被用户使用过，换句话说，对软件项目团队辛辛苦苦实现的一半以上的功能，客户并无兴趣使用，它们没有给用户带来什么价值。这就应了一句老话：每条需求都有成本，但并不是每条需求都有价值。推想一下，又有多少没有完成的项目，因为追求一些没有价值的需求，导致了过多延期和预算超支，使得企业只能放弃它们。

1.1.1 传统的三要素不一定能客观度量项目的成功与否

图1-1定义了传统项目管理铁三角：需求范围（特性、功能）、成本（资源、预算）和进度（时间）。成功的项目应该依据客户需求（范围），在不超出预算的前提下，按时提交项目。

“传统铁三角”定义的项目成功三要素有两个重要隐含假设。

项目定义的需求范围真正反映了客户的真实需要，通过使用这些需求功能，用户可以实现其价值目标。

项目计划是正确的，实际和计划不符意味着错误。

在这两个假设下，和计划不符的都会被视为问题，项目管理工作就是消灭计划的偏差。让我们认真思考一下上面的假设，它真的总是正确吗？按时完成，没有超出预算提交了需求范围的功能，一定就意味着项目是成功的吗？如果这3个目标没有实现，项目就一定是个失败的项目吗？

请你回顾一下以前你们公司发布的产品，在这3个目标方面都做得好的产品中，有多少卖得好，为公司带来了价值？有多少用户并不买账，产品并未对扩大市场占有率有任何正面贡献？而在没有按时完成，没有实现所有项目计划阶段定的需求范围，预算有超出的项目中，有没有卖得好、客户喜欢的产品？这其中有没有为公司带来新的机会的项目？

我们看几个例子。如果微软的Vista符合这3个要求，你能认为这是个成功的项目吗？如果你用过这个系统的话，相信你的体验不会很好。另一方面，你很有可能没有机会用过这个系统，因为它的市场寿命很短，Windows 7很快就替代了它。多年前，我开始为一家国际知名企业内部IT部门做过程改进的咨询工作。作为诊断工作的一部分，我列席了内部IT部门的年终管理会议。这个由公司CIO主持的会议只有一个议题：如何向董事会展示IT部门一年的贡献。度量内部IT部门的贡献要稍微复杂一些，因为这个部门不挣钱、只花钱。让我吃惊的是，超过30%项目由于完成后无人用，很快就停止维护了。这些项目就算是按时完成、不超出预算又有什么意义呢？我看到完成的项目中包含了不少重复实现的功能，这些功能的成本又该怎么算呢？虽然在这次会议上，他们做了一个看起来还是不错的部门年度贡献列表（其中包括所有项目）, CIO不久以后还是不自愿地离开了这家公司。

《泰坦尼克号》是一部国内观众熟悉的电影。也许有些内幕你可能不太清楚，它的预算严重超支（整个电影的制作费用超过2亿美元），进度一再延期，剧情有无数的变化调整。如果按传统三要素来度量的话，这绝对是个非常失败的项目。但面对全球20亿美元左右的票房，导演和演员地位火箭式的蹿升，你能说这是一个失败的电影项目吗？

“传统铁三角”的致命问题是前面的两个假设。因为对一个软件项目来说，一开始我们往往不完全清楚用户真正的需求，产品需求的理解有个逐步演化的过程。哪怕在项目结束时，很可能我们还不能完全确定实现用户价值的需求集合，这也是产品需要不断升级的原因之一。

另一方面我们如何看项目初期制订的计划呢？我们能假设它的正确性吗？几乎无一例外，答案是否定的。在做计划时，你要面对很多不确定的东西，如需求范围、实施技术、团队能力、外在制约等。虽然你参考了组织提供的团队效率数据，但考虑到影响效率的各种因素及具体团队的特殊性，估算出的进度计划的准确性是让人质疑的。更让人头疼的是，在开发过程中，很多影响项目进度的因子（如需求、人员、环境等）会发生变化。把符合一个不靠谱的计划作为项目的主要目标之一，恐怕不是一件很明智的事。

明确成功项目的标准意义十分重要，它是软件开发方法的纲。借用一句老话，“纲举目张”，这是理解敏捷方法的一个很好的切入点。在本章里，我们一起重新审视项目成功要素，对旧的项目管理铁三角做必要的修正。

1.1.2 新的项目管理铁三角

那么究竟什么应该是衡量项目成功的终极标准呢？我们在前面已经提到了它——价值。

Jim Highsmith（2011）提出了敏捷铁三角的概念，他提出了3个新目标。

价值目标：开发出可发布的产品。

质量目标：开发出可靠、易更改的产品。

约束目标：在特定的约束条件下实现价值目标和质量目标。

我十分认同敏捷铁三角的核心理念，这和我多年在咨询、教学中推荐的原则高度一致。对其略做修改，图1-2显示了新的项目管理铁三角。考虑到不同的软件企业的差异性（例如，并不是每个软件企业都是在开发产品）这里有必要对3个目标做深入说明。

1．价值+能力目标

将项目的价值最大化是项目管理的主导因素，不同类型的项目追求的价值目标会有差异。其度量指标可能是：

销售额及市场占有率的增加；

公司品牌及竞争力的提升；

客户忠诚度的提升；

技术创新带来的新机会。

不同类型的项目会有不同的价值目标，但它们有一个共同点，就是项目价值是站在组织而不是项目的角度来看的。

另一方面，在考核项目时不能忽略人的能力的提升。这也应该是一个项目后评价中的重要指标。在项目结束后，软件工程师设计、开发、测试各环节的能力是否得到了提升？需求架构人员是否对产品的价值、合理的架构有了更好的理解？管理人员对团队能力是否更加了解？客户或用户是否对后续产品方向更加清晰？过程人员，如质量保证（quality assurance, QA）人员，是否对过程的适用及执行难处有了更好的认识？对于许多软件应用服务开发商来讲，人会是企业的最重要财富，人的能力成长对公司的发展至关重要。

2．质量目标

我们不应忽视敏捷对质量管理的贡献，它从实践上强调质量不仅是清除缺陷，不仅是功能正确。它提出了技术债务（technical debt）的概念，将其作为后期软件维护隐患的指标，并作为迭代开发的重要质量评估项。敏捷领军人物也提出了许多经过验证的有效实践来管理技术债务，所以敏捷质量目标不仅是可发布（功能正确），同时也是可维护的！

3．约束目标

约束目标主要是进度和成本，约束不应该是目标，它是前提。例如，刚性的进度要求，应该理解成在按期交付的前提下，团队将尽可能实现最大的价值。

我对新的项目管理铁三角的解读是：在特定约束条件下，控制产品遗留隐患对交付产品的使用及维护的影响，关注人员能力提升，尽可能将项目/产品价值最大化。

旧的项目管理铁三角有时会让团队追求错误的目标，如片面追求按时交付，而忽略了是否交付了客户需要的产品。Donald Reinertsen（1997）指出很少有人考虑延期成本，他认为这是个非常重要的度量项，每个组织都应该考虑。在某一特定时间提交产品固然很重要，但提交的产品是可以发布的，也就是说它已经实现的功能特性对客户和用户是有价值的，这一点应该是更重要的。顾名思义，延期成本度量的是产品不能按期提交的代价。如果它小于通过延时实现的功能带来的价值的话，项目延期应该是顺理成章的事。如果延时带来的后果是组织不能承受的，在规定时间发布一个新的版本就是必须要做到的事了。当然在这种情况下，需求范围往往是可调整的变量了。

至于将需求范围作为项目的主导目标就更不合适，项目前期用户很难对需求有全面、充分的理解。如果项目开发周期较长，用户的想法在开发期间发生变化也是一件很正常的事情。在美国IT行业有个说法：有生就有死，工作就要交税；做软件，需求一定会变。

如何衡量项目价值呢？应该看它对自身企业的贡献、对客户的贡献，以及对开发的产品用户的贡献。如何度量价值不是件容易的事，我们可以从这几个方面来考虑：产品的销售额、对品牌及竞争力的影响、对客户忠诚度的影响、通过创新给企业带来的新的机会等。实现价值目标一定意味着你发布了一版为客户解决问题、实现了用户一定需求的软件产品。价值必须是项目管理的主导因素，如果值得，为什么不能延时提交？如果不会增加价值，一分钱也不应该投入。

IT业对人的要求比制造业高得多。学校教的东西和业界需要的技能有很大的差距，这个问题估计在相当长时间不可能解决。同时IT技术的生命周期比其他行业更短。持续更新提升软件管理人员、工程人员的能力是每一个IT企业面临的挑战。对一个软件人员来讲，在工作中学习是最主要的能力提升方式。每个项目结束后，相关人员能力的提升也应该是考核一个项目的指标：开发人员的编程能力、工具使用能力是否有提升？设计人员的设计能力是否有提升？管理人员对自身团队的能力是否更清晰？对项目的风险点是否更加清楚？产品经理、客户、用户代表对产品的理解是否更清晰？关注团队能力的提升是每一个管理者的责任，而每一个软件工程师都有学习提高的义务。项目相关人员能力的提升应该是项目评价的因子之一，它也应该是项目价值的考虑因素之一。

新的项目管理铁三角的质量目标明确了更高的软件质量要求。仅仅将通过验收测试作为目标的话是不能接受的。质量更应该关注的是项目遗留的技术隐患对客户使用和后期维护的负面影响。如果开发团队为追求速度，走了很多捷径，由此植入的隐患有时是不能通过测试发现的。但随着代码的增长，这些隐患会对产品的使用特别是维护有很大的负面影响。有时借一些技术债是必需的，但这些债是需要及时偿还的，不然它们会严重损害产品的价值。在产品开发过程中有效管理这些技术债务，应该是团队的一个重要责任。技术债务也可以是一个变量，可接受的债务多少和项目的质量目标应该是一致的。

需求范围、成本和进度要求可以作为项目约束条件，项目的实施一定是在一个鸟笼子里面进行的，我们需要逐步了解这个笼子的空间、自由度。一般来讲约束条件可以有3个度的度量：刚性、部分灵活、灵活。刚性就是绝对的约束条件，部分灵活意味着有一定的自由度，而灵活则表示更大的自由度。把握了解这个鸟笼子的自用空间是项目管理的一个关键活动。

新的项目管理铁三角要求我们用投资回报分析（return on investment, ROI）作为管理者的决策方式。如果追加了投入，回报是什么？回报大于投入吗？如果延时，延期成本是什么？追加时间完成的工作价值大于延期成本吗？追求价值最大化应该是每一个项目的管理目标，也是所有重要决策的依据。在整个开发过程中，管理决策都应该围绕着价值目标的实现来进行。

从简单常识来讲，价值驱动不光应该是企业层面和部门层面的决策方式，也应该是项目层面决策方式。所有的管理者应该习惯这种管理思路：不论项目中需要做什么大小决策，都应该做投资回报分析，可是传统开发模式常常不能有效支持价值驱动管理模式。

1.1.3 敏捷让我们实现价值驱动管理

实现价值驱动管理不是一件容易的事，我们通过下面这个简单的例子来说明其难度。

收视率是每部电视剧追求的目标。高收视率对投资人意味着高额广告费，对导演意味着在影视圈中的地位，对演员意味着职业生涯的飞跃。所以电视剧在制作过程中，每个重要的决策都是价值（收视率）驱动的，如剧情、演员的选择、布景等。

每个电视剧的预算都不完全一样，这应该是最大的约束条件。如果预算的限制使得导演不能请到他认为合适的演员，而导演认为请到合适的演员是成败的关键因素之一，那么是否追加预算请出导演心仪的演员，制片人必须做个对收视率的影响分析。如果被考虑的演员有几千万的粉丝，请到他就是收视率的保障，只要追加的预算不是很离谱，相信预算会被调高。如果制片人选的演员和导演喜欢的演员对收视率的影响没有明显的差别，而换演员的代价超过数千万，估计预算追加的可能性会很小。

在前期规划阶段，剧组会估算出电视剧的大概播出时间。如果在制作后期，剧组发现某些剧情有明显不合理的地方，而如果重拍将导致播出时间的延迟，相信大部分制片人会通过延期成本分析做出决定。如果重拍投入不大，延时几个月不会对收视率有很大的影响，延时重拍就是顺理成章的事。但如果制片人了解到有一个类似题材的电视剧也在拍摄中，很快要杀青。如果电视剧播出时间落在它的后面，收视率就会受很大影响，这时延期成本会大于重拍带来的效益，重拍就不是一个好的选择。

什么剧情能打动观众？什么样的演员能塑造出深入人心的角色？在电视剧播放之前，谁也没有完全的把握，谁也无法准确预测能够达到的收视率，这是应用新的项目管理铁三角（价值驱动管理）面临的最大挑战。中国电视剧制作模式就不能有效地支持这种管理模式，一部80集的电视集，要全部拍完开始播放后，才会第一次得到大众的反馈。那时的反馈已经太晚了，因为钱已经都花出去了。2013年年初推出的《楚汉传奇》是一部80集的电视剧，制作成本接近2.5亿元人民币，号称有史以来最昂贵的电视剧。它的导演演员阵容都是国内一流的，请来了国内最好的男演员（我个人认为陈道明是国内最好的男演员），制作团队也是一流的。但是播出后，收视率大大低于期望，远远没有实现预期的价值。

美国电视剧的制作模式就能够有效支持价值驱动管理。一部几百集的电视剧，是一集一集地拍，一集一集地播。他们电视剧的播放是每周在固定时间播放一集，第二天就能看到收视率的数据。如果电视剧播出后，收视率达到或超过预期，那么投资人会继续投资下去。如果收视率没有达到目标，制片人有两个选择：一是分析原因，在拍下一集时做出调整，等下周播放时再看调整是否有效果；二是取消这个电视剧的制作，有时放弃很可能是最好的选择。不做任何变动不是一个可选项。哪怕我们选了个错误题材，损失还是很有限（也就是几集的成本）。

国产电视剧模式就类似于以瀑布模式为代表的传统软件开发模式，它要求我们“先知后行”。需要有明确的计划，只有整个电视剧杀青后，才会第一次收集到观众的反馈及收视率的数据。很明显，这种模式是很难支持价值驱动的管理模式的。因为在实际场景下，价值的判断是需要用户的使用反馈的。

而美国电视剧模式则是“知行合一”的方式，这也是本书讨论的敏捷开发模式。它能通过不断收集反馈，支持价值驱动管理的开发模式，这个例子也告诉我们知行合一的敏捷模式能够有效支持新的项目管理铁三角的实施。