固定总价合同的项目实施已跌入低谷｜践行者第26期

固定总价合同的乙方项目实施的底层逻辑是什么？为什么说固定总价合同的项目实施已跌入低谷？合同的选择因人而异、因时而变。本期践行者邀请到了中软国际教练团队项目实施的敏捷教练张洋老师，和我们分享固定总价合同的项目实施！

一、直播实录

Q1：您为什么会选这个话题?

我作为一个大型乙方组织中软国际的敏捷教练，主要负责支持团队。当一线交付团队面临困难，我就要深入组织里支持大家。然而，由于时代和整体背景的变化，固定总价合同面临着许多困难，极大地考验了项目管理者的能力。许多项目管理者经常加班到深夜，但因为没有意识到固定总价合同中的风险而辛劳白费，最后反而赔了钱。我在实践中遇到了很多这样的案例。

我分享这个主题的初衷是让大家拥有实践经验，并在自己的项目合同中落地。特别是在乙方项目实施过程中，我们更要注意固定总价合同可能出现的问题、避免的风险、公司如何盈利、如何达到甲方业务目标。

Q2：如何看待现在很多项目仍在使用固定总价（FP）合同？

近年来，我带了很多项目，规模从几百万到上千万不等，这些项目都采用了固定总价合同。但固定总价合同在合同层面上无法准确识别风险，只能在项目管理中逐步发现。无论是甲方还是乙方的领导，大家心里都没有把固定总价合同作为首要关注点，而项目管理者也没有充分认识到潜在风险。在这种情况下，大家识别不出来风险，项目管理者也没有风险控制意识，这些风险最终就会造成甲方不满意、乙方赔钱的后果。

Q3：固定总价合同的底层逻辑是什么？

在业内有两种常见的合同类型：TM合同和FP合同。TM合同（Time&Materials）是指工时合同或人员外包合同，按照人员的成本（人/天/月）支付费用，并要求遵守甲方的管理。而FP合同（fixed price）是首先确定项目范围，乙方据此提供技术服务后我们进行报价，合同中设定目标范围，由乙方负责具体实施和承担项目风险。因此，TM合同和FP合同之间存在显著差异。

FP合同的底层逻辑在于识别项目风险，即项目经理能否将风险隔离在整体合同之外，并能够控制或有效解决风险。甲方更希望乙方来承担项目风险，以省心。如果甲方无需保留风险，直接使用TM合同是非常合理的，因为可以进行调控。此外，一种观点认为，合同实施之前甲方是监督者，而在实施后，甲乙双方成为合作伙伴。因为在交付阶段，甲方不能随意更换供应商，一旦交付失败，甲方会遭受巨大损失，最后将甲乙双方都困在FP合同中。所以在业内的许多甲乙双方都在共同探索新的模式，以使项目管理更加顺畅，并确保FP合同最终实现约定的目标。

Q4：TM合同和FP合同的区别

TM合同和FP合同的区别在于风险控制。TM合同适用于甲方具备技术能力或对项目有把控能力的情况，甲方可以直接承担项目并成功完成，因此被认为没有风险。而FP合同适用于甲方无法控制风险的情况，这些风险可能来自内部或外部，甲方希望将风险转移给乙方，并愿意支付更多费用以确保项目风险得到控制。这是两种合同之间最根本的区别。

Q5：选择合同类型时需要考虑哪些因素？

作为甲方，当你有着巨大的管理和技术能力时，为了保证项目的顺利实施，TM合同是比较合理的选择。这意味着你可以要求乙方提供人力资源、知识、创造性人才。TM合同虽然会存在一些问题，但对于甲方是比较有利，且对于乙方也是更容易接受。
对于乙方来说，如果风险较高的项目，通常会采用FP合同。实际上，这不是一个最佳的选择，只是一个无奈之举。因为项目存在许多风险，甲方觉得自身无法控制，只能将其委托给乙方进行协助处理。在甲方看来，甲方认可乙方的技术能力和项目管理能力，相信乙方能够把事务处理好，如果处理不好将采取法律途径解决。因此，乙方是被动接受方，没有选择的余地。

Q6：什么原因导致FP合同实施困难？

• 时代背景发生了变化。

在行业发展初期，甲方是业务服务方，而乙方是技术提供方，这是一种有利的合作模式。但现在情况不同，现在的企业都在进行数字化转型，以至于业界有一种说法：每家企业都是一家IT公司或信息服务公司。在VUCA时代，很多技术蜂拥而至，业务越来越讲究细节，业务的变化性越来越高。在这种背景下，企业想要深入了解业务或掌握高深的技术并不容易，而且过度注重反而会成为给对方提供服务的难点和风险。现在业务变得越来越复杂，我们无法掌握所有的变化，这也给我们带来了更多的风险。

