产品文档 | PRD写作手册

01 前言

写PRD是产品经理的基本功，但很多时候，我们无法得到系统的指导，全靠野蛮生长，简称野生产品经理。我们的PRD可能会面临很多问题，在开发过程中由于需求描述不明确，不断地进行修改最后导致延期。文档被领导挑出毛病，打击自信心，在同事中信誉度降低等等。

减少无效的沟通，提高工作效率，是一篇清楚的PRD带来的好处。

02 什么是PRD？

(1)PRD是什么

PRD是Product Requirement Document的简称，我们叫它产品需求文档，它的诞生意味着产品从概念化到图纸化的进化。

(2) PRD的对象有哪些？

以开发团队为主的研发、测试、视觉设计师、交互设计师等相关业务人员。

(3)PRD有什么作用？

• 研发根据PRD进行开发逻辑，并进行代码编写
• 测试根据PRD编写测试用例，进行后期的测试
• 视觉与交互设计师根据PRD设计
• 作为记录逻辑的文档，以便时间长了忘记逻辑可以翻看以前的文档
• 确保项目组所有成员对此次迭代内容达成共识的记录

03 写之前需要注意的问题

(1)这个需求在解决什么问题
很多情况是一个需求提过来，产品经理立马着手开始设计，甚至有时候需求方会附带自己的设计方案，有的产品经理也没有经过思考直接就执行了(早些时候我也这么干过，别人指哪打哪)
事实上一个需求最重要的是发现问题，发现问题比立马出解决方案更加重要。因为没有探究问题是什么，可能一开始设计的方向就是错的了。

我们需要考虑以下内容：

• 这个需求解决了谁的问题？这个谁可能是用户，可能是其他需求方如老板、运营、市场
• 问题的本质是什么？是不是如需求方所说？

这里有一种设计技巧可以使用，叫做RTPA设计框架，他的核心就是重新发现问题。我们可以使用以下的步骤：

image

可以看到，最后才是设计，在设计之前我们重点要搞清楚的是问题所在。

(2)需要多少资源
为实现这个需求，需要多少资源，多少人力，多少时间来完成，需要做一个大致的评估。

(3)是最简单的解决方案吗？
当前的设计是最简单的解决方案吗？实现起来难度怎么样？值不值得去做？

(4)有风险吗？
主要考虑做出来后能不能投入使用，会不会违反法规，或者违反第三方的规则导致不能使用。或者功能会影响别的方面，如线上bug引起的崩溃，或者导致什么数据下降。

(5)设计是否创新
有没有调研过竞品对于这个功能是怎样设计的，对于这个问题是怎么处理的，有没有行业内比较先进的做法。

总之，我们在设计