别看我说得头头是道，做起来完全是疯掉了，首先，文档不全，另外，各类文档的版本号命名规则不同，然后是业务逻辑，通常还会安排串讲和沟通
最近被项目交接的事搞得很焦躁，总也完不了的感觉。影响现在的工作进度不说，还弄得老大颇为不满，以为我藏着掖着不愿意讲，委屈又窝火。希望能总结一下，以后改进，也希望众人多提议，让我赶紧脱离这个苦海。
简单分成了文档&业务逻辑两个部分：
文档已能涵盖几乎所有的内容，但因数量较多且层次不分明，往往需要花费大量的时间阅读，对新接手的人来说，是了解项目最全面最精细也是最慢的方式。所以，为了交接的效率，会辅以会议和串讲，说明核心逻辑和业务需求，还有各方联系人。也会安排答疑，保证项目的平稳过渡。
别看我说得头头是道，做起来完全是疯掉了…… 首先，文档不全，除了提交并评审过的版本，其他的严重残缺，还有些项目做了升级文档却没空update 。另外，各类文档的版本号命名规则不同，很难有序的组织起来。想了想，就按照时间顺序，弄了个文档版本历史，简要说明了功能点。
这部分主要靠个人习惯，有没有定期整理，是否坚持更新，有没有发在wiki或者组内的工作平台中共享。 总之秉承着“有什么就发什么，捡重要的发”这个原则就行。
然后是业务逻辑，“业务”这个词的概念太宽泛，几乎产品的各个方面都能纳进去，内容有以下几点：
1. 基本模型、基本结构、基本流程（各种模型&流程串讲只能概述，细节部分cover不到。
Q2：许多刚接手的同事（特别是新人）遇到问题喜欢随时问，很影响工作。
Q3：容易纠结于细节，在不了解全貌时就爱问为什么，怎么做的？少了对全貌的观察和把握。
Q4：同一个问题反复询问。这是我最恼火的一点，不知道是我之前没说清楚呢，还是他没用心听，或者忘记了。
说到这儿，我不希望有人对号入座。这是在写博客哈。嗯，接着讲。
作为移交的一方，我希望能这么解决：
A1：串讲没有cover到的内容，可以结合各类文档或是代码来增进理解。这个比听人叙述更清晰更准确。
A2：千万别随时问问题，问之前请确认你经过了脑子，查阅了资料，尝试了解决方案，最后仍不明白的可以记录下来，集中在一起问，可以定期沟通。
A3：不理解需求时，接手的同事最好能重新做调研。一边整理已有需求，一边了解新的进展，不要拘泥于旧有的模式和思路，用自己的方式想问题会更好。
A4：可以通过邮件来交流问题。一个是在写邮件组织语言的过程中，有助于理清思路，说不定有的问题就迎刃而解了，一个是给日后备忘，免得想不起来了再麻烦人家讲解一次。这种情况在工作中颇为常见，可能我的耐性不好吧，人家问我一次二次还行，到第三次我基本上要强压怒火，到底是我之前没讲清楚呢，还是你根本没有好好听，或者听完就忘了。
多么希望以后交接不要再遇到这样的问题啊！虐死我了！
最后，还想问问大家产品的规划是否需要移交？
总觉得，之前的规划和发展，之前的idea，之前设计的功能，都是我在做产品的时候定的，是我心里的美好愿景，当产品移交后呢？
打个不恰当的比方。就像你生了个娃，养不起了于是把他送给了另一户人家，从那一天起，你已经不是孩子他妈了，那你干嘛还想着孩子以后上什么学校，要找什么工作，要娶什么样的媳妇，反正想了也不算数的。产品好像也是这个道理嘛。
所以觉得不如不讲，免得让自己的思维定势影响了他人。哎，不知道这样对不对。
作者：wangxuntian
文章来源：wangxuntian.com 转载请注明出处链接。
本文地址：https://www.pizijiang.com/tougao/100830.html
举报投诉邮箱：253000106@qq.com
微信扫一扫 
支付宝扫一扫 
