如何写出连方舟子都满意的需求文档？
2019-04-09 来源：i黑马
内容索引
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.总结：从好需求到好产品
好需求是好产品的必要非充分条件，一份清晰、无疏漏、不轻易变更的需求文档能让团队其他成员专注于开发。当然，仅仅写的清楚也是不够的，还要说的明白，在沟通中达成一致。
版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。
