产品需求文档 - UCD大社区

“BRD”必须具备的核心要素

白鸦 — 2010-11-01 13:21:57

和Herbert一起给公司内部的PM们做了一次分享。明天UCD年会不讲这个，在博客上发出来也许有人需要…

前提，我们把产品相关内容分成了：战略、营销》产品市场（客户价值、商业价值、路线规划）》产品设计（功能、内容、信息架构、使用流程）》界面设计》产品技术》研发。
这里的BRD，是“产品市场”的内容，向前关联一些，向后关联一些。

PPT提纲如下：

一、客户价值
一个产品可能包括很多环节，可能面对很多“客户”，客户可能有很多期望/需求。

1、我要服务哪些客户？这些客户是什么样子的？
2、我可以满足他们什么样的需求(提供什么样的价值，核心价值是什么)？我要满足他们什么样的需求？我(暂时)不打算满足他的哪些需求？
-
1、客户的选择、需求的选择是有阶段性的。
2、无论先从客户出发还是先从需求出发，两者都缺一不可。
3、要搞清楚的是你解决什么，而不是你怎么解决。
4、观察客户需求的关联关系，判断需求的发展趋势，和更本质根源需求。尝试引导/激活用户需求的发展。

二、商业价值
任何产品都需要为企业、为社会创造价值。“不赚钱的企业是不道德的”，保证商业价值才能更长期更良性的保证客户价值。

1、我可以为企业创造什么样的价值？
2、这些价值是否符合企业的整体战略目标？
-
1、一定是可以量化的，显性的。
2、商业价值，不一定是赚多少钱。可能是牵制竞争、可能是做基础\长线的搭建、可能是为了生存…
3、当短期商业价值伤害了长期价值的时候，如何平衡？
4、什么钱可以赚？什么钱应该分给伙伴？
5、获取了这个价值的时候，给客户返还了什么样的增值。

三、路线规划
产品的发展需要一个过程，特别是互联网产品它是长期迭代成长的。这个过程需要提前进行规划，虽然规划绝大部分时候会在发展中被改变，但必须去做，不做连被改变的机会都没有。

1、我先满足什么需求？再满足什么需求？为什么？
2、每个阶段的核心价值是什么？
3、执行计划(时间…)？
-
1、市场的发展趋势是什么？竞争关系如何？
2、在这个过程中你的客户会如何发展\成长？
3、如其他产品、环节之间的关联关系是什么？如何配合？
4、要有大格局，但提倡分阶段迭代实施，提倡小项目。

四、历史回顾
没有历史的记录和回复，反复的重新开始，会造成极低的工作效率，更会造成反复的重复劳动、重复错误。对于已有产品（或项目二期），必须重点回顾该产品之前的发展历史和背景。

1、客户价值和商业价值是否发生了变化？
2、二期产品的路线规划和原规划是否一致，（如有调整）调整原因是什么？
3、之前的实际运营效果和计划的差异是什么？为什么？
-
1、没有历史就没有未来。
2、记录历史是给后人看的，也是给自己看的。

五、成本估算
获利 = 商业价值 - 成本。做产品就好像再投资一个项目，对于可能需要付出的成本必须进行合理估算，才能做出合理决策。

1、整合各类资源所需要的运营成本、营销成本。
2、研发和维护所需要的人力成本。
3、同时，还需要对未来的风险进行预估，并给出合理的预案。
-
1、成本估计可以借助更多的角色来帮助完成。
2、成本估计需要建立在一定程度的“产品方案”基础上。

六、评估方法
客户价值、商业价值、成本估算，都应该有可以评估的方式、方法。每个阶段都需要有明确的目标。

1、为什么制定这个目标？这个目标是怎么推算出来的？
2、如何显现这个结果、数据？
3、凭什么可以做到这个目标？
-
1、不需要很具体的产品设计说明、营销说明，都应该可以解释清楚“凭什么可以做到这个目标”。

最后，关于BRD评审原则：
1、一切从客户出发；
2、明确为什么要做？做什么？怎么做？
3、提供必要的数据支持；
4、提倡做小产品、小项目；
5、不以获取多少“资源”为前提。

评审内容包括：“产品市场计划书”、关键的用户使用过程Demo、核心功能的List

白鸦，2010.10.22

相关话题：产品需求文档源地址：http://uicom.net/blog/?p=890

产品文档的用户体验

raby — 2010-11-01 13:14:38

有很多人跟我说过，产品设计过程中，最讨厌的就是写各种产品文档。一方面强调速度的互联网产品，加入此环节，会降低开发速度；另一方面当产品的定位、概念模型或原型已成形，文档撰写工作就相当枯燥无味，毫无乐趣；更重要的是，你写出来的文档可能根本就没有人阅读。

最早我也是如此认为。产品成形再费力的去写产品定位、功能设计有何意义，更何况重要的流程和规则都已在原型中标注，何必再多此一举。但是几个项目下来，我发现文档仍然有它自己的功用，如果维护的出色，将是产品设计人员的好帮手。

l 借助文档再次系统性的思考产品的定位或者原型设计。当我们在开会确定产品定位策略、用户策略时，通常是在相当长的讨论中完成。如果没有文档整理，难免产品小组成员对决策认识有忽略的环节；而深入到原型设计中，分散的注释也难有系统性的描述。我经常有在撰写PRD文档的时候，发现原型设计上的失当之处。前期发现缺陷修改，比后期补救自然能节省不少时间。

