观点来自楼上各位，做了一个总结:

### 充分沟通和了解，对方的意图

站在他的立场下去充分了解，他做出这个决定的初衷是什么，冲交谈中获取一些信息，帮助了解他目前的状态
*离职无非一是心累，二是钱没到位*

### 表示理解，自己全力配合
如果是因为一些其他原因，表示愿意配合协调各方面的因素还是愿意对方留在目前项目里面，当然对方实在不愿意那就算了，现在不合作，将来还有合作的机会，眼光放在长期合作商

* 确认肯定他目前的工作和贡献，表明他工作的重要性
* 梳理业务目标，看看有没有对方喜欢的方向
* 给他设定新的业务挑战目标，看看对方有没有兴趣
* 带人的需求，作为管理者去统筹组织管理，管理能力，技术架构
* 对新兴领取感兴趣如AI,看能否有机会提供这样的机会，并培养候选人平滑过度

### 换位思考，把问题也抛给对方
明确的表示支持他的决定，在此基础上也把自己的担心说出来，项目延期，接手困难这些问题也抛给对方，看看有什么好的顺滑的解决方案没有，祝福对方

要求对方的业务进行梳理和拆分，提供详细的文档或交接手册，让继任者可以快速的接手这个项目

非技术人观点：这个情况先与当事人沟通，充分了解想法，然后一起核对下工作内容，是否还可以优化的地方，帮助提高这份工作在他眼里的期望值，或者让他试着成为这项业务的管理者。

另外，还可以思考下为什么这份工作，同组的其他人会很难胜任，是对其他组员的低估或者是管理分配上有些问题导致能力成长有落差。

理论上一个好的团队应该少了谁都能和原先保持一样，但是对个人而言，肯定是提高自己的不可替代性。所以这里应该也会有一个平衡性。

经历过团队骨干流失的情况，也做了沟通，顺便给自己带来了一些思考总结，后续做了一系列的管理优化。
1.骨干人员负责了一些其他人暂时不能快速胜任的模块。这是风险，侧面反应了组内的培训工作做的不充分，加大培训力度，避免出现某些模块或功能仅有1个人熟悉。
  阶梯式培养，给大家更多的机会，每个组员都交叉负责模块，降低某个人员流失带来的影响，降低交接成本。
  需求分析和设计文档让一个人去负责，开发调试让另一个人负责。
2.骨干人员流失的一部分原因也是没能给他提供更好的指导，回想其实骨干也有很多提升的空间，但当时没有给予良好指导，让其感觉没有挑战的目标。
  对骨干人员的培养也是很重要的一部分。有对技术感兴趣的，有对管理感兴趣的，需要给予更多的机会。
3.在项目方面之前能出现只有骨干人员才能胜任的功能，有一部分原因出在有些时候为解决一些特殊问题时，选择了更复杂更难维护的方案，长时间叠加起来，愈发复杂，新人很难接手。
  后续从项目可维护性考虑，在选择方案时，会尽可能的选择合适的方案。当没有完美方案的时候，尽可能的不增加业务维护的复杂度。
总结就是加大所有人的培养力度，给每个人更充分的发挥空间，并尽可能的给每个人以合理的指导。对于人员流失，原因太多，基本上是想走的留不住。