甲方对接人换了，项目怎么不脱节

项目走到一半，甲方的对接人调岗或者离职，是常有的事。新来的人对项目没有上下文，容易把已经确认过的事情重新拿出来问，也可能推翻之前谈好的方案。项目因此停摆一两周很常见。

这类风险可以提前对冲，成本不高，但多数项目没做。

一、让每件事都有书面记录

对接人换了会脱节，根本原因是信息只存在于这个人的脑子里和聊天记录里。凡是有书面记录的，换谁接手都能续上。

要记录的内容包括，需求确认结论、变更的来龙去脉、待定项的跟踪、每次评审的纪要。重点是要记清楚谁在什么时候确认了什么。有了这一条，新对接人翻一遍就知道已经定下的事，不用重新讨论。

记录不必复杂，一份按时间倒序排列的变更记录就够用。每条写三行，改了什么、为什么改、谁确认的。看起来简单，但坚持做下来的项目很少出现脱节。

二、让甲方这边不止一个人了解项目

只有一个人对接，这个人一变动，信息断点就出现了。比较稳妥的做法是在甲方内部至少保持两个人对项目有基本了解，一个主对接，一个备份。

备份角色怎么设置。可以在每次评审会的时候轮流参加，或者每次会议纪要都抄送给他。不需要他深度参与，只要知道项目在做什么、进行到哪一步、有哪些悬而未决的事。

如果项目涉及多个业务部门，每个部门最好也有一到两个人知道跟自己相关的部分。这样即便主对接人变动，业务侧的连续性还在。

三、交接清单要能自解释

真到了换人的时候，一份好的交接清单能省掉大量沟通。清单应该包括项目当前状态、已经完成的部分、正在做的部分、待办事项、所有待定问题、关键联系人和各自的职责。

写清单的时候注意一个原则，假设读的人完全不了解项目。凡是缩写、内部叫法、约定俗成的说法，都要展开说明。开发方内部常用的模块代号，在清单里要写清楚对应的业务含义，否则新对接人看不懂。

清单里还要包含账号和访问地址。测试环境地址、演示账号、代码仓库、文档目录，这些不写清楚，新对接人连东西在哪都不知道。

四、对接人已经换了，怎么快速拉回正轨

如果事情已经发生，建议安排一次专项交接会，控制在两周内完成。

交接会分三步走。第一步由开发方做一次完整演示，从业务流程开始，把系统已实现的功能过一遍，让新对接人建立整体印象。第二步过一遍变更记录和待定项清单，逐条确认是否还有效。第三步确认后续的沟通机制，例会时间、对接方式、决策人是谁。

这个过程中，之前确认过的事情原则上不再重开。如果新对接人确实要改，按变更流程走，评估影响之后再定。守住这一条，项目就不会因为换人而反复推倒重来。