好产品经理和差产品经理的文档区别在哪?

一个产品的好与坏是产品生命周期内各环节细节决定。任何一个环节没有做到位,就会打折这个产品质量。作为产品经理核心输出物“产品文档”就尤为的重要。一份好的文档和一份差的文档,就已经决定了这个产品的质量问题。其实文档就是搭积木的说明书一样,说明书不好用描述的模棱两可,意味着积木就搭不好。

所以说产品经理整理需求和做需求是两个概念。整理需求可以说市场需求分析MRD(MRD侧重的是对产品所在市场、客户、用户以及市场运作等需求进行定义),做需求可看为需求的落地PRD(PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”)。把业务需求变为产品需求,这个转变的过程就是通过PRD需求文档来嫁接的。要是说PRD的好坏,直接决定了项目的质量水平;那么BRD的作用,就是决定了你的项目的商业价值。所以业务需求文档可以是粗宽,落地需求文档就讲究细节(任何你要考虑的细节)。

好的产品经理和差的产品经理的PRD文档区别:

好的:

1、业务规则和逻辑清晰

2、业务流程明确

3、需求描述精准

4、图形结合疗效好

5、功能细节描述把控到位

6、复杂逻辑举例说明更清楚

好的文档如下:

1.1. 注册功能概述

1.1.1. 业务需求规则

本功能描述功能的规则。

1.1.2. 功能流程图

本功能的流程图

1.1.3. 页面及其交互说明

页面的交互样式

用户场景:

用户未进行注册,需要用户完成注册才能进入系统。

用户前置条件/输入

用户启用软件,且通过注册页面进行注册访问。

1.1.4. 数据项说明

序号

数据项名称

属性

描述

1

关闭

按钮

点击关闭按钮,隐藏注册页面。

2

手机号

输入框

必填项

默认值:请输入11位手机号

只支持数字输入,限制11个数字

选中输入框,默认值消失

3

短信验证码

输入框

必填项

默认值:请输入短信验证码

选中输入框,默认值消失

验证码为4位数字验证码

4

获取验证码

按钮

1点击获取验证码按钮发送验证码至手机,同时按钮变为60s倒计时“60s后可重新获取验证码”

2点击获取判断手机号是否存在,存在提示“该手机号已存在,请更换后重试”

3判断手机号是否正确,不正确提示“请输入正确的手机号“

4点击发送提示,短信已经发送请查收

5同一个手机号在一个小时内最多获取5次验证码,超过5次提示“获取验证码过于频繁,请稍后再试”

6无网络情况下,点击获取验证提示“网络异常,获取验证码失败”

5

设置密码

按钮

必填项

默认值:请设置6-12位字母+数字组合的密码

选中输入框,默认值消失

6

城市

选择项

必选项

默认值“请选择”

点击进入城市选择页面

7

邀请人

输入框

选填项

邀请人的信息为手机号

用户填写做正确性验证

用户未填写不做验证

8

同意

选择框

默认选中状态

未选择点击注册按钮时提示“请同意注册服务协议”

点击协议文本按钮跳转到协议的h5页面

9

注册

按钮

1判断手机号的有效性、正确性(不正确提示“请输入正确的手机号“)

2验证码有效性,时效性,(错误提示“验证码错误,请输入正确验证码”)

3密码的规则是否满足“6-12位字母与数字组合的密码“不满足提示“请输入6-12位字母与数字组合密码”

4判断邀请人填写格式是否正确。判断选填项的用户邀请人是否存在,如果未填写邀请人将不判断

数据注意项

·



好文档会细致到:

1、字段数据类型限制。

2、字段输入长度限制。

3、字段输入格式限制。

4、单行文本输入框还是多行文本输入框。

5、输入项是否有验重设置。

5、字段输入内容是否可以通过其他表单字段进行计算。

6、表单排序、时间格式、筛选的条件和范围。

7、选择器的时间范围和格式等。

只有产品经理规范死这些内容,在开发的时候才能保证产品的质量。如果细致定义不清楚,程序员或者其他人员可自行定义,那这样的产品最后一定偏离了轨道很远。

差的文档如下:

1.1 账户提现

1.1.1 业务需求

用户可以通过该功能进行账户余额提现至用户的提现银行卡中。

1.1.2 角色及权限

用户登录系统且经过实名认证后才能正常使用提现功能。

1.1.3 处理流程

用户操作

系统显示

1、用户启动桌面应用程序。

1、系统显示系统加载页进入精品推荐页

2、用户在我的财富中选择提现按钮。

2、系统显示提现界面。

2-1用户提现界面(正常界面)

2-2用户提现界面(有绑定银行卡,没有设置提现卡)

2-3用户绑定银行卡界面(用户没有绑定银行卡)

2-4系统显示实名认证界面(用户没有进行实名认证)

3-1、用户输入提现金额、交易密码点击确认按钮。

3-2、用户点击设置提现卡链接。

3-3、用户输入银行卡、姓名、支付渠道等元素,点击绑定按钮

3-1、系统显示提现结果界面。

[3-1-1]、提现错误信息。

[3-1-2]、提现成功信息。

3-2、系统显示设置提现卡界面(后续用户操作3-1操作)。

3-3、系统显示绑定银行卡界面。

3-3-1 绑定错误信息

3-3-1绑定成功信息

(我知道你这数字杆杆啥意思啊?)

1.1.4界面原型

参见界面原型(我没原型的怎么办?让我吃土吗?)。

1.1.5输入输出界面元素

显示界面描述

账户提现界面






名称

输入/输出

显示类型

类型/长度

是否必输

默认值

备注

可提现金额

O

文本


Y



提现金额

I

输入框


Y



设置提现卡

I

链接


Y


没有设置提现卡时显示

提现卡

O

文本


Y



交易密码

I

输入框


Y



提交

I

按钮





显示界面描述

设置提现卡界面






名称

输入/输出

显示类型

类型/长度

是否必输

默认值

备注

持卡人

O

文本


Y



银行卡号

O

文本


Y



开户行

O

文本


Y



开户行地区

I

下拉选择


Y



开户行支行

I

输入框


Y



提交

I

按钮





程序员的心理想(去你的,你都没定义,我自己来凭空想象吧)

差的文档给人感觉:

1、业务规则和逻辑混乱不清

2、业务流程思考不到位

3、需求描述歧义颇多

4、长篇大论的文字

5、功能细节描述模糊不清

6、逻辑复杂到自己都没捋清楚

一份好的文档让产品落地更有声,让产品还原度更高。即使你忙着不在公司,程序猿也能正确的还原需求。所以在苦也不能苦了程序员,你的输出物不精准,造成的就是程序员的各种返工和痛苦。


分享到:


相關文章: