Question

需求管理的过程

Answer 1

    关于需求，可能我们听到比较多的是需求收集和需求分析，它们是需求管理中很重要的部分，但是并非需求管理的全部，需求管理其实是有一个过程的。

    可能有时候会遇到这么个情况：一个产品/项目做的时间不短了，但是却总是不能顺利上线，总是有新的需求要做。这里牵涉到一个需求管理的概念。产品/项目中哪些该做，哪些不该做或暂时不需要做，做到什么程度，都是由需求管理来决定的。

先来说说需求的来源吧，需求的来源可以说是非常的广泛。

来自市场分析的数据

来自用户调研

来自小组的头脑风暴

来自市场上的竞品分析总结

来自上线后用户的反馈

来自运营的建议

来自支持的反馈

来自老板的需求......

需求管理都有哪些过程呢？

如果没有需求管理往往会丢三落四，需求变更也会变的家常便饭。要想管理需求，首先要将来自"四面八方"的需求收集并整理好，俗话说的好"好记性不如烂笔头"，将所有相关统一放在一起总是必要的，我们把这个地方叫做需求池。

在产品规划的时候，其实需求是在做加法，把所有能想到的需求通通扔进需求池，可能这些需求是必须的也可能是提升用户体验的，也可能是性能优化的，亦可能是优化seo的......可能有些需求是要立即处理的，也可能是要等到后续的阶段再进行处理的。可能需求池很快变的很庞大了。

那么需求来了，它是由哪些因素构成的呢？最起码要有主要的点吧，如下图橙色所示：需求编号、所属模块、需求类型、需求来源、需求场景以及需求描述，一定要给这些需求分分类。

前面说到把收集到的需求放入“需求池”，面对海量的需求，我们要如何处理它们呢？全部都做吗？这些需求是用户的真正需求吗？

首先我们要确定需求【做不做】，只有真的需求才需要被实现，千万不要被用户的伪需求所迷惑。

有很多时候我们会发现提需求的那个人往往不是只提出了自己的需求，而是给了我们他建议的解决方案。

举个栗子：有个用户说他“饿了”，想找你要“一个馒头”，他可能跟你提需求这么说“请给我一个馒头”？那他的真实需求真的是“一个馒头”吗？这个“用户饿了”你如果给他个“汉堡”或“一份大餐”他会不会更高兴呢？

他的痛点是“饿了”而不是“一个馒头”，所以我们要知道用户为什么提这个需求。当然了如果用户真的是确确实实想要“一个馒头”你给他“汉堡”确实是没满足用户需求呢。所以做好需求分析是非常重要的。

确定了需求做不做之后我们就需要去考虑【怎么做】的问题了，实现一个需求可能有很多种方法，但是我们要结合我们的产品找到最适合的哪一种，并且实现成本也要相对低。

分析需求是要具体需求具体分析，但是原则总是一样的：

从用户的实际需求出发，抓住用户的痛点，判断需求是否是真实性的需求；

需求是不是刚需？少了这个需求会怎样？

可以提高多少效率或节省多少成本？

该需求会对多少用户有影响？

需求是否具有延展性？

该需求的实现成本

当我们确定了【怎么做】之后我们就需要知道需求【何时做】了，这个中间就会牵涉到一个版本的概念，按照约定的版本发布周期发布既定的内容；想要知道哪些需求应该先做哪些需求应该后做，请先问这么个问题：这个需求实现了可以带来多少效益？实现这个需求预计需要开发花费多长时间，测试人员需要测试多久？

而需求的实现会带来多大的效益则是需要相关人员一起评审后得出结果的，大家一起讨论下需求按照分析的结果实现是否合理，是否大家的理解都是一致的，照着既定的方法实现是否好推行。

我们根据成本和效益的对比可以得出一个优先级，按照既定的版本发布周期，往版本里按照优先级的高低顺序依次放入版本内开发，在开发的过程种可能还会遇到用户提到的新需求，除非非常紧急的，其余是可以放至需求池，在后续的版本中发布的。

需求有了，【如何做】和【何时做】有了，则下面要做的事就是保证研发在实现的过程中确实是按照要求实现的，并没有误解需求的实现方法，这个也需要测试人员再帮忙把关，相关人员做相应的测试。

我们可能遇到过这种情况，最终结果并没有很好的解决用户的问题或者压根没有解决用户问题。若不是需求分析做的不好那便可能是研发实现的过程出现了岔子吧。

多与研发沟通，确保研发过程无误。

从严谨的角度来说，定义好的需求是不允许随意变更的。但人非圣贤，孰能无过，且互联网环境变化速度很快，需求变更产生了是不可避免的，我们也要正视这个问题，只要控制好需求的变更就好，过多的变更会使需求执行的计划整体被打乱。

需求管理是一项很重要的工作，但是并不是每一个产品人都能照着很好的节奏管理需求，选择适当的工具可以有助于需求管理更加好的进行。

姑且不论管的好与坏，需求管理总是要有的！