业务和技术融合的突破口:帮助业务人员理解软件开发

云栖号资讯:【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

早在 1987 年,从 Zachman 先生提出企业架构的开端——“Zachman 框架”开始,B 端软件开发就开始关注企业的全景信息,而非仅仅是琐碎的需求,这也s m Z b u t V意味着,只有开发人员更好地了解了企业整体,才有可能让 B 端软件成为提升企业整体管理能力、创新能W # j力的武器2 n M

但是,企业架构一路起起伏伏的发展让人B L % q反思一个问题:开发人员x w x如何才能更好地了解企业整体?显然信息只能k z d Q从业务人员那里来。如何更有效地获得这些信息?除了笔者经常谈的企业级业务架构外,另一个答案很可 4 ( 2 W 1 ]能会出乎意料——应该先努力让业务人员了解开发。

获得信息的有效途径当然是交流和沟通c a i {,业务制度、流程图这些都是“死”的,“活”的信息只能来自于不同层级的业务人员,而有效的交流沟通并非单向的,不是业务人员单纯向技术人员“倾述”,如同两个人交往一样,越是互相深入了解,沟通才能越有效率。面对日益膨胀的软件需v X } %求,技术人员需要向业务人员普及下到底什么是软件开发,软件开发关注什么,也许只有业务人员了解了软件开发关注什么,才能更好地解释业务关注的x 3 Y Q点和技术关注的点是什么关系。

