一、 什么是需求拆分？
需求拆分是指将一个大的、复杂的、难以实现的需求，分解成多个更小、更具体、更容易实现的子需求的过程。就像把一个大蛋糕切成小块一样，每个小块代表一个更小的、可管理的工作单元。需求分解对于软件开发来说至关重要，它带来了一系列的好处：
1. 小需求更易于理解和管理，开发的复杂性更低
2. 小需求更易于估算开发时间和投入，制定计划更准确
3. 小需求更易于开发、测试和发布，失败影响会更小
4. 小需求更易于开发人员端到端地独立开发，效率更高
5. 小需求更易于排优先顺序，更频繁发布获得真实反馈

二、传统需求拆分vs现代需求拆分
传统需求需求拆分和现代需求拆分的核心区别在于：前者围绕解决方案域进行拆分，而后者则围绕问题域进行拆分。为了进一步解释这一区别带来的结果，就必须先理解这里提到的“解决方案域”与“问题域”。在软件工程中，将整个软件管理分为问题域和解决方案域。

问题域是指我们开发一款产品或一个功能要解决的问题的范围。这些问题涵盖多个层次，如：
业务问题：我们要借助该功能达成什么业务目标？
用户/客户问题：客户要借助该功能解决什么痛点、带来什么收益？
产品/服务问题：产品和功能需要怎样的体验和流程？

解决方案域是指我们为了将问题域中的问题加以解决，所能够采取的所有方案的集合。比如，如果我们希望家里一尘不染（问题域），我们的解决方案域中，就会出现“自己每天打扫”、“雇佣家政人员”、“购买一次深度保洁”、“购买扫地机器人”等。问题域会随着时间动态变化，因此解决方案域中的方案必须尽快适应问题的变化，才能够不被淘汰。上层的解决方案域会创建出低层的问题域，例如，实现业务目标的方案之一是解决客户的问题，而解决客户问题的途径之一是向客户提供产品和服务，最终产品和服务的实现方式之一是开发软件方案。

了解了这些基本概念之后，我们言归正传。围绕解决方案域的传统需求拆分会带来怎样的问题呢？

图1 围绕解决方案域拆分需求的过程

上图展示了围绕解决方案域拆分需求的整个过程：
1、 由需求方提出一个大而复杂的需求，也就是一大坨问题，常见形态就是常说的“一句话需求”，并将整个一坨丢给软件交付团队。
2、 在收到需求方的一坨问题后，由交付团队中专门的需求分析人员进行方案设计，需求分析人员先针对那一坨问题给出一个完整的解决方案，然后，自上而下地将这个方案拆解成一堆小模块的设计。这些模块就好比是零件，只有所有这些模块都严格按照设计实现完成，并被正确地组装在一起，才能够形成解决问题的有效解决方案。任何一个环节出问题，都会导致整个解决方案失去作用。接下来，需求分析人员会将这些小模块的设计丢给开发团队中的工程师加以实现。
3、 在工程师团队收到需求分析人员丢过来的模块设计之后，这些模块便会被分派给不同的工程师加以开发实现。这时的工程师，并不能通过分配给自己的模块了解问题的全貌，也不知道更底层的实现是否是解决问题的最优解，更不知道自己实现的模块，是否能够和其他工程师负责的模块正确地组装在一起。此刻，所有工程师各自开发自己的模块，互不干涉，直到最后一个模块被实现出来。然而可怕的事情才刚刚开始，这些模块将交给方案集成人员进行组装并由测试人员进行测试。
4、 方案集成人员接收这些散落的模块，也就意味着此刻这些模块将进行此生第一次集成，被按照设计预期的方式组装成可用的方案，然后由测试人员对整套方案是否能够按照预期的方式解决问题加以验证，只有成功集成和通过验证后，方案才会最终交付给需求方。

貌似顺理成章，然而，意想不到的情况就会出现在方案集成和验证环节：
在方案实现过程中，任何一个模块的缺失都无法产生前期设计的可用方案，因此谁也不知道自己实现的模块是否能够和其他模块集成成功，直到最后一个模块实现结束后，大概率会发现集成问题，然后进行大量的返工。

在好不容易完成了方案集成后，方案验证环节却发现，由于方案实现过程中，问题域发生了变化，最初的方案设计需要进行修改、因为工程师无法掌握问题的全貌使得模块的实现也不能快速低成本地应对方案设计的修改。最可怕的是，整个方案的任何一处修改，都意味着所有模块都要配合进行调整。在整个设计、实现、集成的交付过程中，整个团队如同“死亡行军”，根本无法获得来自问题域的反馈，即便获得反馈，调整的成本也难以负担。

