产品经理内容分享(二十三):需求流程规范的制定方法和落地技巧

目录

1. 需求流程的常见问题

问题1:反馈需求的渠道太多,难以集中管理

问题2:责权不明,需求长时间无人处理

问题3:需求质量差,经常返工造成延期

问题4:各个团队流程存在差异,跨团队协作比较困难

2. 为团队制定科学有效的需求流程

团队角色分析

定义需求类型和结构关系

定义需求管理空间

制定需求流程规范

确定需求评审/排期的时间节奏

需求流程规范发布

3. 通过云效进行专业的需求规范化设置

配置协作角色

配置需求类型和需求关系

配置工作流

配置流程状态的角色和卡点

配置项目空间模版

将项目模版的配置同步到各个项目空间

通过自动化规则实现需求状态的联动

配置需求评审流程

总结


1. 需求流程的常见问题

问题1:反馈需求的渠道太多,难以集中管理

如果团队没有使用协作平台,一般会使用Excel文档,在IM聊天工具中进行协同编辑,有的团队也会采用多人编辑的在线文档。这种方法在短期的协作中是非常高效的。但是随着业务的发展,客户的增多,这种协同文档也会越来越多,给提需求的人和承接需求的人都带来了困扰,他们不清楚应该在哪一个文档中管理需求。并且,由于创建文档非常的方便,团队成员很容易创建新的文档来管理需求,这样会让整体的管理越来越糟糕,旧的文档中的需求便没有人再关注了。

即使团队使用了协作工具平台,如果缺少流程规范,也很容易出现类似的问题,产品经理会发现平台中有很多的需求池,收集需求和集中管理需求也非常的困难。

问题2:责权不明,需求长时间无人处理

需求的交付时间过长,是困扰很多团队的问题,而在这个过程当中我们发现并不一定是开发的时间长,而是需求长时间无人处理,一直处于停滞状态。

出现这种问题的原因,一般是团队之间的责权定义不明确,比如业务团队认为需求已经提交,等待研发团队开发,研发团队认为需求还没有说清楚,还要补充很多的信息,最后当团队发现问题的时候,可能时间已经过去了很久。这种停滞是毫无意义的,很容易让团队之间产生信任危机。

问题3:需求质量差,经常返工造成延期

需求质量差也是需求流程当中一个经常被提到的问题。质量差一般包括包括以下几个方面:

  • 需求表述不清

  • 需求遗漏

  • 逻辑存在漏洞或者冲突

在需求进入开发阶段以后,一旦发现需求的质量问题,就会造成开发和测试工作的返工,让需求交付时间延长,出现不必要的资源浪费。如果不幸在需求上线后才发现问题,那么损失就更大了。很多团队都在想办法解决需求质量的问题,需求评审是一个有效的手段,能够规避大部分的风险。

问题4:各个团队流程存在差异,跨团队协作比较困难

随着业务不断发展,业务线和产品线都有可能进行拆分,不同团队的需求流程也会逐渐形成差异化,如果一个需求需要两个以上的产品团队合作,就有可能会出现协作的问题。

如果产品形态确实存在较大差异,那么需求流程存在不同也是合理的。但是在一个产品线内部,产品形态基本是接近的,比较理想的情况是,各个产品团队尽量采用相同的需求流程来进行管理。这就好像医院的就诊流程,不同的科室都会采用相同的就诊流程,这样对于病人来说更加容易理解。不同科室之间,如果需要联合会诊也会更加的高效。

2. 为团队制定科学有效的需求流程

需求流程的规范化从制定规范到实施规范,是一个复杂的系统工程。在这个过程中,既要考验团队的组织协作能力,也要依靠工具平台的配置管理能力。接下来我们介绍一下需求流程的整个过程。

团队角色分析

完成一个需求,往往需要很多的角色一起协作,因此制定需求流程,首先需要对流程中所有相关的角色进行分析。

我们可以用一张简单的表格列出各个角色的职能和责任,这里的关键是澄清角色在需求流程中所需要完成的工作,这也是我们后面设置需求详细流程的依据。将各个角色的关系绘制成完整的团队结构图,也有助于在需求流程推广过程中让每一位成员都清楚的了解完整的协作关系。

分析团队角色不能只关注技术团队,还要格外注意需求的来源团队(业务团队)。如果需求的来源很多,涉及多个业务团队,那么一定要把每个团队的业务特点、需求类型、客户类型都考虑到,这些信息在需求流程中可能会产生不同的影响。

图片

团队结构图

定义需求类型和结构关系

需求类型的定义可以说是整个需求流程当中的关键环节,常见的需求类型包括产品需求、用户需求、系统需求、技术需求,还有一些英文概念,例如user story、Feature等等。

面对这么多需求类型,很多团队会感到困惑,不知道该选择哪个类。这里切不可完全照搬网络上的一些推荐方案,而是要选择适合团队的需求类型,尽量选择团队成员比较熟悉的比较常用的概念。

需求的类型其实跟团队角色有着非常大的关系。一般每个需求类型都会由一个角色主要负责。我们用递进的方式向大家介绍一下需求类型和结构关系,从简单到复杂逐渐转变,大家也可以看一下自己的团队更适合在哪个模式更合适。

我们先说一下最简单的模式,只采用一个需求类型:产品类需求。产品需求的负责角色就是产品经理,产品经理创建需求并完成设计,再指派给开发由开发团队完成需求的交付。当技术团队的分工更加明确,一个需求可能会有多个技术人员合作完成,这时我们会在需求下拆分任务,任务的负责角色就是技术团队,这些任务会分配给不同的技术人员各自完成,这样就形成了从产品需求到任务的两层结构。

由于产品需求是由产品经理创建的,因此产品需求的颗粒度会基本保持一致。如果需求的来源不仅仅来自于产品经理,很多业务角色也会创建需求,这时我们将会面临需求的分层,引入业务需求的类型,业务需求的负责角色就是业务团队。由于业务需求是来自于一线的客户或者用户,需求的颗粒度可能存在较大的差异,有的需求很小两周就可以实现,有的需求可能需要几个月。业务需求是无法直接

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

之乎者也·

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值