技术人如何帮助业务人理解软件开发？
极客时间编辑部
讲述：初明明大小：4.72M时长：05:10
你好，欢迎收听极客视点。
对于技术人与业务人的关系，你是怎么看待的？最近，原国有大行资深业务架构师付晓岩在其个人公众号“晓谈岩说”表示，“技术的归技术，业务的归业务”，这种泾渭分明的思想要不得。时代在发展，结构化思维是数字化时代重要的思维方式。技术人员有义务帮助业务人员更好地理解软件开发，以提升沟通效率，业务人员也应当更加积极主动地了解这些知识，从而推动业务思维的转变。打破理解的鸿沟，业务与技术才有深度的融合，而两者之间的差距也许没有你想的那么大。
软件也是一种“业务”
第一，软件过程与业务过程有很多相似性
软件开发关注的核心问题主要是过程与设计，也就是软件工程和软件设计，前者关注的是软件的生产过程，后者关注的是软件的设计方法。这两个核心问题在思维模式、工作套路上与业务人员的工作很相似，完全可以很好地解释给业务人员听。软件开发关注的主要问题如下图所示：
软件过程主要是从工程管理的角度研究软件生产过程的工序、标准，核心目的是为了提高软件的质量，减少 Bug，也是为了尽可能通过科学地安排工序，缩短软件开发时间，从而提高产量。
技术人员对软件过程的关注与业务人员对业务过程的关注没有本质区别。业务人员推出一个新业务产品时，也要关注产品的全生命周期管理，从需求收集、市场调研到产品设计、内部审批，再到试运行或者上市，之后关注运营、客服，这也是一个基于工序和标准的管理。业务人员也经常研究如何优化内部流程加速产品上市，如同技术人员研究工程模型一样。业务人员对业务的关注也集中在产品质量上，不违规、不给客户带来困扰。业务人员对产品流程的优化也包含着让客户在更短的时间、更好的体验中快速获得产品，也就是对产量的关注。并非由于技术人员生产的是软件，二者就有多大的底层思维差别。
第二，软件设计与业务产品设计也有相似性
软件开发中关注的另一个问题是软件设计，设计中最重要的部分是架构设计，架构设计关注的核心是结构和关系，如何划分模块、组件、服务，各部分之间又是一种什么样的关系。
清晰架构的目的之一是为了更好地复现。目前大部分软件开发的需求还是来自业务，是对业务需求的复现。所以，理清了业务的结构、应用的结构，才能保证复现的正确性，也就是确保软件的质量。目的之二是为了更好地实现复用。清晰、统一的架构定义，有助于识别已有的业务能力、软件资产是否可以被复用，复用有助于解决产量问题，也就是缩短开发周期，而已经被使用过的软件资产往往经历过检验，也有助于保证新应用的质量。
其实，软件设计与业务人员做产品设计关注的东西也没有很大差异，业务人员做产品设计时一样要考虑产品的构成，如何更好地复现。所以，二者思维模式接近，如何更好地帮助业务人员在设计产品时进行结构化思考，就会让业务和技术的关系更近一步。
软件过程是业务人员学习技术知识的基础
科技发展速度越来越快、应用越来越普及，用技术改变业务模式的呼吁声也越来越强烈，所以很多业务人员也对技术发生了浓厚的兴趣，人工智能、区块链、大数据、云计算也都成了业务人员的案前书。但是很多业务人员都忽略了对软件工程、系统设计、业务架构这些基础性内容的了解，经常直接撞上了技术领域中“不讲人话”的部分。
这些“不讲人话”的内容，比如人工智能中的各种算法、区块链中的哈希与共识等等，其中的很多内容连技术人员都说不太清楚。靠封装好的函数、模块进行调用的，业务人员在此花费精力很不值当。而再“牛”的新技术，也是要经过软件工程中的辛苦劳动才能转化为应用。所以，在关注这些新技术之前，先了解软件工程和系统设计原理，反倒可以更好地思考这些新技术的落地方式。
软件设计的架构知识中确实有不适合业务人员学习的技术理论部分，但就整体模块的设计与划分而言，是业务和技术可以沟通的部分，也是必须要沟通的部分。通过双方对软件工程、业务架构、应用架构的共同理解，可以打破双方在理念上人为设置的“鸿沟”，更好地促进双方融合。只有强化了这些底层的融合，才可能让战略层面、企业层面的业技融合真正得以实现。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
WJJ356生产制造型企业是很容易理解软件开发过程的
收起评论