一位拥有 17 年经验的项目经理，历经上百个项目后深刻体会到：甲乙双方实则是 “命运共同体”，如同一双筷子，唯有配合默契才能成事。本文将通过几个亲身经历的案例，剖析合同签订与执行中的 “门道”，探讨如何在明确权责边界的基础上，实现双方的风险共担与合作共赢，为项目的顺利推进扫清障碍。

作为一个在软件行业干了17年的项目经理，经手过上百个项目后，越发觉得甲乙双方的关系像一双筷子——单拿一根夹不起菜，凑成一对才能成事。合同盖了章，双方就成了命运共同体，一荣俱荣，一损俱损。

今天借着几个亲身经历的案例，跟各位同行聊聊合同里的“门道”。

Part 01 技术协议的“模糊艺术”：项目无限延期，“老司机”也栽了跟头

提到合同，就不得不提最让人头疼的这个项目。

那是前几年，我们接到了一个与各业务系统实现数据贯通的项目，类似于建设一个业务中台，打通上下游系统，客户是某集团的生产单位。

项目技术协议中除了商务部分、技术要求部分，还附带用户功能需求方案。跟我们对接的甲方项目经理是信息化业务负责人，在商务谈判等方面经验丰富，非常懂得控制技术协议的“艺术”，把需求写的比较宽泛，范围界定的比较模糊。

在当时看来，他这么做的初衷是帮公司实现利益最大化，也无可厚非。我们呢，因为协议中也规定了，项目实施之前，有方案评审和需求确认的环节，而且开发前也进行了原型签字确认，所以对于协议也没有过多担忧。

谁知道这份“敞着口”的协议，为后期我们和这位项目经理的工作埋下了“大坑”。

要想“数据贯通”，就意味着要与企业的门户、ERP、MES、LIMS、PDM、财务、合同等全栈系统做集成。看似明确的需求，背后却牵扯甚广。

比如协议里只要求了要“完成与ERP系统的集成”，但业务部门在项目实施时却提出要求：数据要实时同步、数据要分批次推送、数据要清洗、审批流程结束要反向触发ERP操作…

就拿“流程审批”这个功能来说，通常情况下，任何一个流程的发起、审批、完成，都是在自己的系统里面完成的。但是在这家客户单位，所有的数据都起源于其他系统，作为独立的异构系统，需要先把数据接过来做一个整合，再做流程的推进。所以，业务部门的这些要求在前期建设需求方案，以及后期项目实施和运维阶段，都给我们带来了巨大的沟通成本和工作量。

一个简单的ERP系统集成工作，我们在与甲方项目经理和业务部门反复沟通后，至少做了30个接口，原本15人天就能完成的工作，我们花费了3人月才完成。

在这个过程中，业务部门复杂的业务需求，也让甲方项目经理身心俱疲，他私下跟我叹气：“协议里没写清楚范围，业务部门一提需求，领导就觉得是‘分内事’。我若拦着，反倒成了‘阻碍业务’的罪人。”

当初的“好心”最终办成了“坏事”，项目延期半年，这位项目经理的年终考评受了影响，我们团队的口碑也蒙上一层灰。

**关键问题：**甲方项目经理凭借“宽泛的协议条款”，看似是为业务部门争取到了“额外”的权益，但从长远来看，这是为自己的工作埋下了“坑”。有了协议的加持，后期做再多工作，业务部门和领导都会认为这是项目经理的本职工作。反之，如果在协议约定很具体的情况下，项目经理能够协调乙方多做一些工作，领导才能认为这是为企业争取到了额外利益。

如果项目能提前结项，是甲方项目经理的成绩；如果项目延期，即便是让乙方背锅，对甲方项目经理来说，也不可能被嘉奖。只有在清晰的“边界”下，甲乙双方约定好各自的权责，才能真正做好项目交付。

Part 02 当“君子协定”撞上“铁面审计”：合同条款才是项目验收的依据，侥幸心理要不得

再讲个实验室管理系统建设的项目。

当时，客户需要上线一套LIMS系统，实现实验室“人机料法环”全要素的管理。

