早在 1987 年，从 Zachman 先生提出企业架构的开端——“Zachman 框架”开始，B 端软件开发就开始关注企业的全景信息，而非仅仅是琐碎的需求，这也意味着，只有开发人员更好地了解了企业整体，才有可能让 B 端软件成为提升企业整体管理能力、创新能力的武器。
但是，企业架构一路起起伏伏的发展让人反思一个问题：开发人员如何才能更好地了解企业整体？显然信息只能从业务人员那里来。如何更有效地获得这些信息？除了笔者经常谈的企业级业务架构外，另一个答案很可能会出乎意料——应该先努力让业务人员了解开发。
获得信息的有效途径当然是交流和沟通，业务制度、流程图这些都是“死”的，“活”的信息只能来自于不同层级的业务人员，而有效的交流沟通并非单向的，不是业务人员单纯向技术人员“倾述”，如同两个人交往一样，越是互相深入了解，沟通才能越有效率。面对日益膨胀的软件需求，技术人员需要向业务人员普及下到底什么是软件开发，软件开发关注什么，也许只有业务人员了解了软件开发关注什么，才能更好地解释业务关注的点和技术关注的点是什么关系。
“技术的归技术，业务的归业务”，这种泾渭分明的思想要不得。时代在发展，数字化时代需要劳动者技能发生改变，结构化思维是数字化时代很重要的业务思维方式，而数字化产品也是数字化时代最主流的产品，软件将是最主要的生产工具，无论从以上那个角度讲，技术人员都有义务帮助业务人员更好地理解软件开发，以提升沟通效率，业务人员也应当更加积极主动地了解这些知识，从而推动业务思维的转变。打破理解的鸿沟，业务与技术才有深度的融合，而两者之间的差距也许没有大家想想的那么大。
一、软件也是一种“业务”
（一）软件过程与业务过程的相似性
软件开发关注的核心问题主要是过程与设计，也就是软件工程和软件设计，前者关注的是软件的生产过程，后者关注的是软件的设计方法，其实这两个核心问题在思维模式、工作套路上与业务人员的工作也是很相似的，完全可以很好地解释给业务人员听。软件开发关注的主要问题如下图所示：
图 1 软件开发关注的问题
软件过程主要是从工程管理的角度研究软件生产过程的工序、标准，按什么样的方式和顺序组织生产，每个生产环节该达到什么样的标准，这样做的核心目的是为了提高软件的质量，减少 BUG，也是为了尽可能通过科学地安排工序，缩短软件开发时间，从而提高产量。
技术人员对软件过程的关注其实与业务人员对业务过程的关注没有什么本质区别。业务人员推出一个新业务产品时，也要关注产品的全生命周期管理，从需求收集、市场调研到产品设计、内部审批，再到试运行或者上市，之后关注运营、客服，这也是一个基于工序和标准的管理；业务人员也经常研究如何优化内部流程加速产品上市，如同技术人员研究工程模型一样；业务人员对业务的关注也集中在产品质量上，不违规、不给客户带来困扰；最后，业务人员对产品流程的优化也包含着让客户在更短的时间、更好的体验中快速获得产品，也就是对产量的关注。并非由于技术人员生产的是软件，二者就搞出了多大的底层思维的差别。
（二）软件设计与业务产品设计的相似性
软件开发中关注的另一个问题是软件设计，设计中最重要的部分是架构设计，架构设计关注的核心是结构和关系，如何划分模块、组件、服务，各部分之间又是一种什么样的关系。
清晰架构的目的一是为了更好地复现，目前大部分软件开发的需求还是来自业务，是对业务需求的复现，无论你写没写需求文档，这个本质是不变的。所以，理清了业务的结构、应用的结构，才能保证复现的正确性，也就是确保软件的质量。目的之二是为了更好地实现复用，清晰、统一的架构定义，有助于识别已有的业务能力、软件资产是否可以被复用，复用有助于解决产量问题，也就是缩短开发周期，而已经被使用过的软件资产往往经历过检验，也有助于保证新应用的质量。
其实软件设计与业务人员搞产品设计关注的东西也没有很大差异，业务人员做产品设计时一样要考虑产品的构成，产品中包含什么内容，比如银行产品中申请的环节、审批的环节、放款的环节，不同的环节之间是什么关系；如何更好地复现、迎合客户需求；以往的业务经验、业务规则能不能用在新产品设计上，如果能用那自然产品设计的效率也会提高。所以，二者思维模式接近，如何更好地帮助业务人员在设计产品时进行结构化的思考，就会让业务和技术的关系更近一步。
（三）“乐高积木”的局怎么破？
随着软件需求量的激增，现在到了需要需求侧能力提升的时候了，技术端无论如何改进自身，如果需求端没有相应的改进，那么，软件开发效能的上升始终是有限的。比如，谈论近 30 余年的“乐高积木”式构件化设计迟迟未见好的实现，是不是与需求侧的结构化程度严重不足有关呢？需求侧的结构化思维中，是不是也需要对软件开发的关注点多了解一些呢？
“乐高积木”问题其实也就是服务的颗粒度问题，服务的颗粒度与业务管理上经常处理的分工问题是不是高度相似呢？给小张同学安排 1 件事情好还是 5 件事情好？如果有 100 件不同的事情，是安排给 100 个小张同学好还是安排给 20 个小张同学好？这个问题对业务人员和技术人员的困扰是一样的，并非是一个有着极大专业界限的问题。
“乐高积木”最终是要支持业务人员的需求变化，那服务的切分到底是技术人员自己的事情，还是也需要业务人员的参与呢？我们目前在 B 端软件上经常会以双方关注点的分离来解释现有的软件研发分工，但是，面向数字化转型，这个分工该适当改进一下了，新的时代需要新的生产方式，不然，“乐高积木”这个局可能就无解了。
二、软件过程是业务人员学习技术知识的基础
现在科技发展速度越来越快、应用越来越普及，用技术改变业务模式的呼吁也越来越强烈，所以很多业务人员也对技术发生了浓厚的兴趣，人工智能、区块链、大数据、云计算也都成了业务人员的案前书。但是很多业务人员都忽略了对软件工程、系统设计、业务架构这些基础性内容的了解，经常直接撞上了技术领域中“不讲人话”的部分。
这些“不讲人话”的内容，比如人工智能中的各种算法、区块链中的哈希与共识等等，这里边的内容很多是技术人员自己都说不太清楚，靠封装好的函数、模块进行调用的，业务人员在此花费精力很不值当。而再“牛”的新技术，也是要经过软件工程中的辛苦劳动才能转化为应用，所以，在关注这些新技术之前，先了解软件工程和系统设计原理，反倒可以更好地思考这些新技术的落地方式。
软件设计的架构知识中确实有不适合业务人员学习的技术理论部分，但是就整体模块的设计与划分而言，是业务和技术可以沟通的部分，也是必须要沟通的部分，通过双方对软件工程、业务架构、应用架构的共同理解，可以打破双方在理念上人为设置的“鸿沟”，更好地促进双方融合，只有强化了这些底层的融合，才可能让战略层面、企业层面的业技融合真正得以实现。
