PRD产品需求文档到底怎么写？

[何洪文]

我们经常提，但如何下手？应该包括哪些内容？

请高手具体指点一下。不要太空洞，实际一点，

如果有模版或已有例子供参考，那再好不过了。

谢谢

[健杨]

wif...@gmail.com

同求

2009/6/5 引子 <yinz...@gmail.com>

一般离不开基本的概述，包括名词说明、产品目标等；主要说明功能需求，还有可能的非功能需求；成本、风险也要兼顾；运营类的还要做好上下线的说明。

当然，不同类型的产品会有着差别很大的格式和侧重点，但是以上说的几点一般都要考虑。

我这里倒是有两份资料，有需要的话，我单独发给你吧。

2009/6/5 何洪文 <hongw...@gmail.com>

-------------------------------------

引子作坊：http://www.q3q.org/

QQ：3779085

Twitter：http://twitter.com/yinzi

MSN：yi...@live.com

Email/Gtalk：yinz...@gmail.com 

[James.zhu]

引子：同求

2009/6/5 健杨 <cros...@gmail.com>

[丢失的叶子]

成本、风险如何评估？能否也发我一份？谢谢

2009/6/5 引子 <yinz...@gmail.com>

一般离不开基本的概述，包括名词说明、产品目标等；主要说明功能需求，还有可能的非功能需求；成本、风险也要兼顾；运营类的还要做好上下线的说明。

当然，不同类型的产品会有着差别很大的格式和侧重点，但是以上说的几点一般都要考虑。

我这里倒是有两份资料，有需要的话，我单独发给你吧。

2009/6/5 何洪文 <hongw...@gmail.com>

[小斌]

同求！
谢谢～～
------------------------------------
Name :Robin Mu
Mobile:15888824299
Mail   :robi...@gmail.com
MSN  :robi...@live.com
Blog   :www.toboshu.com
------------------------------------

2009/6/5 丢失的叶子 <shiy...@gmail.com>

[少尉]

同求~谢谢共享

2009/6/5 小斌 <robi...@gmail.com>

[iamsujie的产品设计]

发一下我们的PRD目录，应该能看出一点东西

1. 总体说明 2
1.1 修订历史 2
1.2 项目概述 2
1.3 功能范围 2
1.4 用户范围 2
1.5 词汇表 2
1.6 非功能需求 2
1.7 其他说明 2
2. UC部分 4
2.1 整体说明 4
2.2 UC正文 4
2.2.1. UC_<用例名称> 4
2.2.2. UC_<用例名称> 6

On 6月5日, 下午4时08分, 少尉 <sha...@gmail.com> wrote:
> 同求~谢谢共享
>
> 2009/6/5 小斌 <robin...@gmail.com>

>
> > 同求！
> > 谢谢～～
> > ------------------------------------
> > Name :Robin Mu
> > Mobile:15888824299

> > Mail :robin...@gmail.com
> > MSN :robin...@live.com
> > Blog :www.toboshu.com
> > ------------------------------------
>
> > 2009/6/5 丢失的叶子 <shiyu...@gmail.com>
>
> > 成本、风险如何评估？能否也发我一份？谢谢
>
> >> 2009/6/5 引子 <yinzi...@gmail.com>

>
> >>> 一般离不开基本的概述，包括名词说明、产品目标等；主要说明功能需求，还有可能的非功能需求；成本、风险也要兼顾；运营类的还要做好上下线的说明。
>
> >>> 当然，不同类型的产品会有着差别很大的格式和侧重点，但是以上说的几点一般都要考虑。
>
> >>> 我这里倒是有两份资料，有需要的话，我单独发给你吧。
>

> >>> 2009/6/5 何洪文 <hongwen...@gmail.com>

>
> >>> 我们经常提，但如何下手？应该包括哪些内容？
> >>>> 请高手具体指点一下。不要太空洞，实际一点，
>
> >>>> 如果有模版或已有例子供参考，那再好不过了。
>
> >>>> 谢谢
>
> >>> -------------------------------------
>
> >>> 引子作坊：http://www.q3q.org/
>
> >>> QQ：3779085
>
> >>> Twitter：http://twitter.com/yinzi
>
> >>> MSN：yi...@live.com
>

> >>> Email/Gtalk：yinzi...@gmail.com

[小蛮]

也给我一份学习下，谢谢。

opq...@gmail.com

[归途如虹]

多谢，一份目录胜千言哪！其它产品研发过程中的文档目录也能分享吗，对互联网行业的产品研发过程比较陌生，正想了解下。

2009/6/5 iamsujie的产品设计 <iams...@gmail.com>

[lesugar]

谢谢，不知能否发份供我学习？起步阶段，很需要高人指点。多谢啊

