敏捷外包工程系列之三:固定合同(敏捷外包工程,敏捷开发,产品负责人,客户价值)

本文是敏捷外包工程系列的第三篇。(之一之二之三之四

 

下面的很多外包场景以国内的外包为例,因为往往这些项目更加严苛。

外包合同常常是固定价格固定工期固定需求(一般称为定额合同),这个时候“拥抱变化”的敏捷感觉意义不大,那么敏捷开发是否就无用武之地了呢?其实不然。

下面的一些用法,是利用敏捷开发来促进这种固定合同的达成。在提出这种“如果……,不但……,而且……,那又怎么办呢?”的限制性问题时,不能期待完美的答案,因此下面这些方法有些能用,有些不能用,有些需要在现实环境中加以变形才能使用。而如果发现哪一种方法都没用,企业极有可能运行在高危状态,不是敏捷开发或其他开发方法能解决得了的,应该从市场、销售、定位、运营等其他角度思考。

需要提前认识的一点是:事实上不存在三固定合同(或者更多的固定)。例如一个刚刚想出概念的项目要招标,指出现在就要确定价格和工期,而需求将在合同签署3个月后才会产生,而合同将在12个月后在价格-工期-需求三者约束下完成。这件事情就实际上是不现实的。因为在价格与工期已经确定的情况下,即使尚未得知需求,也应该已经对需求的数量有了约束条件(这里暂时不假设其他约束如质量等),而不可能在3个月后毫无约束地编写需求,并恰巧又在12个月后发现需求的数量与价格/工期暗合。

因此当拿到三固定合同的时候,要问自己一句话:“到底哪个约束条件是真正固定的?”,找到答案后,敏捷开发就能帮忙了。


工期优先

有些合同工期是第一位的,本人也经历过几次。无论需求完成的情况如何,倘若在某个时间点顺利完成某事,结果都算过得去。

比如某年有一个军队的项目,项目必须结束于某个节日前,而价格也是在合同签署时固定下来。价格固定,工期固定,需求就不可能固定了。当然如果在合同签署时对客户说:“需求不可能固定,只能视工期来确定”客户一定会反对,但实际情况是,当最重要的需求已经完成,而在那个节日软件运行正常,庆功宴后合同也就结束了,没有人会去真正在意剩下的需求。

工期优先的合同包括为某个特定事件开发的合同(如奥运会,阅兵,校庆……),伴随基础建设发生的合同(如机场/车站/地铁等……),实际上没有限制但受限于预算执行等活动导致的工期优先合同等。

这类合同应本着运营的角度,思考“在工期到达的那一天,客户到底要运营什么功能?”功能开发出来但客户却不用是常有的事,也很难预料,但“功能开发出来客户暂时不会用到”却可能被预测到。比如当年我在的项目要开发某数字电视系统,参考国外的同类产品,设计了类似“区域禁播”“家长码”等功能,这些功能好像至今都未被使用。原因不是电视台的操作习惯问题,而是“区域禁播”用于“帕尔马市只有9万人,却拥有一个9万人的体育场,因此当那里比赛时,我们希望把全城人都赶到体育场看球,因此他们将被无法在家里看此场比赛的电视转播”这种场景,而后者需要电视节目分级制度,两者都可被预测到无法在短期内运营。

这样,一定运营的功能就成了敏捷早期迭代的优先任务。

每当有新功能被提出,也要先思考是否是一个必须的功能,是否应该提前到其他必须功能之前或推迟到之后。

每当一个功能被变更,如果是必要的功能,则应该在其他功能开工之前就完成变更,以保证变更在运营之前完成。

“一个功能真的没用,但是是对方领导上个月提起的,不做不行,怎么办?”如果专业知识足以帮助那位领导判断到底真的有用还是没用(相当困难,慎用),不妨拖一拖,他也就忘了。如果领导居然再次问起来,就要想想自己的判断真的准还是假的准?或许这位领导真的有何用意,这时候就要问清楚。

“怎样处理剩下的没有开发的需求?”这不是一个开发人员或开发方法解决的问题,我见过它们随风而去,也见过它们被滚动到下一项目(甚至重新给钱)。正如同开发团队会用敏捷开发这样的先进方法,其他角色如销售人员也有其先进方法;如果他们回答没有,那么找一个回答有的人,比创造一种能处理这些需求的开发方法论要容易得多。


价格优先

倘若合同金额巨大,或公司运营紧张,都应该把价格放到首位考虑。

价格常常是在合同签署的时候确认的,甚至可能在签署之前客户就申请到了“有限的预算”,看上去没有什么可“考虑”的,其实不然。以下方法可以帮助在价格上做文章。

1. 掌握一种价格估算方法。

国际国内实际上已经有各种估算方法,不但在用而且已经在法律框架下使用(比如韩国所有政府软件造价均需要使用其《软件成本估算标准》),详情会在造价估算篇做介绍。国内的类似标准正在制定中。

即使不使用这些专业的方法(其实已经谈不上专业了,国际上已经有大约6000人掌握了这类方法),基本的估算如Delphi估算也在一定程度上可行,“有比没有好”,几乎是估算的第一定律。

“如果甲方不认可估算结果怎么办?”很好的一个问题,但是即使甲方不认可,乙方仍然有必要了解项目的真实造价估算是多少,以保证做出正确的决策。比如一家甲方和两家乙方招投标,而只有一个乙方真正知道最终造价,显然他最主动。最终结果无外乎2种:另外一家>这家>造价 = 甲方选择了这家乙方,有一定利润;另外一家<造价<这家 = 甲方选择了另外一家,项目失败。另外几种排列组合呢?由于这家乙方知道造价,所以不会出现另外一家<这家<造价和这家>另外一家>造价等这几种情况。“如果对方以低于造价中标但后来在第二期项目得到补偿怎么办?”这不是一个敏捷开发话题,甚至不是一个造价估算话题,轮到销售和老板出场了。

“如果估算结果是亏损,但此项目又不计成本志在必得怎么办?”也是很好的一个问题,几乎没有一家企业没有遇到过“不惜一切代价”的项目,但也没有一家企业总是遇到“不惜一切代价”的项目。一个5万的项目可能会为了认识一个新客户而不惜一切代价,但一个5亿的项目,其目标几乎就是盈利。如果5万的时候就习惯了不计成本,到5亿的时候很可能就迎来了公司的难关。所以,不计较成本和不计算成本是两码事

国内的外包型项目基本上是关系型销售,企业还没有太感觉到估算的压力,但随着竞争越来越激烈以及法律的健全,情况将会改变。

国外的外包则不同,笔者遇到一次一个外国企业要发包,前提是接包商能事先回答“这个单子用多久?多少钱?为什么?”可惜当年接包商们和笔者尚不了解如何用两天时间从100多页文档中看出工期和成本,最终没有一个接包商接单。

2. 仍然是从最重要的需求开始开发,迭代交付

“价格已定而且资金不足,需求还都要保证,客户还同意延期也要把需求做完(更加造成成本上升),迭代交付还有何作用?”其实多数情况下,甲方都比乙方更担心项目失败。与合同金额相比,甲方因项目失败而造成的损失要大得多。而且乙方即使单个项目亏本,仍可能从别的项目赚钱;即使单个客户搞砸,仍可能和别的客户做生意;即使公司关门,各级管理者和一线人员仍可以在本行业内发展。而甲方则不同,多数项目都属于“一次性的”不容失败;对个人而言,在甲方跳槽的难度也比乙方大得多。

因此倘若真的估算不准,当项目因为经费问题无以为继时,甲方有很多做法可以让项目顺利进行,比如许诺有二期工程,砍掉部分相对无用需求,甚至追加款项……但一切都取决于当时的境地。

倘若这是一个瀑布开发项目而我们正处于测试阶段,总不能现在结项,把测试和交付活动当作二期工程吧?也不太可能砍掉什么功能,因为需求、设计、编码都结束了,砍掉功能还得重新编码。追加款项……什么也没看到呢,谁有信心再向里边投钱?别看已经到了测试期,测试期比开发期还长的项目有的是。

但如果是一个敏捷项目则完全不同:最重要的功能已经完成了,随时可以上线;边边角角还有点东西,可做可不做……甲方拥有众多选择,二期工程,放弃枝节,追加投资,都可以。


寻求战略合作关系

或许可以靠关系维护客户,但是客户的高层也会更换,一朝天子一朝项目,有风险。

或许可以靠无限制迁就来维护客户,但迁就的结果就是产品利润越来越薄,有违企业初衷。

但是笔者也见过其他的方法来维系客户。

比如之二中提到的电信开发商,就与客户渐入佳境,长期合作和稳定的交付,习以为常的定期结帐,使得客户无意冒险更换开发商。比如之前我拜访过的一家对日外包企业,佳能公司甚至会定期询问他们的人员空置率,因为如果空置率过高,佳能会考虑多分包一些合同过来,防止企业亏损和倒闭。他们都与客户建立了一定的战略合作关系。

但是这些都不是甲方的仁慈造成的,而是乙方的实力造成的,有道是 don't pray for easy life,pray to be stronger man!  

对于敏捷开发而言,可以避免失败,可以在关键点上满足最需要的功能,可以不让客户左右为难……时间久了,甲方会根据自身利益做出选择,而stronger man的日子就开始了。


“固定合同” 其实是不定的,总归在工期或价格上有一个是真正固定的,而需求极少是真正固定的(“几乎总有50%的功能客户从来不用”)。

若工期固定,应借助迭代交付,在工期完成时确保运营所需的最关键功能完整无缺,时间或老板会处理剩下的需求。

若价格固定或很在意价格,应借助优先级排序和迭代交付,使项目进入左右逢源的状态,以保证甲乙方可以有多种选择。

 

上述工作需要至少项目经理级别的人配合销售乃至老板完成,倘若一个普通的一线员工突然接到一个客户电话,让加上一个新功能,到底是拥抱还是阻止呢?请看下期需求开发与变更管理。

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

posted @ 2011-07-21 23:22  Java EE  阅读(146)  评论(0编辑  收藏  举报