在软件研发流程中,团队一步步“过关斩将”,才能把通过业务收集而来的诸多需求转化成实际的价值功能交付给用户。作为研发流程的第一步,糟糕的需求管理流程,常常被认为是项目失败的首要原因。从需求的产生到需求的结束,对需求生命周期的可视可控管理,能帮助项目更快更好地完成并交付产品。
既然需求管理如此重要,那么我们应该如何让需求管理更加清晰呢?
相当数量的团队采用的按部就班的标准流程,我们称为 「金字塔指令式」流程,主要包括以下四个部分:
在软件研发流程中,首要是处理通过业务收集而来的诸多需求。下面,将详细介绍在第一部分——决策中,如何将收集到的需求进行甄别和整理,这一甄别和整理的过程,也就是需求管理的过程。(以下内容均以 Gitee 企业版为例)
在使用 Gitee 企业版中,「需求」和「缺陷」都将通过一级菜单「任务」进行管理。
根据业务情况的不同,需求之间会存在诸多的差异。Gitee 企业版从实际出发,对于每个被创建的「需求」提供了用于分类的「标签」,该标签同时也支持自定义。
确定好需求的分类之后,对于粒度相对较大的需求,应当进行拆分。在 Gitee 企业版中,需要拆分一个「需求」任务时,应当由相关人员(譬如需求分析师、产品经理等)在它下面创建若干的子任务,以便保证之间的关联。
小提示:需求的拆分通常不超过三级。业内常把需求按大小依次分为「Epic」、「Feature」、「Story」三级。在 Gitee 企业版中,企业管理员可以通过进入「管理-任务类型与状态」,然后新建名为「Epic」、「Feature」、「Story」的任务类型来满足上述的管理需要。
经过了分类与分层拆解之后,就该给整理后的需求确定「优先级」。而确定优先级的首要步骤,是明确何为优先级。
在 Gitee 企业版中,我们默认提供了「严重」、「主要」、「次要」、「不重要」四个程度的优先级。在使用之前,团队成员应当对优先级的程度形成共识。
譬如「严重」,团队约定 关系到战略目标层面,且需要近期上线 的「需求」才算「严重」,遇到这类产生时自然心领神会,降低沟通落地的成本。 当然也可以采用 四象限法则:
确定优先级后需要各方对需求进行确认,达成统一认知和共识,推进需求实现落地。 在需求评审的过程中,一定要说明清楚需求的背景、价值、意义,而不是纯粹的需求讲解,这样有助于各方对需求的理解。
当因外部环境变化或者内部需求定义错误导致需求需要更改时,做好需求变更管控,防止因为变更而导致需求执行的过程无法进行下去。善于利用 Gitee 企业版中任务的操作日志, 自动记录下需求的每一次变更,让所有操作有迹可循。
经历了分类、拆解、确认优先级、评审之后的需求,通过比较需求定义与后续工作成果之间的对应关系,建立与维护需求跟踪列表,我们可以根据团队或者产品功能模块的区别,分别归属于不同的资源池,方便不同的团队进行统筹管理了。Gitee 企业版中的 资源池 被称为「项目」。
以上各个需求管理的环节在整个需求的生命周期当中都会实际发生,但很多小伙伴在实际工作更多的是关注在需求分析的环节,而没有注意后续的落实环节,导致虽然找到了真实需求,但却没有办法落地。从用户需求转化为产品需求更多的是前三个环节,而从产品需求变成实际的产品则需要后三个环节。
在整个研发管理流程中,需求管理往往是第一步,也是比较重要的一步,只有需求管理足够清晰和明确,后续的任务规划、排期及执行才能更高效地进行。一个好的研发管理工具能帮助更好的管理实践,达到事半功倍的效果。 Gitee 企业版 是一款不仅具备精细化代码管理能力,还能为需求管理、迭代规划、进度跟踪等经典 Scrum 环节提供工具支撑,帮助企业有序管理研发全流程,云端/本地均可灵活部署,想开始小范围测试的企业可以注册免费使用!