产品邦

 找回密码
 立即注册

QQ登录

只需一步,快速开始

产品邦 首页 产品经理 查看内容

百度内部怎样写好MRD培训资料

2012-12-11 23:25| 发布者: masterchat| 查看: 1606| 评论: 2

摘要: 可能是由于社会化分工越来越细,产品经理也被分为了产品市场经理和产品研发经理,目前大部分的产品经理都在纠结于如何写好PRD文档以及如何做好产品的交互设计和原型,我觉得如果大家想得到更好的发展或者说将来自己 ...



Market Requirement Document 市场需求文档

对产品需求的完整描述
开发和测试的唯一依据
写mrd的理想境界

多、快、好、省

多——完整。各功能点无遗漏,无缺失。

快——高效。从方案确定到文档完成耗时短。

好——准确。无歧义,结构合理,便于开发及测试人员阅读和理解。

省——节约沟通成本。讨论、评审、后期修改通报,流程合理,沟通顺畅。

基本步骤

搭建框架

梳理主线

填充细节

第一步:搭建框架

将产品所有功能进行合理分解和排序,确定mrd各节标题。基本规则:

按页面元素分解

上—>下、左—>右

按用户操作步骤分解;

提交—>展示—>展示后编辑

按在系统中所处位置分解

前台页面—>用户管理后台—>官方管理后台

按功能主次分解

主要功能—>次要/附属功能(特殊权限、广告位、 wise和其它相关说明等)

第二步:梳理主线

按照已确定的mrd章节顺序,用关键示例图+简要文字描述的方式对主要功能点进行说明。

此步骤只关注功能主线,不用有过于详细的描述,也不用涉及各种特殊状态和细节的处理。

使产品所包含的主要功能在mrd中有完整体现。

在主要功能点的整理过程中,对mrd的结构及时进行合理调整

此步骤完成之后,可与开发人员进行初步沟通

第三步:填充细节

对产品功能及其它相关需求进行完整说明

包括所有操作流程、判断逻辑、权限区别、页面效果、特殊状态处理、错误提示、已有功能说明等

此步骤完成之后可发起MRD评审

细节说明通常会占到mrd篇幅的70%以上。一份细节清晰完整的MRD是项目顺利进行的有力保障,也是PM对产品理解和掌控程度的重要体现。

1.任何页面都要说明“从哪来,到哪去”

页面入口

页面title和布局方式

页面初始状态

页面展现和功能细节,按一定顺序描述

各链接点击效果、指向地址、打开方式、刷新方式

浮动层具体策略

是否自动关闭

右上角是否展示关闭按钮,点击效果如何

若在浮动层中可打开新页面,原浮动层是否关闭

关闭后是否刷新页面

……

2.不要只考虑普通用户

若页面对不同权限用户有不同展示和功能,要完整说明并提供准确示意图。

PM/管理员
吧主
吧务团队
会员
登录用户

……

3.形成条件反射的错误提示

输入为空

包括输入空格/空字符串

超过字数上限

前台以汉字数提示,技术上以字符数限制

含特殊字符

可用字符集一般分常用字符(汉字、字母、数字、下划线)和GBK字符两种,由输入内容的应用范围而定

含过滤词

需明确过滤词表

其它输入无效的情况

有特殊格式要求/不能重复/有特定范围限制/

无提交权限

退出登录/被封禁/不符合权限要求

……

4.输入框里陷阱多

是否可以为空

是否有初始内容,是否默认选中

大小写/全半角/繁简体是否转换

任何输入框都需要字数上限

允许的字符集

空格出现在首尾和中间部分,或者连续多个空格的各自处理方式

多行文本框的连续空行、不连续空行、空格、tab键、回车键等处理方式

是否允许快捷键控制

5.事情的发展总可能脱离理想状态

对于满足一定条件才有效的功能,需要说明流程中遭遇各种非正常情况时的处理策略

例1:签名档不超过5个时,显示“添加一个签名档”链接

例2:点击俱乐部转让链接,可成为此俱乐部创建者

6.不要轻易写“与线上保持一致”

升级类项目,可以只说明有改动的部分

新产品移植或调用线上已有功能,需重新进行详细需求描述

搜索框、翻页等通用模块,可以不再单独说明

拿捏不准时可与项目组同事沟通后达成一致

7.无结果页/边界限制/统一出错页/

初始无数据/搜索无结果

无论实际上限或理论上限,mrd中最好给出各种边界值,并说明是否要求灵活可配置。

除已说明的错误提示外,需要给出在其它情况下默认的统一出错页。

8.特殊上线要求需说明

是否分批开通
是否初期只支持特定用户
是否需要先上线但隐藏用户入口
是否对上线时间有精确要求
是否对各功能有上线顺序要求
是否有其它前置项目

如果上线要求比较复杂,而且原mrd内容已经非常多,最好单起文档说明

9.图文一致,符合实际

页面截图和文字说明必须保持一致
前后文中的截图必须保持一致
截图必须与实际情况相符

例:吧主申请流程优化

与其它部门的沟通

1)在线管理部

过滤/审核策略制定
mis等管理后台设计方案
相关协议的更改
上线步骤等具体实施

2)广告部

页面变动涉及对广告位的影响

3)wise

新功能是否在wap应用
需要wap配合修改

如果评审后有修改……

与相关开发和测试人员明确修改细节
邮件通知项目组成员
在mrd中对修改点进行特殊标注,及时上传icafe,并在适当的时候重新发起评审
如有必要,确定mrd冻结时间

小贴士

关于截图

一个页面至少需要一个完整示例图

页面各模块至少需要各一个示例图

其它细节说明,在不影响理解的前提下,截图越局部越好

截图在mrd中加边框以便和文字区隔
一千个文字比不上一个图表

例1:发贴权限控制

发贴权限控制

2:置顶模块设置逻辑


置顶模块设置逻辑

逻辑繁琐复杂但重要的功能,最好在醒目位置单独描述

例1:club中各权限的具体前台体现

例2:pb页改版中涉及老版页面的改动

再啰嗦几句

关于check list
关于通用策略文档
mrd和我们工作的关系
结束

来自:百度内部MRD培训资料

刚表态过的朋友 (0 人)

阅读推荐

小黑屋|产品经理之家 ( 粤ICP备12078725号 )

GMT+8, 2023-5-1 15:13

Powered by Discuz! X3.4

© 2001-2023 Discuz! Team.

返回顶部