并非所有企业都能拥有完备的软件开发团队，尤其是那些传统企业更是如此。由于各种原因，这些企业自身的软件开发力量非常薄弱，不得不借助外部软件供应商为其开发各类运营管理系统。
本文中，我将讨论传统供应商管理的合同形式及其弊端，以及分享如何采用敏捷合同来管理外包开发。
1. 传统的供应商管理合同形式及其弊端
传统的软件供应商管理合同形式主要有以下四种：
- 固定价格合同（Fixed Price）
- 目标价格合同（Target Price）
- 成本加酬金合同（Cost Plus）
- 包工包料合同（Time and Materials）
1. 固定价格合同（Fixed Price）
固定价格合同是最常见的合同形式，其主要特征为：
- 给出了固定的需求规格。
- 给出了固定的交付日期要求。
- 给出了固定的总价格。
- 如果发生变更，需要支付一定的费用。
固定价格合同是传统项目管理和瀑布过程的应用产物。在项目启动前，合同中就已明确了传统的项目管理“铁三角”——范围、进度和成本。
这种合同最大的问题在于：期望在项目前期就期望能明确所有需求和细节，并且作出关键决策。
然而，这时候却恰恰是项目不确定性最高的时期。此时进行关键决策，将为项目引入巨大的风险。
采用这种高度预定义的合同，会将项目实施过程中的变更风险全部转移到供应商头上。这就导致供应商非常厌恶和抗拒变更，缺乏主动响应变化的意愿。
当项目存在较强的不确定性时，不应当采用这种固定价格合同来进行管理。
2. 目标价格合同（Target Price）
由于固定价格合同的风险完全由供应商承担，出现了目标价格合同——甲乙双方共同分担项目风险的合同，具体特征如下：
- 给出了固定的需求规格。
- 给出了固定的交付日期要求。
- 给出了目标价格。
约定好当目标价格与实际价格出现差值时，双方如何分配差值的方式。
采用这种合同，当实际费用低于目标价格时，甲乙双方能够共同分享差值带来的利益；反之，当实际费用超出目标价格时，甲乙双方需要共同负担差值带来的亏损。
采用这种目标价格合同方式，虽然实现了合同双方的风险共担，然而并未从根本上改变一开始就明确所有需求和细节、并作出关键决策的项目管理方式。在项目过程中，供应商仍然厌恶和抗拒变化。
当项目存在较强的不确定性时，也不宜采用这种目标价格合同来进行管理。
3. 成本加酬金合同（Cost Plus）
区别于以上两种高度预定义的合同形式，成本加酬金合同具有以下特征：
- 给出了可变的目标性需求规格。
- 给出了可以调整的目标性交付日期。
- 付给供应商的费用是：供应商的运营成本 + 合理的利润。
采用这种成本加酬金合同，供应商不会厌恶和抵制变化，但却会带来另一个严重问题：所有的风险都转移到了甲方身上，乙方完全不承担任何项目延期风险；为了获得更多的项目执行收益，乙方更愿意拉长项目周期和加大工作量，由此可能出现低效。
成本加酬金合同貌似能够鼓励供应商主动响应变化，然而却会带来低效问题，并不推荐采用。
4. 包工包料合同（Time and Materials）
包工包料合同，也叫“人力外包合同”。随着越来越多的企业意识到软件开发的重要性，并且持续强化自身软件研发管理力量，出现了这种由乙方出人、甲方管理的合作模式。
包工包料合同的特征具体如下：
- 不存在完整的需求规格。
- 按照工作量来计费。
- 甲方负责管理项目，确定何时交付、何时结项。
这种合作形式，某种程度上已经接近于甲方的自建团队，貌似能够基于甲方业务需要而快速响应变化。
然而，开发团队毕竟不是真正的甲方自建团队。由此而衍生的问题是：
- 对于由乙方长期沉淀下的系统，甲方人员真地足够了解系统吗？
- 甲方人员真地具备足够的业务能力、技术能力和管理能力吗？
- 对于由乙方发放薪酬的团队成员，甲方人员真地能有效激励团队吗？
这种撇开乙方管理力量、由甲方大包大揽的合作模式，无法有效利用乙方的专业能力和管理能力，将所有的风险都转移到了甲方，对甲方要求过高。
2. 采用敏捷合同来实现与供应商的共赢
我认为好的供应商管理和敏捷合同，应当具备以下特征：
- 能够有效激发乙方响应变化的积极性。
- 能够有效利用乙方的业务能力、专业能力和管理能力。
- 能够有效激发乙方高效、高质量地完成软件开发和交付工作。
对于企业主要业务运营系统的供应商管理，建议以下敏捷合同管理形式：
1. 改项目为产品
在某客户现场，我遇到过这样一件事情：某银行S系统的一期项目是供应商A承接的。一期交付后，供应商A的这个项目团队解散了。半年后，银行又启动了S系统的二期项目，仍然是供应商A应标和承接项目。然而，新组建的二期项目团队却完全是另一帮人，他们不得不艰难地与一期项目遗留的代码和系统说明文档做斗争。这导致二期项目从一开始就进展得很不顺利。
这种传统的项目制运作方式，带来了两个非常大的问题：1）临时组建的项目团队，容易在人员、知识和经验上出现断层。2）需要攒一批需求，才能启动二期项目立项，而冗长的项目立项、招投标周期，又进一步阻碍了对业务需求的快速响应。
只有改项目为产品，才能令供应商建立长期稳定的开发团队，在人员、知识和经验上得到延续，并持续快速地响应业务需求。
2. 建立实现双方长期利益一致的合作框架
在单个外包项目中，甲方追求的是按期达成目标，而乙方追求的是合同执行利益的最大化，双方的利益是不一致的。
要想激发乙方，就必须实现双方利益的一致。这就意味着，要建立起实现双发长期利益一致的合作框架。
例如，甲乙双方签署长期稳定的合作协议，在某种程度上让乙方也能分享甲方业务增长带来的好处，例如带来更多的业务开发需求量，等等。
3. 采用精益-敏捷的思维和工作方法
传统的瀑布过程是不利于双方的透明和建立互信关系的。甲乙双方要采用精益-敏捷的思维和工作方法，统一研发管理的思维模式，并约定好双方的工作过程和方法。例如：
采用精益创业方法来控制史诗需求的风险。
- 采用小版本短迭代来进行工作的规划和开发。
- 采用用户故事和验收标准来控制需求质量。
- 统计迭代速率，作为规划基础。
- 控制迭代开发的并行数量。
- 采用可视化手段，对过程保持透明。
- 迭代中及时进行已完成故事的验收。
- 。。。
通过采用精益-敏捷的思维和工作方法，能实现透明和信任，控制风险、更高效地开发和交付。
4. 明确双方的职责边界
明确甲乙双方的职责边界，在保证甲方利益的同时，避免对乙方工作造成过多干扰。例如：
甲方的职责：
- 甲方负责定义系统的使命和愿景。
- 甲方负责确定的业务解决方案。
- 甲方负责验收和发布业务功能。
乙方的职责：
- 乙方负责提供长期稳定的全职能开发团队。
- 乙方负责承诺版本计划、迭代计划，和完成高效地开发交付。
- 乙方在开发过程中，向甲方保持透明。
- 乙方负责按照SLA要求，完成系统运维工作，确保线上问题能够得到及时有效的解决。
甲乙双方的共同职责：
- 甲乙双方共同确保按照精益和敏捷的方式来进行工作。
- 甲乙双方共同建立和维护业务的解决方案、特性和路线图。
- 甲乙双方共同确定当前版本及下一版本的内容和交付时间。
- 甲乙双方共同确定迭代的目标，基于客观的系统演示来评估进展和验收工作成果。
3. 您怎么看？
您的组织存在外包开发吗？是如何管理外包开发的？您认同以上敏捷合同管理方式吗？欢迎在下面的评论中分享您的想法。
作者：李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练
