产品方法论—如何写好PRD文档

    产品要写的文档不少，但一般来说用，用得最多、最基础的还是需求文档。那需求文档应该怎么写呢？要回答这个问题，首先要考虑的是，这是给谁看的？产品需求文档的主要阅读对象为项目内的产品，交互，UI，技术，测试，运营同学，需要足够地详细和清楚，才能让他们明白怎么按照这份文档来开展下一步工作，所以这份文档的基础性、重要性不言而喻。
    那这份文档应该包含哪些内容，又有哪些规范和注意事项呢，具体见下文：

1、需求记录
    产品PRD文档是产品经理与其他相关人员（Boss，产品组，交互，视觉，技术，测试，运营）沟通和pk的主要工具，每一次的沟通结果都应在这里有一定的体现和记录，因为只有如此，后续的工作才能有效地开展。而需求记录在这起到的作用就是对这个过程有个记录，并且每个看到这个记录的人都能知道这个文档的进展，不会做无用功，重复功。可以想象，如果不做详尽的记录，文档的每一次变化，相关人员看到的时候都会不知从何下手，不知道哪里有变化，上次讨论的结果最后如何做等等。需求文档是一个统一思想，同步进度的工具，而需求记录就在其中起着至关重要的作用。做好了这个记录，需求变更，需求追踪都会变得轻而易举，是我们产品与其他同学“撕逼”的一大利器。

需求记录

 

2、需求背景
    介绍市场情况，产品定位，竞品分析，用户研究，需求来源，需求分析等，这些工作都要做的扎实，可以参考前面的内容。要让文档面向的对象明白为什么要做，做的大致方向，起到统一思想的作用。这里的功夫更多的是在文档外。

3、总体介绍
    对需求总体进行介绍，在这我一般采用思维导图的形式，对需求进行介绍，涉及的模块，功能范围。让大家对需求有个总体的认识。不要过早的进入细节，这点还是很有好处的。只有大家的思维站在了同一高度，才不会在后续的需求讨论时局限于细节，而这点也是在各个评审会上最令人头疼的一点。

4、需求描述

需求描述

 

    关于流程图，有些产品不怎么画，但对我来说，在需求的完善阶段，一个好的流程图，能起到查缺补漏的作用，而且可以让产品不用过早的进入到交互、视觉界面等问题的考虑上。这里想得越清楚，后面的需求变更会少很多。用这个和开发进行沟通其实挺有帮助的，测试也不需要追在后面不停的问，这里有个情况怎么处理。

5、相关原型

    原型的做法往细了讲，太占篇幅，主要分为低保真，中保真，高保真。在工作中，我一般做到中保真的程度，足够传递界面，交互细节。这里还有个特点就是为了便于讨论，最好把需要讨论的页面都做出来。具体一些细节，因为是讨论需求的，就不过多讨论了。有机会在原型篇章再做讨论。