业务系统演化的几个阶段

伴随着计算机技术的不断发展，软件也得到了长足进步，软件的发展历程大体可以分为以下4级阶段：

最早的软件雏形可以追寻到上个世界50年代，在那个时代，软件以“0”，“1”的方式呈现在纸带上，主要用于科学计算或工程计算。
新型计算机不断涌现，运算速度不断提升，用于编制软件的高级编程语言（如C语言）相继出现。这一时期现了大量的基础类软件系统，如操作系统、数据库、编译器等。
软件进入了社会生产和生活的各个领域，另外由于软件规模的持续扩大以及软件危机的出现，人们提出了软件工程这一学科，开始使用工程的方法来设计和开发软件。
软件领域开始向智能化方向发展，已经能够理解自然语言、声音、文字和图像，并且能进行思维、联想、推理，并得出结论，这期间AI技术起到至关重要的作用。

基于软件系统的业务系统也搭上了信息化技术进步的班车，在软件系统演化的过程中随之进化。其进化过程大致表现为以下3个阶段：

业务系统信息化时代：业务系统搭上了信息化的列车，从手动操作方式向系统化、信息化转变；在这个时代出现了各种面向个人和企业的系统，如：MS Office、ERP、CRM、进销存系统等。
业务系统互联网化时代：跟随着互联网的发展以及云技术的兴起，业务系统开始以互联网服务的方式进入我们的生活，如：百度、淘宝、腾讯、新浪、唯品会等。
业务系统社会化时代，随着智能移动设备、通讯网络、人工智能技术的高速发展，各种各样的软件服务进入社会经济方方面面，万物互联而形成了复杂的社会网络，构成了高度复杂的生态系统，成了为社会基础服务的一个部分。

伴随着业务系统的不断变化，对过去高效运作的业务架构和组织形式带来不小的冲击。如何在纷扰的变化中抓住主要矛盾，让业务系统适应新的环境以及平稳过渡呢？这使得我们对业务系统的开发产生了几点思考。

传统软件设计-基于确定性的统一

在传统软件开发阶段，就业务系统而言，主要表现在把原来人工处理的流程信息化，如这一时期的ERP，CRM，SCM系统等。这一时期的软件开发过程有个显著的特点，就是业务流程、职责和边界都是比较明确的。

传统软件开发阶段的业务系统的开发过程，大体上都是遵循瀑布模型的方式实现业务需求。从需求收集、用例分析、概要设计、详细设计、编码、测试、上线发布等各个阶段的来看，产品经理（或者系统分析师）和开发人员的工作分工是比较清晰的。产品经理（或者系统分析师）所扮演的角色是收集和分析需求、概要设计和详细设计编写以及协同沟通等；开发人员承担的工作主要集中在编码，以及部分用例测试和发布上线等环节。从上述分工可以看出，经过产品经理归纳和抽象的业务需求，拥有呈闭环状的流程，稳健的领域模型和完整的功能逻辑。用一句话表示，即产品经理对外输出的是“确定性”的业务需求。在这种情况下，开发人员的工作更像是在进行“翻译”，把产品经理输出的业务需求转换成计算机系统能识别的编程语言。

瀑布模型开发流程

刨除瀑布模型自身的优缺点，仅从遵循瀑布模型时的业务需求经过产品经理之手，从业务方流向开发人员的过程来说，由于经过了产品经理的归纳和整理，以及开发人员的工作仅仅是编写代码，则大体可以认为产品经理与开发人员对业务的逻辑与本质的理解是确定和一致的。正是因为以上的情况，才把传统软件开发阶段的产品经理与开发人员的合作关系称之为基于确定性的统一。这种统一是建立在开发人员承担单一工作（仅编码实现业务逻辑），牺牲了业务参与度前提下的。如果产品经理的业务能力突出，则能弥补开发人员在业务贡献方面的失位；如果产品经理的业务能力达不到预期，则会对整个项目带来灾难性影响。

敏捷开发下的分歧

当业务系统进入具有快速变化特点的互联网时代时，由于社会宏观环境的千变万化、商业机会的瞬间即逝以及各种新技术的层出不穷，对业务系统提出了更高的要求。业务系统不能以“静态”的方式被动的应对外界环境的变化；要拥抱变化，以“动态”的方式与外界相联动，以更优雅的方式展示自身的适应能力。

