项目做到一半，对接的开发人员换了。开发方通常轻描淡写说一句正常调整，甲方的担心却是实实在在的，新来的人要重新摸索，工期会不会拖，做出来的东西能不能接得上。
这件事甲方不能完全控制，但有几件事可以做，让影响降到最低。
一、先判断影响有多大
换人不一定都影响大。如果走的是普通开发，项目有完善的文档和明确的模块划分，新人接手相对容易。如果走的是从项目一开始就在、所有业务规则都在他脑子里的核心成员，影响就大了。
判断影响可以问几个问题。走的人负责哪部分，这部分有没有文档，接手的人有没有参与过这个项目，交接安排了多长时间。这几个问题问下来，情况基本清楚。
交接时间是个关键指标。开发方说下周就换人，通常意味着没有交接，新人要边做边猜。合理的交接至少有一到两周的并行期，双方同时在场，走的人把知道的事情讲清楚。
二、要求一次像样的交接
甲方可以要求交接有输出物，而不是两个人私下聊一下。输出物至少包括，负责模块的说明文档、待办事项和遗留问题清单、关键决策的原因记录、外部对接方的联系人。
其中关键决策的原因记录特别重要。为什么这里这么设计、当初为什么否掉了另一种方案，这些信息如果没留下来，新人很容易把已经论证过不行的方案重新提出来，或者在不了解背景的情况下改掉一处关键逻辑。
可以要求交接结束后，让接手的人做一次复述。把业务流程和负责模块讲一遍，甲方和开发方一起听。讲不清楚的地方就是要补的地方。这个做法很有效，成本也不高。
三、从源头降低这类风险
签约的时候可以约定人员稳定性相关条款。比如关键岗位人员在项目期内变更需提前通知，变更后要保证交接质量，因交接不到位导致的延期由开发方承担。这类条款不一定经常用得上，但写进去对开发方是个约束。
另一个做法是要求项目组至少有两人熟悉核心业务模块。也就是不要做成一个人全懂的结构。这条要在合同或方案里写明，作为交付质量的一部分。
甲方自己也能做点事。把重要的确认结论留在书面上，别只在会上口头说。这样即便对接的开发人员换了，新人翻记录也能搞清楚之前定了什么。
四、换人之后要盯紧这段时间
换人后的两到三周是风险高发期。这段时间建议提高沟通频率，把原来每周一次的例会改成每周两次，重点看新人做出来的东西是不是跟之前保持一致。
还要留意几种迹象。新人反复问已经确认过的事情，说明交接没做到位，要提出来。新人对自己负责的模块说不出整体业务流程，说明理解不到位，也要提出来。变化不一定是坏事，新人有时能发现问题，但变化的理由必须说得清楚，否则就是偏离。
如果换人之后问题持续超过一个月还没好转，要正式跟开发方谈一次。问清楚后面的人员安排，必要时提出调整团队的要求。这类事情早说比晚报好，拖到项目末期再说，双方都没有腾挪的余地。