l 文档撰写也是技术活儿。如何写让读者，用更少的时间，清晰的了解产品的策略及设计细节，是件相当考究的事情。不是有很多人抱怨自己写的文档没人阅读吗？你得好好想想，是否只把它当成了码字的体力劳动。

l 对产品思路的记录，有据可查。很多人会说我记忆力很好，产品的各个环节我都能记住，需不需文档记录，差别不大。但是不是团队里的每个人都有这么好的记忆力。我相信好记性不如烂笔头。当产品要做相关模版的关联开发时，模块内的细节规则需要准确了解。这时候文档的回溯功能变能得到充分的展现。

就像做产品一样，需要考虑文档各种读者的不同需求。我想这里面多少有些技巧是值得探讨的：

1.概括分组+小标题

这里有一个较出名的原则“7±2”原则，主要意思是人一次能够理解的思想或概念的数量是有限的，最高限度是5-9个项目。因此我们需要将观点按照一定的逻辑关系分组阐述。并且配合使用能概括此段的主要观点小标题，这样读者就可以开始在阅读这段的最初几秒钟了解你的观点。

2. 模版不是为了让文档千篇一律

很多公司为了产品的规范性，减少项目成员阅读文档的学习成本，都制作了相应的产品文档模版，规范不同产品设计人员的写作风格。但产品人员因根据内容的不同性质，应灵活应用模版。拿PRD为例，以承载内容信息为主的页面，与以互动交流为主的页面阐述重点将有很大的不同。展示内容的描述，主要阐述展示字段、提取规则、排序规则、链接地址及方式等；而表单类的描述，更偏重流程及填写规则的描述。

3. 能用图不用表，能用表不用字

如小标题描述的，读者总是会对图比文字有更高的接受度。07版的WORD提供了Smartart的功能，给我们极大的方便，可以充分利用里面各种类型的图来表达观点。

4. 文档也需要排版

排版有很多技巧，例如留言、间距、字体大小颜色的对比等。一个排版很舒服的文档，浏览者会相当的轻松的找到重点。这里有篇介绍如何排版PPT的文章，很多原理也适用于WORD——《如何设计一份令人舒服的PPT（上）（下）》。

5. 回访你的文档读者

其实很多人都无意识的做了这件事情。每次我写完PRD，同步给技术和测试人员后，会询问他们阅读的情况，并根据他们的反馈做相应的调整。有人会嫌麻烦，其实这个环节一般你只需要1个小时就能搞定了。

总之你需要根据文档的性质、内容和不同的浏览者，做出不同的调整。这个过程不仅仅是简单的陈述想法而已。

相关话题：产品需求文档源地址：http://www.xmued.com/?p=1421

比“以‘PRD’为唯一依据”更高效的产品设计方法

白鸦 — 2008-07-26 21:45:39

在上期关于信息架构的文章里我匆匆留下”一个网站不超过30个界面”的观点，有不少人表示疑问和不解。

其实这里是我未表述清楚，结合Angela在上期介绍的这个迭代过程：”任务分解(粗略) > 信息架构(主要) > 任务分解(详细) > 信息架构(详细)”。
应该不难明白：事实上我所说的”30个界面”是指”信息架构(主要) “这个阶段时的界面，而非真正最终归纳到一起的网站界面数。因为，我们最好用最少的界面综合总结整个网站的界面(信息)架构。
再咬文嚼字一点来说，我更加愿意把”信息架构(详细)”这个过程称之为”交互原型设计”。(Angela大概也是为了更好的说明这个过程，所以才这么称呼的)

可以简单的认为把”信息架构(详细)”里所有的界面原型完整的总结并链接起来其实是我们在”交互设计”阶段最重要的工作 — 任务分解。

1、任务分解的基本原则和方式

我常给项目组人说：任务分解应该是一个从整体到细节的过程。每个网站就是一个大任务，通常每个网站栏目又是一个分任务，所谓任务分解就是大任务分成小任务，再把小任务分成小小任务，然后小小任务分下去就具体到了每个页面的每个元素和每个过程可能出现的每一个小提示等。
它其实是一个剥树皮的过程，最好的方法是一层层的往下剥，而不是一股脑在某一块死剥到底然后再一股脑的在另一块剥到底..
拿最简单的”注册”任务来说，我们先设计：”填写注册信息 > 发送验证 > 验证注册 > 注册成功”；然后再去设计”填写注册信息时格式错误怎么办？发送验证的时候发送成功的提示是否需要？”等问题；最后会具体到每个页面的每个按钮、每个文字…

也就是说我们最好先做的是把整个过程走一遍然后再一层层的完善细节，而非每遇见一个地方就停下来完全把细节搞透，然后往下走。
和画画一样，我们会先画好构图和透视，然后一层层的往细致里面刻画，而不是先只刻画好鼻子，然后再去刻画嘴巴..

2、如何统计要做那些任务的分解

来源一：功能的信息架构
来源二：具体分析每个角色在使用该产品过程中最常用的功能需求
来源三：商业需要给流程提出来的额外任务

