对项目交接的一些思考
天下大势，分久必合合久必分。这些年交接了很多项目，也从别人那里接手了很多项目。最近又接收了一些项目，但团队接收的效果不是很好，或者说掌握的不全面，所以就在想怎么能够做的更好一些？
团队关系
其实我觉得这个是比较重要的。
因为首先在心态上，凡是要把项目交接出去的团队，肯定是另有安排了，从各种方面来看都得在新方向上努力奔跑，这些交接的内容价值不是很大。
其次交接是个良心活，就像师傅教你功夫，你啥都不懂，本来有一百招，但是给你讲的多明白、有没有讲全，没有什么标准。
这不是说交接的团队有什么问题，而是大部分时候普通人的正常反应。所以和交接的团队保持良好的关系，一是能够在资料梳理、内容讲解上更用心一些，另一点是有问题的时候也好咨询。
如果搞的很僵，很多事情会比较难办。
资料整理
资料整理一般按照模块来整理，把内容梳理好，方便大家查找。也需要指定交接人，算是完成交接仪式。
| 内容 | 资料 | 交接人 |
|---|---|---|
| 技术文档 | ||
| TCE | ||
| FAAS | ||
| Cron | ||
| Git | ||
| 数据库 |
交接讲解
我比较喜欢的讲解流程是这样的。
首先过一下整个场景，真实的体验一下功能，这样大家对会对功能有初步的了解。
- 在讲解的过程中，对于比较重要的地方，让大家看看对应的接口，入参和输出结构。
- 其他同学也会思考可能是怎么实现的，有利于带动大家的情绪。
其次开始讲架构
- 有哪些服务，它们之间的关系是怎样的
- 这些服务有哪些接口和模块
- 数据是如何流转的
掌握
其实无论如何讲解，接收人都很难立马深刻的理解这些内容，毕竟代码不是自己写的。
所以对于接收人有几个要求
- 进行反串讲：可以在一个星期或者两个星期内，给交接的团队再进行一次讲解。这能push接收人去读上面的资料和代码，更加深刻的理解交接内容。
- 跟进问题：可能不会很快有相关的项目，但肯定有报警，这时候需要接收人跟进报警。查问题是快速领悟整个系统的方式。