18.固定的价格就意味着背叛承诺

“对这个 项目,我们必须要有固定的报价,虽然我们还不清楚项目的具体情况,但任要有一个标价,到星期一,我需要整个团队的评估,并且我们必须要再年末交付真个项目。”

固定价格的合同会是敏捷团队的一个难题,我们一直在谈论如何用持续,迭代和增量的方式工作。但是现在却有人跑过来,想提早知道她会花费多少时间及多少成本。

从客户方来看,这完全是理所应当的。客户觉得做软件就好比是盖一栋楼房,或者是铺设一个停车场,等等。为什么软件不能像建筑业等其他传统的行业一样呢?

广告:个人专属 VPN,独立 IP,流量大,速度快,连接稳定,多机房切换,每月最低仅 5 美元

也许它真的与建筑有很多相似之处------真正的建筑行业,但不是我们想象中的建筑业。根据英国1998年的一个研究,由于错误而返工的成本大约占整个项目成本的30%。这不是因为客户的需求变化,也不是物理定律的变化,而是一些简单错误。比如,横梁太短,窗户洞太大,等等。这些都是简单并且为人熟悉的错误。

软件项目会遭遇各种各样的小错误,还要加上基础需求的变化(不,我要的不是一个工棚,而是一栋摩天大楼),不同个体和团队的能力差别费城巨大(20倍,甚至更多),当然,还不停地会有新技术出现(从现在开始,钉子就变成圆形的了)。

阅读 ‧ 电子书库

软件项目天生就是变化无常的,不可重复。如果要提前给出一个该规定的价格,就几乎肯定不能遵守开化上的承诺。那么我们有什么可行的办法呢?

我们能做更精确的评估吗?或者商量出另一中约定。根据自己的处境,选择不同的战略。如果你的客户一定要你预想确定项目的报价(比如政府合约),那么可能你需要研究一些重型的评估技术,比如COCOMO模型或者功能点分析法(Function Point analysis)。但他们不属于敏捷方法的范畴,并且是它们也要付出代价。如果这个项目本质上和另一个项目十分相似,并且是同一个团队开化的,那么你就好办了:为一个用户开化的简单网站,也下一个会非常相似。

但是,很多项目并不像上面所说的那么如意。大部分项目都是业务应用,一个用户和另一个用户都由着巨大的差别。项目的发掘和创造需要很多配合工作,或许你可以提供稍有不同的安排,试试下面的方法。

? 主动提议先构建系统最初的、小的和有用的部分(用建筑来打个比方,就是先做个车库)。挑选一系列小的功能,这样完成第一次交付应该不多于6-8周。向客户解释,这时候还不是要完成所有的功能,而是要足够一次交付,并能让用户真正使用。

? 第一个迭代结束时客户有连个选择:可以选择一系列新的功能,继续进入下一个迭代;或者可以取消合同,仅需支付第一个迭代的几周费用,他们要么吧现在的成果扔掉,要么找其他的团队来完成它。

? 如果他们选择继续前进。那这时候,应该就能很好的预测下一个迭代工作。在下一个迭代结束时候。用户仍然有同样的选择机会;要么现在停止,要么继续下一个迭代。

对客户来说,这种方式的好处是项目不可能会死亡。他们可以很早的看到工作的进度(或者不足之处)。他们总是可以控制项目,可以随时停止项目,不需要缴纳任何的违约金,他们可以控制线完成哪些功能,并能精确地知道需要花费多少资金。总而言之,客户会承担更低的风险。

而你所做的就是在进行迭代和增量开化。

基于真实的评估。让团队和客户一起,真正地在当前项目中工作,做具体实际的评估。由客户控制他们要的功能和预算。

切身感受

你的评估数据会在整个项目中发生变化------他们不固定的。但是,你会觉得自信心在不断增加,你会越来越清楚每个迭代可以完成的工作。随着时间的推移,你的评估能力会不断的提高。

平衡的艺术

? 如果你对答案不满意,那么看看你是否可以改变问题。

? 如果你是在一个基于计划的非敏捷环境中工作,那么要么考虑一个基于计划且非敏捷的开化方法,要么换一个不同的环境。

? 如果你在完成第一个迭代开化之前,拒绝做任何评估,也许你会失去这个合同,让位于哪些提供了评估的人,无论他们做了多么不切实际的承诺。

? 敏捷不是一味着“开始编码,我们最终会知道何时可以完成”。你仍然需要根据当前的知识和猜想,做一个大致的评估,解释如何才能到达这个目标,并给出误差范围。

? 如果你现在别无选择,你不的不提供一个固定的价格,那么你需要学到真正好的评估技巧。

? 也许你会考虑在合同中确定每个迭代的固定价格,但迭代的数量是可以商量的,他可以根据当前的工作状况进行调整 [又名工作条款说明(Statement of Work)]。