统计有多少可以想到的任务很简单，一般都能迅速统计出N多的任务；综合对比所有统计出来的任务，做一些筛选和提炼，是需要很多经验积累的。
所有的任务只需要覆盖所有的功能点和用户操作点即可。如果你做了两个极相似的任务，如果你的任务A和任务B其中有三四个点是一样的，那其实是在浪费时间和精力。

3、我的实践方法

通常情况下我们任务分解的产出物最好是可以演示操作过程的中保真交互原型；这样的原型起码可以简单的模拟单向的人与机器交互。（所谓的”单向的人与机器交互”指，用户点了”下一步”会出现什么，点了”完成”又出现什么。不包括”用户A发了一个信息，用户B看到後返回一个信息”..）

具体到以往项目中，任务分解产出物我会有三个：每个任务的详细分解流程图、每个流程图的说明文档（基本类似某些公司的PRD，但要比PRD简单很多。一个PRD往往需要30页左右，这里只需要不超过3页）、带链接的动态HTML中保真原型(包括ajax效果)。
工程师拿到这三个产出物以后就可以很好的开展工作了，强于某些只看文档的做法…

每个任务的详细分解流程图（附一个某网站邮件邀请的小流程）

作用：让工程师和产品设计都能很好的具像的详细清楚理解产品的交互流程及逻辑；产品交互设计的每个点都能在此很完整的体现和阐述。

每个流程图的说明文档：
作用是补充说明某些细节的逻辑以及算法，主要为工程师的开发需求说明。
比如，同时上传N个照片，那么他们的排序是什么样的、照片的ID需要如何生成、照片的名字是否需要有中文和长度的限制等等；

带链接的动态HTML中保真原型：（黑白的带链接的网页即可，在此就不拿具体的样例了）
他的作用：可以很好的完整模拟除了和数据库交互之外的几乎所有用户操作过程，让包括工程师和老板在内的所有团队成员可以很巨像的理解产品的每一个具体交互过程，在原型的用户测试中也可以很好的让用户体会到更加真实的产品使用效果。
有人会问：成本是不是太高了？，答：成本很不高！因为前面实际上在信息架构里面已经做了这些页面，在做流程图的过程中也陆续完成并添加了信息架构里面未包含的细致页面，其实这个工作只是把这些界面加上链接而已。

另外，一般在做软件设计的时候我会用PPT来代替HTML页面。PPT一样可以很好的实现简单的人与机器互动演示。而且软件的原型就直接在PPT里面画好，拷贝到PS里面做流程图即可。

还是那句话：设计师有其他角色不具备的能力 — 模拟未来。
交互设计就是讲故事（链接一、链接二），用故事来模拟未来，每个任务的分解就是一段故事。故事的情节设计越符合真正用户的使用情景，设计就越合理。
我常说：任务分解中的情景设计其实是借在用文学创造的方法，更加形象的完成产品设计的目的。但，却又并非是在搞文学创作。

最后，当你阅读完了任务分解的做法，至于本文的标题，我想，没必要再具体做论证了…

基于Axure的PRD写作思考

kent.zhu — 2010-08-11 08:56:47

本文想说的事情是，那个叫PRD文档的家伙只是个称呼而已，PRD的问题不在于如何写而在于如何被传递与执行。这里简单介绍一下我基于axure rp的一种新的PRD写法。（友情提醒：从来不用axure，认为他笨重无比的人请路过。）

从半只脚迈入产品经理这个大门的那天起我就被2个文档的名称深深的纠缠着，他们是市场需求文档（MRD）、产品需求文档（PRD）。先不论你是什么方向的PM，这2个玩意一定会一直伴随你的Title跟着你。这2个文档在不同的团队中有不同的叫法和写法，我也见过有团队的MRD其实就是PRD，不沾半点商业市场分析的边的，当然，这些不是本文探讨的内容。

长久以来，有个很有趣的现象：“有没有PRD模板，PRD该咋写”这个问题已经成为新手入门经典必问题目之一；如果1年以后这个家伙还在这行里混，他一定会抱怨，娘滴，我们的QA压根就不看我的文档、我们的交互（如果有这个职位的话）还是会问我一些我写的很明白的问题、我们的测试拿着文档问我该咋测试、….

Web页面之间的关系是网状的，而Word文档只能树状的表述，这无疑是矛盾的；PRD文档无法做到实时更新发布，我回顾了我第一年写的PRD文档，很多下面的修改栏都是空的，惭愧之至….；所谓一图胜千言，万言刚够文档标准，每个PRD都是臭长臭长的，这样的东西别说交互设计师了，很多PM自己写完了都不想看。所以，我武断的认为，撰写某些PRD文档实在是一个既耽误时间又费劲且不敏捷的事情（很多PRD都是一夜情，写完了就不会修改更不会有人乐意看100P以上的文档），是在让产品经理实现慢性自杀！

个人认为，一个PRD文档需要包含以下的内容：

