产品需求写什么

‘壹’ 互联网产品的需求文档写作，应该注意哪些事项和规范

1、写前准备(信息结构图)：产品需求文档的写作(一)在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。2、梳理需求(产品结构图和用户流程图)：产品需求文档的写作(二)当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。3、原型设计(手绘原型,灰模原型,交互原型)：产品需求文档的写作(三)当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。4、撰写文档(PRD文档)：产品需求文档的写作(四)当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的(很多产品经理直接使用Axure制作PRD)。当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范标准，这类情况可能是需要存档归类。无论什么样的规范标准，PRD文档的目的都是相近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写PRD文档的方式。5、用例文档(UML用例图、流程图)：产品需求文档的写作(五)《产品需求文档(PRD)的写作方法》的补充文章，主要讲解PRD文档中的重要辅助文档“用例文档”。

‘贰’ 如何写好产品需求

产品经理日常一项重要工作就是收集整理产品需求，转化为产品需求文档，将需求传递给项目团队成员，完成需求功能开发测试上线。如何写好产品需求属于技术活，好的产品经理的需求有条理，由浅入深阐明问题及解决方案，而一般的方案会让人看过后不知所云，需要再次澄清需求。

如何写好产品需求，有小窍门或理论可以参考，比如金字塔原理，在产品初期，我们往往会犯思路不清晰、无法明确表达自己的想法，或者提炼不出产品核心需求点的问题。这时，运用金字塔原理可以帮助我们构建清晰的逻辑思路，更好地表达产品观点。

根据金字塔原理的指导，从分析需求产生的背景，到根据背景认清冲突点，分条列出冲突问题，归纳整理思路；最后根据已知问题，针对性地提出解决方案，寻求解决问题之道。以上步骤完成后，便可以将所有思路总结成文档，具体实施。这种构建方式可以很明确地表述自己的思想，增强代入感。

归纳总结共三点：

1、分析背景，提炼关键需求点

关键需求点不用长篇大论，最好能一句话说明要做的事情，如果要深入细节，再详细描述。

2、用归纳法理清你的思路

提炼关键需求点后，可以针对需求点提出相应解决方案，多个需求或解决方案之间可能存在逻辑关系或冲突，通过归纳法来总结梳理，帮助把握核心需求点、区分优先级。

3、寻找问题解决知道

归纳总结问题后，剩下就是针对问题寻找解决方案了，解决方案的好坏取决于产品经理的经验与学习能力。

‘叁’ 需求文档怎么写最有效

能将功能需求写清楚的就是好的需求文档，因为现在的需求文档一般都是给开发看，一般来说创业公司追求小步快跑快速迭代的开发模式的话，需求文档不是一个很有必要的东西，直接在原型上表述效率会更好。如果公司追求规范管理的话，建议还是需求文档，写清楚项目名称，迭代版本，及相关的日期规划。

‘肆’ 如何写一份易用的产品需求文档

产品需求文档分很多种，这里我只说一种让程序员看起来舒服的需求文档格式吧：

作为程序员，在需求文档当中，最关注的内容是哪几种呢？
1、流程：包括业务流程和基本流程；
2、数据：包括输入数据和展示数据；
3、事件流：特别是分支事件流和例外事件流，感觉很多需求文档中，缺少了这部分；

那么，文档的模板是怎么样的呢？
1、需求说明：主要阐述为什么要做这个需求；
2、业务流程：最好使用VISIO来绘制，画出整个业务的流程图，特别是其中所要涉及的判定，分支等，都要画出来，越详细越好；
3、基本流程：继续使用VISIO，画出基本流程即可，一般来说都是业务流程中的最主要部分，但是可以加入更多的细节；
4、分支事件流：VISIO，各种分支事件的详细流程，越详细越好；
5、例外事件流：这里要使用表格，示例如下：主要是系统判定和对应的提示；6、输入数据：用户可以输入数据的字段，已经相应的定义，包括是否必填，字段长度，录入方式，对应规则等；
7、显示数据：页面显示给用户的数据，对应的字段，取数规则，对应规则等;
8、补充说明；这个需求文档模板，更倾向于传统的软件模板，而不是网络上比较流行的AXURE文档。

‘伍’ 产品需求文档应该包含哪些内容

我们先假如产品需求文档（PRD）是一个产品，那么该如何做出一个拥有良好用户体验的PRD？

首先先来考察下PRD的用户群体（User Persona）：主要是开发人员，在繁忙的开发任务中最希望看到“简洁易懂”的产品需求文档。

梳理下PRD的功能：

传达出产品需求；

管理记录产品迭代过程；

各部门共享产品信息，以促进沟通；

因此一个好的PRD的原则是：

结构清晰

语言简洁易懂

实时共享

具体我们该如何制作？

答案很简单——一个PRD文档即可

现在，越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式，因为之前的word+原型的方式管理起来繁琐，而且还容易产生信息疏漏。

将原型和文本说明统一，直接分享一个链接，开发人员就能看到所有信息，是理想状态。

多级导航结构展示PRD信息

通常来讲，一个产品需求文档里包含“产品概述”、“流程图”、“功能详情和原型”，“全局说明”，“非功能性需求”。

如何把这些内容清晰有条理地呈现在一个文档里呢？使用一个网页般的多级导航结构即可。

1、产品概述

产品概述部分用于展示文档修订历史、版本说明、开发周期、和产品介绍。

“文档修订历史”用来记录产品经理对该PRD文档的修改状况，也方便成员能及时了解到PRD是否有改动；

“版本说明”展示上线产品各版本的核心功能；

“开发周期”用于梳理开发、测试、上线的预计开始和结束日期。

“产品介绍”用来记录产品名称、简介、用户画像、使用场景、产品定位等等。

通过墨刀的分享链接还能直接让公司内部人员在线实时同步PRD的更新，不用再担心信息滞后或者文档不兼容问题。

让我们着手开始创建或者优化您的产品需求文档吧～
希望采纳！谢谢！

配图来自 “运维派”以及墨刀官网截图