简单易懂高效的PRD（需求文档）模板格式

产品经理的三大工作是什么？

答案是：原型、需求文档、项目管理，尤其占据PRD需求文档的时间可谓贯穿产品新人到产品老年的职业生涯。如今网上充满了各种各样的PRD需求文档模板。

产品新人们由于没有做过太多实际互联网研发案例，往往马上就拿着网上感觉写着“最详细”的需求文档作为模板来工作。那这样真的就能保证需求做得好吗？

答案是否定的。因为一个产品的研发除了需求文档外，需求问题的灵活沟通、需求评审等各个环节也至关重要，同时还有许多开发同学根本没有阅读需求文档的习惯。

我今天分享我的PRD简易需求文档撰写风格。既能够敏捷完成软件

产品研发团队的人数多少、公司规范要求，通过巧用写需求文档格式规范，省下不少时。

我这套需求文档撰写风格，不仅快速，而且撰写格式简单，适合小团队、和创业型项目

值得说明的是：

需求文档在不同的公司，之所以会有要求不同，是因为成熟团队面临的用户量、业务政策的考虑，而小团队只需要优先考虑功能实现即可。

需求文档的意义

产品经理之所以要写需求文档，是因为仅靠原型图的表达是非常有限的。比如我们以下面的原型页面为例，是PMTalk产品经理社区的信息流。

▲  PMTalk的问答模块 

一个简单的问答列表页面不仅有背后的展示顺序逻辑，还会有前置、后置条件。仅靠原型，导致需求颗粒度不够细，难免造成开发效率低下和阻碍。

开发同学由于不知道如何展示、运算规则是什么，导致产品没有实际使用价值。

如今互联网盛行的敏捷管理方式，要求尽可能减少需求在PRD文档的输出，增加产品经理和面对面开发沟通的时间。

因为过渡的需求文档造成了上线问题，开发同学都会极力甩锅给PRD文档撰写者，导致产品经理团队和开发人员割裂。

如何保持文档的一个度？

再举个例子，比如登录注册页面的密码设置。密码设置的长度、字符限制，以文档的方式记录显然比原型、当面沟通更实际。

▲  APP的登录注册，需要账户密码 

需求文档减少需求理解失误导致开发错误功能、逻辑的情况出现。

我需求文档简单撰写格式

1.需求背景说明

写需求背景，有利于让开发同学知道为什么要这样做。让参与项目的团队知道需求来自谁，以及需求的受益业务是谁。

▲  需求背景描述 

2.原型页面标注

原型页面我的习惯是以截图的方式放在协同文档里面进行说明。就像教科书的图文说明一样。

▲  原型页面的标注说明 

要注意的是原型页面中的按钮、交互动效、前置条件、后置条件、背后算法逻辑要提前用符号标识号。

3.字段说明

原型页面中某些字段涉及到运算逻辑处理，比如PMTalk产品经理社区的活动报名页有门票计算、分销计算、活动人数计算、活动时间。

需要后台限制和配置，才可以实现数据展示。

4.逻辑流程示例图

每个业务都有起点和终点。对于开发人员，要清楚业务流程，才能更好的知道撰写页面访问规则。

▲  产品业务逻辑 

比如PMTalk的问答需要用户先注册登录才可以回答问题。商城版块用户下单后只能通过人工客服退货或换货。

5.需求文档版本号

需求文档由于撰写的时间和开发时间一般会有较远的时间差。有时候一个需求文档可能要管1个月的开发时间。

▲  文档版本号 

但在1个月的开发周期中，存在需求变更是非常正常的情况。所以保持文档的版本更新，避免开发同学仍然按照老版本。

以上的简易需求PRD文档格式适合给创业团队、敏捷项目小组，在早起项目孵化阶段往往不涉及到其他的资源。

由此只需要解决产品与开发、设计的需求理解问题即可。

今天的分享就在这。