需求管理的整个流程应该是:采集、处理、排期、分析、落地、验收、迭代。
需求采集——需求来源
需求的采集是收集尽可能多的数量,二是覆盖尽可能多的渠道。以下是我整理的一些需求来源。
明确了来源,采集到了需求之后,我们还要学会需求过滤和需求分类。
需求过滤
对需求进行过滤的目的是避免为一些没有价值的需求浪费不必要的时间。
需求分类
我们可以根据具体情况进行不同方向的分类,例如按照各种用户的使用流程、功能类型或者需求类型来进行分类。
并且也要确定需求的紧急重要程度:重要紧急;不重要紧急;重要不紧急;不重要不紧急。
需求管理
常用的方法是建立需求池,它的主要作用在于对需求进行评估和管理。需求池里的需求必须再一次评估和审核。放入需求池后,可对其进行排期等处理。
需求池里的需求详情应该包含有这些信息:
1.需求信息:编号及名称,提出人及提出时间,需求描述。
2.需求状态:需求分类,需求涉及产品模块等。
3.需求实现:当前状态,处理人员,规定处理时间,优先级,备注等。
需求池有什么作用
算是产品版本规划的源头;对产品整体的一系列需求有一个宏观的掌握,也可以记录我们暂时无法彻底消化的需求。
还有一件事是:需求上线前,需要进行方案评审,要做好四件事:原始需求说明、方案讲解、方案评估以及工作量评估。
以及有些需求并不是那么浅显,我们会需要对需求进一步分析。
我是一个数据人员,我日常接触到的更多是业务需求。这类需求在我这现存的情况是:业务说不清需求,IT不太会引导,有时候明明按照确认好的demo去开发,但最后依然不满意,改来改去,不知道啥情况。
其实原因在于,管理和业务更专注做专业领域的事情,刚开始不可能精通数字化的,数据需求自然表达不好;市场和客户每天都在变,需求不可能不变,而且变化后很难第一个时间告诉IT。
其实问题很好解决,就是按需求分析框架分析。这个大家有兴趣的话,整理好 发一篇文章吧,不过多赘述。
分析完需求之后是具体的实施落地,在此不做多余赘述。
需求上线前后:验收、迭代
需求方案上线前,对应方案的负责人需要在上线前两天在测试环境验收,以保证方案的正确实施。上线后,还需要第一时间在正式环境再次验证,再次确保不会出现问题。
再往后,还需要持续跟踪监测。统计用户行为,并根据需求预期价值,确定分析指标,通过对比指标实际数据与预期数据,找出差距,探究差距原因,并制定相应优化策略。
需求走完生命周期之后,还要有一个很重要的复盘阶段,尤其是在需求管理出过故障和问题的时候。主要是防止问题再次发生。解决问题很简单,如何尽量规避下次再出问题很复杂。所以当一整个需求流程走完后,当中的资料的整理收纳非常重要。方便查找和后续的复用。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理