2009/6/5 引子 <yinz...@gmail.com>

一般离不开基本的概述，包括名词说明、产品目标等；主要说明功能需求，还有可能的非功能需求；成本、风险也要兼顾；运营类的还要做好上下线的说明。

当然，不同类型的产品会有着差别很大的格式和侧重点，但是以上说的几点一般都要考虑。

我这里倒是有两份资料，有需要的话，我单独发给你吧。

2009/6/5 何洪文 <hongw...@gmail.com>

-------------------------------------

引子作坊：http://www.q3q.org/

QQ：3779085

Twitter：http://twitter.com/yinzi

MSN：yi...@live.com

Email/Gtalk：yinz...@gmail.com 

--
尘世里的一抹微笑

[iefen.wen]

文档属于流程中的产出，主要是用于沟通的。其实文档的好坏标准最基础的一点就是让上下流的工作能有所传承，让所有角色都是在做“同一件事情”。

所以需要考虑写PRD的目的是什么，及其受众是什么角色。

虽然用了类似的职位名称和过程定义，但细节中的职能分工和过程中每个环节所要完成的任务，应该会有较大差异。

个人比较建议从自身公司在这个环节中所涉及到的上下工作流角色所需要的内容入手来构建PRD的内容，呵呵

[丢失的叶子]

      同意iefen.wen的观点，文档的目的主要就是为了沟通，具体的内容、目录之类的标准并不是行业统一的，关键要根据公司、团队和自己的实际情况去写，比如大公司分工细化，有严格的财务、风险控制体系，那么，PRD中就要加部门协作和风险评估之类的，但小公司就没有这些。再比如，有的PRD里会有页面原型图，有的则没有。

      

      个人认为写文档只要能做到可读性好，逻辑严谨，没有信息丢失，能保证项目的有效传承就好了。

2009/6/7 iefen.wen <iefe...@gmail.com>

[iamsujie的产品设计]

你难得冒出来啊...
支持，其实文档、流程、团队组织结构、所用的工具软件等等都是支撑，背后的核心还是产品，要满足哪个市场哪些人，想清楚了，支撑的东西自然而言会浮出水
面。
当然，浮出水面的过程中，有个“经验足且熟悉这个产品”的人是必须的，大多数团队碰到的问题就是只有熟悉产品没有经验足的人，于是到处去问经验足而不熟
悉产品的人，其实是得不到满意的答案的。。。。。。
我们都在错误中前进，难以避免的悲剧？

On 6月7日, 上午10时39分, "iefen.wen" <iefen....@gmail.com> wrote:
> 文档属于流程中的产出，主要是用于沟通的。其实文档的好坏标准最基础的一点就

> 是让上下流的工作能有所传承，让所有角色都是在做“同一件事情”。
>
> 所以需要考虑写PRD的目的是什么，及其受众是什么角色。
>
> 虽然用了类似的职位名称和过程定义，但细节中的职能分工和过程中每个环节所要
> 完成的任务，应该会有较大差异。
>
> 个人比较建议从自身公司在这个环节中所涉及到的上下工作流角色所需要的内容入
> 手来构建PRD的内容，呵呵
>
> 在 2009-6-6，下午11:19， lesugar 写道：
>
> > 谢谢，不知能否发份供我学习？起步阶段，很需要高人指点。多谢啊
>

> > 2009/6/5 引子 <yinzi...@gmail.com>
> > 一般离不开基本的概述，包括名词说明、产品目标等；主要说明功能需求，还有

> > 可能的非功能需求；成本、风险也要兼顾；运营类的还要做好上下线的说明。
>
> > 当然，不同类型的产品会有着差别很大的格式和侧重点，但是以上说的几点一般
> > 都要考虑。
>
> > 我这里倒是有两份资料，有需要的话，我单独发给你吧。
>

> > 2009/6/5 何洪文 <hongwen...@gmail.com>

>
> > 我们经常提，但如何下手？应该包括哪些内容？
>
> > 请高手具体指点一下。不要太空洞，实际一点，
>
> > 如果有模版或已有例子供参考，那再好不过了。
>
> > 谢谢
>
> > -------------------------------------
> > 引子作坊：http://www.q3q.org/
>
> > QQ：3779085
>
> > Twitter：http://twitter.com/yinzi
>
> > MSN：yi...@live.com
>

> > Email/Gtalk：yinzi...@gmail.com
>
> > --
> > 尘世里的一抹微笑

[丢失的叶子]

呵呵，偶尔冒泡才能令人印象深刻嘛，这叫“物以稀为贵”，吼吼……

难免避免的悲剧，我们只要尽量减小悲剧的几率了。

接你的提醒又能整理一下关于文档写作的思路了，

