打破铁三角: 新的项目管理角度

时至今日, 依然有很多项目受困于项目管理铁三角: 范围, 时间, 和成本. 是啊,

• 必须在2月底完成, 因为报税高峰期3月份就来了. 必须在10月底完成, 因为要撑过双十一的并发量. 必须在10.1前完成, 因为要国庆献礼.
• 这些需求都得做, 因为被替换的系统已经有这些功能了, 好多人在用, 没了他们会叫的.
• 就这些人了, 招人短时间内也招不到, 再说你们不是说了加人反而会降低开发速度吗?

这些都是现实的困难, 很难突破, 这也是前面几项被称为”铁三角”的原因. 那是否就一点办法没有了?

打破一条规则最有效的方法是推翻它的前提和假设. 当我们重新审视铁三角的时候, 会发现它至少有四个假设. 其中有两个假设比较明显, 早早就被人发现并利用了. 而另外两个假设则需更进一步的洞察力, 敏捷项目管理正是对准了这两个不那么明显的假设. 对这四个不同假设的颠覆, 导致了截然不同的软件过程管理方法. 下面我们依次来看一下.

时间变慢

第一个假设较为明显, 即铁三角中的时间是按每周工作5天, 每天8小时来计算的. 无数的团队发现了这一点, 然后毫不犹豫的打破了它. 每周工作6天, 每天12小时如何? 工作吞吐量立即可以提升(72-40)/40 = 80%. 相当于时间的流逝减缓了近一倍. 这就是我们常见的加班背后的原因之一.

牺牲质量

第二个假设也不难发现, 即铁三角中没有提及质量, 尤其是内部质量. 其实就算客户和供应商的合同中对质量做出一定要求, 由于其难以衡量和验证, 以及延时效应, 通常也沦为最弱的一种约束. “精明”的团队对此心知肚明, 通过拷贝粘贴等牺牲内部质量的方式来快速堆积功能. 这就是我们常见的匆忙赶工的产品其代码难以长期维护的原因之一.

对以上两个假设的颠覆导致了不利于团队, 不利于客户的开发方法, 长期来看都是输家. 所幸我们还有第三和第四个假设, 对它们的重新审视把我们引导到更加合理的项目管理角度.

关注价值

第三个假设是这样的: 铁三角之所以这么引人关注, 是因为大家认为只要在固定的范围, 时间和成本的约束内完成项目, 就是成功的.

这是一个看似合理的假设. 然而考虑以下两种情况: 第一种是在规定的时间和预算内完成了全部预期的功能, 但产品没人用, 投向市场没啥反应. 第二种是工期超了一点, 预算也超了, 计划的功能有很多没做, 相反根据变化做了点别的, 但产品推向市场后反应不错, 带来了利润. 那么两种情况哪种算是成功呢?

我会选第二种. 这么选的还有一个叫Jim Highsmith的. 他针对这个问题提出了新的三角, 他称之为敏捷三角: 价值, 质量和约束. 见下图(摘自Agile Project Managment) :

其中传统的铁三角被局部化成一个维度, 称为约束. 而引入了新的维度, 价值和质量. 其中价值代表的是利润等正向的因素, 而质量代表的是变化的成本. 质量越好, 意味着变化的成本越低. 据此, 我们打破铁三角的第一个手段是, 关注真正的用户价值, 降低变化成本, 并为此而调整计划.

提高生产效率

铁三角的第四个假设是生产效率不会发生变化. 因此固定其中两个只能调节第三个, 铁三角因而是铁的.

这个假设具备一定合理性的原因是短时间内生产效率很难发生突破性的变化. 但这不妨碍我们持续去提高生产效率, 从而软化铁三角.

这方面有众多的选择, 比如通过自动化减少手工工作, 通过预防错误避免返工, 而这里面最重要的, 是持续学习, 提升每个个体的效率. 我们通常说程序员之间的效率差异会达到数量级的差别. 花些时间在沟通交流培训反馈上, 是我们即使在最严格的外部约束下, 也可以做的, 并且是为数不多的手段之一.

其实我们从来就只有两个问题…

做什么和如何做.

对做什么保持关注，就会得到敏捷三角; 对如何做保持关注，就会得到持续改进；不思考才会被约束住.

新的假设

这两种方法有没有自己的问题? 比如第一种方法的问题是, 它假设价值和功能是有明确对应关系的…这为这种方法带来了软肋, 也提供了新的可能…

(To Be Continued…)