聊过需求，看过需求，也写过需求，最近在想，什么样的需求才算是好需求？
产品经理的一大作用就是“承上启下”，无论是写PRD，画原型，还是去考察行业，搜集、理解竞品，都是在重复“收集挖掘->学习理解->转化输出”，将自己得到的内容梳理后，以清晰、简洁又直观的形式，辅助他人做进一步的工作。其中对需求的描述，就是最常见的“承上启下”形式。
笔者认为，好的需求应该至少有如下特征：
阐述需求背景
说明需求来源，整理出需求方的原始描述。并依据该描述，能与需求方进一步沟通，来理解该需求的目的，对需求进行粗略分类：
- 功能补充：是不是产品现在的版本完全没有应对需求的方式方法？
- 优化建议：是不是产品包含了该功能，但是用起来不方便？或者只能通过walk around去达到目的？
- 问题修复：是不是产品提供的功能有bug？
- 常规变更：是不是上线一段时间后，用户提出的需求变更？
- 其他：是不是用户对项目、产品、甚至公司的不满，导致的吐槽或情绪发泄？
通过沟通，进一步判断出需求的级别：
- 产品级：满足此需求后，能对产品本身的通用性、易用性等带来提升，让产品所在的各个客户项目受益，或者能为销售提供有力武器。
- 项目级：需求不具备行业通用性，也对产品本身没有本质提升、优化，但对于改善项目中的产品体验有所帮助。
- 个人级：个别用户的单方面意见，不具备项目内通用性，但对缓解用户情绪有所帮助。
判断优先级
对需求有了初步理解之后，要了解客户对满足需求的时间期望。同时，应该对需求的“规模”有一定的判断（可依据前文需求级别、分类），粗略评估工作量，避免低效、被动沟通，并尽可能为处理需求赢得时间。
判断优先级，要综合考虑客户的时间期望，和需求本身的影响范围。而定义优先级可以通过四象限法，说明该需求的重要性和紧急程度。比如，影响SaaS产品全部租户的重大bug（需求类型：问题修复），即使客户没有时间期望，也应该是“重要&紧急”的最高优先级进行处理。
说明业务场景
对于一个前台模块/功能，通常都有其完整的业务场景。从对该需求涉及到的用户入手，描述该用户对于此需求的业务期望，通过满足该需求，具体解决了此用户什么样的问题？提升了工作效率？还是完善了其在产品中的体验完整性？
有了期望，针对该期望去设计并描述业务场景涉及到的流程、边界、系统影响，并以此去确认自己的理解和设计，是否真正满足了客户需要，启发客户进一步明确需求。
在说明业务场景的过程中，进一步将该需求进行模块化、功能化的拆解，把一个场景梳理为一个个步骤。可通过用例图、流程图，将业务场景进行描述。
- 推荐工具：Xmind
考虑实现难度
这个见仁见智，毕竟对于产品经理是不是应该懂技术这件事都没有共识，尽管本人坚决认为产品经理必须要懂点技术。
一个需求，如果其业务场景凭空而来，产品经理无法判断目前系统是否在技术、数据上可以支持的话，设计地再精妙，也可能落不了地，导致需求在产品经理和研发之间变来变去，最终做出来的也未必能满足用户的原始需求了。当然，也不要被现状所累，不敢去承接需求，不敢去拥抱变化，技术现状如果不够好，那么需求本身就是个去挑战现状的机遇，总不能做一只鸵鸟，把头埋在土里视而不见。
如若了解当前系统的实现方式，知道目前数据结构以及结构变动的代价，在描述需求、开展设计的时候就考虑到实现的难度，那么至少可以去贴近现有的技术方案（或发现现在的不足）、更清晰地描述数据流程。
梳理数据流程
在业务流程图之上的，是一条业务数据在系统内流转的完整故事。业务流程可以粗略、直观，便于与需求方进行沟通、确认，而数据流程则应该细致、精准，把这一条数据从“出生”到“消亡”，起承转合，所经历地增删改查，乃至对其他业务对象的影响，尽可能完整地梳理、呈现出来。
该过程涉及到对底层系统、数据结构的了解。要清楚理解一个操作对数据的影响，以及数据对后续系统自动化处理的影响，有逻辑，有依据地表达出来。
- 推荐工具：ProcessOn
文档结构清晰
有的需求文档看着就头大，有的文档看着就舒适——这很可能是因为文档结构、格式所带来的直观感受，完全是写文档的态度、对文档工具利用程度的问题，甚至到不了“文字功底”这个级别。
对于需求文档：
- 有清楚的目录。让阅读者清楚了解文档结构，也能让撰写者有一以贯之的思路。
- 格式、字体统一。并不是全篇都是“正文”，而是依据文档目录结构，该正文的时候就是正文，该标题的时候就用标题，对于粘贴来的文本也要将其统一为当前文档应有的格式。
- 善用条目。无论是1、2、3、4这样的编号，还是一个个项目符号（bullets），把观点逐一列明，提高文档的可读性。
- 少用颜色。除非强调关键点，否则尽量避免多种字色混杂，加粗、斜体滥用。
- “一图胜千言”的前提是——图要画得好。尤其是流程图，看过画了还不如不画的流程图，依据这图做解释讲都讲不清楚。流程图是阐述逻辑的工具，千万避免形式大于内容，为了画图而画图，要先有逻辑，再出图，把流程图的格式布局调整清晰，对于完善逻辑和思路都有帮助。
避免成为传话筒
最后想说的是处理需求的态度。作为承上启下的产品经理，如果不能“对上深挖需求，向下清晰表达”，而仅仅是复述转达，没有任何消化理解，这就不是需求好或不好的问题了，而是产品经理对待本职工作的态度问题。
需求说明，是对客户的责任，对产品的责任，对个人工作的责任，对团队成员的责任。也许以上每一点都可以做的不够好，但是至少不要只做一个需求的传话筒。
自勉，共勉。
网友评论