项目管理铁三角:追求价值还是约束条件

如何评判一个IT项目是否成功呢?很多人会脱口而出:在预算范围内,按期向客户提交需求范围要求的产品。这个著名的项目管理铁三角(需求范围、进度、成本)沿用至今,一直是大部分软件项目的实施目标。但我始终觉得这个铁三角有一个致命问题:它们到底是项目追求的终极目标,还是项目实施的约束条件?项目的价值似乎没有在这三个度量指标中明确体现。
现实场景中,很多项目为实现不合理的进度目标辛苦努力,其他很多重要的东西被忽略,特别是没有关注项目要获取的价值,似乎价值这个东西随着进度目标的完成自然就会实现,一如国庆节要献礼的某某工程,大干三百天风光剪彩之后,在某个月黑风高日,轰然坍塌。也有些项目沉迷于具体的需求项,而看不见这些需求项到底给用户带来什么价值。超过50%的软件产品功能基本没有被用户使用过是软件行业不争的事实。不瞒各位,我连我的手机都有至少一半功能没用过。这就应了一句老话:每条需求都有成本,但并不是每条需求都有价值。
“传统铁三角”定义的项目成功三要素有两个重要隐含假设。
● 项目定义的需求范围真正反映了客户的真实需要,通过使用这些需求功能,用户可以实现其价值目标。
● 项目计划是正确的,实际和计划不符意味着错误。
在这两个假设下,和计划不符的都会被视为问题,项目管理工作就是消灭和计划中的偏差。让我们认真思考一下上面的假设,它真的总正确吗?按时完成,没有超出预算,提交了需求范围的功能一定就意味着项目是成功的吗?如果这三个目标没有实现,项目就一定是个失败的项目吗?
请你回顾下以前你们公司发布的产品,在这三个目标方面都做得好的产品中,有多少卖的好,为公司带来了价值?有多少用户并不买账,产品并未对扩大市场占有率有任何正面贡献?而在没有按时完成,没有实现所有项目计划阶段定的需求范围,预算有超出的项目中,有没有卖得好客户喜欢的产品?这其中有没有为公司带来新的机会的项目?
举两个例子说明吧。假设微软的Vista符合这三个要求,你能认为这是个成功的项目吗?如果你有幸用过这个系统,相信你的心情和我一样,没摔键盘只是因为自己的东西舍不得。当然大多数应该没机会用这个系统,因为它面世没多久就挂了,Windows 7很快取而代之。几年前,我列席参加一家国际知名企业内部IT部门的年终管理会议。这个由公司CIO主持的会议只有一个议题:如何向董事会展示IT部门一年的贡献。我看到的数据是超过30%项目由于完成后无人用,很快就停止维护了。这些项目就算是按时完成、不超出预算又有什么意义呢?完成的项目中包含了不少重复实现的功能,这些功能的成本由该怎么算呢?不要觉得这家公司问题大了去了,其实你家公司也一样,这类问题一样都存在。
“泰坦尼克号”是一部国内观众熟悉的电影。也许有些内幕你可能不太清楚,它的预算严重超出(整个电影的制作费用超过两亿美金),进度一再延期,剧情有无数的变化调整。如果按传统三要素来度量的话,这绝对是个非常失败的项目。但面对全球20亿美金左右的票房,导演和演员地位火箭式的蹿升,你能说这是一个失败的电影项目吗?当然,这个电影如果跟“战狼2”比投资回报率,完败!
T1
“传统铁三角”定义的项目成功三要素有两个重要隐含假设。
● 项目定义的需求范围真正反映了客户的真实需要,通过使用这些需求功能,用户可以实现其价值目标。
● 项目计划是正确的,实际和计划不符意味着错误。
在这两个假设下,和计划不符的都会被视为问题,项目管理工作就是消灭和计划中的偏差。让我们认真思考一下上面的假设,它真的总正确吗?按时完成,没有超出预算,提交了需求范围的功能一定就意味着项目是成功的吗?如果这三个目标没有实现,项目就一定是个失败的项目吗?
请你回顾下以前你们公司发布的产品,在这三个目标方面都做得好的产品中,有多少卖的好,为公司带来了价值?有多少用户并不买账,产品并未对扩大市场占有率有任何正面贡献?而在没有按时完成,没有实现所有项目计划阶段定的需求范围,预算有超出的项目中,有没有卖得好客户喜欢的产品?这其中有没有为公司带来新的机会的项目?
举两个例子说明吧。假设微软的Vista符合这三个要求,你能认为这是个成功的项目吗?如果你有幸用过这个系统,相信你的心情和我一样,没摔键盘只是因为自己的东西舍不得。当然大多数应该没机会用这个系统,因为它面世没多久就挂了,Windows 7很快取而代之。几年前,我列席参加一家国际知名企业内部IT部门的年终管理会议。这个由公司CIO主持的会议只有一个议题:如何向董事会展示IT部门一年的贡献。我看到的数据是超过30%项目由于完成后无人用,很快就停止维护了。这些项目就算是按时完成、不超出预算又有什么意义呢?完成的项目中包含了不少重复实现的功能,这些功能的成本由该怎么算呢?不要觉得这家公司问题大了去了,其实你家公司也一样,这类问题一样都存在。
“泰坦尼克号”是一部国内观众熟悉的电影。也许有些内幕你可能不太清楚,它的预算严重超出(整个电影的制作费用超过两亿美金),进度一再延期,剧情有无数的变化调整。如果按传统三要素来度量的话,这绝对是个非常失败的项目。但面对全球20亿美金左右的票房,导演和演员地位火箭式的蹿升,你能说这是一个失败的电影项目吗?当然,这个电影如果跟“战狼2”比投资回报率,完败!
那么究竟什么是衡量项目成功的终极标准呢?价值。没错就是它。
Jim Highsmith提出了敏捷铁三角的概念,他提出了3个新目标。
● 价值目标:开发出可发布的产品。(可发布是指能给用户带来新的实际价值)
● 质量目标:开发出可靠、易更改的产品。
● 约束目标:在特定的约束条件下实现价值目标和质量目标。
敏捷铁三角的核心理念,我非常认同。对其略做修改,下图显示了新的项目管理铁三角。考虑到不同的软件企业的差异性,例如,并不是每个软件企业都是在开发产品,这里有必要对三个目标做深入说明。
T2
1. 价值+能力目标
将项目的价值最大化是项目管理的主导因素,不同类型的项目追求的价值目标会有差异。其度量指标可能是:
● 销售额及市场占有率的增加;
● 公司品牌及竞争力的提升;
● 客户忠诚度的提升;
● 技术创新带来的新机会。
不同类型的项目会有不同的价值目标,但它们有一个共同点,就是项目价值是站在组织而不是项目的角度来看的。
另一方面,在考核项目时不能忽略人员战斗力的提升。现今社会什么最宝贵?——人才啊!假设员工通过项目,一个个都功力精进,那公司的江湖地位自然也跟着提高。
2. 质量目标
我们不应忽视敏捷对质量管理的贡献,它从实践上强调质量不单单是清除缺陷,不单单是功能正确。它极聪明的提出了技术债务(technical debt)的概念,将其作为后期软件维护隐患的指标,并作为迭代开发的重要质量评估项。敏捷派一代宗师也提出了许多经过验证的有效实践来管理技术债务,所以敏捷质量目标不仅是可发布(功能正确)同时也是可维护的。近几年来,我将技术债务的概念延伸至质量债务,并将其作为软件开发过程中重要管理指标,也探索出了一些新的方法。后面有机会,也会和大家做个分享。
3. 约束目标
约束目标主要是进度和成本,约束不应该是目标,它是前提。比如刚性的进度要求,应该理解成在按期交付的前提下,团队将尽可能实现最大的价值。
我对新的项目管理铁三角的解读是:在特定约束条件下,控制产品遗留隐患对交付产品的使用及维护的影响,关注人员能力提升,尽可能将项目/产品价值最大化。
旧的项目管理铁三角有时会误导追求目标,比如只片面追求按时交付,却忽略了是否交付了客户需要的产品。Donald Reinertsen指出很少有人考虑延期成本,他认为这是个非常重要的度量项。顾名思义,延期成本度量的是产品不能按期提交的代价。如果它小于通过延时实现的功能带来的价值的话,项目延期应该是顺理成章的事。如果延时带来的后果是组织不能承受的,在规定时间发布一个新的版本就是必须要做到的事了。当然在这种情况下,需求范围往往是可调整的变量了。
如何衡量项目价值呢?应该看它对自身企业的贡献,对客户的贡献,以及对开发的产品用户的贡献。实现价值目标一定意味着你发布了一版为客户解决问题,实现了用户一定需求的软件产品。价值必须是项目管理的主导因素,如果值得,为什么不能延时提交?如果不会增加价值,一分钱也不应该投入。
新的项目管理铁三角的质量目标明确了更高的软件质量要求。仅仅将通过验收测试作为目标显然不达标。质量更应该关注的是项目遗留的技术隐患对客户使用和后期维护的负面影响。如果开发团队为追求速度,走了很多捷径,由此植入的隐患有时是不能通过测试发现的。但随着代码的增长,这些隐患会对产品的使用特别是后期维护有很大的负面影响。有时借些技术债是必须的,但这些债是需要及时偿还的,不然它们会严重损害产品的价值。套用大家耳熟能详的话就是,出来混,迟早是要还的。在产品开发过程中有效管理这些技术债务,应该是团队的一个重要责任。技术债务也可以是一个变量,可接受的债务是多少和项目的质量目标应该是一致的。
需求范围、成本和进度要求可以作为项目约束条件。项目的实施必须是在一个鸟笼子里面进行的,我们需要逐步了解这个笼子的空间和自由度。一般来讲约束条件可以有三个度的度量:刚性、部分灵活、灵活。刚性就是绝对的约束条件,部分灵活意味着有一定的自由度,而灵活则表示更大的自由度。把握了解这个鸟笼子的自用空间是项目管理的一个关键活动。
新的项目管理铁三角要求我们用投资回报分析(return oninvestment,ROI)作为管理者的决策方式。如果追加了投入,回报是什么?回报大于投入吗?如果延时,延期成本是什么?追加时间完成的工作价值大于延期成本吗?追求价值最大化应该是每一个项目的管理目标,也是所有重要决策的依据。在整个开发过程中,管理决策都应该围绕着价值目标的实现来进行。
这么说吧,所有的投资都要分析投资回报率。如果出场费还不如置办行头的费用多,那就老老实实在家喝茶吧!
本文摘自“知行合一:价值驱动的敏捷和精益开发”,整理重发。(来源:丛斌博士)

发布了2 篇原创文章 · 获赞 0 · 访问量 2437

猜你喜欢

转载自blog.csdn.net/ipmc2017/article/details/104917469