沟通

沟通对于产品经理来说算是老生常谈的话题了,无非是IM、邮件、需求文档、会议等。

为什么需要沟通?产品经理做为需求发起人,从需求收集、分析到最终形成方案,运营、开发、测试同学只是部分参与,大家不知道需求最终要做成什么样子,因此,产品经理需要将自己的想法讲给大家听。

搞清楚本质就好办了,在我刚入行的时候,以为需求文档就是产品工作的全部了,其实需求文档更多是一种类似档案的东西,主要用于记录,毕竟人的记忆是有限的,便于以后需要时回溯。还有就是,在需求评审会议前,通过文档跟开发及测试同学先进行一轮纸面上沟通,让他们对需求有个比较全面的了解,并指出需求中不合(sha)理(bi)的地方或形成疑问,带着这些问题参与随后的需求评审。

需求评审是个好东西,开发、测试及其他需求相关人员大家齐聚一堂,一起欢乐讨(tu)论(cao)需求方案。产品经理做为主讲人,结合原型对方案进行说明,如果其他同学准备充分(当然,一般都不太充分),会提出一些不合理或存在疑点的地方,这时候产品绝对不能抱着老子是最聪明的,质疑我的人都是傻X。开发、测试总是能想到一些你考虑不到的点,在整个沟通中对方案进行了完善,最终根据会议内容对需求文档进行修改。需求评审一定要充分沟通,记住是沟通,不是吵架,并且产品经理要控制会议话题,不要跑偏从而浪费时间。在会上,只讨论需求方案,如果与会人员都没有异议,会议就可以继续了,不要去讨论实现细节了,我经常面对客户端和服务端同事开始愉快的讨论接口,囧。如果开发提出来实现比较复杂,产品经理记录下来,会后根据需求的目的,重新思考是否有其他方式实现。

我一直提出需求评审要进行三遍,第一遍是产品主讲,第二遍是开发主讲,第三遍是测试主讲。这么做的原因主要是为了大家对需求的理解达到一致,前期对需求沟通的越充分,后期出现的bug越少。

最近接了一个急活,年前接二月底就要上线,需求是对核心业务进行调整,由于我们团队是半路接手,加上基本无任何文档,因此对之前业务的了解只有询问需求方及读代码两条路。我们先提出需求方要对需求有个比较详细的描述文档,其次,我们同时安排开发同时读代码,了解之前业务流程。对方将需求描述发来后,我们根据读代码了解的旧业务流程,根据需求,找出最小实现代价的方案,毕竟时间紧迫。几轮讨论下来,方案基本敲定,我将方案文档化,接下来的一个礼拜,基本天天跟开发、测试在会议室泡着沟通需求。结果,自然效果比较明显,开发用了十来天,测试及bug修复用了不到一个礼拜,我们按时完成了任务。

沟通无所谓形式,达到目的就好。

推荐阅读更多精彩内容