• 组织结构发生了变化。
在复杂组织结构下，进行FP项目肯定会受到许多组织层面的影响。因此，从宏观层面来看，签订FP合同之前，行业背景对FP合同有着巨大影响。然而，没有人能够将这些影响整理清楚并传达出来，以规范化的方式告诉你存在哪些风险。今天我们的目的就是探讨这些风险的本质，并讨论如何掌控它们。

Q7：有哪些因素影响了这些情况？

• 合同风险外溢

FB 合同的底层逻辑是风险从合同之外溢，在前期无法识别出来。回顾整个项目招标的流程，销售需要在场，把解决方案提出来，随后交付再入场，入场后大家最终对所提出的技术方案达成一致，并签订FB合同。

在交付入场时，其实合同的框架和价格已经确定，此时在框架和价格之下进行交付，很多风险就已经外溢，并转移到了项目经理等关键角色身上。

• 组织管理问题

作为乙方的项目经理，首先会遇到组织机构的问题。甲方组织结构通常是复杂的，原来的甲方组织机构基本上是7-9层的架构，作为甲方老员工都有可能不清楚整个组织机构的情况，作为乙方员工更加难以了解整个组织，更难识别出问题。在这种情况下，就要搞清楚：这个庞大的甲方组织结构对我FP合同的实施有什么风险？

在项目管理中，大家经常遇到的都是各种技术风险，我们能解决的技术问题是有限的，需要与技术负责人、架构师沟通，然后他们再和项目经理沟通。这时问题在沟通的基础上就变成了管理问题。当双方项目经理都无法解决问题时，问题就上升成组织问题，这可能涉及多个部门的协作。

举例来说，我在一家制造企业中，甲方与一个供应商合作，该供应商属于甲方组织结构中二级分公司，而该供应商又与另一个硬件供应商合作。这个硬件供应商与我们甲方既没有合同联系，也没有直接服务联系，但他们确实是为甲方提供服务的供应商。也就是说组织结构的复杂性使得问题需要通过多层级的沟通来解决，而在复杂的组织中进行沟通时，首先很难找到关键角色并与其达成共识，而这又带来了另一层难度。

• 组织架构问题
说到组织，这是一个非常令人头痛的问题。组织架构决定了业务架构，业务架构决定应用架构。由于组织原因，应用架构都非常复杂庞大。作为项目经理是无法立即识别或短时间内识别出应用架构的细节。所以如果能够理清应用架构，就能够识别组织架构和应用架构问题，从而有效控制FB项目的风险。这样，在实施FB项目时就能够取得良好的效果，避免亏损。

Q8：FP合同面临复杂的环境该如何破局？

FB合同在签订之初，项目经理的参与度不高，很多风险没有在合同中明确标明，使得风险外溢，在项目管理中会受到很多的挑战和风险。我们要注意以下三个方面：

• 组织问题。通过IT部门的关键角色，了解清楚甲方的组织架构，这可以更好地了解与项目相关的关键人物和职能，以便后续的沟通与交流。如果沟通不及时，可能会出现目标不一致的情况。

• 应用架构问题。如果不识别应用架构，就像在别人已经画满的纸上作画，在寻找一个合理路径的同时，还要规避应用风险、安全风险、数据风险。应用架构并不困难，困难在于与各个部门沟通并落地，应用架构的落地需要与上、下游进行集成，而这些问题都是需要在前期识别与把控的，但往往在前期的解决方案中没有真正理清。

• 业务复杂度问题。企业在信息化上已经进行了十几年，如果要成立新的系统，那么其业务复杂度和业务积累度是非常高的。这需要在前期调研清楚，但这并不是那么容易控制。甲方业务人员无法表达业务点，而业务分析师或产品经理对甲方业务了解不够深，这就会导致需求范围在项目实施过程中不断地蔓延和扩大。在项目实施过程中，需要有需求管理的能力，在前期将需求真正梳理清楚。

Q9：有哪些破局的新方式和新机遇？

以一家世界500强制药企业为例，该企业认为FP合同已经不适合当前情况，但为了嫁接风险仍然采用FP合同。

我们的新玩法是什么呢？
1. 采用一种以敏捷合同为主的模式，这是一种新的框架模式，与现在的MVP产品迭代实施息息相关。
2. 打造一个MVP产品，选择最有业务价值的部分开始打造MVP产品。
3. 在前期可以签订一个较小的合同。获得MVP产品后，可以定义后续迭代来完成整体产品，并将有效的风险转嫁给乙方。乙方可以预知需求范围、交付时间和所需资源的情况。在这样的合同下，风险可以得到控制，甲方和乙方之间能够达成默契的合作。
4. 在与这些企业合作的过程中，合同本身是一个框架合同，类似于TM的合同。如果框架合同无法给出总价，预算申请就会受阻。在这种情况下，可以采取多申请的方式。针对Epic进行预估预算数值，根据预估值申请预算。
这类敏捷合同的方式能够减少过程中的风险，并能够解决固定总价合同中乙方无法控制风险的问题。这是一种新的方法，我们正在不断推行，行业内也有许多企业早早意识到这个问题，并开始采用这种模式，而不仅仅是简单粗暴地采用FP合同。