1、概述
1.1、名词说明：文档中涉及到的名词
1.2、产品概述及目标
1.3、产品风险预估
1.4、产品开发进度：产品开发阶段及责任人与时间节点
2、使用者需求
2.1、使用者需求描述：定义用户是谁
2.2、管理员需求描述：后台管理部分（很多人会忽略这个部分）
2.3、任务流程图：从业务逻辑流程到产品逻辑流程转化
3、功能需求
3.1、功能总览
3.2功能需求分解：界面分解及交互说明和用例
4、非功能需求：与该产品相关联的辅助产品等
5、上下线需求：产品的生命周期
6、运营计划：产品的上线后的反馈与改进

整个文档中，最大的部分其实是对功能需求的分解，但是最核心的部分是使用者需求与功能需求部分。使用Axure后，我发现Axure可以很好的承载我平常写的这个产品需求文档的全部内容，最主要的问题是，Axure是可以网状的展示的。下面是举个例子：

在Axure的站点导航中，默认的Home页面承担了PRD文档的第一部分内容；而使用者需求描述及任务流程图也可以由Axure自带的流程图功能完成；任务流页面的分解本来就是Axure中完成的；最后的非产品功能部分也可以由axure完成（文本块组件）

同时，Axure支持多种格式的输出，一般情况下我是发送给团队Html文件包，也可以是.chm格式的文件（团队协作目前还没有尝试）。该文件包打开后，左侧是整个系统的导航菜单，右侧是相应的说明。最主要在于，原型中的页面是可以相互跳转的（得益与axure的强大交互功能），同时页面有注释功能。所以，整个产品需求文档真正实现了基于产品的模拟，网状的传播，而不是Word式的树状阅读。

1）见过不少新手使用Axure生成的原型有页面是空白的，我问为什么，他说这个页面不知道放什么，但是又不能不命名，否则逻辑上有些不通。实际上，这个空白页面就可以用来放这个页面的流程图及整体的说明。

2）不建议做太复杂的Axure动作，比如使用多个层、动态面板等。因为在工程师等的眼里原型图是不可以点击的（基于viso等的惯性思维），所以，为了避免花很长时间去实现一个很炫的axure交互而最后被埋没，建议把任务分解来画。比如一个输入框，需要画：默认状态、获得焦点状态、输入字符判定状态、失去焦点状态等，按照逻辑分步来展示。（在我特别蛋疼的时候我会先分步展示，然后搞个比较炫的交互放在上面自己玩或者用于演示）

3）在每个页面的下方或者侧边（由页面大小来定）要放一个功能详解的文本块来对本页面的功能进行详细说明。也可以直接使用Axure自带的注释功能（组件注释、页面注释）为什么不推荐用Axure的组件注释功能？因为这个功能在生成的原型里是被隐藏的，有被人无视的可能。

4）使用axure的组件库功能（可自制）和模块功能既可以保证设计的统一性（设计规范），又可以提高原型制作的效率。图中我采用了注册模块。

下面，QA时间（这个QA是问答，文中的QA是技术，呃，注意区分）

Q：为什么我看到有的书上说要写N多文档，带RD的有：BRD、MRD、PRD、….
A：是的，有这样的定义。BRD（商业需求文档）、MRD（市场需求文档）、PRD（产品需求文档）。每个公司的风格不一样，我个人倾向于把BRD与MRD整合，PRD单独做。但是MRD与PRD中会有内容重合，就是会同时提到用户是谁？为什么要做？产品目标是什么？等几个问题

Q：Axure有个功能是可以导成Word格式，把做的原型导入后是归类好的，包含了用例文档，为什么不这么玩呢？
A:没人说不可以这么玩。还是那句话，个人习惯。

Q：除了页面原型之外你塞了这么多东西到Axure里，会不会导致源文件以及生成的文件体积巨大？
A：实际上塞进去的东西都是文本，使用axure的文本组件完成的，体积并不会大。同时，请不要在用axure做原型的时候使用过多的图片，尽量是用组件和模块完成。我目前位置做的最大的一个原型是4.7M，这是一个完整的系统原型。

Q：按照你的写法Axure好像是万能的了？
A：没有不好用的工具，只有用的不顺手的人。人是活的，工具是死的，且Axure目前在mac平台下功能并非很强大，也有很多人觉得axure很笨重，更加喜欢轻量级的原型功能。不过，这些都不是核心问题，核心问题是要让你的团队能够以最高的效率进行合作。使用Axure的人不必鄙视Viso，用excel的人也不必羡慕OmniGraffle，拿Word的人也不必留恋firework。

既然提到了MRD也顺便说下我写这个文档的习惯。一般情况下这个文档是给老板看的，主要是对市场的分析、同类产品的竞品分析、我们产品的盈利预测等等。所以，一般由PPT来完成。你的文档越长老板越反感，你的文档文字越多老板越没兴趣，所以，PPT是最好的方式。

文档这个东西跟流程有类似的地方，大公司会相当重视这个事情，因为要规避风险。流程与文档的核心点在于如何高效传递如何快速执行而不是他如何写以什么形式写。相对于小团队而言，流程之殇大可避免。当然，如果大公司能够以小团队的心态去做大产品的话，定会事半功倍！我更相信小团队大产品的力量，而不是大团队大产品的说法。

产品经理不是神，需求文档不是银弹

大徐 — 2008-07-31 10:27:41