因为我们在此之前做过几个同类型的项目，有一些经验积累和标杆案例，所以在与这个客户对接需求和商务洽谈的过程都很顺利，客户对我们提出的方案也很满意。只是在签订合同时，合同条款中对于有些产品功能的描述，跟前期对接的需求不一致，甚至难以实现。

比如关于“实验任务分配”这个功能，技术协议中写道要实现“系统自动生成实验任务。系统应根据每个人默认检测项目、当前任务数、今日完成任务数、本月完成同类任务数等关键信息，进行任务自动分配”。但是由于实验室中每个岗位的任务分配逻辑都是不同的，所以实现起来非常困难。

对此，我们跟甲方项目经理商量道：“其实以‘小组’为单位来进行实验任务划分就能满足咱们的需求，这样写是不是范围太广了”。他给出的回答是：这是集团对于LIMS系统的一些设想，我们也觉得不好实现，但是领导提过了，就加上吧。并且向我们承诺：后期不按合同来，只要能实现6个检验小组的实验任务自动分配，到时候再由主管把每个人的任务手动分一下就行了。

毕竟是合作多年的老客户，这个回答让我们放下心来。但是没想到，在项目推进到后半程时，客户集团更换了领导人，新上任的领导实施了一系列现代化企业改革的举措，尤其是加强了对项目的审计追踪，严格审查项目和合同“两张皮”的情况，这可给我们的项目交付出了个大难题。

毕竟，项目验收是要一条条卡合同的，即便前期商量的再好，也抵不过合同上的白纸黑字。

最终，即便项目已经进行到后半程，有些功能实施又要重新来过。我们跟甲方项目经理一起找出合同，一项项的比对，单是“实现每个人的实验任务自动分配”这个功能，我们就额外做了大量的定制化，比正常预估的工作量多出270人天。

结果就是，我们承担了更多的成本，甲方项目经理也因为“对需求把握不准”而被领导问责。

**关键问题：**有些功能并不见得好落地，但又不得不写到合同里，这不仅给我们的交付“挖坑”，也给甲方项目的验收“挖坑”。我相信，当甲方项目经理在承诺“后期不按照合同卡你们”时，是真的这样想的，但是随着内外部审计越来越严格，在遇到制度要求或者其他变数时，他也没有办法。

项目验收必须严格依据合同条款进行，任何前期的口头约定或非正式协商，都无法替代书面合同的效力。

Part 03 甲乙双方是命运共同体，同一战壕的战友

在项目上干了这么多年，我最深的感悟是：甲方项目经理和乙方，其实是命运共同体，是同一战壕的战友。

某次项目复盘会上，我们长期合作的一个甲方信息中心负责人说了句大实话：“我是你们的甲方，同时也是我们业务部门和领导的乙方，所以我也希望合同写的越明确越好，这样对双方的权责有个界定，你们能按期完成，我也好交差”。

高质量合同的核心是“客户满意、风险可控、正现金流、合理利润”。高质量合同，除了能给客户带来正向的商业价值，还应该让双方都能规避潜在风险，最终实现双赢。如果我们乙方在项目前期不计成本、不识别风险，将这些问题都放到交付环节，那么不仅会造成自己的损失，也是对客户的不负责任。

如今我带团队做项目，必守三条铁律：

1）建立“命运共同体”共识

与甲方项目经理达成共识：甲乙双方不是对手，而是风险共担、合作共赢的“搭档”。只有把项目做成了，才是双方共同的成绩。

2）加强合同一致性评审

加强“从需求到方案”“从方案到标书”“从标书到合同”的一致性评审，只有将需求精准写入合同，并严格履约，才是规避风险的最优解。

3）做好需求变更管理

协议中标注清楚：“超出本协议范围的需求，需双方另行签订商务条款”。

说到底，无论是对甲方而言，还是对乙方而言，做项目拼的不是谁更“精明”，而是谁更“厚道”。白纸黑字厘清边界，才是对彼此最大的尊重。

共勉。

本文由 @数智前沿洞察 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务