作为一名产品人，掌握“拆组挂”这一高阶技能至关重要。本文从需求分析、设计和开发三个核心环节出发，详细解读了如何通过“拆解”将复杂需求分解为共性和个性部分，通过“组合”将要素进行高效整合，以及通过“挂接”实现灵活的系统开发。

最近打开《大话软件工程——需求分析与软件设计》这本书，很想对作者李鸿君在书中的细致拆解表示致敬。

回想起4年前分享过徐锋的《有效需求分析》，今天借书中一页内容来谈谈产品人的高阶技能——拆、组、挂。我们主要从宏观角度谈，不深入细节谈具体工具，但至少要在逻辑层面讲清楚。

需求分析的核心——拆解

在企业需求调研过程，我们会听到不同岗位的人的各种各样的需求描述。到底听谁的？获取了这么多信息要如何处理？

这常常让产品同行们无从下手。但如果能应用一些结构化的分析工具，比如上一本书《有效需求分析》提到的UML工具，是可以逐步理清楚一些问题。

李鸿君在书中将拆解分成了共性和个性这两大类。可以说是一种比较通用的分解方式。

为什么要这样分？背后是有这样一套道理：共性的部分，往往是需求人之间没有歧义的内容，这部分内容我们也容易借用前人的经验。而个性的部分，则是需要进一步澄清，这往往也是我们未来开发的重点。

作者在书中提到了典型的三种分解维度：业务与管理、组织架构、生产要素。

我们举其中的业务与管理来展开来说说。先做下概念定义：

业务是指企业为达成某个目标而进行的一系列活动。

管理是为实现业务目标而进行的决策、计划、组织、指导、控制的过程。

企业ERP最常见的两块内容是：业务流和审批流。

谁在执行业务流的每个环节？这大部分是企业的执行层在做的事；又是谁在做审批的事？这往往是管理层在做的事。

所以在需求分析环节，我们得先分清哪些是业务活动？哪些又是管理活动？

有人可能会说真要这么区分吗？我们的ERP就把业务和审批做到了一起。

这样的话，以后会有我们好受的。这个放后面挂接环节再来揭秘。

设计的核心——组合

软件的设计常常被外行看成一个神秘的过程。这东西没有实体，如何进行设计？这都停留在脑袋中。

在企业管理软件中，各行各业、不同职能部门在用的软件，其实背后都可以抽象出共性的部分。

这些部分就是要素、逻辑、模型。

就拿其中的要素来说，先做下定义：

要素是构成软件必不可少的因素，比如我们要设计企业整体的业务管理软件，那么最大粒度的要素就是财务、计划、生产、设计、销售、物流等。

这里每个都可以继续拆分，比如财务又可以分为：收入、成本、费用、支出、报销等。

其中的成本还可以继续拆分成：材料成本、生产成本、物流成本等。

看到这里，你会发现这也用到了分析阶段说的拆分这个工具。但拆分的目标是为了下一步的组合。在每个要素都进行拆分到可设计的最细粒度时，就要派组合这个工具上场了。

我们会发现不同粗粒度的要素，可能会用到部分相同的细粒度的要素。比如成本里会用到物料资料，支出里也会用到物料资料，这时物料资料就是它们共同的要素。

这时我们就可以把物料资料这个要素抽象出来。它就可以组合到各个需要它的地方。

这个有点像每个房间墙面上的开关插座。所有的房间都需要用到电，所有的电器都需要通过开关插座来接上电源。

物料资料就是我们设计出的一个组合要素。

开发的核心——挂接

我们回头来讲第一部分提到的为什么不能把审批流耦合到业务流中？一套灵活的ERP系统，应该有独立的审批流组件。这样才能适合企业的组织架构随时变动，而不用去调整相对稳定的业务流。

当组织架构变动时，如果原本的业务流与审批流是松耦合，就可以直接配置审批流来适应新的变化。

系统开发的重点就是要尽量地将前面设计环节提炼出来的设计要素做成可独立存在的“零件”，并且将零件之间的连接设计出一套支持挂接的“机制”。

还拿上面的审批流组件来说，合同需要用到、付款需要用到，而且每个业务环节的审批过程还不一样。开发出“审批流”这样的零件，那就是谁要用都可以拿走不谢。

真正做到这一步，就真的让PPT上那句：随需应变、随时应变，不是墙上的口号了。