熟悉产品是保证文档内容完善，不出现信息丢失，业务逻辑严谨的前提；

经验更多是帮助提高文档的可读性。

借鉴学习别人的经验是好事情，千万别变成照搬经验，那就真的是自虐了（切身感受，貌似也是无法避免的悲剧？）

2009/6/7 iamsujie的产品设计 <iams...@gmail.com>

[王政]

能伐我看看伐，非常感谢

2009/6/5 引子 <yinz...@gmail.com>

一般离不开基本的概述，包括名词说明、产品目标等；主要说明功能需求，还有可能的非功能需求；成本、风险也要兼顾；运营类的还要做好上下线的说明。

当然，不同类型的产品会有着差别很大的格式和侧重点，但是以上说的几点一般都要考虑。

我这里倒是有两份资料，有需要的话，我单独发给你吧。

2009/6/5 何洪文 <hongw...@gmail.com>

-------------------------------------

引子作坊：http://www.q3q.org/

QQ：3779085

Twitter：http://twitter.com/yinzi

MSN：yi...@live.com

Email/Gtalk：yinz...@gmail.com 

[iefen.wen]

莫非是first show up，哈哈的。

因为公司里一直都有专业角色负责PRD的撰写（以前叫PD，现在叫PA），所以我也一直觉得其他的角色来写PRD是不专业的。而前年当我在为一个内部工具写PRD时深感惶恐，刚才翻出前年自己写的那个PRD，又考虑了一下。

PRD从沟通的作用来看，具备一定的阅读可用性是很关键的。这点跟专业与否的关系不大。

但在此之外，PRD的核心沟通内容，我理解应该是需求分析的结果，有时还会包含“业务架构”的设计结果，这是需求分析的创新部分。因为PRD是代表“开发需求”的重要文档。

其他的边边角角，应该是作为项目中各类沟通结果的书面化结果。

[wonlange]

PRD文档怎么写，我也没有写过，不过我认为文档应该是为工作而服务的，不能为了写文档而去写文档，如果你的公司人数很少，沟通成本不高，简单的两句话足已说明问题，就没有必要写什么文档。但是如果公司人数多，管理很规范的话情况就不一样，各个职们的人就像流水线作业一样，为了能把各个环节的工作结果沿到下一环节，标准化的文档是非常重要的。

 

很多时候一些老外PM或是一些大公司出身的PM希望达到一种境界，进行完详尽的分析和文档后，开发人员按部就班就行了。

 

喜欢饮食的人都知道，中餐和西餐有很大的不同，中国人做菜喜欢个性发挥，油盐酱醋通常都需要自己拿捏，菜谱上多“少许、半勺、少量”等描述性词语。有时候PM也希望工程师这样做菜，我们想吃甜味，但放多少克糖是需要厨师自己揣摩。自己揣摩有利有弊，好处是PM省心，坏处是项目不可控。但如果你的研发团队的人员很牛那就另当别论。我在上一家公司就任的时候，人数也不少，一个PM忙的时候可以同时负责六个项目。但研发部的人蛮年的，因为经验比较丰富，经常可以发现很多设计中的不足，给以反馈，稍稍讨论一下就可以解决很多问题，这样PM也就省了很多心从而可以让PM更加关注于产品的开发。如果你们研发团队的工程师没有这样的水平，还是把文档与清楚一点好。 当然，实际过程中如何运用，还是那句老话，具体问题具体对待，在实践中找到一个平衡的点。

 

以上本人一点小小的看法，本人并没有做过什么管理，只是跟据自己的一些工作情况胡乱说一通，这里牛人众多，也多想听下大家的高见！

---

wonlange

2009-06-28

---

发件人： iefen.wen

发送时间： 2009-06-07 10:39:49

收件人： UCDC...@googlegroups.com

抄送：

主题： [UCD]_Re:_PRD产品需求文档到底怎么写？

[Ken]

PM 其实是细化需求的阶段。
我们公司的需求通常有两种形式，一类是页面提纲模块型，一类是简图型。

提纲模块型，先列页面，后列表页面中的模块：

4.    企业服务

1.    登录（默认页）：登录窗口，服务内容介绍，注册引导，最新应聘数据展示（表明网站活跃度）

2.    注册：注册窗口（帐号+基本资料），已注册登录引导；
3.    取回密码：帐号输入框，无法取回提示联系客服；

5.    个人服务

1.    登录（默认页）：服务介绍，登录入口，注册引导
2.    注册：注册窗口，已注册登录引导
3.    取回密码：同上

简图型就不用说了，大家都知道了。

--
大郎：百才招聘(baicai.com).产品部
Email: k...@baicai.com
Gtalk: qicha...@gmail.com
twitter.com/qichangxing