敏捷合同[自InfoQ]

原文:http://www.infoq.com/cn/articles/agile-contracts

 

敏捷合同

作者 Allan Kelly 译者 郑柯 发布于 2011328 上午120

社区

敏捷  

主题

客户及需求   ,

许可证   ,

法律案件   ,

商业  

标签

合同与谈判  

对于敏捷方法,人们常常提出这样的问题:如果基于敏捷工作方式,应该如何签署合同?

传统的瀑布式模型,与公司采购的方式完全契合:先整理出需求,一家供应商提供一个报价(基于他们对需求的阐释和对成本的估计),大家都签署一个法律上的捆绑协议。

一旦合同签署之后,接下来就是一段开发时间段,大家争论到底哪些功能在范围之内,哪些在范围之外,以及对于合同来说哪些构成变更请求。但是当工作最终完成后,激烈的讨论结束后,客户最终正式验收软件并且为之付款。客户这时得到繁重无比的软件,供应商得到自己的合同款项,所有人皆大欢喜,也许不是所有人吧。

如果供应商和客户都能从敏捷工作方法中得到最大的收益,就要重新思考传统方式工作合同的合理性。这是一个不断演化的领域,公司们在不断寻找适合敏捷合同的新模型。结果就是:扰乱了现状的创新思考着们得到更多机会。

本文检查了4种不同的模型,供供应商和客户使用,以建立敏捷相关的合同。将来可能出现新的模型,但是现在大概也就这4种。

揭穿固定合同

固定价格、固定时间、固定范围的合同继续成为IT行业合同的标准方式。这种类型的合同基于如下想法:在项目一开始可以定义出工作范围;供应商可以从中判断需要什么——或者说多少人要工作多久——并据此计算出一个价格。一旦完成,合同就等于是用血来签署,执行起来也是如此。

这种模型背后的理念是:将软件看做有实体的东西予以提供,也就是说看成购买一定量的通用软件。然而,购买定制软件可不像从裁缝那里买一套西服,更像是购买财务建议。你所购买的,更像是服务,而不是商品或是货物。

我碰到过很多人和公司都希望以上述方式完成工作招标,然而我还没碰到谁能够在成功完成项目的同时,不放弃对于至少一个固定项目参数(范围、成本或日程)的控制。IT行业阐述类似合同已经很多年了,而未能成功交付的情况也出现了这么多年。

这些失败发生的原因并不难找:项目范围变更、新的需求出现、已有需求忽略,错误解读(同样词汇对不同人的含义不同)引发的问题等等。要说明合同范围变更的各种情况,可以写出一整篇文章。不论原因如何,一旦固定合同种需求变化,其他所有东西都要跟着变化。先是时间和人员可能需要变动,接下来价格也必须改变。

退后一步好好想想,继续使用这种类型的合同实际上很令人感动。这么做充分展现了信仰和积极思考的力量,以及对于下一次事情将会有所不同的无望之希望。

也许这些合同存在的原因在于:它们能够在法庭上起到辩护作用。一边说合同没有完全兑现,另一半声称早已彻底完成,让法官去评判吧。但是考虑到固定价格合同模型的本质问题,我们可以说这种合同实际上增加了上法庭的风险。最后,应该指出:签订这样一个合同,需要所有相关参与方暂时认可所有需求已知而且不变,估算很准确,质量也可以接受。想想类似的合同过去的历史,这真是让人有点讶异呢。

不适用所有人

在进一步展示更多内容之前,我想指出:不是所有开发软件或是尝试敏捷的公司都会收到类似问题影响。创建并销售软件产品的公司,有时被称为ISV——独立软件开发商,比如Adobe或是Intuit,他们只会受到一些边缘影响。他们绝大部分的客户只购买完成多产品,对产品功能没有多少直接决策权。

有些企业的IT组织也开发软件,但是也能避开这个合同问题。他们直接购买已经完成的软件(比如SQL Server),或者开发供公司自己使用的定制软件。很多企业的IT部门会把工作外包,然后需要创建合同,并就其达成一致。在这些情况下,IT部门是第三方软件供应商的客户。

承接企业IT部门转包合同的服务公司,有时被称为外部服务提供商(External Service Provider,简称ESP),它们最需要敏捷工作合同。

敏捷能够轻而易举地融入到ISV的工作之中。实际上,很多敏捷实践都在这个领域内兴起。同样地,只要企业的政策和流程允许,敏捷也能够符合企业IT领域的要求。

但是,ESP与其客户们接受敏捷就有点困难,因为两者之间需要有一个法律合同。不过这个问题之中也孕育着机会。

因为客户(企业的IT部门和政府部门)知道IT项目会遇到问题,因此合同条款就已经变得更加严苛,财务方面的惩罚也更加高企。只有最大型的ESP公司们才能考虑投标大型合同。小公司承担不起惩罚条款,因此无法与有钱负得起大额罚款的大企业竞争。

