Scrum_tp11

如何采用敏捷合同来管理外包开发

并非所有企业都能拥有完备的软件开发团队,尤其是那些传统企业更是如此。由于各种原因,这些企业自身的软件开发力量非常薄弱,不得不借助外部软件供应商为其开发各类运营管理系统。

本文中,我将讨论传统供应商管理的合同形式及其弊端,以及分享如何采用敏捷合同来管理外包开发。

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中文网资深敏捷顾问和培训师,敏捷教练