几乎每个项目都会时间紧、任务重，在形成快速反映和调整的团队之前一定会出现这样那样的问题。现在的项目几乎都是多工种共同参与才能产出，职责分工、流程因此很容易成为问题，因为时间紧、任务重而产生的问题也会很严重。昨天写了一篇关于超级产品经理的文章，其实今天要写的这个东西也和这个有关。我始终认为，每个角色都有话语权，都不应该成为工具，而项目最终的产出一定是所有人智慧的结晶。而且需要从繁杂的项目管理事务中把产品经理解放出来，让他们回归本质。

最近遇到一种情况，开发团队把开发过程中的反复、出现大量的bug等问题的根源归于需求文档，希望文档写的更详细，更确定。测试团队把bug的反复、新功能缺乏开发工程师自测等问题归于需求文档，希望文档写的更详细，更确定。现在因为还没有法务、客服、BD、市场等等其他部门的同事，因此还没有得到他们的反馈。唯一的欣慰是产品团队和设计师、前端工程师的沟通比较频繁和畅通，因此对方没有提及这个问题。在这个问题上我认为产品经理不是神，需求文档不是银弹，软件工程许多年来的问题通过产品经理解决是不可能的，通过需求文档解决更是不可能的。

对于要求产品经理全程跟踪产品，把握每个细节和过程的意见我很赞同，我认为，产品经理是虚拟团队的领导者，是项目、产品的CEO。还能有谁更清除产品的所有细节？如果产品经理不去全程关注谁回去关注？管理一个产品就要管理它的方方面面，管理它的前世今生。

对于加强流程的建立，加强评审机制的意见我也很赞同，流程很重要，多成员、多角色的项目中流程很重要。每个人的思维和意识都是有局限的，每个人的经验和能力也是有局限的，我们中间的所有人都不是天才，没有人可以完全的独当一面、力挽狂澜。任何产品都需要不同工种同事的讨论、建议甚至是拍砖，这样才能汇聚大家的智慧，帮助产品经理完善产品的细节。

对于细化文档的意见我也很赞同，文档很重要，虽然有很多比文档更重要的东西，但文档还是很重要。我们的每次思考、每次讨论，每次会议、每次变更都要体现在文档上。我们每个人的脑子都会遗忘，俗话说好记性不如烂笔头子说的就是这个道理。通过语言的表达根据时间、表情、语气的不同会产生信息传递的偏差。产品的复杂性决定了需求的复杂性，自身的逻辑性和环境内其他部件之间的关联等内容让我们不得不采用结构化文档的方式来记录。文档在一些时候也可以提高交流的效率，特别是一对多的时候。文档也可以是一个存档式的东西，后续版本的需求变更要依据它，项目成员更替也需要它。

但………………

产品经理不是万能的，应该解放产品经理，现实的情况是产品经理要做很多事情，完全和我之前提到的“超级产品经理”的情况相反。和管理层沟通，领会公司的策略和方向。和用户沟通，满足用户的需求。和各种角色的同事沟通，领导大家一起出力。关注公司内外的资源，做项目管理，保证资源，保证沟通，保证进度，保证结果。靠产品经理一个人大权独揽，什么都干，显然是不行的。我觉得靠谱儿的办法应该是有专职的项目经理，别以为这个时候项目经理会闲得慌，专职的项目经理应该很忙。而产品经理的主要关注点应该回归到产品要满足的需求上面，充分考虑和调研用户的需求，做充分的数据分析和行业观测，保证产品路线协同公司的发展规划。说到底，就是我觉得应该解放产品经理，不让他们兼职做项目经理的事情。

流程对项目本身也会起到负面的影响，互联网上的应用要求快速决策、快速开发、快速响应。要求产品团队及时调整、及时变更、及时应对。要求技术团队做敏捷开发，做快速响应，不断重构。使用快速原型的方式活其他更灵活的方式进行迭代式开发，而不是采用传统的瀑布式的项目开发方式。我希望项目团队中的每个人都是产品经理，每种角色都贯穿于产品的生命线。产品经理只是个“主事儿”的而已，产品经理决定做什么，其他角色决定怎么做。

文档是问题的一部分而不是解决问题的一部分，写文档只占产品经理工作的很小一部分，产品经理更多的工作是在思考和沟通。一个产品从无到有，在产品经理的脑海中逐渐成型，经过和不同角色人员的沟通不断的完善，最终通过撰写的文档体现出来。撰写文档相对简单，占用的人力资源也少。这就像系统设计往往需要较多的时间，具体编码的时间相对较少。

靠产品经理来试图解决软件工程这么多年的问题是不可能的，产品经理撰写的需求文档无法解决项目延期的问题、无法解决软件维护复杂的问题，无法解决成本过高的问题。难道产品经理写个80页的详细需求文档就可以放假回家了码？产品就可以完美开发了？用户就喜欢了？公司就挣到钱了？其实文字只是沟通方式的一种而已，要充分利用这种沟通方式但也不能过于依赖。产品经理要写多少文档才可以？市场需求文档、产品需求文档，会议纪要，方案，策划，规范，文档文档还是文档！产生更多的文档肯定不能更好的解决问题，达成项目的目标。

