先来一个案例，近期，由于组织架构变动，鄙人接手了几个项目。
其中一个项目处于新需求功能开发、老问题维护阶段（简称项目一）；另一个项目处于接近收尾，甲方大提整改意见阶段（简称项目二）；其他项目都是维护；
接手之前，鄙人根据以前的一些了解，对这些项目大概评估了一下，认为功能单一，技术简单，不存在大的技术壁垒或者其他障碍；欣然接手。
接手之后发现如下有趣的问题：
1、项目一以前对我们说的是全自动配置界面以及功能，实际为纯手写html+纯手工实现前后台；
2、项目一前负责人对于功能了解甚少，找他沟通问题，基本回复去找谁谁，看了代码提交，前负责人的确基本没写代码；
3、项目一里面存在大量写死id进行查询的情况；
4、项目一没有提供任何可用文档；
5、项目二临近收尾，时间紧迫，更改项较多；
6、由于对项目一的具体实现比较迷惑，而项目一负责人又扯不清，故期望项目一负责人能够提供一些文档，能够降低一点学习成本，但是被本组领导认为是找项目一负责人麻烦；
7、项目二负责人为一毕业两年的新人，积累了大量的文档；
在以上问题上，最老火的事情为项目一前负责人(主要程序员)以前与我一个团队，但在本轮中已经升职(非离职)，其前身为开发人员；项目二前负责人目前为项目一负责人的组员；
按照以前协商，我将逐一接手项目，但是目前情况是，项目一负责人极力想扔出这些项目。
从以上来说，软件项目交接最怕以下几点：
1、技术沟通障碍，包括前负责人不了解他所负责的项目、不配合或者已经离职这些情况；
2、除开代码以外，无任何文档可参考(含需求文档)，全靠口述薪火相传；
3、非平级或者跨部门进行具体交接；
4、与非正规程序员进行软件工程交接；
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！