0岁产品经理：如何写需求文档

作为一个产品新人，入职之后，就要开始撰写各种文档。而在我看来，其中最重要的非产品需求文档莫属。产品需求文档的英文名称为product requirement document，简称PRD。该文档是将一个产品由抽象到具体最重要的步骤之一，也是让技术人员详细了解一个产品的【三部曲】之一，其他两步分别是产品原型和语言沟通，会在接下来的两篇文章中细说。而PRD也是令很多产品新人比较头疼的东西，那么PRD到底该怎么写？

要明白写文档的直接目的！

一般PRD大约会给以下这三类人看技术人员，公司BOSS以及客户，而本文以及接下来的两篇文章所说的内容目标用户均是【技术人员】。

即然目标人群已经明确，那么将PRD交给技术人员最直接的目的是什么？那就是让技术人员看完PRD之后，便会知道你的产品具体是一个什么样子。一个好的PRD会有什么样的效果？那就是技术人员只有你的PRD，没有原型，不经过语言沟通，他做出来的东西依然是你心中理想的样子。

我该写什么？

上图便是我为了写这篇文章特意写的一个PRD，是一款快速原型设计软件的PRD，类似于Axure的手机版。我个人偏爱用Axure去写文档，这样可以把产品原型直接嵌套进去，更加方便和直观，而且个人推荐用Axure去写PRD。，工具只是辅助性的，文档好坏看的还是内容，大神用word同样可以将文档写的栩栩如生。

接下来进入主题看右侧内容，你们只需看一点，就是【文档的版本】一个文档诞生之后，肯定是要经历不断修改的过程，那么修改之后，为了让他人清楚的知道你修改的内容，你就需要更新你的版本号，并写好日期与修改的内容。

然后看左侧的列表，也就是目录，只有三条，因为我喜欢三这个数字，既简约而又不简单，使人看起来一目了然。每条都有四个字，因为我有点轻微强迫症，如果不对齐就会浑身难受，而且用过五笔的都知道，无论是两字词组还是四字成语，都只需要敲击四下键盘就能输入。

列表的三条分别是【项目概述】、【需求评估】和【阶段规划】，可能会有人说为什么这么少？能问出这点的人们，你们需要先明确我们写文档的目的只要能让技术人员完全了解一个产品的样子，哪怕是你只写一条也不会有人说你。狼蚁网站SEO优化我们举个反例。

上图是在百度找的需求文档，我以一个技术人员的角度去看这个文档，看完前六条之后，我甚至不知道我要去做的是什么东西，那么它错在哪？

不能快速进入主题。 无关开发的内容太多。

那什么是【无关开发】的内容？我曾见过的有市场调研、竞品分析、用户研究、产品价值观、以及上图的开发风险分析，以上内容基本都可以单独拿出来做为一个独立的文档去写，不要一厢情愿的认为技术人员会去看这些内容，我只想说我！不！看！

我该怎么写？

知道了写什么之后，我们再谈谈怎么写

由于以前是搞安卓开发的，我对tablehost和viewpager情有独钟，于是就仿照做了一个Tab分页，如上图。

项目概述，顾名思义，就是要做到看完之后让人大概对这个产品有一个初步的了解，并且心中对产品有一个雏形。那么目的明确了，怎么去实现说明使用人群，使用人群明确之后，才好针对他们的需求，去设计和开发功能，也就是用户需求，而用户需求往往都是多而杂的，需要对其分类之后，再详细描述，如下图

用户需求大致可以分为以下三点来分类说明基本需求、期望需求和兴奋需求。

基本需求，便是我们产品初级开发阶段要去满足的内容，也是用户使用你产品的必要不充分条件。 期望需求，便是在基本功能可以实现的基础之上，用户希望你去添加的功能，也是开发中后期以及运营前期我们去要实现的功能。 兴奋需求，便是用户没有想到，你不但做到了，而且用户很需要，用户使用之后会感到兴奋，甚至推荐给他人使用。也是运营中后期要去做的事情。

在我过去开发经历中，并没见到过什么另人眼前一亮的功能，这不得不算是一种遗憾，甚至有的时候PRD只看了开头，便已经猜到了结尾，这不得不说是业内互相模仿的悲哀。

项目概述写完之后，大概功能就已经了然于心，那么我们就需要将它具体化，而实现这一目的最好的方式就是需求评估，如下图

图中我只列举了四个例子，实际开发中要实现的功能远远不只这些。这个表格有三列，分别是需求等级、功能名称和功能简介。

我只说一下需求等级生活中无论做什么事情，先后顺序都是按轻重缓急去分的，开发亦是同理，所以你需要给产品的功能加上需求等级，让技术人员清楚的知道开发的优先级。做完这步之后，你就需要详细的描述每一个功能，如图中左侧的画图功能和跳转事件，这个我就不放图了，大家根据具体情况去写就可以了。

基本上写完以上内容，你的需求文档就已经成型了；如果技术人员看完之后还不知道要去做什么，那只能说明你的PRD不合格。真的不合格该怎么办？你需要做的不是去改，毕竟连写都写不好，你又能改成什么样子？你现在所需要的是补救！那么怎么去补救？你需要去写一个阶段规划，如下图