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

答案是：原型、需求文档、项目管理，尤其是占据PRD需求文档的时间可以说贯穿了新产品到老产品的生涯。如今，互联网上充斥着各种各样的PRD需求文档模板。

产品的新来者经常以互联网上写的“最详细的”需求文档为模板立即工作，因为他们没有做过很多实际的互联网R&D案例。那这样真的就能保证需求做得好吗？

答案是否定的，因为在一个产品的研发过程中，除了需求文档，需求的灵活沟通和需求评审也是非常重要的。同时还有许多开发同学根本没有阅读需求文档的习惯。

今天分享一下我的PRD简单需求文档的写作风格。不仅可以快速完成软件

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

我写需求文档的风格不仅快，而且简单，适合小团队和创业项目。

值得注意的是：

不同公司的需求文档，因为成熟团队对用户和面临的业务政策的考虑，需求是不一样的，而小团队只需要优先考虑功能实现。

需求文档的含义

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

PMTalk的问答模块

一个简单的问答列表页面，不仅有显示顺序背后的逻辑，而且有前置和后置条件仅仅依靠原型导致需求粒度不够，必然导致开发效率低下，障碍重重。

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

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

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

如何保持文档的一个度？

再比如，登录注册页面的密码设置。以文档的形式记录密码设置的长度和字符限制，显然比原型和面对面交流更实用。

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

需求文档减少了对需求的误解导致开发错误的功能和逻辑的情况。

我需要一个简单的文件写作格式。

1.需求背景说明

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

需求背景描述

2.原型页面标注

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

原型页面的标注说明

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

3.字段说明

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

实现数据显示需要后台限制和配置。

4.逻辑流程示例图

每笔生意都有起点和终点。对于开发人员来说，有必要明确业务流程，才能更好地知道如何编写页面访问规则。

产品业务逻辑

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

5.需求文档版本号

由于写作时间和开发时间的原因，需求文档通常有很长的时间差。有时候一个需求文档可能需要一个月的时间来开发。

文档版本号

但是在一个月的开发周期中，有需求变更是非常正常的。所以要保持文档版本的更新，避免开发生还在沿用老版本。

以上简单需求PRD文档格式适用于创业团队和敏捷项目团队，其他资源在早期项目孵化阶段往往不涉及。

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