怎样输出一份高品质需求？
0
作为产品经理，能够输出一份“高质量”的需求文档是十分重要的，而在这种场景中对于“高质量”的定义就是“不论交给哪个Scrum Team进行开发，都能开发出一样质量的软件产品或服务”。
为此，我们有以下原则，模板，输出物来定义高质量的产品需求。
1
不论出于何种目的输出需求，都可以遵循如下原则，即
Unambiguous：
需求足够明确，每个人对于需求的理解没有歧义（如果真的有歧义，则需要对需求进行重新表述和记录）；
Precise：
内容足够精确，能够逐步细化，并采用精确的描述文字或图片；
Consistent：
上下文一致（或与其他需求中的用语一致），避免需求重复或矛盾，可以在需求中使用术语表来进行约束，从而形成共同、惯用语言；
Correct：
逻辑正确，能够随着背景信息进行细化，从而确保需求能真的解决问题；
Complete：
内容完整，在内容中包括足够的必需信息，能保证需求被完整的描述与理解；
Measurable：
结果可测量，每项需求都是可以独立测量从而确定是否完成的；
Feasible：
在可行性，运行，技术，成本效益，时间等方面都具备可行性，是当前所遇到问题的最优解；
Traceable：
具有跟踪性，即不仅往前可以追索到需求的起源和前置需求，往后也可以跟踪到解决方案的实现与后续还需要优化的内容；
Testable：
需求具备可测性，能够便于测试同学输出测试用例；
2
产品经理确定待办需求，输出需求文档，互相进行内容 review 的时间十分有限，因此在有限的时间中进行合理的时间规划则十分必要。我们习惯的流程如下：
审阅需求池（Product backlog），整理下个迭代需要实现的需求 → 产品需求预审会，明确并确定产品迭代计划，制定需求优先级 → 撰写需求文档，互相审阅产品经理文档，并及时进行更新 → 与研发同事进行需求内审，确定需求实现的成本与难易度 → 完成 UI交互与设计相关工作 → 拆解并加入迭代计划表，同时建立对应的 jira 用户故事卡片 → 在迭代中跟进需求实现进度，关注风险 → 完成测试验收并跟进上线
3
在我们的日常工作中，习惯性将需求按照实现过程所需要耗费的成本，以及输出物进行分类，大抵有如下 6 种类别，他们分别是：
| 需求类型 | 什么时候使用 |
|---|---|
| 大需求 | - 整个功能均为新增且相对独立，与其他功能模块解耦 - 整个prd对应的工作量超出3人天，且涉及多端协作（前端/后端/移动端） |
| 优化需求 | - 功能已经存在，是在已有功能上进行优化 - 功能不存在，但本次新增功能对应工作量极小（小于2人天） |
| 技术需求 | - 前端页面 / 无原型 - 由研发牵头完成，并以技术方案为交付方式 - 需特别关注交付内容与形式 |
| 运营需求 | - 由运营提出的需求点，通常为官网需求或运营活动 - 以前端工作量为主 - 需特别关注交付时间点与适配 |
| 文档需求 | - 根据迭代，需研发或多人配合完成的文档 - 更新通常需发布至finclip在线文档中心 |
| 对外文档需求 | - 需要针对某个客户，合作商输出对外使用的模板 |
以下内容则为对应的需求模板，供你参考。
4
在产品需求中，需要关注表达清楚需求背景，可以从如下角度思考如何补充背景信息：
用简单的内容描述为什么要做需求，可以从以下角度进行整理
- 这个项目开始的原因是什么？客户直接需求？自身规划？技术储备？还是什么原因？
- 我们的方案是什么？要研发什么？
- 做这个项目对公司的意义和影响是什么？不做这个项目对公司的影响是什么？
- 整体周期安排是什么（能接受的红线是什么）？
5
同样的，需求文档中需要包括环境说明，需求内容，与需求相关的通知，权限，异常情况等。
请尽可能保证需求文档具有高可读性，方便不同角色的用户快速理解，可以从这几方面考虑：
考虑真实的场景：
把自己当做用户，多种路径、多种场景下模拟使用情况；
不过于关注功能：
即考虑需求与需求之间的联系，不仅可以保证相关功能之间的体验统一，又能利于开发层面统一考虑实现方案；
具备抽象的思维：
需要对需求进行模块化设计，又能够具备一定的高度，最好能 1 个需求解决 10 件事，而不是 10 个需求解决 10 件事；
考虑边界与异常：
考虑边界场景，兼顾各端差异；
拥有设计专业性：
尽量在体验和实现上统一，不要只埋头于做线框图，而将用户的体验交互相关的事情丢给设计师；
- 拥有开放的心态 积极并参与响应评审的反馈，将需求设计或实现中有缺陷的部分记录下来，在后续迭代中逐步完善；
本节标签
【审阅】：熊思宇
【作者】：王字
【适用范围】：全公司
【公开范围】：公司内和公司外