源地址：http://younglibin.iteye.com/blog/2012874
源地址没有账号，无法向该博主申请转载授权，特此说明，如禁止转载，我将尽快删除此转载。
刚换了工作， 交接了十几个项目工程，交接给别人的时候，总想着怎么才能将这个项目交接清楚，在做项目初期，想象的都非常好，需求文档，产品架构，详设，概设有时候连代 码流程图都已经画出来了， 但是在开发过程中，难免会出现很多需求改动，设计不合理之处，会有修改，但是由于时间紧迫，项目规划时间，毕竟测试，销售等在等着你的项目呢， 怎么才能在计划的时间点将需求功能提供给测试测试，在计划的时间点把项目保质保量的上线，这写问题，不得不考虑， 一个小小的需求变更，一个小小的表设计可能需要依次打开很多word、execl、mmp、axure......去做修改， 先不说修改量大不大， 就光打开着文档，找到需要修改的地方就需要一些时间，大家都知道设计中要， 但是工作这么多年，做过项目型的，做过产品型的，设计总是在每一次迭代每次需求确认中有变化，对于程序员来说也许只有代码才不会欺骗人，也只有代码才是最 好的文档。但是没有谁有足够的时间去看这些代码，时间更是不允许，怎么才能更好的更快的将代码这些东西交接给别人不影响公司开展业务，怎么快速接受新工作 的，了解新工作，成为新公司的老手，结合自己摸索总结一点希望对自己工作能有帮组：
一、离职工作交接，这个时候我们需要考虑的是怎么将自己在这个工作待了2、3、5、7年掌握的东西怎么能在两周左右的时间甚至更短时间交接给几个人，甚至可能交接给一个新入职的同事。
交接要点：
项目概览：项目背景、项目功能、项目设计思想、项目最终达到的目的、项目当前情况、工作环境搭建；
1.项目背景：项目产生原因，项目解决了那些问题；
2.项目功能：在技术角度实现了那些功能，例如CRUD， 报表等
3,项目设计思想： 站在设计角度，说出原型来自与那里。站在技术角度，列出项目使用的框架架构，例如SSH、springmvc、一些设计模式、前端使用什么，后端使用什 么、数据库(oraclemysqlpostgres)、其他开源框架、技术点（消息的MQ，RPC的thrift或者hession，spring 注解，spring或者quartz的定时器，JSP或者freemarker，HDFS，或者hadoop生态圈，也可能使用其中的 Hbase、Hive、Zookeeper） ， 如果有时间最好把技术选型也做一下说明，为什么选择springmvc 注解，不适用struts ，为什么使用 thrfit不适用hession 等等 。总之说这么多，就是对于技术人员来说技术是个无底洞，要交接 这些当然也可以不说，就算你和公司不和，但是站在程序员素质这边应该把这些尽可能多的说清楚；
4.项目最终达到的目的：做这个项目目的是什么， 比如是为了给用户提供以这一年营业额的一个概览，为用户对下一财年计划提供依据，或者为用户提供一个存储服务、或者为用户提供资源查询系统等等。
5.项目当前状况： 当前项目是已经上线了一部分功能，还是全部上线了， 是已经处于维护状态已经两三年没有出现过bug还是近期用户有新需求正在做很多改动等等。
6.工作环境搭建：在了解了以上这些之后，被交接者 应该熟悉了50% 之后， 学习下项目中自己没有接触过的新技术，接下来就应该将工作环境打起来，对于技术人员，开发环境软件安装这些事必须的，各个软件版本不同，也会存在很多问 题，所在安装环境之前，最好找之前同事了解一下，防止盲目安装出现版本信息不相符，甚至有些比较难以安装的软件，对于一个新手来说，可能是一件比较头疼的 事。例如java版本，数据库版本、IDE。设计软件上例如：数据库设计软件，UML设计软件，原型图设计软件..........,工作环境的搭建要保 证自己能够把，测试代码跑出来，看到效果为标准。最后还要学会怎么讲项目部署到生产环境上，就算没有生产环境的权限，也要在测试环境部署成功。
二、入职交接：
交接要点：
项目概览：项目背景、项目功能、项目设计思想、项目最终达到的目的、项目当前情况、工作环境搭建；
1.项目背景：对于一个项目背景，其实对于以后工作没有直接关系，但是这些在工作中是有作用的，比如了解项目产生背景，可以查一下这个行业的一些相关信息，说不准以后公司会将这个项目重构。
2.项目功能：当然要了解的最好能够话大把的时间做详细了解，如果以后有针对这个功能的，原来已经有了，你不知道，还需要重新分配任务来做这些东西， 那就劳民伤财，你的员工也会恨你的。
3.项目设计思想： 这个在交接上已经说过了， 同样重要， 这也为你以后项目优化，项目重构提供了基础，包含之后很长一段时间技术技能的学习点都有很大的关系。
4.项目最终达到的目的：这也是未来你工作的目的
5.项目当前情况： 知道哪些要修改，待修改， 最怕的就是那种好几年一种处于维护状态的项目，花时间吧，不用，不分配时间吧，万一来问题了，一时处理不了。
6.工作环境：只要你是做技术的，这个是必须， 任何时间，都要保证爆出来的bug你可能很方便的重现并且方便定位问题，快速做出修改的决策。
大家会说， 为什么不去看代码，这样不是跟可靠吗?首先要说的是，第一我们没有时间去一行一行的看代码，第二如果你是一个manager或者leader ，你需要这样子做吗？不管你处于什么职位，全局把控是必须，不管你能力再强，都应该多多向老人去学习，去了解，花最少的时间获得最大的信息，才能够在段时 间之内融入公司，创造价值。
最后唠叨一下：
在当前处于一个被交接者，手头一下子下来了十几个项目， 新到公司压力很大啊，以前接触过的没有接触过的都很多，只希望能够找到一个好的方法能够最大程度的接收项目，面对新入职就接受交接，老员工还要离职的情 况，再加上交接流程不明确，只能靠自己追着屁股去问。谁知道明天会不是线上环境有bug，这个时间谁来搞？阿门！
谁还有更好的交接方式一起共享一下................