作为产品新人，进公司后首先要开始写各种文档。在我看来，最重要的非产品需求文档莫过于它了。产品需求文档英文名称为：productrequirementdocument，简称PRD。这份文档是一个产品从抽象到具体的最重要步骤之一，也是技术人员详细了解一个产品的【三部曲】之一。另外两个步骤是产品原型和语言沟通，这将在后面两篇文章中描述。而PRD也是很多产品新人头疼的问题，那么PRD应该怎么写呢？直接明白写文件的目的！一般PRD会被以下三类人阅读：技术人员、公司BOSS和客户，本文和接下来两篇文章的目标用户都是【技术人员】。既然目标群体明确了，把珠三角交给技术人员最直接的目的是什么？也就是让技术人员看完PRD就知道你的产品是什么样子的。一个好的PRD有什么作用？也就是技术人员只有你的PRD，没有样机，也没有语言交流。他做的还是你心目中的理想。我该写什么上图是我专门为这篇文章写的一个PRD。是一款快速原型制作软件PRD，类似于手机版的Axure。我个人比较喜欢用Axure写文档，这样可以直接嵌套产品原型，更方便直观，个人更推荐用Axure写PRD。当然，工具只是辅助，文档的好坏还要看内容。大师也可以用word把文档写得淋漓尽致。接下来进入正题：首先看右边的内容，只需要看一点，就是【文档版】：一个文档诞生之后，必然要经历不断修改的过程，所以修改之后，为了让别人清楚的知道你修改了内容，你需要更新你的版本号，并写上日期和修改的内容。然后看左边的列表，就是目录。只有三项，因为我喜欢数字三，简单而不简单，一目了然。每个词条都是四字，因为我有轻微的强迫症，如果不对齐，我会觉得不舒服，用过五笔的人都知道，不管是二字词还是四字词——汉字成语，只需轻敲键盘四下即可输入。列表中的三个项目是：[项目概况]、[需求评估]和[阶段规划]。可能有人会说：怎么这么少？能问到这一点的人，首先你需要明确我们写文档的目的：只要技术人员能够充分理解一个产品是什么样子的，即使你只写一篇文章，也不会有人批评你.我们举一个反例。上图是我在百度上找到的需求文档。我是站在一个技术人员的角度来看这份文件的。看完前六项后，我什至不知道我要做什么。那么它有什么问题呢？不能很快进入主题。与开发无关的内容太多了。那么【无关开发】的内容是什么呢？我看到的是：市场调研，竞品分析，用户研究，产品价值，以及上图中的开发风险分析，以上内容基本可以拿出来作为一个独立的文档来写，不要一厢情愿技术人员看到这个内容，我只想说：我！不！看！应该怎么写知道了怎么写之后，我们来说说怎么写：由于之前从事Android开发，对tablehost和viewpager情有独钟，所以就仿制了一个Tab页面，如上图。项目概览，顾名思义，就是让人看完之后对产品有一个初步的了解，心中有个产品的原型。那么目的明确了，如何实现：首先说明用户群体，明确了用户群体之后，我们就可以根据他们的需求来设计和开发功能，也就是用户需求，而用户需求往往是多元的、复杂的.对其进行分类后，对其进行详细描述，如下图所示：用户需求大致可以分为以下三点进行分类描述：基本需求、预期需求、激发需求。基本需求是我们产品初级开发阶段要满足的内容，也是用户使用你的产品的必要和不充分条件。预期需求是基于能够实现的基本功能。用户希望你添加的功能，也是我们在开发中后期、运营前期想要实现的功能。精彩的需求，就是用户没有想到，但不仅你实现了，而且用户非常需要。用户使用后会感到兴奋，甚至会推荐给其他人。也是运营中后期要做的事情。不过，在我以往的开发经历中，并没有看到什么让人眼前一亮的功能，不得不说是一种遗憾。有时候，PRD只看开头就已经猜到了结尾。这不得不说是行业相互模仿的悲剧。projectoverview写完之后，功能大概已经很清楚了，接下来我们需要具体化，而实现这个目标最好的方式就是需求评估，如下图：图中我只列举了四个例子当然，实际开发中要实现的功能远不止这些。这个表有三栏，分别是：需求级别、功能名称和功能介绍。只说需求层：生活中不管做什么，都是有先后顺序的，开发也是一样，所以需要在产品的功能上加上需求层，让技术工作人员可以清楚地知道正在开发的优先级。完成这一步后，需要对每个函数进行详细描述，比如图片左侧的绘图函数和跳转事件，这张图我就不展示了，大家可以根据具体情况来写。基本上，写完上面的内容，你的需求文档就已经形成了；如果技术人员看了之后不知道怎么办，那只能说明你的PRD不合格。但如果你真的失败了怎么办？你需要做的是不要改变它。毕竟连字都写不好，又能改成什么？你现在需要的是补救措施！那么如何补救呢？你需要写一个阶段计划，如下图所示：所谓阶段计划，就是把一个产品的开发过程一步步分解，详细说明技术人员在接下来的一段时间内要做什么。如果文字描述不清楚，那就用工具：比如大家用得最多的流程图，需要把你的产品在图中的逻辑顺序画清楚，既要简洁又要全面，这并不矛盾.除了流程图，你还可以使用N-S图、PAD图、E-R图等。一定要记住，使用工具不是目的，目的是使用工具来解决问题。基本上阶段方案写完了，PRD就可以敲定了，接下来要做的就是随着需求的变化不断修改内容。本文到此即将结束。如果看完这篇文章，你还是写不出让技术人员满意的文档，导致技术人员无法理解你的意图，那么不要着急，请等待我下一篇文章的发表，在下一篇中这篇文章，我将教你：如何用Axure中最简单的功能做出一个满意的产品原型。
