如何写出连方舟子都满意的需求文档?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情


=========================
内容索引
1.一个高质量需求的经典要素
1.1 评估需求:确定目标和优先级
1.2 细化需求:SMART原则的运用
2.反例:低质量的需求
3.实践:亲手制造高质量需求
3.1举例:自动告诉妈妈,我快到家了
4.总结:从好需求到好产品
=========================

1.一个高质量需求的经典要素

何谓高质量的需求?一是需求本身有价值,二是需求被清楚明晰的表达没有疏漏。所以,需求从「一个想法」蜕变为「高质量的需求文档」需要经历评估和细化的过程。

1.1评估需求:确定目标和优先级

评估是确定需求价值的过程。每个产品都有着生命周期,把握好迭代的节奏能让产品迅速占领市场、收益最大化。那么,就要确定需求的目标,即达到效果的量化标准。一坨需求的目标拿来比较排序,就是优先级。

如何确定需求的目标和优先级呢?「假如你是QQ的产品经理」这篇文章中有很好的分析,如下:

用户需求重要性的判断标准:用户基数、使用次数和类别重要性。类别重要性分成基本型、期望型和兴奋型需求三类。

对于基本型需求,比如产品的性能、安全、浏览器兼容等方面,一旦出现问题,用户不能访问使用产品,应立即利用一切可利用的资源尽快解决。
对于期望型需求和兴奋型需求,可以通过分析运营数据,使用公式计算:用户需求重要性=功能使用用户百分比(用户使用率)*功能使用次数百分比(功能 或内容使用率)*类别重要性百分比(期望型需求、兴奋型需求)。

目标有了公式来计算量化标准,自然也就便于比较优先级。当然,产品经理对于百分比的预估可能是不准确的,这就要求了每个需求要配合相应的统计项需求,用来观察验证与目标是否一致。随着经验累计,预估会越来越准确,直到成为直觉。

对产品节奏的把握是关键甚至致命的,在同一个时间点,米聊选择做涂鸦信息,微信选择做查看附近的人,产品的用户规模就此拉开距离。

1.2 细化需求:SMART原则的运用

SMART原则自从被「杜拉拉升职记」使用后广为人知,即明确性(Specific)、可衡量(Measurable)、可实现(Attainable)、相关性(Relevant)、时限性(Time-bound)。笔者发现,其实不只是用在目标管理上,SMART原则用于需求管理和细化也非常贴切。

 

  • S:明确性

首先,需求要无歧义,这就需要尽可能少的出现形容词,比如“可能、大部分”等;出现的名词如不确定对方能够理解,需给出名词解释,比如“准确率、召回率”。

其次,需求要完整。可以从用户操作流程出发,考虑到不同的用户角色和用户环境,操作时的每一个分支和异常。

在此仅以手机端为例

从用户角色上:使用的App版本不同、首次启动/非首次启动、用户权限(免费/付费、普通用户/管理员等);

从用户环境上:无网络环境/网络环境异常中断/网络环境良好、不同机型、不同系统、横屏/竖屏使用、手机/平板;

从操作分支上:前置条件、后置条件(我的理解是当前界面上每一个按钮/手势的下一步反应);

从操作异常上:操作的边界情况(比如:在评论框中恶意输入调用数据库的代码)。

 

  • M:可衡量

可衡量意味着需求需要有量化标准,使其可以被测试和证实。

仅以注册页面为例

“当用户输入用户名和密码后,注册成功;当输入出现错误时,弹出错误提示”

这并不是一个可衡量的需求,因为没有定义什么是正确什么是错误,无从验证。

应为:

“当邮箱格式为example@example.com,密码至少为6个字符,密码和确认密码一致这三个条件均满足时,注册成功;否则分别出现’邮箱格式错误’,’密码应至少为6个字符’,’密码和确认密码不一致’的错误提示”

另外,需求目标也需要可衡量,也就是上文提到的“每个需求要配合相应的统计项需求来检验上线效果”。

 

  • A:可实现

可实现除了考虑需求的可行性,还需考虑到成本控制,包括时间、人力、资源等等。