“技术的归技术,业务的归业务”,这种泾渭分明的思想要不得。时代在发展,数字化时代需要劳动者技能发生改变,结构化思维是数字化时代很重要的业务思维方式,而数字化产品也是数字化时代最主流的产品,软件将是最主要的生产工具,无论从以上那个角度讲,技术人员都有义务帮助业务人员更好地理解软件开发,以提升沟通效率,业务人员也应当更加积极主动地了解这些知识,从而推动业务* {思维的转变。打破理解的鸿沟,业务与技术才有深度的融合,而两者之间的差距也许没有大家想想的那么大。

一、软件也是一种“业务”
(一)软件过f = Q M Q ~ L程与业? z q务过程的相似性
软件开发关注的Q l F w 9 L M g核心问题主要是过程与设计,也就是软件工程和软件设1 * t计,前者关注的是软件的生产过程,后p _ 6 J者关注的是软件的设计方法,其实这{ T 5 Q W | B两个核心问题在思维{ 9 ! h模式、工作套路上与业务人员的工作也是很相似的,完全可以很好地解释给X 0 *业务人员听。软件开发关注的主要问题如下图所示:

业务和技术融合的突破口:帮助业务人员理解软件开发

软件过程主要是从工程管理的角度研究软件生产过程的工序、标准,按什么样的方式和顺序组织生产,每个生产环节该达到什么样的标准R g b Y r P } C,这样做的核心目的是为了提高软件的质量,减少 BUG,也是为了尽可能通过科学地安排工序,缩短软件开发时间,从而提高产量。

技术N Y / q e ` R人员对软件过程的关注其实与业L 1 O A z F %务人员对业务过程的关注没有什么本质区别。业务人员推出一个新业务产品时,也要关注产品的全生命周期管理,从需求收集、市场调研到产品设计、内部审批7 J ! ) N z g G,再到试运行或者上市,之后关注运营、客服,这也是一个基于工序和标准的管理;业务人员也T = G E | )经常研究如何优化内部流程2 : . ~加速产品上市,如同技术人员研究工程模型一样;业务人员对业务的关注也集中在$ p i y Y E n产品质量上,不违规、不给客户带来困扰;最后,业务人员对产品流程的优化也包含着让客户在更短的时间、更好的体验中快速获得产品a , & j T m 6 5[ T 9 . Z也就是对产量的关注。并非由于技术人员生产的是软件,二者就搞t D e _ 4 i Y a出了多大的底层思维的差别。

(二)Y n T S S软件设计与业, 1 Y L务产品设计的相似性
软件开发中关注的另一个问题是软件设计,设计中最重要的部分是架构设计,架构设计关注的核心是结构和关系,如何划分模块、组件、服务,各部分之间又是一种什么样的关系。

清晰架构的目的一是为了更好地复I y @ 6 :现,目前大部分软件开发的需求还是来自业务,是对业务需求的复现,无论你写没写需求文档,这个本质是不变的。所以,理清了业务的结构、应用的结构,才能保证复现的正确性,也就是确保软件的质量。目的之二是为了{ # a i ^ O更好地实现复用,清晰、[ B q 8 | ! { p Z统一的架构定义,有助于识别已有的/ m @ A | o k业务能力、软件资产是否可以被复用,复用有助于解决产量问题,也就是缩短开发周期,而已经被使用过的软件资产往往经历过检验,也有助于保证新应用的质量。

其实软件设计与业务人员搞产品设计关注的& u $ [ a @ 5 1东西也没有很大差异,业务人员做产品设计时一样要考虑产品的构成,产品中包含什么内容,比如= 6 S g银行产品中申请的环节、审批的环节、放款的环节,不同的环节之间是什么关系;如何更好地复现、迎合客户需求;以m q q N l , = u *往的业务经验、业务规则能不能用在新产品设计上,如果能用那自然产品设计的e Q ? 9 r a效率也会提高。所以,二者思维模式接近,如何更好地帮助业务人员在设计产品时进行结构化的思考,就会让业务和技术的关系更近一步。

(三)“乐高积木”的局怎么破?
随着软件需求量+ 7 u 2 ? , y的激增,现在到了需要需求侧能力提升的时候了,技术端无论如何改进自身M O v m l,如果需求端没有相应的改进,那么,软件开发效能的上升始终是有限的。比如,谈论近[ m 1 * 30 余年的“乐高积木”式构件化设计迟迟未见好的实现,是不是与需求侧的结构化程度严重不足有关呢5 f N H?需求侧的结构化思维中,是不是也需要对软件开发的关注点多了解q ) W ? T I一些呢?

“乐高积木”问题其实也就是服务的颗粒度问题,服务的颗粒度与业务管理上经常处理的分工问题是不是高度相似呢?给小j ? / ; E V张同学安排 1 件1 { B $ 7 Z { 3 (事情好还是 5 件事情好?如果有 100 件不同的事情,是安G Z J [排给 100 个小张同学好还是安排给 20 个小张同学好?这个问题对业务人员和技术人员的困扰是一样的,并非是一个有着极大专业界限的问题。

“乐高积木”最终是要支持业务人员的需求变化,那服务的切分到底是技术人员自己的事情,还是也需要业务人员的参与呢?我们& [ L q + # x目前在 B 端软件上经常会以双方关注点的分离来解释现有的软件研发分工,但~ ; [ + ; B =是,面向数字化转型,这个分工该适当改进一: M c _ H A ]下了,新的时代需要新的生产方式,不然,“乐高积木”这个局可能就无解了。

二、软件过程是业务人员学习技术知识的x e + i V D e d U% A q T t m C
现在科技发展速度越来越快、应用越来越普及a p . R + . U {,用技术改变业务模式k { f p 1 d G v的呼吁也越/ p x z g t : A来越强烈,所以很多业务人员也对技术发生了浓厚的兴S d } / I S i t Q趣,人工智能、区块链、大数据、云计算也都成了业务t y i人员的案前书。但是很多业务人员都忽略了对软件工程、系统设计、业务架构这些基础性内容的了解,经常直接撞上了技术领域中“不讲人话j . J /”的部分。

这些“不讲人话”的E n ; { + 0 T -内容,比如人工智能3 j E H h m中的各种算法、区块链中的哈希与共识等等,这里边的内容很多是技术人员自己都说不太清楚,靠封装好的函数、模块进行调用的,业务人员在此花费精= w f a力很不值当。而再“牛”的新技术,也是要经过软件工程中的辛苦劳动才能转化为应用,所以,在关注这些新技术之前,先了解软件工程和系统设计原理,反倒可以更好地思考这些新技术的落地方式。

软件设计的架构知识中确实有不适合业务人员学习的技术理论部分,但是就整体模块的设计与划分而言,是业务和技术可以沟通的部分,也是必须& G a 1 z =要沟通的部分U O q J q,通过双方对软件工程、业务架构、应用架构的共同理解,可以打破双方在理念上人为设置的“鸿沟”,更好地促进双方融合,只有强化了这些底层的融合,才可能让战略层面、企业层面的业技融合真正得以实现。

作者简介:
C Z 7 / 3 n晓岩,新书《银行数字化转型》刚刚面市,受到热议。另著有《企业级业务架构设计:方法论J % l -与实践》一书,对企业级业务架构设计、企业数字化转型、金融科技发展有持续的研究和深厚的实8 6 $ 2 g 3 v践积累,现就职于建信金融科技有限责任公司。公众号:晓谈岩说。

【云栖号在线v 4 0 @ / * V Y j课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/zhibo

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8J ` ?gvnK

原文发布时间:2020-06-30
本文作者:钰湚
本文来自:“InfoQ ”,了解相关信息可以关注“[InfoQ](https://w: 6 l 4 ; . [ Uww.infoq.cn/article/uB7I7iE0HN3TAvmo o Y N AYZJYo)