巧妇难为无米之炊。
对于产品经理来说，需求就是用来煮饭的米。
但产品经理的工作可比熬一锅粥要复杂多了，不光要基于需求设计产品，需求的管理能力也极其重要。
很多时候，糟糕的需求管理，会使产品工作乱成一团，甚至导致项目的失败。
作为产品狗，需要经常体验各种产品，也常遇到需求管理失败的案例。
最近就有这么一次糟糕的体验：
一款定位小众社交的App，名字就不说了。
产品逻辑是，通过心理测试，确定性格分型，匹配陌生人。
心理测试分为：初级、中级及高级等三个阶段，每深入一级就更准确。
然而，问题就出在心理测试上。
我在完成了高级测试后，测试结果依旧是中级的结果，高级测试的状态则是未完成。
我尝试了重新答题、重新登陆、注册新号、甚至卸载重装，老样子。
换台iphone手机，问题依旧（android正常）。
于是，我在App内的用户反馈功能中，详细描述了该问题。
一周后，App更新，Bug依旧。
接着，我在Appstore上面通过评价的方式，再次详细描述了该问题。
半个月后，App更新，Bug依旧。
最后，我按照官方网站的邮箱，讲问题描述再次反馈。
一周后，App更新，Bug迎风招展。
在坚持了一个多月之后，我默默的放弃了它。
如此糟糕的Bug管理，绝不是偶然。今天顺眼看了下在Appstore，简直就是车祸现场。
（如下信息，是我按照一星进行的筛选，实际并非全部都是差评）
我如此执着地反馈问题，却毫无结果，我只能推测：
要么他们看到了，却没有有效处理；
要么就是他们连看都没有看到。
不管是哪种，都说明需求管理能力缺失。
需求管理的重要性
产品经理工作的核心就是采集、加工和传递信息，而最重要的信息就是需求。就算idea再棒，就算开发效率再高，就算运营团队推广效果再好，需求管理不好，负面都会被不断放大。
卸载前，我发了最后感悟：
「眼看他起朱楼，眼看他宴宾客，眼看他楼塌了」
你可能会有疑问，前面说的不是Bug么？
不论是反馈者，反馈渠道，或是反馈方式，Bug和需求都是共享的。
用户访谈时，他会反馈需求，也会反馈Bug。
老板找你沟通时，会提想法，也会告诉你他看到的问题。
所以我更倾向于，将Bug作为（广义上的）需求的一种。狭义需求当作一种正向需求，而Bug则作为一种反向（优先级更高）需求。
同时，把Bug作为需求，还有一个优点。
像对待需求一样，对Bug进行分析，而不是原封不动的直接抛给开发。
经过分析，你有可能发现它不是Bug，而是需要培训用户，或是转化为新需求。而确定是Bug的，经过你的分析后再交给开发，本身已经完成搜集、复现和定位等环节，修复速度也必然会快很多。
下文所说的需求和需求管理，都是广义上（除非特指）的。即将狭义需求和Bug都作为广义需求来统一说明。
需求的种类
讲需求管理之前，先对需求的种类做个全面认识。全面认识需求的种类（区分维度），有助于在管理需求时，做到兼顾所有情况。
需求的种类（区分维度）有：
- 来源（提出方）：用户（客户）、协作方（开发、运营、销售、项目等）、管理层（投资人、老板、上司）等；
- 渠道：访谈、问卷、内部会议、内部系统、IM、产品内反馈、服务邮箱等；
- 形式：录音、录像、文档、邮件、会议记录、留言、聊天记录等；
- 类型：就是前面说的，正向需求和反向需求（Bug）两种；
- 场景：正式使用、体验产品、开发测试、产品演示等；
- 紧急重要度：有很多方法，建议使用四象限法（重要紧急、重要不紧急、紧急不重要及不紧急不重要），或直接用1、2、3、4级代替。
需求管理的四个阶段
需求管理全过程可以分为四个阶段：
- 需求的采集，维护高效稳定的采集渠道和合理的记录规范；
- 需求的处理，对采集到的需求进行筛选和加工明确；
- 需求的实现，对加工明确后的需求进行规划和开发；
- 需求的反馈，反馈需求信息的处理给需求来源。
通过这四个步骤，做到对需求信息有效管理。
下一篇，我会详细讲解，如何搞定这四个阶段的工作。
