转行产品经理后的写的第一份产品需求文档,懂得了如何写一份实用的需求文档,将自己的心得和体会分享出来,希望和大家一起交流成长。
自从我从事产品岗位以来,在这半年里我学了许多关于产品岗位的知识与技能。相信有涉足产品设计领域的人估计都听说过这么一句话“人人都是产品经理”或看过《人人都是产品经理》这么一本书,可能也正是这么一句话或这么一本书让无数的人一头扎进了产品经理的大营并开始从事产品的工作,它也许让很多人成功的成为了一名合格的产品经理,同时也误导了很多人走上不归路。
从程序员转行做产品以来,我个人撰写的第一份产品需求文档,是2018年2月份,也就是我入职现在这家公司半年后,在这之前,所做的事情大都为杂事,和产品经理的日常工作关系不大,这可能和公司性质有关(公司为一家初创型企业)。在写这份需求文档前,我个人完全地参与了这个项目的招投标,十分清楚该项目所包含的各种需求,这些需求囊括了同行业已有的好几个产品的核心功能,同时也添加了客户主观方面的需求,因此要针对这么一份招标书写一份产品需求文档,对刚从事产品岗位的我来说确实是一项不小的挑战。
为了写好这份需求文档,我体验了同行业的多款产品来熟悉系统的核心功能和业务流程。当我自以为对要做的产品需求很清楚明白的时候,我便开始准备写起来,可是问题来了,我根本就没写过需求文档,文档格式应该是什么样的呢?为此,便上网搜索各种格式的需求文档,经过一番比较之后,确定其中一份格式略轻量级的文档模板,然后再花点时间重新整理一下文档格式,就这样,一份条理清晰的简易需求文档模板就确定好了。
文档模板确定好后,我就开始飞速地码字了,几天后就码了1千左右的字,毕竟码字和码代码差不多,使用复制粘贴就可以解决很多事情。不过,事情远远没有想象中的那么简单,不然就太容易完成了,因为在接下来的几天里,我发现需求文档中显示的总字数并没有大幅度地增加,有时候还会有所减少,原因是我发现功能点之间存在一些逻辑问题,导致需求文档不断地被修改,同时因为该项目招标书上的很多功能相互之间无关联,进一步加剧了修改的工作量。经过反反复复地修改,约两个星期后,需求文档总算是写完了。
现在回过头来看,当时写需求文档走了很多的弯路,而且到最后也没起到多大的作用,这其中有多方面的原因,现总结如下:
1、写需求文档前,先找上级领导讨论需求点。如果公司老板是最大的产品经理,或者他自认为自己是,那么,写需求文档前,先将主要的需求点列出来,然后找老板一一讨论这些需求点,只有老板认可的需求点才能写入需求文档。这样,如果产品取得成功,那肯定是老板的运筹帷幄(自己了不起也就是个执行者),即使出错,则属于战略失误,从而不至于被甩锅。
2、写文档时,功能点不要写得太过于详细。当初自己写需求文档时,生怕开发人员因需求描述不清楚而看不懂或理解错误,从而花费了很多时间在解释和描述需求方面,而一旦发现某些地方描述错误时,又得花大量时间去改正,简直费力不讨好。而且,说实话,开发人员基本不看产品需求文档,他们更多的是依赖于交互原型、业务流程,还有就是张嘴问。
3、需求文档写好后,必须通过评审!必须通过评审!必须通过评审!未经过评审的需求可能是个伪需求、自己臆想的需求、理解错误的需求。此类需求一定会消耗整个团队宝贵的时间和精力从而影响核心功能的开发;即使做出来,也是鸡肋,不能解决客户的根本问题,后期可能还需时间和人力对它进行维护;同时,未经过评审的需求可能以现有团队的实力根本无法实现或很难实现,这无疑增加了团队的压力影响开发效率,进而影响整个项目进度。最后,需求未通过评审,意味着上级领导对产品需求不够了解,一旦后期出现任何问题,领导一定会追责到产品经理,他们会认为产品经理自作主张地决定了产品的表现形态。
以上就是我个人第一次写产品需求文档的心得和体会,分享给大家,希望能给那些刚刚从事产品经理岗位的小伙伴带来一些帮助和启发,祝大家早日成为产品大神!