关于产品与需求

内容索引
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.总结：从好需求到好产品
好需求是好产品的必要非充分条件，一份清晰、无疏漏、不轻易变更的需求文档能让团队其他成员专注于开发。当然，仅仅写的清楚也是不够的，还要说的明白，在沟通中达成一致。