没有合适的资源?快使用搜索试试~ 我知道了~
互联网产品经理必备文档技巧.pdf
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 56 浏览量
2021-10-11
15:30:36
上传
评论
收藏 598KB PDF 举报
温馨提示
试读
11页
互联网产品经理必备文档技巧.pdf
资源推荐
资源详情
资源评论
[ 网编教材 ] 互联网产品经理必备文档介绍 ( 转)
互联网 , 文档, 经理
BRD
Business Requirements Document ,商业需求文档。这是产品声明周期中最早的问的文档,再早就
应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,通常是和老大们过的 ppt ,所以
也就比较短小精炼,没有产品细节。
商业需求文档重点放在定义项目的商业需求。 BRD要能说出客户碰到的一个或多个商业问题,并且
通过公司的产品能够解决这些问题。接着建议一个方案 —— 通常是新产品或者现有产品的改进来解决
这些问题。 BRD也可能包括一个高级的商业案例,例如收益预测,市场竞争分析和销售 / 营销策略。 BRD
通常是由拥有产品经理,产品营销经理或者行业分析师头衔的人撰写的。在小公司,可能由高级主管或
者甚至创始人撰写。 BRD通常是一份连续的 1-3 页 Word文档,或者不超过 10 页的 Powerpoint 文档。
MRD
Market Requirements Document,市场需求文档。 获得老大的认同后,产品进入实施, 需要先出 MRD,
具体来说要有更细致的市场与竞争对手分析, 通过哪些功能来实现商业目的, 功能 / 非功能需求分哪几块,
功能的优先级等等。 实际工作中, 这个阶段 PD可能的产出物有 Mind Manager的思维图, Excel 的 Feature
List 等。
市场需求文档( MRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与 BRD指
出商业问题和解决这些问题的解决方案不同, MRD更深入提议解决方案的细节。它包括一些或者所有这
些细节:
a. 解决商业问题所需要的特色
b. 市场竞争分析
c. 功能和非功能需求
d. 特色 / 需求的优先级
e. 用例
MRD通常是由拥有产品经理, 产品营销经理或者行业分析师头衔的人撰写的。 MRD通常是一份连续的
5-25 页 Word文档,或者正如之后描述那样在一些机构中甚至更长。
PRD
Product Requirements Document ,产品需求文档。进步一细化,这部分是 PD写得最多的内容,也
就是传统意义上的需求分析,我们这里主要指 UC(use case )文档。主要内容有,功能使用的具体描述
(每个 UC一般有用例简述、行为者、前置条件、后置条件、 UI 描述、流程 / 子流程 / 分支流程,等几大
块), Visio 做的功能点业务流程,界面的说明, demo等。 Demo方面,可能用 dreamweaver、ps 甚至画
图板简单画一下,有时候也会有 UI/UE 支持,出高保真的 demo,开发将来可以直接用的那种。
产品需求文档( PRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与 MRD侧
重于从市场需要角度看需求的不同, PRD侧重于从产品本身角度看待需求。通常在特点和功能需求上更
深入细节,并也可能包括屏幕截图和用户界面流程。在那些 MRD不包括具体需求和用例的机构中, PRD
就包含这些具体内容。 PRD通常是由拥有产品经理,行业分析师或者产品分析师头衔的人撰写的。 PRD通
常是一份连续的 20-50 页 Word文档,或者针对复杂产品甚至更长。
提醒:一些机构将这里描述的 MRD和 PRD合并成一个文档,并称最后的文档为 MRD。在这种情况下,
MRD包括本段描述的内容,也包括上一段描述 PRD的内容,并且可能超过 50 页。
FSD
Functional Specifications Document ,功能详细说明。有一点像“概要设计”,这步就开始往开
发衔接了,产品 UI 、业务逻辑的细节都要确定,细化文档并保持更新。相应的,有很多内容,比如表结
构设计,要由项目经理来编写了。
功能规格文档( FSD)把焦点集中在实现,定义产品功能需求的全部细节。 FSD可能通过一张张的截
屏和一条条功能点来定义产品规格。这是一份可以直接让工程师创建产品的文档。与 MRD和 PRD侧重于
以市场需要和产品角度看需求不同, FSD把重点放在了以表格形式定义产品细节,再让工程师实现这些
细节。 FSD也可能包括完整的屏幕截图和 UI 设计细节。 FSD通常是由拥有产品分析师,工程领导或者项
目经理头衔的人撰写的 – 作者通常属于工程部门。通常一个连续几十页的 Word或类似文档。
写好 MRD的 10 种技巧
2008-04-22 13:14
MRD- “市场需求文档”,是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这
些文档用于计划一个新产品或修正一个已有的产品, 是被工程师团队开发产品时使用。 在硅谷
的一些软件公司, MRD仅仅覆盖 high-level 的功能。在这种情况下,产品经理通过创建了另一个文档 -
通常指的是 PRD(产品需求文档)来定义更加详细的产品需求。
在本文中,我用术语“ MRD”泛指所有那些由产品管理和 / 或产品市场团队创建的,为工程师团
队传达产品需求为目的的文档。
写好 MRD的 10 种技巧
1、从用户角度的编写
从用户角度编写需求内容。使用“用例 (Use Case)”和“用户角色( User Personas )”来达到
这个。考虑用以下两种方法来详细说明你们公司正在开发的 SFA(sales force automation )软件的
“Login ”的功能性。
方法 A:
用户通过一个要求用户提供证书的登陆界面, 然后软件允许用户带着特定的权限进入系统。 软件
鉴别这些证书,在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。
方法 B:
Mike 是一个销售经理, Cathy 是一个销售代表。当他们打开软件,他们看到登陆界面。他们通
过用户名和密码进入系统。如果用户名和密码是正确的,他们能登进系统。一旦登陆进系统, Mike 能访
问软件所有的功能部件。 Cathy 只能访问那些对销售代表有有效的功能部件。
哪个方法更加容易阅读和理解 ?就我的看法 , 毫无疑问, " 方法 B"。还有,它同时减少了令人烦
恼的阅读!
2、使用 Screen Shots
使用 Screen Shots 或者 mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文
字”。当提到写 MRD的时候,一个 screen shot 好比一千个文字!
举个例子 , 看看下面这个 screen shot ,你需要多少字来描述?我想可能不只一千个字。
3、用简单的语言编写
在我超过 11 年的行业中,我通常注意到的(更多是令我懊恼)一件事是用很做作的语言来写的
MRD。我想这个主要是因为 MRD听起来是正式的和专业的原因吧。
相反,想象你写的 MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什
么,以便于他能开发产品实现这些需要。 这个将有助于你避开陷入那些令读者人厌烦 (有时他们会把 MRD
撕碎然后再碎片喂给碎纸机)的用做作的语言的陷阱。
还有:
a) 保持简短的语句,把长的语句分解成多个小的语句。
b) 避免大篇幅的连续文本,把他们分解成多个小的章节。
c) 把大块文本内容分解成, screen shots ,表格、重点列表等等。
4、小心的使用模板
我发现 MRD模板非常有用。他们的几个好处包括:
a) 模板提供了一个标准的格式,使那些不得不阅读大量 MRD的读者更加容易阅读。
b) 模板让新的产品经理快速的写 MRD变得容易,因为公司与公司之间的 MRD内容是不同的。
c) 模板确保你不会忘记所有需要在 MRD中覆盖描述的部分;
然而,一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近 60
页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用:
a) 产品经理害怕但又不得不写 MRD - 几乎和不得不和 Dick Cheney 去南德克萨斯打猎一样(译
者按:美国副总统 Dick Cheney 在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴)。
b) 工程师团队害怕但又不得不阅读 MRD。
c) 写 MRD和读 MRD都需要花大量的时间。
我推荐你使用 MRD模板,但确保他们不要过分的长。还有如果需要,确信产品经理可以灵活的
跳过模板某些部分和创建新的内容。
5、区分需求的优先级
在这些年里, 我从来没有碰到一个工程师团队实现了 MRD里包括的所有特性的没有删减的项目 -
通常由于那些我们控制之外因素!
这就是说作为 MRD作者的产品经理,当出现需要决定取舍的时候,应该提供一个办帮助让他们
剩余10页未读,继续阅读
资源评论
苦茶子12138
- 粉丝: 1w+
- 资源: 6万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功