该帖子同步发自：(子墨的博客  访问该博客)

　　最近被项目交接的事搞得很焦躁，总也完不了的感觉。影响现在的工作进度不说，还弄得老大颇为不满，以为我藏着掖着不愿意讲，委屈又窝火。希望能总结一下，以后改进，也希望众人多提议，让我赶紧脱离这个苦海。

　　简单分成了文档、业务逻辑两个部分：

　　文档已能涵盖几乎所有的内容，但因数量较多且层次不分明，往往需要花费大量的时间阅读，对新接手的人来说，是了解项目最全面最精细也是最慢的方式。所以，为了交接的效率，会辅以会议和串讲，说明核心逻辑和业务需求，还有各方联系人。也会安排答疑，保证项目的平稳过渡。

　　别看我说得头头是道，做起来完全是疯掉了…… 首先，文档不全，除了提交并评审过的版本，其他的严重残缺，还有些项目做了升级文档却没空update 。另外，各类文档的版本号命名规则不同，很难有序的组织起来。想了想，就按照时间顺序，弄了个文档版本历史，简要说明了功能点。

　　这部分主要靠个人习惯，有没有定期整理，是否坚持更新，有没有发在wiki或者组内的工作平台中共享。 总之秉承着“有什么就发什么，捡重要的发”这个原则就行。

　　然后是业务逻辑，“业务”这个词的概念太宽泛，几乎产品的各个方面都能纳进去，内容有以下几点：

　　1. 基本模型、基本结构、基本流程(各种模型&流程图)

　　2. 已上线的功能

　　3. 需求方

　　4. 需求汇总、分析

　　5. 解决方案

　　像填表似的写完了讲完了，接手方基本就清楚了，至少不会有太多的理解偏差。除此之外，通常还会安排串讲和沟通，于是新问题又出现了……

　　Q1：串讲只能概述，细节部分cover不到。

　　Q2：许多刚接手的同事(特别是新人)遇到问题喜欢随时问，很影响工作。

　　Q3：容易纠结于细节，在不了解全貌时就爱问为什么，怎么做的?少了对全貌的观察和把握。

　　Q4：同一个问题反复询问。这是我最恼火的一点，不知道是我之前没说清楚呢，还是他没用心听，或者忘记了。

　　说到这儿，我不希望有人对号入座。这是在写博客哈。嗯，接着讲。

　　作为移交的一方，我希望能这么解决：

　　A1：串讲没有cover到的内容，可以结合各类文档或是代码来增进理解。这个比听人叙述更清晰更准确。

　　A2：千万别随时问问题，问之前请确认你经过了脑子，查阅了资料，尝试了解决方案，最后仍不明白的可以记录下来，集中在一起问，可以定期沟通。

　　A3：不理解需求时，接手的同事最好能重新做调研。一边整理已有需求，一边了解新的进展，不要拘泥于旧有的模式和思路，用自己的方式想问题会更好。

　　A4：可以通过邮件来交流问题。一个是在写邮件组织语言的过程中，有助于理清思路，说不定有的问题就迎刃而解了，一个是给日后备忘，免得想不起来了再麻烦人家讲解一次。这种情况在工作中颇为常见，可能我的耐性不好吧，人家问我一次二次还行，到第三次我基本上要强压怒火，到底是我之前没讲清楚呢，还是你根本没有好好听，或者听完就忘了。

　　多么希望以后交接不要再遇到这样的问题啊!虐死我了!

　　最后，还想问问大家产品的规划是否需要移交?

　　总觉得，之前的规划和发展，之前的idea，之前设计的功能，都是我在做产品的时候定的，是我心里的美好愿景，当产品移交后呢?

　　打个不恰当的比方。就像你生了个娃，养不起了于是把他送给了另一户人家，从那一天起，你已经不是孩子他妈了，那你干嘛还想着孩子以后上什么学校，要找什么工作，要娶什么样的媳妇，反正想了也不算数的。产品好像也是这个道理嘛。

　　所以觉得不如不讲，免得让自己的思维定势影响了他人。哎，不知道这样对不对。