最终在你的项目范围蔓延失控、成本远超预算之后，需求方还甩出一句：“这不是我要的”，你和你的团队彻底崩溃。

总结一下传统需求拆分方法的问题：
1）无法快速迭代交付
所有模块完成后才能进行方案的集成和验证，无法分步、迭代地解决问题。

2）变化成本高、不灵活
所有模块的开发同步开始，在被集成之前一直处于半成品状态，需求一旦发生变化，这些半成品都面临返工的风险。

3）因果链条割裂
方案一侧的人员无法看到方案背后的原因，难以从问题方的视角评价方案优劣，闭门造车和局部优化，难以创新。

要避免这种悲惨收场，现代需求管理体系给出了一条有效的道路：拆分问题！

图2 围绕问题域拆分需求的过程

上图描绘了围绕问题域进行需求拆分和迭代交付的过程：
1、 需求方又带来一坨问题，只不过这次，由需求分析人员、工程师、集成和测试人员组成的跨职能团队会和需求方持续而紧密地协作，持续地将大问题分解为一系列小的子问题。
2、 在与需求方持续协作的过程中，选择需要最先解决的子问题。
3、 整个团队对即将解决的子问题逐一进行端到端的共识，快速实现子问题的解决方案增量，并集成到整体解决方案中，并快速进行解决方案的验证、获取需求方反馈。快速修复这个过程中发现的方案增量局部的集成问题和验证问题，并根据需求方的反馈快速调整后续问题的优先顺序。
4、 持续而重复地进行上述问题拆分、选择、设计、实现、集成、验证、反馈地过程，逐步形成与问题域动态匹配的完备方案。

聪明的你应该一眼就看出来了，围绕问题域拆需求不仅能让你的团队以最小的成本找到问题域的最适合解，还解能让你的解决方案更加“敏捷”地跟随问题域一同变化！

三、现代需求管理体系中的需求分解结构
既然不再围绕解决方案来拆分需求，那么原来的WBS肯定也会有所不同。由于问题域存在多个层次，由上自下依次为业务、客户、产品、技术。因此，对应每个层次的需求都有各自的分解结构。

1、业务需求的分解结构

图3 业务需求分解结构

业务需求的问题域对应的问题是“如何实现高层业务目标”，而拆分该问题需要以实际的业务规则为介质。
例如，如果某零售制造企业的业务目标是提高整体利润。如果零售制造的整体利润是边际利润和销量的乘积，而边际利润是单价与变动成本的差，那么我们可以初步将该问题分解为提高价格、降低可变成本、扩大销量三个子业务需求。

2、客户需求的分解结构

图4 客户需求分解结构

客户需求的问题域对应的问题是“客户期望如何让自己变得更好”，而每个特定的问题只存在于特定的场景之下，根据不同的场景，客户的问题也可以进行进一步细分。

例如，同样是为了让自己更好地在超市购物，“每天996的上班族”和“推着婴儿车带着双胞胎新生儿的新生儿父母”所面临的就是两个截然不同的场景，我们的产品功能需要匹配其中的一个还是两个都要满足？

3、业务需求的分解结构

图5 产品需求分解结构

产品需求的问题域对应的问题是“产品/功能需要怎样的流程和体验”。产品的使用体验是产品价值交付的主线。任何产品、功能、服务的分解，都要以保障客户价值端到端交付为前提，始终紧盯整个客户旅程，而不是把旅程中割裂成一个个的环节分别交付。

图6 借助客户旅程和故事地图拆分产品需求

4、技术需求的分解结构

图7 技术需求分解结构

技术需求的问题域对应的问题是“如何使用技术实现产品和功能”。产品所在的业务领域，都有其内在的领域知识，成熟的领域知识是在大的时间跨度上是稳定的，无论产品需求如何变化，都不会脱离领域知识。而架构设计原则与模式，则提供了跨业务领域针对通用问题的指导方针和解决方案。因此，软件如果内置了领域知识、遵循了架构设计原则，就能更容易快速响应需求变化。这也就是为什么要基于领域建模和架构设计原则是拆分技术需求的不二之选，诸如领域驱动设计、四色建模法、事件风暴等都是非常值得借鉴的方法和实践。

图8 使用事件风暴建模保险理赔的例子

结语
尽管通常提到的“拆分需求”是指“拆分产品需求”，但本文为你导入了更高层的需求拆分视图，帮助你了解不同的需求层次分解结构，这将有助于理清从一个企业战略逐渐分解为软件代码的整个过程。虽然本文并没有深入介绍“拆分产品需求”的原则、套路、工具，但对这一话题感兴趣的朋友可以关注后续发布的内容。