巧妇难为无米之炊。
对于产品经理来说，需求就是用来做饭的米。
但产品经理的工作可比熬一锅粥要复杂多了，不光要以需求为基础来设计产品，对需求的管理能力也极其重要。
很多时候，糟糕的需求管理，会导致产品工作乱成一团，甚至导致项目的失败。
作为产品狗，我会经常体验各种产品，也常常遇到需求管理失败的案例。
曾经有过这么一次糟糕的体验：
那是一款定位一二线城市小众社交的App。
产品的主要逻辑是，用户通过简单心理测试题，确定一个性格分型，基于各自的性格分型和指数，进行陌生人匹配。
用户的心理测试分为三个阶段，初级、中级及高级，每深入一级号称更加准确。
然而，问题就出现在这款产品宣为亮点的心理测试上，我在完成了高级测试之后，它会自动跳转到结果页面。我的测试结果依旧停留在中级，高级测试题的状态则是未完成。
我尝试了重新测试、注销重新登陆、换手机号注册新号、甚至卸载重装，问题依旧。
换一台iOS设备，问题依旧。这不是一个偶发性的Bug。
于是，我在App的用户反馈中，详细描述了该问题。
一周后，App更新，Bug依旧。
接着，我在Appstore上面通过评价的方式，再次详细描述了该问题。
半个月后，App更新，Bug依旧。
最后，我按照官方网站的邮箱，讲问题描述再次反馈。
一周后，App更新，Bug迎风招展。
在坚持了一个多月之后，我默默的放弃了它。
这种糟糕的Bug管理，绝对不是偶然。我今天看了看在Appstore上的差评，简直就是车祸现场。
（如下信息，是我按照一星进行的筛选，并非该App的评价至于差评）
鉴于我如此执着的向他们反馈问题却毫无结果，我只能推测：
要么他们看到了，却没有有效处理；
要么就是他们连看都没有看到。
不管是哪一种，都说明了他们需求管理能力的缺失。
产品经理工作的核心就是采集、加工、和传递信息，其中最重要的就是需求。就算Idea再棒，就算开发效率再高，就算运营团队推广效果再好，产品核心工作的失误，都会不断被放大。
在卸载之前，我在动态中发布“眼看他起朱楼，眼看他宴宾客，眼看他楼塌了”。
你可能会有疑问，前面说的不是Bug么？
不论是反馈者，还是反馈渠道，抑或是反馈方式，Bug和需求都是共享的。
用户访谈时，他会反馈需求，也会反馈Bug。
老板找你沟通时，会提想法，也会告诉你他看到的问题。
所以我更倾向于，将Bug作为（广义上的）需求的一种类型。狭义的需求当作一种正向的需求，而Bug则作为一种反向的（优先级更高）需求。
同时，把Bug作为需求的一类，还有一个优点。
像对待需求一样，对Bug进行分析，而不是直接原封不动的抛给开发。
经过你的分析，有可能发现不是Bug，而是需要培训用户，或是转化为新的需求。而确定是Bug的，经过你的分析之后再交给开发，本身已经完成了搜集、复现和定位等环节，修复速度也必然会快很多。
所以，下文所说的需求和需求管理，都是广义上（除非特指）的。即将需求和Bug作为一类信息来说明。
网友评论