今年冬天不太冷，IT行业有点冷。现在很多公司都处于“人才优化”，“末尾淘汰”过程中，开猿节流在所难免。我们公司第三方同事所在的公司今年没有中标，因此他也面临着走人。于是就有了本文中提及的项目交接过程。

1.项目交接文档

  在项目交接的过程中最好自己提前准备一个交接清单，列出来自己需要的一些资料。如果不清楚话，可以问问有经验的同事，也可以假设比如自己向别人交接工作，怎么能够使对方明白呢？网上很多网友列出来有以下一些资料：
从测试环境和生产环境两个方面进行列举
网站框架、Web地址:端口、网站部署地址、当前部署的网站是不是最新版
若访问网站部署地址是否需要远程连接/TeamViewer
网站登录账号
系统使用了哪几种数据库，如：SqlServer、Oracle、MySql……
数据库部署地址、数据库表结构是不是最新版
若访问数据库部署地址是否需要远程连接/TeamViewer
数据库登录账号
App框架、下载地址、下载地址中App是不是最新版
App登录账号
系统使用了哪些服务，如：WebService、Windows服务、Ftp、Tomcat……
服务框架、Web地址:端口、服务部署地址、当前部署的服务是不是最新版
访问服务部署地址是否需要远程连接/TeamViewer
服务登录账号
如果想修改服务的端口号需要改哪些地方
如果想重新部署该项目该怎么做
网站、App、服务是否需要提供图片、Word、Excel、Pdf等资源给用户下载
供用户下载的资源存放在哪里，写在哪个配置文件中
网站、App、服务是否需要用户上传图片、Word、Excel、Pdf等资源
用户上传的资源存放在哪里，写在哪个配置文件中
除资源存放路径配置项外，还有哪些重要的配置项
该项目有哪些遗留问题
该项目的SVN、Git地址
该项目甲方联系人、联系方式

2.业务相关文档

  除了这些内容以外，还需要向项目交接人了解一下项目的接口信息，业务逻辑，API接口文档，项目运行过程中常见的问题及解决方案。如果这些资料项目交接人也没有怎么办呢？我就遇到了这种情况，这个项目我实在想象不出当初是怎么开发的。什么文档都没有，遇到这种情况时，就只能自己把文档写出来。把文档写出来一方面可以加深自己对于项目的理解，另外一方面可以便于以后项目的交接方便。
我当初为了理解业务，跟测试的同事要了两个项目相关的测试用例，一般情况下，测试用例是很详细的。结合第一部分提及到的相关测试环境和生产环境中交接的账号可以登录到测试环境和生产环境中，自己走一遍测试用例，并且把每一步都截图，方便自己后期理解查阅方便，最后总结成测试流程文档。
为了更好的支持项目，还需要了解一下项目相关的责任人。一个项目可能涉及到好几个团队，及时是一个团队内部也会有客服，开发，需求，运维，项目经理等等分工。如果涉及到外部团队，就会有接口对接的需求。这就需要我们理清楚相关的负责人是谁。可以画一个思维导图，以项目为中心向外辐射出外部团队，客服，运维，开发，项目经理等等。
通过测试用例可以熟悉业务，但是有些项目是只提供API接口的。因此，我们还需要把测试环境或者生产环境中的操作和后台的API接口要对应上，我这次对接的项目就设计到这个问题。前端把我们的API接口封装了，我向他们要了一份前端路由和后端接口的对应文档。
接下来就需要开代码写一个API接口文档了，记录一下接口的地址，入参和出参等等。通过写接口文档可以进一步结合界面和接口功能，加深我们对于业务的理解。一旦出了问题以后，我们可以迅速的通过客户的界面操作定位到API接口上面，方便我们排错。
如果有精力的话，最好了解一下在项目的运维过程中以前出现过那些问题以及相应的解决方案。自己整理成相关的文档，方便自己以后遇到类似的问题时快速的解决。不至于浪费时间去分析排错，高效的解决问题。

3.总结

  项目交接额过程中，真的可以见识到对方的人品。我的交接人很被动，问一句答一句。希望通过我的努力，让这个项目以后的交接人更轻松一下，提高交接效率。当然，也希望能够对项目交接过程中没有任何文档的小伙伴们一点启发，顺利的完成项目交接。