传统软件开发阶段所推崇的瀑布模型就不能适应上述情形了。在新的环境下，大家逐步转移到具有“快速发布，多次迭代，持续重构”特点的敏捷开发阵营上来。在敏捷开发的过程中，大家更多的把注意力发在了“快”上面，以至于认为能快速把流程跑通，能实现功能就是完成了业务系统。另外 “迭代”和“重构”的理解上也开始出现了偏差，“迭代”和“重构”逐步变成了肆意调整需求。如开发人员正在进行编码，甚至是已经进入测试阶段的需求说变就变了；又如下一个迭代把上一个迭代版本的需求全盘否定了。这种例子在互联网公司更为常见。我们经常能看到开发人员无奈眼神以及听到开发人员充满怨气的声音：什么，需求又变了！从此，江湖上开始流传起了产品经理与开发人员的恩怨故事。

产品经理与开发人员的恩怨故事

究其原因，是为了适应互联网快速变化的环境，敏捷开发实施过程中出现了需求片面化的问题，造成了对业务蓝图缺乏全面的认识和理解。在不同阶段和不同环境下，对同一需求的认知出现“横看成岭侧成峰”的现象。另外，从业务需求的传递过程来看，敏捷开发实际上是在“快速”和“业务需要试错”的口号下，没有正确理解“迭代”和“重构”的本意，即通过抽丝剥茧和提炼锻造，抽象出一个稳定和符合业务逻辑的模型，而是把业务需求的不确定性传递给了开发人员。当整个业务系统缺乏起到定音作用的基石时，带来的问题就是产品经理和开发人员对业务系统背后的商业逻辑的本质的理解出现了不一致。这也正是导致产品经理和开发人员的矛盾冲突点。

面向业务系统社会化的融合

业务系统源自于社会现实世界，是对社会上已存在业务流程和未来的商业趋势的抽象和归纳；业务系统最终是要回归到社会中，促进社会的发展。由于社会自身的连续性、群体性、复杂性以及组织性等特性，对业务系统能力的多样性、稳健性和扩展性提出了新要求。在业务系统社会化的环境下，为了快速应对多业务体系发展，业务系统应该具有融合、滋养和开放的特点。

唯品会电商业务体系

以唯品会电商业务体系为例，其除了特卖业务外，目前还有支持C端的社交电商渠道业务、支持B端的社交电商渠道业务、专注于品牌商品清仓促销的业务、支持线下店的新零售业务，以及其他细分市场等各种业务。从其电商业务体系可以看出，各业务模块（如商品、交易、导购等）已内聚成通用的组件。各种前端业务共用了业务模块（如商品、交易、导购等）的能力，这样就有利于前端业务更关注于该领域特性以及用户群体的差异性，孕育新的前端业务。

社会化业务系统一个显著的特性就是具有相似性的各商业逻辑已抽象成一个确定的业务内核，业务内核清楚地知道其在社会中的作用和地位。基于该业务内核派生出多种业务实例继承了该业务内核的基因，并在组合了各业务模块基础上进行创新以提供不同的业务能力。在这种情况下，拥有业务基因的业务内核具有确定的边界。产品经理和开发人员在此基础上相互配合，共同探讨业务本质以及自己对业务的理解。这样对产品经理，特别是开发人员的要求更高；对业务商业逻辑和本质问题有更深入的理解，能预判业务发展趋势，这样才利于大家以业务为中心，群策群力，共同推进业务发展。

回到上述电商业务体系上来，如何在各不相同的前端业务中，抛开彼此业务特性，抽象和归纳出业务“主心骨”并打造出业务内核，这不仅是上述电商企业员工，也是各位电商乃至其他业务领域从业者需要思考的地方。另外，如何以业务内核为中心重构已有的工作方式和流程（敏捷开发、极限编程、结对编程等），提出与业务内核相匹配的新的软件工程方法论，是业界和学术界都需要关注的焦点问题，日后可单独行文扩展讨论。

结束语

争执源于认知偏差。从产品经理与开发人员的恩怨故事来看，表面上是需求变更和长期以来双方矛盾积累导致的彼此不信任，更深层次的原因是无法框定业务背后的商业逻辑以及双方对业务本质的认知差异。在业务系统演化过程中，如何抽象业务逻辑、沉淀领域模型、演绎出具有确定性的业务内核以及使产品经理与开发人员在业务内核的理解上趋于一致，最后在此基础下形成产品经理和开发人员融合与统一，这是我们需要思考的地方。另外，文中以某电商业务体系为例，在分析了其电商前端业务和业务模块的基础上，提出了如何打磨它的业务内核以及基于新业务内核的软件工程方法论的问题。

最后，在业务系统演过的过程中，我们一直在思考的路上。

本文转载自公众号唯技术（ID：VIP-Tech）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MjM5NjM5MzQ1MQ==&mid=2651040092&idx=1&sn=d6630bfea8acdab9693553d08ee0914f&chksm=bd1ef1d88a6978ce1815b4dbd543c4cfb720391fddd36b4d79e1eb7371e16a011d4f2d8d2483&scene=27#wechat_redirect

创作场景

左手产品，右手开发：业务逻辑和本质的分与合