作为一个产品新人，入职之后，首先就要开始撰写各种文档。而在我看来，其中最重要的非产品需求文档莫属。产品需求文档的英文名称为：product requirement document，简称PRD。该文档是将一个产品由抽象到具体最重要的步骤之一，也是让技术人员详细了解一个产品的【三部曲】之一，其他两步分别是产品原型和语言沟通，会在接下来的两篇文章中细说。而PRD也是令很多产品新人比较头疼的东西，那么PRD到底该怎么写？
要明白写文档的直接目的！
一般PRD大约会给以下这三类人看：技术人员，公司BOSS以及客户，而本文以及接下来的两篇文章所说的内容目标用户均是【技术人员】。
即然目标人群已经明确，那么将PRD交给技术人员最直接的目的是什么？那就是让技术人员看完PRD之后，便会知道你的产品具体是一个什么样子。一个好的PRD会有什么样的效果？那就是技术人员只有你的PRD，没有原型，不经过语言沟通，他做出来的东西依然是你心中理想的样子。
我该写什么？
上图便是我为了写这篇文章特意写的一个PRD，是一款快速原型设计软件的PRD，类似于Axure的手机版。我个人偏爱用Axure去写文档，这样可以把产品原型直接嵌套进去，更加方便和直观，而且个人推荐用Axure去写PRD。当然，工具只是辅助性的，文档好坏看的还是内容，大神用word同样可以将文档写的栩栩如生。
接下来进入主题：首先看右侧内容，你们只需看一点，就是【文档的版本】：一个文档诞生之后，肯定是要经历不断修改的过程，那么修改之后，为了让他人清楚的知道你修改的内容，你就需要更新你的版本号，并写好日期与修改的内容。
然后看左侧的列表，也就是目录，只有三条，因为我喜欢三这个数字，既简约而又不简单，使人看起来一目了然。每条都有四个字，因为我有点轻微强迫症，如果不对齐就会浑身难受，而且用过五笔的都知道，无论是两字词组还是四字成语，都只需要敲击四下键盘就能输入。
列表的三条分别是：【项目概述】、【需求评估】和【阶段规划】，可能会有人说：为什么这么少？能问出这点的人们，首先你们需要先明确我们写文档的目的：只要能让技术人员完全了解一个产品的样子，哪怕是你只写一条也不会有人说你。下面我们举个反例。
上图是在百度找的需求文档，我以一个技术人员的角度去看这个文档，看完前六条之后，我甚至不知道我要去做的是什么东西，那么它错在哪？
不能快速进入主题。
无关开发的内容太多。
那什么是【无关开发】的内容？我曾见过的有：市场调研、竞品分析、用户研究、产品价值观、以及上图的开发风险分析，以上内容基本都可以单独拿出来做为一个独立的文档去写，不要一厢情愿的认为技术人员会去看这些内容，我只想说：我！不！看！
我该怎么写？
知道了写什么之后，我们再谈谈怎么写：
由于以前是搞安卓开发的，我对tablehost和viewpager情有独钟，于是就仿照做了一个Tab分页，如上图。
项目概述，顾名思义，就是要做到看完之后让人大概对这个产品有一个初步的了解，并且心中对产品有一个雏形。那么目的明确了，怎么去实现：首先说明使用人群，使用人群明确之后，才好针对他们的需求，去设计和开发功能，也就是用户需求，而用户需求往往都是多而杂的，需要对其分类之后，再详细描述，如下图：
用户需求大致可以分为以下三点来分类说明：基本需求、期望需求和兴奋需求。
基本需求，便是我们产品初级开发阶段要去满足的内容，也是用户使用你产品的必要不充分条件。
期望需求，便是在基本功能可以实现的基础之上，用户希望你去添加的功能，也是开发中后期以及运营前期我们去要实现的功能。
兴奋需求，便是用户没有想到，但是你不但做到了，而且用户很需要，用户使用之后会感到兴奋，甚至推荐给他人使用。也是运营中后期要去做的事情。
但是在我过去开发经历中，并没见到过什么另人眼前一亮的功能，这不得不算是一种遗憾，甚至有的时候PRD只看了开头，便已经猜到了结尾，这不得不说是业内互相模仿的悲哀。
项目概述写完之后，大概功能就已经了然于心，那么我们就需要将它具体化，而实现这一目的最好的方式就是需求评估，如下图：
图中我只列举了四个例子，当然实际开发中要实现的功能远远不只这些。这个表格有三列，分别是：需求等级、功能名称和功能简介。
我只说一下需求等级：生活中无论做什么事情，先后顺序都是按轻重缓急去分的，开发亦是同理，所以你需要给产品的功能加上需求等级，让技术人员清楚的知道开发的优先级。做完这步之后，你就需要详细的描述每一个功能，如图中左侧的画图功能和跳转事件，这个我就不放图了，大家根据具体情况去写就可以了。
基本上写完以上内容，你的需求文档就已经成型了；如果技术人员看完之后还不知道要去做什么，那只能说明你的PRD不合格。但是真的不合格该怎么办？你需要做的不是去改，毕竟连写都写不好，你又能改成什么样子？你现在所需要的是补救！那么怎么去补救？你需要去写一个阶段规划，如下图：
所谓的阶段规划就是：将一个产品的开发过程一步一步的分解开，详细的说明技术人员在接下来的这段时间具体要做些什么，如果用文字描述不清，那就借助工具：比如说大家用的最多的流程图，你需要在图中把你的产品逻辑顺序画清楚，既要简洁，又要全面，这并不矛盾。除了流程图，你也可以用N-S图，PAD图以及E-R图等，你要记住，用工具不是目的，目的是用工具去解决问题。基本上阶段规划写完之后，PRD就可以结稿了，接下要做的事情就是随着需求的变更而不断的去修改内容了。
本文到这里就即将结尾，如果阅读本文之后，你还是无法写出令技术人员满意的文档，导致技术人员无法理解你的意图，那么不要担心，请等待我下一篇文章的发表，在下一篇文章里，我会去教你们：如何用Axure中最简单的功能去制作一个另人满意的产品原型。