我相信写个80页的文档不会有几个人会仔细的看，那么这个文档给谁看？给领导看？给开发工程师看？给设计看？给前端工程师看？给客服看的？给法务看的？给商务看的？给市场看的？他们要看的、能理解的东西一致吗？产品经理写的需求文档能满足所有的需求吗？一定不能满足。这时候就需要短平快的去通过各种方式去沟通，包括文字、图像和语言。

另外就是我一直坚持的一个观念，产品经理的人力资源无法预估！开发可以根据产品需求文档预估，根据页面数、产品复杂程度、安全级别等内容进行人力预估，测试可以以开发时间的一半来预估。但产品经理的工作如何预估？答案是没有人可以预估。但现实是领导总会对产品经理的人力资源做预估，或者产品经理迫于某些压力自己做人力资源的预估。这样的情况很普遍，但是需要改变，给产品经理一个相对宽松的环境来工作。

相关话题：产品需求文档源地址：http://daxu.net/archives/851.html

产品需求文档的10步

风到月来 — 2009-07-05 20:49:21

做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

第一步：做好准备工作

你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。

第二步：确定产品的目的

任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。

产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。

产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。

这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

第三步：确定用户原型、用户目标和用户任务

现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。

用户原型

在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。

比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。

PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。虽然是想像的，但是应该是典型的、可行的和真实的，让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。

举个例子：

“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。虽然他开着一个小店，但是他的生意大部分来自Ebay,每个月平均有400多次交易。他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷，还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。

里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。里昂已经在Ebay上销售产品已经三年了，他学会了在ebay应该掌握的东西，他非常自豪的拥有超过5000的信用度。如果Ebay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。”

但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时，我就要问问自己里昂会是什么发应，为了让他能顺利的使用这个功能我们需要做什么。

注意缩小范围，让他仅仅描绘必不可少的。满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户。

用户目标（用户意愿）

一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。

从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。

最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。

用户任务（tasks，用户为达到目标使用产品而需要做的任务）

掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。

许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。

以“必须功能”这个理由可以排除很多功能。讽刺的是，你用越少的功能，你的产品被发现得越来越强大。这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

第四步：定义产品原则

现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡，为你的产品标准作出最佳的决定是非常重要的。

在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。
尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。

用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：

1.它是娱乐的
2.一个傻瓜式的电视
3.一个该死的视频设备
4.平滑柔顺的
5.没有模式和深层次
6.尊重观众的隐私权
7.像电视一样强大

这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。比如易趣的口号就是：1、易于使用 2、安全 3、有趣

它将在该项目中，在面对众多问题而作出决定的时候进行指南.

第五步：产品原型和检验

这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方.

很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。

对于许多产品来说，这个时候你可以用大量的原型做很多的实验。首先，下面的三个非常重要的测试你可能需要做

可行性测试
一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的，但是有其他的办法可行是非常有希望的。
工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。

可用性测试
产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。

概念测试（Product Concept Testing）
光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。

对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。

原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并且他们可以给您质量反馈。

以前做原型主要有两个障碍。第一是缺乏良好的原型工具，需要花费很多的时间制作原型；另一个是管理方不知道原型和真实产品的区别，在不可预计的情况下，按照最终产品来要求原型。

今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型，可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样。

在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始，作出重要的变动会变得非常困难，花费也会变得很高。

第六步：验证和质疑

当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。

假设甚至当作不知道是很容易的，但是切勿把不可知的结论当作指引，那会妨碍你获得成功。天文学最初定义是研究太阳和其他行星如何围绕自己转，本身的定义就是一个臆断，反而阻止人们获得真相。

第七步：写

当然你需要把这些都写下来，大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。

记住对话是两个人之间的，但是PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。

PRD文档主要有四个部份组成

产品用途
你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：
*那些问题你要解决，不是解决方案
*谁是目标用户
*细节很多，但是大图片必须清晰
*情景描述
多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。

产品功能特性
产品需求文档最主要的当然是需求。具体的需求完全地将取决于您的领域，但是不管你是什么行业，您的产品团队将受益于陈述需求的清楚，毫不含糊的要求，而不是模糊的解决方案。
描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验，还需要给工程团队留下足够多的灵活自主空间。
同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”，对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的，如果某人决定削减要求，想要深入了解就会非常困难。从要求到目的明确说明将会是文档更加清晰。

发布标准
发布标准经常是不断变化的，但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如：性能，可测量性，可靠性，可用性，可控性。

时间进度
其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的，你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标，最终完成一个成功的产品。

第八步优先级

除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理，如果他们给予优先级，一般都是表明要求是否是“必须有， “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的，不可掉以轻心。

产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”，这些标注“必须拥有”的功能直接反应出产品的核心价值。
“重要”的分类也很重要，在产品销售前只要有机会就要满足这些功能。
“希望拥有”产品团队也应该注意到，即使大多数也都没有实现，在未来版本也适当的慢慢实现。

这些有时候是不够的，从1到n每一个分类优先排序都是很重要的。有几个原因：
首先，上市时间总是被关注，并且日程表经常下降，您说不定被迫使削减有些特点为了尽快进入市场。你也不想产品团队先开发简单的功能而放松重要的功能，导致最后客户使用的关键功能还没完成。
其次，在产品设计和开发阶段，团队将会发现更多的问题产生并解决这些问题，所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。
这点就是说产品经理如何不给出优先级和重要等级，其他相关较少的因素也会跟着无法确定。

