本文从三个角度,分析了PRD这项基本功的培育方法~
曾有一个段子:
第一个问题:如果把你派到竞品公司捣乱,作为产品你会怎么做?
产品经理答:每天疯狂提需求,不管是否有用。研发排期我不管。
第二个问题:你现在做的主要工作是什么?
产品经理:……
这篇文章,虽然不会让你瞬间越阶,但至少会让你对产品需求文档有个相对系统的认识,提升工作效率。只要你在做产品相关工作或是想往这方向就业做准备,都可以学习一下。
作为一只有梦想的产品狗,每天必备功课就是和各部门沟(si)通(bi)。
但你是否还能回忆起,被程序猿挑战逻辑漏洞的恐惧?还有被UI设计狮质疑需求价值的尴尬?
更有当你兴致勃勃准备验收需求,突然发现实现方案完全不是自己想要的,是不是只能无可奈何,忍气上线。
如果你经常遇到上面的情况,说明你的产品基本功:PRD需求文档撰写能力还不到家。
一份好的产品需求文档,可以减少开发人员与设计人员对需求的理解难度,避免产品经理陷入无休止的沟(si)通(bi)中….
今天就想和你聊聊这项基本功的培育方法~
01 什么是PRD产品需求文档
传说中产品经理一生要面对三大文档:商业需求文档(BRD)、市场需求文档(MRD)、产品需求文档(PRD)。
其中产品需求文档PRD的撰写是很多产品新人首先要掌握的,因为它是在项目过程中给设计、开发、测试这样的实施人员看的,
它仔细描述了产品功能应该怎么做,是产品落地前的指南针、方向盘。也就是说,PRD的目的是给实施人员讲述产品最终要做成什么样。
较完整的PRD目录结构包括:概述、产品描述、功能需求、非功能需求、上下线需求、运营计划、附录。
如下图所示:
PRD的展现形式,行业内有2种:
一种是传统WORD,有清晰的目录结构,自顶向下阅读,以图文方式说明各个功能模块的设计思路,业务逻辑,如下图PRD目录:
WORD格式的PRD在大公司会比较常见,优点是结构完整,阅读顺畅,也不会有遗漏,适合成熟产品;
还有一种是把PRD和Axure交互原型混排在一起,如下图:
这种做法适合要求快速迭代的产品:
- 对产品人员:能够做到PRD快速产出;
- 对开发人员:不必一页页的翻文档,可以直接可视化查看页面交互情况,对照页面标记去查看对应功能,所见即所得;
-
对测试人员:则可以根据页面交互跳转去写测试用例,对后期测试可提供更加完整的测试思路。实际做的时候,可以二者结合,取最适合自己团队的方法。
02 哪些人会关注PRD文档
如上所述,PRD面向的是产品落地的实施人员,涉及到多个角色,每个人关注的点都不同。
具体如下:
- 产品经理:自查产品功能点,更加透彻和完整地梳理产品需求;
- 交互设计师:检查自己的交互稿是否满足需求,是否有遗漏特殊情况、异常情况、极限情况等;
- 开发工程师:检查自己的程序开发是否符合PRD中描述的相关要求;
- 测试工程师:将PRD中的功能描述和用例转化为测试用例的一部分,进行产品可用性测试;
- 运营/财务/法务等:确认产品上线前的准备工作
优秀的产品经理会在写PRD时换位思考:
一方面,会在语言描述上更客观,使用“支持、显示、要求”字样。
尽量不用形容词、模棱两可的词,比如“可能、以后、尽量、很好地、快速地”。
另一方面,会在描述功能时,更多以开发逻辑去思考书写方式,使用流程图、数量级、优先级这样的表达方式。
或者用开发语言来阐述概念,比如“接口定义、数据结构、云端存储”。做到精确无歧义。(产品懂点研发没有坏处,只会让你和研发沟通更顺畅)
03 如何写出优秀PRD?
PRD作为产品经理的第一个产出物,也应该以做产品的思路来实施。
- 第一,站在用户,也就是读者(上文提到的其他团队伙伴)角度去想他们想从PRD中获得什么;
- 第二,保证文档结构清晰、排版美观,阅读舒适;
- 第三,保持文档的持续更新,并及时通知修改情况;
- 第四,逻辑严谨,需求说明有理有据。
OK,如果你现在还一头雾水的写不出没关系,最简单的办法,人人都是产品经理上找一份成熟的需求文档,逐条阅读理解以你的话复述一遍。这是深度理解需求文档最简单粗暴的方法了。
本文由 @Jason 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于 CC0 协议
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;
想了解更多移动互联网干货知识,请关注微信公众号运营小咖秀(ID: yunyingshow)
【转载说明】  若上述素材出现侵权,请及时联系我们删除及进行处理:8088013@qq.com