有这样一种说法,“理论上来说所有明确的需求都可以实现,只是需要时间。”

尤其移动端采用敏捷开发的话,搞一个需要做半年的需求就给跪了。

资源上来说,类似个性化推荐、云端产品需要把每个用户的数据在服务器存一份,小公司可能会烧不起服务器。

 

  • R:相关性

需求和产品定位保持一致,策略和已存在的产品保持逻辑一致,形式和风格与已存在的产品保持形式和文案风格的一致。

需求之间的逻辑、定义和文案风格一致。

 

  • T:时限性

T原则一般用于工程师细化需求,而非产品经理。在计划会之后,每个需求会被拆分并有相应排期。
2.反例:低质量的需求

假设老板给Google now产品经理提了这样一个需求:让多个城市的天气显示在同一张card上。

首先,评估需求。根据现有数据计算得出

用户需求重要性=功能使用用户百分比(5%)*功能使用次数百分比(10%)*类别重要性百分比(20%)=0.001

优先级低。不过既然是老板提的需求,还是先细化一下需求吧,运用SMART原则。

每张card有相应的布局和排版,如果要多个城市的天气显示在一张card就需要拉长card或者重新排版。多个城市的阈值需定为多少?当多个城市=2,3,4…时是否要每种单独定制模板和布局?同时如何保证主要信息全部显示?

产品经理突然发现,这样一个反人类的需求不仅开发量增大而且收益微小。

这时,普通产品经理在心里暗骂老板SB,二逼产品经理向同事倾诉老板是个SB,炫酷产品经理反过来想,老板为什么会这么想呢?啊,他一定是想更便捷的查看同类型的card。于是,他推出了一种炫酷的设计——Google now中同类型card为叠放样式。

(本故事纯属杜撰,如有雷同,呵呵)
3.实践:亲手制造高质量需求

这里用一个小例子来一步步制造高质量需求。笔者的母亲希望笔者在晚上十点前仍未回家时发短信报平安,但笔者经常忘记,受到ifttt启发萌生这样一个想法,当我十点前仍没到家时,自动发短信给妈妈报平安。

3.1 需求评估

用户需求重要性=功能使用用户数量(2.7亿*18%*5%)*功能使用次数百分比(30%)*类别重要性百分比(50%)=364500

有此需求的用户特征大致是:未婚、与父母同住、上学或工作,故年龄分布大致在21-26岁。

中国目前有2.7亿智能机用户[3],智能机用户中20-29岁人群占比36%[4],如果均分则21-26占比18%,预测其中有此需求的用户占比5%;功能使用次数为一周两次,重要性为50%,得出用户需求重要性的数量为364500.当然这个估计可能偏大了,重点还是想说细分需求的步骤嗯。

3.2 明确概念

当某时未到某地时,自动发短信给某人。

未到某地的定义:距离某地大于等于1000米的直线距离。

3.3 主线流程

先完成主线的执行逻辑,注意每一个步骤的可衡量

3.4 继续完善分支和异常情况

考虑每一个步骤的其他操作和错误情况

至此,便完成了需求的主要逻辑。

可以通过观察反推成熟产品(比如iOS上的备忘录)的需求逻辑来训练简化流程且不遗漏的能力,也可以多阅读同行的优秀文档,比如白鸦老师的「微信自定义机器人的最初需求样本」。
4.总结:从好需求到好产品

好需求是好产品的必要非充分条件,一份清晰、无疏漏、不轻易变更的需求文档能让团队其他成员专注于开发。当然,仅仅写的清楚也是不够的,还要说的明白,在沟通中达成一致。

引用:
[1]高质量的科学谣言是如何出炉的,Ruki
[2]假如你是QQ的产品经理,Krrishyan
[3]2012互联网趋势报告,Mary Meeker,2012.12
[4]中国移动互联网发展状况调查报告,中国互联网络信息中心,2012.03
[5]微信自定义机器人的最初需求样本,白鸦

作者:林茜茜

您的赞赏,是对我创作的最大鼓励。

评论( 1

登录后参与评论
  1. 很好,谢谢!

    回复
加载中