整个PRD是一个不断完善和思维提高的过程，明朗锐利就是可以成功的产品的，模糊就是失败的产品。在争论最激烈的时候也能容易做决定，并且帮助工程师做出计划。

第九步测试完整性

现在你有一个PRD草稿，你需要测试它的完整性。工程师是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？

当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。

第十步管理产品

在产品实施期间，就算是最好PRD，也有不计其数的问题被解决。解决所有PRD中存在问题，如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。

如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部份都历历在目。

记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。

本文大体已经结束，全面的阐述一个PRD的产生和管理过程，感谢SVPG的分享。接下来有空闲时间我会整理上传一份互联网行业的产品需求文档模板在本页面，供大家下载。

相关话题：产品需求文档源地址：http://www.xaoxua.com/

从“产品需求文档”（PRD）到“产品设计文档”（PDD）

心弦 — 2009-12-22 20:56:27

传统上写产品需求文档（PRD）的做法，就是把用例、流程图和网页原型图一股脑的放到一个Word文档里。一般一个产品都包含乃几十个乃至上百用例，每个用例都有自己的流程图，每个流程图又包含了少则几个多则几十的网页原型图，结果就是产品需求文档变得庞大无比，写的人费事儿，读的人更惨。

自从我受到了这样文档的折磨，我就一直都在琢磨怎么才能把文档写得更简单一点，让阅读的人－通常是设计师和程序员－能够在最短的时间内领会产品的设计。

原来做UI设计师的时候，我创造了一种用流程图来表示产品交互的办法，这个方法受到了很多人的欢迎，这篇文章也引起了一定的反响。其实当时在实际使用的时候，我不仅产出这样一份流程图，还利用网页热区，把流程图中的界面元素（蓝色的元素）和原型网页（HTML文件）给结合起来了，这样设计师和程序员在看流程图的时候，只要用鼠标点一下界面元素，就可以连接到原型网页，非常方便！这个办法我一直都在用，只是当时没有写在文章里罢了。

后来随着工作性质的变化，我需要越来越多地考虑产品的整体和功能、而不是像原来一样只在特定需求内围绕界面做文章，我就开始寻找把用例整合进前述方法的可能。在经过了一段时间的摸索和实践后，我逐渐形成了自己特有的一套产品需求文档的写法，为了表示区别，我称之为“产品设计文档”，简称PDD。

本文就是对PDD的介绍。

PDD的组成部分

PDD有三个组成部分，它们分别是用例、流程图和原型图。

用例

用例从整体脉络上定义了产品所具有的功能。比如对于一个邮件系统来说，“写邮件”、“发邮件”和“删除邮件”等功能都是用例。

用例比较流行的写法，是在每一个用例中标明它的前后置条件和异常情况等属性。不过在PDD中，我完全放弃了上述属性，只保留用例的名称和简要描述。因为“用例”的出发点就是“用户”，如果你站在一个用户的角度来思考产品的功能，你会发现那些属性你根本就不会考虑。并且，各种前后置条件和异常情况，完全可以放在流程图中，这样更清楚。

流程图

流程图是对用例的细化，它可以清晰地表现一个用例所有相关的前置、后置和分支条件。流程图的画法我在“画Web流程图的一点心得”一文中已经说得非常清楚了，在此不再赘述。唯一值得注意的是，我以前并没有意识到流程图本身也是有ISO标准的，因此“画”中使用的流程图元素并不符合ISO标准，也和一些已经成型的系统（比如这篇“描述信息结构和交互设计的图示词汇表”）有出入，因此元素在使用上还存在一些问题。在日常工作当中我已经对元素使用做了修改，以后有时间我会更新“画”一文的内容，也有可能直接把模板放出来。

原型图

原型图是对流程图中“界面元素”的展现。这个东西没什么可说的。

PDD的表现方式

用例、流程图和原型图一般都是产片需求文档（PRD）中已有的东西，PDD在这点上和PRD没什么区别。而下面要说的表现方式，则是PDD的精髓。我比较孤陋寡闻，还没看到过有人像我这样组织这三块内容，所以姑且认为这是我的首创吧。

用例和流程图

首先把用例和流程图整合起来。方法很简单，利用网页的frame标签，新建几个帧：

index.html－另外两个帧的容器，不用解释吧
navigation.html－导航帧，用于存放用例列表
main.html－默认情况下的主帧，用于存放文档简介、作者、版本和更新日志一类的东西

然后新建一大堆网页，把所有的流程图都放在这些网页里，每个流程图（即每个用例）放在一个网页里，最后修改navigation.html，把用例名称和其对应的网页链接起来。完工以后，页面应该是下面这个样子：

PDD文档首页

左侧为用例，右侧为流程图

好了，左侧为用例，右侧为流程图，这样就把用例和流程图整合了起来，并且结构清晰，查看方便。

流程图和原型图

整合流程图和原型图的重点在于，提供一种方便的方式，以让读者能够在看流程图时方便的看到其中包含的原型图。为了达到这个目的，我的做法是：

