在我所经历过的公司中，项目的交接都很简单，过一下流程，中小项目没有文档甚至数据库表字段注释都没有。好吧，不知道大家工作的地方是个什么情况，我这是这样。
接手3个项目，简单一个邮件通知，然后一哥们发个我2个系统的源代码(另一个由于人员流动，代码丢失，囧)，OK，完成交接了。我看了一下，发现连数据结构说明都没有，赶紧叫那哥们把所有的表字段和每一个页面做什么用的写个文档我，之后，他发来一份其中一个项目的过时的数据结构文档（项目设计之初的文档，后期的修改并没有更新文档），碍于怕扫大家面子和想到可能有问题直接问他就得了的单纯想法，就到这里，项目交接完毕。这样不负责任的结果导致了后面一系列悲剧的发生。
由于每个项目都在使用，其中两个项目是几乎每天都得由公司一个部门出报表给客户，中途出现很多大大小小，繁繁琐琐的各种问题，竟让我冒出了离职的念头。太它娘的憋屈了。
原因归纳：
1.由于对项目代码质量和数据结构设计的排斥使我不愿意在有时间的时候去浏览，熟悉流程，业务逻辑和关系
2.另外部门同事人员流动大，导致几乎每人熟悉该系统，出现问题都在想当然
3.文档规范啊！
如何解决
1.良好的交接工作，必须让交接人员提供强有力的数据结构文档，表关系文档
2.每个页面每个功能是做什么用的，可以截图来看图说话
3.复杂的逻辑，核心业务用文档列出来实现流程
4.程序部署环境文档，有无需要额外的设置，比如权限，IIS配置，数据库是否有作业工作等
5.如果有在此系统上做的工作，（比如出报表，这边的是用Excel链接数据库，得到基础数据之后用Excel公式出最终表报。）那么让交接人员联合使用部门人员出详细流程和每个表做什么的
6.程序中针对特殊业务的实现必须记录清楚，比如针对系统在每个星期2的时候做某些工作
如果说上述太理想化或者不容易实现，那么就自己花时间理清楚这些东西，交接之后就是自己的事了.这时候埋怨别人都已经没有用了。