Q10：什么样的项目适合FP合同？

FP合同的底层逻辑是甲方将一些风险抛给乙方时，他更希望乙方能承担这些风险并有效地把控风险。但当乙方有话语权，可以将一些风险交还给甲方时，这些项目更适合FP合同。

Q11：Scrum Master应该具备什么能力？

未来，项目经理是一个非常有发展潜力且不可或缺的角色，因为他们领导整个团队实施执行项目。在行业内，除了产品负责人和项目经理可能是确定的角色，其他的人是临时组件的团队成员，所以项目经理在项目过程中起着巨大的作用。如果想要成为好的项目经理，我建议先挑战一些高难度的任务，从乙方做起，在微权力之下，努力把项目实施得好，把自己的职责做好，然后再逐步迈向更好的发展。

与项目经理相对应的角色，我认为并不是敏捷教练，而是Scrum Master。Scrum Master实际上是一个团队级别的角色，它负责的团队规模较小，通常是7-8个人。然而，Scrum Master对自己的定位可以相对较浅。我认为你能晋升到团队层级会更有优势，因为你管理的范围会大大增加，不再仅限于7-8个人的团队，可能会扩展到更大的团队。

在这样的基础上，如果你能有效地管理团队，这在晋级过程中非常有利。Scrum Master应该具备的软技能大于硬技能。这些软技能无法从书本上学习，只能在实践和经验当中学习。

硬技能包括三个方面：
• 业务相关的深层技术栈；
• 针对IT项目管理或技术项目管理的技术栈，包括需求管理、研发管理、质量管理等；

• 针对目前流行的技术或所擅长的技术，比如在Java开发、微服务、数据库等。

在软技能方面包括三个方面：
• 沟通能力。如何识别出需要进行沟通的关键角色，以及如何通过沟通拉近双方的分歧。
• 沟通方式。如何确保团队的目标一致，以及如何使个人目标和团队目标与团队目标保持一致。
• 处理事务的思维能力。这个非常重要，很多人在逻辑处理过程中往往抓不到主线，总是陷入一些支线问题。
可想而知，项目经理这个角色是非常重要的，同时他们所拥有的能力和技能是非常的多，因此在市场上的价值很高。在市面上很难找到60分以上的项目经理，我每天面试了很多项目经理都很难达到我的预期。

Q12：项目经理如何度过“35岁危机”？

我现在招聘的项目经理基本上都是35岁以上的人，因为市场上真正合格的项目经理非常稀缺。他们的成长路径就可以说明这一点。就我个人而言，我以前是开发人员，从事过开发、架构、需求分析等工作。因为我对金融领域的业务有深入的了解，成为项目经理后，我还会给业务人员讲业务。当时是银行业界理财爆发时期，理财业务和我们项目组都在不断扩大，我成为项目经理后在业务方面积累了很多经验。

对于这些岗位来说，要真正理解并胜任可能需要七八年的时间。在这个岗位历练并真正掌握硬技能后，还需要积累软技能。“先做人，后做事”，这句话对项目经理来说可能有点虚，但是从我的视野来看，与他人沟通的方式和能力非常重要，能够使大家达成共识。如果没有十年的积累，我认为担任项目经理可能还欠点火候。

现在的小伙伴们工作时可能都二十五六岁了，再给他们十年时间积累，他们36、37岁才能真正成为合格的项目经理。我更喜欢35岁-40岁之间的项目经理，我认为“35岁危机”并不存在，你真正需要把握的是行业风向。“管理层存在年龄危机”这个观点，我认为是不成立的，因为“35岁危机”是技术层面的问题。因为很多35岁的同事由于家庭稳定或外界干扰因素较多，他们的关注度可能会下降。在这种情况下，他们学习或工作时间会受到一定的挤压，那用人单位可能不太会选择你。

Q13：信息化项目行业现在有监理吗?

在信息化项目中，甲方一般不会派监理的角色。监理的主要职责是把关质量验收，确保最终的交付物符合验收标准或质量标准。在项目的最后阶段，我们会进行UAT（用户验收测试），以及线上的Alpha测试和Beta测试。这些测试环节会有效地保证我们交付的产品能够被用户验收，并能达到业务价值。

二、送给大家一句话

成为一名合格的项目经理是一条很艰难的路，但就因为难，所以才有价值和意义。我在这个行业干17年，将近10年都在做项目经理，还是坚持在一线去干项目经理的角色，但是我觉得在一线支持小伙伴们渡过难关，或者说给大家分享一些经验非常非常好，也希望大家能够继续努力。