王洛堇:项目交接小总结

注;本文转载自王洛堇的博客

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

简单分成了文档&业务逻辑两个部分:

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

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

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

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

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

2. 已上线的功能

3. 需求方

4. 需求汇总、分析

5. 解决方案

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

Q1:串讲只能概述,细节部分cover不到。

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

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

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

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

作为移交的一方,我希望能这么解决:

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

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

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

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

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

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

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

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

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

 

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部