Apple资讯

当前位置: 爱新闻 > 移动互联网

优质产品需求文档(PRD)三大原则

上一篇文章中有介绍,产品经理的两项主要职责包括:对产品机会进行评估,以及对开发的产品进行评估。而定义即将开发上线的产品,则需要借助产品需求文档,来进行产品的特征和功能描述。PRD文档的写作会因公司、团队以及个人习惯而异,没有标准的规范和统一模板,但有三大原则是不可忽略的:文字简练、中低保真、测试验证。本文仅陈述个人对产品需求文档的理解,若有不正确的地方,还望多多指教。

(一)PRD的定义、主要构成及用处

简而言之,产品需求文档(Product Requirement Document),是将商业需求文档(BRD)和市场需求文档(MRD)进行结合,然后用更加专业的语言进行描述。它向上是对BRD内容的继承和发展,向下是把MRD文档中的各种理论要求技术化,向研发和设计部门说明产品的功能和性能要求。BRD>MRD>PRD是一个逐步论证并产出结果的过程,也是产品经理思维升华的过程。

prd-components-image.png

PRD主要构成:

1.引言及概要

这部分主要解释:需求背景、需求概要、需求目的、全局规则说明、名词解说以及文档变更记录等,目的是让阅读者尽快了解并熟悉需求背景和概要。作为公司内部文档来看的话,可以从简来写作。

2.业务说明及原型图

整个文档最核心的部分,其中包括产品功能主框架,比如:业务结构图/流程图、页面交互/功能模块元素构成、权限说明表等。同时,各页面之间基本的交互形式、文本注释及线框图,也是不可或缺的。

3.非功能需求

一些偏向“辅助”类的需求,包括:地理位置获取、CDN缓存策略、Push推送机制、本地文件存放策略...

如果是产品的第一个版本,那么在整个产品的业务流程和功能结构上就需要花更多时间来说明,既可以降低与整个团队的沟通成本,也能作为后期开发的证据和备份,而这恰好是PRD文档最大的用处。此外,它也发挥着将需求管理归档,促进从“概念化”阶段到“图纸化”阶段的过渡作用。

low-vs-high.jpg

(二)PRD写作的三大原则

1.文字简练

诚然详尽的说明能给开发人员最全面的指导和参考,但“事无巨细”的备注及文字说明,有时反而会成为“过犹不及”的反例,增加沟通成本及延误开发进程。在产品进行评审和讨论具体开发细节时,有些问题会被重复提到,而在此过程中,如果能把关键性的逻辑用图表或文本展现出来就很关键了。对于有些“众所周知”的规则和功能需求的话,可以在产品文档中进行适当精简,否则开发人员也是没有耐心看完的。

事实上,即使你的PRD已经十分精练,团队成员也很有可能不会完完整整地看完,有时候甚至会忘记其中一些内容,然后认定是你当时没有添加。当然,如果你跟团队成员之间已经很有默契,彼此知道对方的开发习惯和设计套路,那么即使有些需求没有说明,产品的规划和迭代也同样能进入高效运转的状态。

2.中低保真

追求视觉细节和交互特效,在对外展示或用户测试时,效果固然好。但通常的原型是为了内部沟通交流,只需要用线框图将核心功能及架构进行展示,便可以把产品设计的思路梳理清晰。相反,高保真的原型在遇到后期的需求变更时,会带来非常高的修改成本,而且会严重影响产品设计和开发的进度。正如用户体验五要素理论,产品的设计流程应该是:战略层>范围层>结构层>框架层>表现层。

write-design-document-image.jpg

3.测试验证

这是将产品经理的想法进行呈现的阶段,也是创造力和创新力出彩的地方。对于很多产品来讲,有下面三个测试十分重要,而且对于PRD最终是否“接地气”有着不言自明的决定作用。

1)可用性测试 - 不仅能适应不同的用户,而且可以找出遗漏的产品要求,从而进一步确认产品最初的要求是否是必须的。当然,从目标用户获取测试反馈,也是非常科学和艺术的。

2)可行性测试 - 通过让设计师和工程师介入技术的可行性调查和探索,可以尽早解决一些不太“现实”的问题,避免后期再调整的时间和精力代价。

3)概念测试 -对用户是否有价值以及产生购买欲望的测试,可以结合一些优质快速的原型工具,将产品的预览版本呈现出来,之后在实际目标顾客身上测试,从而得到有质量的反馈。

总而言之,精简说明文字、保持中低保真、进行原型测试和验证,把时间和精力花在如何提高产品核心竞争力上,减少无效及重复的工作,是产出优质、有价值产品及产品需求文档的牵引力。

热门推荐

回到顶部