改变合同结构,也就可能改变大企业消费者购买定制软件的方式,并且提供公认的双赢结果。相对于市场领导者,能够打破固定价格、固定范围和固定时间合同的供应商就能获得更多竞争优势。客户也能够从提供更高产出的创新方法中获得收益。

选择1:隐藏起来(Hide it

在交付合同中使用敏捷,将其隐藏起来是最简单、最没有破坏性的方式。不要告诉客户你的做法与通常做法的区别。以正常方法估算、规划工作,签署一个完全正常的合同,然后用敏捷技术来改进交付结果。

测试驱动开发、持续集成、定期重构和重新规划,这些敏捷实践都能帮你更好交付。想办法尽可能忽略最初的计划,因为它是错误的。如果可能,把它抛在一边。

问题在于,某些客户希望看到按计划的进度。你可以做一个假的出来。我听说某些团队会定期更新计划,就好像他们真得遵循了这个计划一样。不过这种方式不足以取信于人,如果客户相信我们虚构的进度,我们又怎么能指望建立与他们之间的信任呢?毫无疑问,我们不想对客户撒谎,我们希望建立信任,如果我们假装遵循某个计划,他们又怎么能相信我们?

当然,你可以说:相对于真正的交付,客户希望按照计划看到工作进展状况,这样的客户也没有表现出信任。可不管怎么说,我们作为承包商,让他们信任我们,这是我们的职责。

因此,要想让隐藏起来这个方法起效,必须要有类似于你不问,我不说这样的策略。如果你的客户愿意服从该策略,并且愿意根据真正的工作交付来衡量进度,而不是去看原来的计划,隐藏敏捷的方式也许可以生效。但是如果你的客户这么通情理,也许你就没有必要在一开始把敏捷藏起来了。

选择2:不起作用不收钱(No cure, No pay

采取不起作用不收钱的方式需要一定的自信。这个方法很简单:如果客户不喜欢你交付的东西,那就不收费。不过,如果他们为你开发出来的东西付费,他们也不能保留下来。

虽然这个方法看起来很恐怖,但是却能增加收费的机会。使用这种方法,客户能够降低承包商带来的风险。这种重新平衡风险的方法收费也要更高。

这个方法使用起来,也许能让人们在智力层面(也许还有道德层面)站到比较高的位置,但是也引入了新的风险。因为客户的风险降低了,他们让项目成功的动力也就降低了。当决策难以制定时,就需要做出妥协;时间很宝贵,或是需要客户主动参与时,客户就没有多少动力去做必须要做的事情了。

客户没有切身利益牵涉其中,任何失败都将是承包方的失败,客户什么也不会失去。

如果供应商只选择与能够信守承诺的客户做生意,风险就可以缓解。前提是承包方能够拒绝他们认为有风险的工作,而且可以正确评估客户的承诺达成水平。

到今天为止,我只听说个人和小型承包商能够提供这种模式。有钱的公司要么很注意风险,要么觉得没有必要提供这种选择。

选择3:滚动合同(Rolling contracts

如果我们希望保持客户的参与度,那么就需要一种机制,让他们参与进来,并不断让他们承诺相关的工作。滚动合同在此时就可以起到作用。客户与供应商之间不会去做孤注一掷(all-or-nothing的工作,而是达成一个框架协议,完成一系列只需短期开发的小项目,根据个人喜好不同,可以把它们称作情节(episode或迭代。

合同也许有某些整体目标,但是不包括所谓的购物列表,不需要列出特定的功能特性。发现需求是工作的一部分。我知道一个ESP把所有需求文档都放在法律合同之外。每个迭代中都会交付一些东西,同样重要的是,对于需求的理解会不断增加。

伴随着每次交付,客户会付款给供应商,同时面临一个选择:继续下一个迭代,还是就此停止。重点在于供应商首先交付了有价值的工作,而且让人知道还有更多可以增加价值的工作可作。如果客户认为产生的价值还不如耗费的成本多,他们就可以在已完成工作的基础上就此停手。与之类似,如果供应商发现客户合作程度不苟,供应商也可以就此罢手。

某种程度上,这与传统的实践有类似之处,都是要在每个独特的阶段后停下来付款,双方重新承诺,这些阶段包括:需求收集、设计、开发、测试和部署。区别在于:传统模式中,在结束前离开,不会交付任何收益;在这种模式中,总是可以交付一些东西。

从供应商的角度来看:使用已完成功能的纵向切片来展示价值,这能起到明确的激励作用。这是一个常见的敏捷实践。

因为客户能够看到正在完成的工作、正在产生的价值和逐步显现出来的解决方案,他们应该对工作的继续推进充满热情;他们也知道:如果没能达成自己的承诺,他们可以选择离开;这也让他们有信心继续。

这种方式将法律框架从提供东西转移到了提供服务上。客户签订的是服务合同,而且可以思考他们购买的服务的数量。是4个人月,还是200个工作点数?

虽然这种方式听起来很激进,很多IT部门和供应商已经在相关领域使用服务合同了。举个例子,IT支持部门和软件维护合同一般都是采取服务合同的形式编写。

选择4:不劳而获,变更免费(Money for Nothing, Change for Free

Scrum的创始人Jeff Sutherland不劳而获,变更免费有详细记述。这种合同没有采取迷你项目框架的形式,而是维护一个大合同,也就是说要完成一些概括的前期需求分析。但是,合同中加入了两个额外条款。

合同中第一个变化是:要确保总是在开发优先级最高的工作,而且允许加入新工作。客户同意定期与供应商碰面,调整剩余工作的优先级。这时,他们可以向Backlog中加入更多工作,同时要明白:这么做的话,有些工作就得丢掉,再也不会完成了。这有助于增加工作激励,对供应商有帮助,还能保证客户的参与。

与滚动合同类似,客户定期付款,可以按月支付,付款的增量对应交付出来的可工作的软件。这么做保证客户的参与,同时为将来的再次承诺奠定基础,并给后续的改变铺平道路。

不劳而获条款让客户在任何阶段都可以取消剩余的工作,并保留目前已经完成的工作。在这种情况下,客户要为未完成的工作支付20%款项。

假如有一个1200万美元、为期12个月的合同已经完成了一半,这时客户希望取消剩余的工作,除了必须要付的600万美元之外,他们还要多付出120万美元。这样相对于整个合同金额,客户还能省下480万美元。

初看上去,供应商可能不会喜欢这种方式,因为这样会让他们少收原来可能赚到的480万美元。然而,他们收到的120万美元却可算是无偿得到的,这应该足以缓解他们的顾虑。假定他们能够马上把人员分配到其他工作上,那么这120万美元就可以算是纯利润了。

因此,这种机制和激励措施能够让客户提高参与度,同时更早完成工作,节省资金。同样的是,供应商也有激励能够接受变化,把工作做好,得到免费的报酬。

目前,这种类型的合同在业界出现得还不多。

组合

基于上述四种选择,可以看到:以不同方式组合能够得到更多变更方案。比如:变更免费可以跟其他任何3种方式组合在一起,产生更有效的解决方案。类似,不起作用不收钱也可以应用到选择3“滚动合同的单次交付中。

从财务角度看,选择3和选择4大概没有很大区别。也许主要的区别在于:选择3打破了传统的模式,因为它假定人们在项目刚开始时知之甚少,而且让客户以积极方式反复交付。

与之相反,选择4契合现有模式,认可前期需求分析的必要性。变更免费条款提供的框架类似于滚动合同:初始需求作为估算工具,辅助判断所需时间和预算。一旦工作开始,前期需求就可以抛开了。不劳而获条款与滚动合同有共通之处:允许工作在任何时点停止,不过是以比较昂贵的方式。

无论敏捷团队采取哪种形式的合同,有两个必要因素需要考虑。首先,合同本身应该体现敏捷的迭代本质:完成一点,展示一点,再多完成一点。这在敏捷中反复出现:时间盒迭代、回顾、测试驱动开发,等等等等。这是现实版的PDCA循环。

其次,合同应该可以激励客户及其代表参与到项目的整个过程中。反复研究发现:客户的持续参与是确保IT项目成功的关键因素之一。不管你是否采用敏捷,你都需要客户持续参与。

最后,还有重要的一点……

没有接触过传统IT行业工作方式的客户可能觉得这些选择非常合理。过去曾与IT供应商一起工作的人员会觉得这些合同形式有些出人意料。我们的行业给客户造成伤害,就是因为我们总在宣扬:只要你能写下来,我就能以预先确定的成本和时间完成。

不可避免的是,有些客户会继续固守传统的合同模式。有些供应商会发现:可以在这样的客户身上赚到很多钱;而另外一些供应商则会发现这么做得不偿失。不管是哪种结果,人们都不会喜欢。

我有个客户,现在总是给他的客户两种选择:传统的固定合同,还有滚动式的敏捷合同。如果客户认为一切都可以在工作开始前固定下来,他们就可以使用传统方式。如果他们不确定,就可以试试看迭代式的、滚动敏捷合同。

随着时间推移,客户会更深入理解这些IT合同的新形式,还有可能采取的多种选择,大家都可以从中受益。现在,对于能够尽快在早期转向新合同模式的人,他们是有机会的。是,是有一些风险,但是同样也会有奖励。

关于作者

Alan Kelly几乎从事过软件开发领域中的所有工作:系统管理员、测试人员、开发人员、架构师、产品经理和开发经理。他住在伦敦,擅长以培训、咨询和指导等形式,帮助软件公司采纳敏捷和精益实践,并加深对其理解。

除了给杂志撰写大量文章、做会议演讲之外,他还是Changing Software Development: Learning to become Agile一书的作者。

查看英文原文:Agile Contracts


InfoQ中文站投稿或者参与内容翻译工作,请邮件至[email protected]。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

 

 

你可能感兴趣的:(info)