复杂商业模式下,B端如何进行需求管理(上)

懂后台的产品经理更值钱!3周线上课程,带你掌握电商后台12个子系统模块设计要诀。了解一下>

B端需求管理,无论是乙方对甲方的需求,还是甲方自己的需求,如何做到高效管理,是这几年来大家都在热议的话题。如果说2019年前大家都在追求需求交付的“快速”,那么2019年以来,需求管理的趋势就是追求需求质量的提升,追求交付的“准确”。

B端需求管理之所以长久以来是BA、产品经理的心头之痛,就在于它的复杂性,利益相关方、流程、场景、使用者、销售过程……等等,本文分为两个部分,分别讲解如何通过针对性的管理措施,提升需求交付的速度和准确度。

Epic/Feature/Story/Task需求四层划分是目前一些银行的需求管理办法。但已经有客户反馈说,并没有感觉到交付速度提升,还向我咨询,你有没有一些案例,来证明这么做可以提升研发效能?

作为这套方案的构建者,我只能说需求四层划分其实是当年做的一个临时解决方案,现在看起来很别扭,但在当年的那个场景下,这么做是解决当年的问题的。

临时解决方案能不能作为“标准品”,就要还原当时的场景,看看企业真要这么来管理需求,是不是乱用方子。

Epic/Feature/Story/Task是怎么来的?

一句话讲明白:就是整合解决方案和商业系统,专门为客制化IT系统开发服务的,这是个什么样的场景呢?

某国内的顶尖企业,是一家以产品为核心能力的公司,它的内部商业系统供应商、客户群,都是世界级的领先企业。

其客户A,有自己的内部系统A’,企业买了大厂的商业系统B,作为内部IT系统,然后B不完全满足企业自己的内部需求,因此开发了内部系统B’。

随着时代的演进,IT突然成了增值服务,企业对客户A,在一套解决方案中有了打通A’B’内部系统以更快完成产品交付的需求,并且这个需求也是可收费的服务。很明显,客户A并不想改动A’,于是问题来了,如何把客户A对企业产品的需求,转化为行业共性的解决方案,又如何把这个解决方案,层层转化为对B’及最终系统B的客制化开发任务?另外,如何在同一个客制化系统中分清内部IT需求和外部客户需求?

下图灰色区域,代表开发不可控,绿色区域,代表增值服务中的客制化开发。在企业现行的解决方案、版本需求文档、设计文档的模式下,节奏混乱、缓慢。

解决方案层面痛点:需要对客户承诺交付周期,但内部IT项目及B商业产品实施复杂,且与内部IT需求交织在一起,管理困难。

需求管理难点:

  1. 解决方案跟随对客户的产品及服务销售合同到达,承诺范围广,需求规模大,通常是面向某系列产品的完整业务的IT支撑。
  2. 内部技术可行性评估要一直深达B商业产品,耗时长、涉众广,最后压缩开发周期,牺牲交付质量。
  3. 客户A、B…多做了几个直到N后,发现大量相似、重复工作,B’系统严重腐化,小改动引发大量回归测试工作量,且线上事件量爆增。
  4. 以解决方案为中心的开发模式,由于每个解决方案领域及分析师固定,每个版本周期需求量都会变化,导致研发不停地挪动开发人员,每个版本都要“重组”一次,解决方案分析师反复交接需求,如果没在版本前期确认完成,转眼就被工作量确定的另一个领域“夺走”了之前交接的开发资源,再次重新评估……反复折腾……人仰马翻……

这种情况下,就需要一种更好的需求组织模式,来分门别类地处理各项事务。

  • 第一,将解决方案拆解为专题管理,缩小规模。适用的拆解方式有基于业务类别的、业务问题的、业务场景的、业务流程的,总之,不能再直接把销售合同转为解决方案工作包。拆解之后的解决方案专题,要更充分考虑客户所在的行业普适性,从业务层面降低开发工作量。
  • 第二,解决方案专题对B系统的开发需求,识别为待开发特性,用于评估B系统客制化之后对各种其它外围系统的影响。
  • 第三,针对B’系统开发团队作为内部IT,用户感知弱、体验设计能力不足的情况,使用用户旅程、用户故事等方法,增强开发团队对客户使用场景的理解,提升B’系统面向客户交付的正确性和易用性体验。
  • 最后,B’系统架设到B系统的客制化工作量依然巨大,拆解为任务,以更好地管理开发进度。

特性比专题更小,目的是为了在特性团队内部独立完成开发。这样,通过建立稳定、产能近似的特性团队,自主评估每个迭代的容量,由解决方案分析师协调特性分配,而不用跨团队转移调配开发人员,减少了资源协调时间,极大地提升了需求交接的效率。

从这里我们可以看到,需求管理的模式,需要针对组织具体的问题,提供针对性的管理办法。Epic/Feature/Story/Task的目的,不是为了将需求层层分解,而是处理不同视角、共性与特殊性、内外并存、定制化开发与商业系统运行升级的矛盾。

需求拆分又是为了啥?

也用一句话讲明白:就是提升可管理性,包括计划、执行和监控。小任务更容易跟踪工作量,从而提升需求交付的速度,降低交付的风险。

需求过大,不容易在任务接收时完全理解和评估,导致进度不透明,每天都在做,但实际上无进展、风险不能及时暴露,等到最后迭代快完了,功能一跑才发现业务理解都有问题,漏做、错做,不要太多。

很多客户都在问:需求如何拆分?拆分到什么粒度算合理?

答案就是:现在你的看板上卡片每天有进展吗?能看见进度吗?团队成员在早会上是含糊地报进度数字,还是有真实的代码产出提交上来了?没有的话,就拆分一下了。

如果你不能拆分,你就无法高效执行,因为你对待办需求的理解是不透彻的,对如何做是不清楚的。只是领一个需求的符号然后回到座位上慢慢摸索,效率怎么能高起来?

对管理者而言,这其实是管理中一个基本的常识:日清日结。

总结:需求管理之交付速度

从这个案例我们可以学习到,组织的交付响应力和速度的来源,就是一套合适的组织模式,把待办事项、资源用最有效的方法、最合适的节奏组织起来,打造一个以任务为中心的组织。既不是一昧地追求“拆成多小”、“拆多少”,也不是一定要搞成“迭代开发”。

​而需求是什么呢?需求管理本质是企业满足市场、满足客户最重要的达成企业目标的手段。所以,对需求的管理,使用一种合适的结构化需求的模式,事实上就是一种组织内部任务的分解、协同、完成销售目标的关键手段。

B端需求管理的挑战,就在于数字化世界在不断的内外延伸,许多业务形态、模式都发生了变化,把挑战落到了以前并不承担这种挑战的内部IT团队身上。关于企业内部能力与效率提升,就不在此文讨论范围内了,有兴趣可以参考我的前一篇文章《B端:少谈产品方法论,多看企业效率本质》。

在什么样的场景下,是我们提出或采用某个具体解决措施时,必须要问的问题。下一篇,我们将讲一讲需求交付的准确度如何通过需求管理来改进。

 

作者:陈加兴,场量科技创始人,资深敏捷精益专家,精益企业认证产品概念领导者,微信号:one-oracle。

本文由 @陈加兴 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 啥也没有讲清楚。

    回复