在用OmniGraffle画流程图时，选择界面元素（蓝色的那个），然后在“检查器”－“属性：动作”中选择“打开文件”，然后按“选择文件”，找到你的原型图文件并按“确定”，这样你这个元素就和原型图链接起来了。如下图所示：
在OmniGraffle中输出这个流程图文档时，不是选择图片，而是选择“HTML图像映射”，这样在生成出来的网页上，蓝色的界面元素都是可以点击的，点了以后就链接到原型图。很方便对吧？但这还不够；
用Lightbox，把所有图片链接都改成弹出图层，这次再点刚才那些链接看看，效果是不是更棒？

好了，通过这样的方法，产品设计文档（PDD）就将用例、流程图和原型图这三块内容有效的整合了起来。

如何正确的看待：产品需求文档和产品需求

费杰 — 2010-08-17 11:42:16

其实那会还在北京的时候，就曾经写了篇文章叫《正确的写产品需求文档（PRD）》后来被转载无数，现在想想那会还仅仅是停留在技能的熟练度一样，或者说通过这篇文章可以让大家掌握一种快速文档的套路。

因为最近还是有很多新人问我要产品需求文档，他们很想看看一个典型的产品需求文档应该是什么样的，我直接拒绝了，我一般会说：“请多想想”。我是这么的理解：看文档本身其实是没有意义的，特别是产品需求文档，其实是需求的产物。作为产物就好比是你今天用一个手机，看手机的说明书一样，你已经知道了这个产品是什么样子，但是为什么这么做，如何做？先做什么，后做什么，你还是不知道！

所以从产品需求而言，文档本身没有个推导的过程。这也就回到一个问题上，很多产品经理新人本身是意识不到，如何做需求，如何写需求文档的差别的。在他们的潜意识里，反正公司是需要有产品需求文档这么一种载体来表达他们的想法，所以很自然而然的认为，学会了写需求文档，就掌握了如何做需求，处理需求一样。

这样听起来有点绕口，但我表达的观点是：想与做的过程是分开的。一个是过程，一个是因为有这个过程的产物，很可能很多时候产物本身可能没有太多的意义。但从表象上来看，文档写的有没有逻辑感，有没有层次感，表述的文字是否清晰、清楚也是一种境界。

很多时候我们写方案做PPT，很多人写出来的东西是完全不一样的。那PPT的宗旨是：简单、标题化、有视图、也不乏空洞。之所以举这个例子，其实是所以一样的情况。写产品需求文档本身其实更多的是：产品需求推导的过程。因为先有了推导的过程，然后再有了推导的结果。很顺利成章的，各位产品经理新入门的朋友，你是否也具有：“产品推导”的过程呢？

产品推导的过程是：做什么，为什么要这么做，谁来做，怎么做，一步步怎么做，最后做成什么样，最什么要做成这样，不做成那样。写需求文档的过程其实就是处理需求的过程，所以以上这几点有没有写想明白？很多公司要做一个产品，可能高层是想要一个东西，但在执行的过程中因为上下级之间认识、理解的不一样，所以在执行的过程中或多或少有所偏差。所以在这个过程中，回答上面几个本质的问题，是会纠正你做需求的思路，不会做弯路。

产品经理这个群体是个很奇怪的群体，他们的主观性非常的强，喜欢把产品按自己的兴趣和喜好去做，所以得出一个结果本身不难。因为这个结果很可能是出于产品经理主观喜欢的结果，但如果从过程出发得到一个结果，这个时候大家相比一下过程和结果本身而言，对于结果的认识想必也会不太一样。

结合今天说的主题：《如何媒体正确的看待：产品需求文档和产品需求》，产品需求文档可以是没有固定格式的，大家不要把产品需求文档想象的怎么样怎么样。写产品需求文档，是做产品经理的一个基本能力，写的逻辑感怎么、层次感怎么样，写的是否清晰和明白，是有一定差别的。但本质上不管是excel、word、rose、还是txt，其实都是次要的。

宗旨：让给你需求拍板的人，知道你的逻辑是什么，让和你一起做的程序员很清晰的知道需求是什么，让给你一起测试的人员知道你的细节就可以了。以后也方便于版本升级，知道你一个版本、一个版本都加了哪些需求，改了哪些需求，删了哪些知道需求就可。所以文档本身起到的东西就是这个，一个是告知，一个是存档。

但产品需求是本质核心的东西，只有你想明白要做什么，怎么做，谁来做，一步步推导的过程是否合理、是否让自己信服，让别人信服，这才是最根本的。有了这个做保障产品需求在文档化的过程中，才会层次分明，结构清晰。所以当很多朋友一直在问我文档怎么写的时候，请大家好好的想一想：我应该在哪几个方面处理这个需求，需求的维度怎么切割？需求的优先级怎么切分？哪些是核心的，对整个产品起到重大关键的？哪些是锦上添花的？哪些是可有可无的？需求的主线是什么？……等等

只有想明白了这些，才会轮到如何把产品需求，进行文档化的阶段。这个时间，我们再回顾头看看《正确的写产品需求文档（PRD）》，通过一些小的思维方式把写文档的技能组织起来，发现所有的一切都是那么顺利成章。最后也忠诚的建议大家：要想学会写需求文档，请先学会怎么样分析需求开始。生活也一样，从本质看起，这样我们感受到的会不一样。

相关话题：产品需求文档源地址：http://www.kuliqiang.com/?p=3209