敏捷外包工程系列之三：固定合同（敏捷外包工程，敏捷开发，产品负责人，客户价值）
下面的很多外包场景以国内的外包为例，因为往往这些项目更加严苛。
外包合同常常是固定价格固定工期固定需求（一般称为定额合同），这个时候“拥抱变化”的敏捷感觉意义不大，那么敏捷开发是否就无用武之地了呢？其实不然。
下面的一些用法，是利用敏捷开发来促进这种固定合同的达成。在提出这种“如果……，不但……，而且……，那又怎么办呢？”的限制性问题时，不能期待完美的答案，因此下面这些方法有些能用，有些不能用，有些需要在现实环境中加以变形才能使用。而如果发现哪一种方法都没用，企业极有可能运行在高危状态，不是敏捷开发或其他开发方法能解决得了的，应该从市场、销售、定位、运营等其他角度思考。
需要提前认识的一点是：事实上不存在三固定合同（或者更多的固定）。例如一个刚刚想出概念的项目要招标，指出现在就要确定价格和工期，而需求将在合同签署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%的功能客户从来不用”）。
若工期固定，应借助迭代交付，在工期完成时确保运营所需的最关键功能完整无缺，时间或老板会处理剩下的需求。
若价格固定或很在意价格，应借助优先级排序和迭代交付，使项目进入左右逢源的状态，以保证甲乙方可以有多种选择。
上述工作需要至少项目经理级别的人配合销售乃至老板完成，倘若一个普通的一线员工突然接到一个客户电话，让加上一个新功能，到底是拥抱还是阻止呢？请看下期需求开发与变更管理。
点击下载免费的敏捷开发教材：《火星人敏捷开发手册》
