复杂商业模式下，B端如何进行需求管理（上）

　　B端需求管理，无论是乙方对甲方的需求，还是甲方自己的需求，如何做到高效管理，是这几年来大家都在热议的话题。如果说2019年前大家都在追求需求交付的“快速”，那么2019年以来，需求管理的趋势就是追求需求质量的提升，追求交付的“准确”。
　　B端需求管理之所以长久以来是BA、产品经理的心头之痛，就在于它的复杂性，利益相关方、流程、场景、使用者、销售过程等等，本文分为两个部分，分别讲解如何通过针对性的管理措施，提升需求交付的速度和准确度。
　　EpicFeatureStoryTask需求四层划分是目前一些银行的需求管理办法。但已经有客户反馈说，并没有感觉到交付速度提升，还向我咨询，你有没有一些案例，来证明这么做可以提升研发效能？
　　作为这套方案的构建者，我只能说需求四层划分其实是当年做的一个临时解决方案，现在看起来很别扭，但在当年的那个场景下，这么做是解决当年的问题的。
　　临时解决方案能不能作为“标准品”，就要还原当时的场景，看看企业真要这么来管理需求，是不是乱用方子。
　　EpicFeatureStoryTask是怎么来的？
　　一句话讲明白：就是整合解决方案和商业系统，专门为客制化IT系统开发服务的，这是个什么样的场景呢？
　　某国内的顶尖企业，是一家以产品为核心能力的公司，它的内部商业系统供应商、客户群，都是世界级的领先企业。
　　其客户A，有自己的内部系统A’，企业买了大厂的商业系统B，作为内部IT系统，然后B不完全满足企业自己的内部需求，因此开发了内部系统B’。
　　随着时代的演进，IT突然成了增值服务，企业对客户A，在一套解决方案中有了打通A’B’内部系统以更快完成产品交付的需求，并且这个需求也是可收费的服务。很明显，客户A并不想改动A’，于是问题来了，如何把客户A对企业产品的需求，转化为行业共性的解决方案，又如何把这个解决方案，层层转化为对B’及最终系统B的客制化开发任务？另外，如何在同一个客制化系统中分清内部IT需求和外部客户需求？
　　下图灰色区域，代表开发不可控，绿色区域，代表增值服务中的客制化开发。在企业现行的解决方案、版本需求文档、设计文档的模式下，节奏混乱、缓慢。
　　解决方案层面痛点：需要对客户承诺交付周期，但内部IT项目及B商业产品实施复杂，且与内部IT需求交织在一起，管理困难。
　　需求管理难点：
　　解决方案跟随对客户的产品及服务销售合同到达，承诺范围广，需求规模大，通常是面向某系列产品的完整业务的IT支撑。
　　内部技术可行性评估要一直深达B商业产品，耗时长、涉众广，最后压缩开发周期，牺牲交付质量。
　　客户A、B多做了几个直到N后，发现大量相似、重复工作，B’系统严重腐化，小改动引发大量回归测试工作量，且线上事件量爆增。
　　以解决方案为中心的开发模式，由于每个解决方案领域及分析师固定，每个版本周期需求量都会变化，导致研发不停地挪动开发人员，每个版本都要“重组”一次，解决方案分析师反复交接需求，如果没在版本前期确认完成，转眼就被工作量确定的另一个领域“夺走”了之前交接的开发资源，再次重新评估反复折腾人仰马翻
　　这种情况下，就需要一种更好的需求组织模式，来分门别类地处理各项事务。
　　第一，将解决方案拆解为专题管理，缩小规模。适用的拆解方式有基于业务类别的、业务问题的、业务场景的、业务流程的，总之，不能再直接把销售合同转为解决方案工作包。拆解之后的解决方案专题，要更充分考虑客户所在的行业普适性，从业务层面降低开发工作量。
　　第二，解决方案专题对B系统的开发需求，识别为待开发特性，用于评估B系统客制化之后对各种其它外围系统的影响。
　　第三，针对B’系统开发团队作为内部IT，用户感知弱、体验设计能力不足的情况，使用用户旅程、用户故事等方法，增强开发团队对客户使用场景的理解，提升B’系统面向客户交付的正确性和易用性体验。
　　最后，B’系统架设到B系统的客制化工作量依然巨大，拆解为任务，以更好地管理开发进度。
　　特性比专题更小，目的是为了在特性团队内部独立完成开发。这样，通过建立稳定、产能近似的特性团队，自主评估每个迭代的容量，由解决方案分析师协调特性分配，而不用跨团队转移调配开发人员，减少了资源协调时间，极大地提升了需求交接的效率。
　　从这里我们可以看到，需求管理的模式，需要针对组织具体的问题，提供针对性的管理办法。EpicFeatureStoryTask的目的，不是为了将需求层层分解，而是处理不同视角、共性与特殊性、内外并存、定制化开发与商业系统运行升级的矛盾。
　　需求拆分又是为了啥？
　　也用一句话讲明白：就是提升可管理性，包括计划、执行和监控。小任务更容易跟踪工作量，从而提升需求交付的速度，降低交付的风险。
　　需求过大，不容易在任务接收时完全理解和评估，导致进度不透明，每天都在做，但实际上无进展、风险不能及时暴露，等到最后迭代快完了，功能一跑才发现业务理解都有问题，漏做、错做，不要太多。
　　很多客户都在问：需求如何拆分？拆分到什么粒度算合理？
　　答案就是：现在你的看板上卡片每天有进展吗？能看见进度吗？团队成员在早会上是含糊地报进度数字，还是有真实的代码产出提交上来了？没有的话，就拆分一下了。
　　如果你不能拆分，你就无法高效执行，因为你对待办需求的理解是不透彻的，对如何做是不清楚的。只是领一个需求的符号然后回到座位上慢慢摸索，效率怎么能高起来？
　　对管理者而言，这其实是管理中一个基本的常识：日清日结。
　　总结：需求管理之交付速度
　　从这个案例我们可以学习到，组织的交付响应力和速度的来源，就是一套合适的组织模式，把待办事项、资源用最有效的方法、最合适的节奏组织起来，打造一个以任务为中心的组织。既不是一昧地追求“拆成多小”、“拆多少”，也不是一定要搞成“迭代开发”。
　　而需求是什么呢？需求管理本质是企业满足市场、满足客户最重要的达成企业目标的手段。所以，对需求的管理，使用一种合适的结构化需求的模式，事实上就是一种组织内部任务的分解、协同、完成销售目标的关键手段。
　　B端需求管理的挑战，就在于数字化世界在不断的内外延伸，许多业务形态、模式都发生了变化，把挑战落到了以前并不承担这种挑战的内部IT团队身上。关于企业内部能力与效率提升，就不在此文讨论范围内了，有兴趣可以参考我的前一篇文章《B端：少谈产品方法论，多看企业效率本质》。
　　在什么样的场景下，是我们提出或采用某个具体解决措施时，必须要问的问题。下一篇，我们将讲一讲需求交付的准确度如何通过需求管理来改进。