理解「业务」与「技术」概念

时间:2023-02-07 09:07:47

技术也好,业务也罢;


01


【什么是业务?】

对于那些久经职场的人,也很难一句话说明白;

业务,作为工作中绝对的核心点,即便在一个公司待的足够久,对业务足够熟悉,也很难简单直接的说清概念;

业务,立足在一个行业的范畴内,比如物流、金融、电商等;

从行业向下看,延伸到工作中经常说的业务需求和价值,进行结构化的梳理;

理解「业务」与「技术」概念

从个人的经验中来描述业务的定义:行业的基本模式,运作的流程,具体的事务执行;

对于业务这种结构化的概念分析,只能作为了解事物的入门参考,并不在具体问题的范畴内;

核心的业务能力,要站位所处层级和阶段,体现在解决方案的设计和执行策略;

回到实践场景中来分析;

理解「业务」与「技术」概念

虽然对于公司来说,商业的生意模型是顶层,产品矩阵在上层,因为面向客户的是产品;

业务的核心需求对应着消费方,也就是客群;

业务的核心价值对应着生产方,也就是组织;

而产品就是业务高度聚合的可视化呈现,产品不单指互联网上的应用,也可以是商品或者服务;

而商业,通俗的说就是生意模式,是由基本的供需关系产生的,即客户和平台的之间的需求和利益;

所以业务对于公司内部来说,是绝对的核心位置,并且公司的运营和协作都要紧紧围绕业务;

在工作中要具备基本意识,产品是商业价值的关键,业务是产品的核心竞争力;


02


【什么是技术?】

对于一众码农玩家来说,很难一句话聊清楚软件技术的定义;

从个人实践经验来思考,肤浅的描述:软件技术就是数据的增删改查;

这种说法显然只能是内心戏,如果在工作中表述,容易把路走窄;

想要全面深刻的描述软件技术,可以对比一个经典的线下和线上的场景,比如电商;

传统的线下购物场景,就是买家(顾客)通过现金的方式,在实体门面中交易卖家的商品,流程简单高效;

对于线上交易的电商场景来说,围绕用户购买的一系列行为,都涉及数据的处理;

比如浏览行为的数据采集、存储、加工等;

基于行为数据分析出用户的画像,进行精准的推荐营销,进而实现商品销售;

这些场景的核心技术支撑,依赖软件的数据处理能力;

所以软件技术可以理解为数据的生产、采集、传输、存储、加工、交换、显示、分析,各种能力的统称;

从现象上看,就是把线下的场景映射为线上产品的能力,肤浅的表达为数据的增删改查也不为过;

但必须要强调的是,这里只是单纯的站在应用层面来描述软件技术;

实际上,当下主流的定义,是指基于信息技术实现业务的数据化、信息化、数字化、智能化的转型能力;

关于这个话题,后续会结合案例再详细总结;

对业务和技术的定义明确之后,就可以统筹性的将二者进行综合分析;


03


【业务的核心流程;】

流程是组织协作的最核心机制,也是效率和质量的基本保障;

尤其对于复杂度偏高的业务来说,任何一个流程节点不严谨,都可能导致损失,时间和成本投入巨大,但是效果不符合预期;

从实践经验来看,业务的流程通常划分:需求、落地、沉淀三大阶段;

理解「业务」与「技术」概念

需求阶段

  • 调研:采集和统筹各方意见,业务的核心要围绕客户需求设计,但是协作方的利益,产品的考量,技术的分析,运营的策略等,同样重要;
  • 评估:围绕市场的现状,判断成本投入,包括直接成本,时间周期,人力资源等,预估创造的价值,平衡投入与产出;
  • 设计:输出业务的前期设计,包括各个参与方的协作流程,时间周期和关键节点,产品以及视觉稿的初步呈现;
  • 决策:需求阶段的核心流程走完之后,得到各个协作节点的负责人认同后,并进行邮件确认,避免后续的拉扯问题;

落地阶段

  • 生产:产品可以是互联网应用、商品、服务能力等,作为业务流的高度聚合产物,产品决定了价值和竞争力;
  • 营销:通过相应的营销策略和手段,推广产品并放大其价值,为业务营收提供助力,当然也要考虑投入和产出比;
  • 销售:将产品的价值定义转换为具体的营收,挖掘更多的付费客户,维持业务和产品的持续能力;

沉淀阶段

  • 业务:当业务周期结束时,其应用服务有可能随之消失,但是很多业务是具有共性的,需要保留下来支撑新的业务流;
  • 技术:在架构设计中追求技术和业务的分离,很大程度可以避免业务消失导致技术投入清空,技术的复用能力沉淀,可以降低新业务的实现周期和成本;
  • 客群:客群的运营是业务流中的核心环节,对于互联网行业的产品来说,缺乏客群基础即没有流量,很难具备成长的持续性;

虽然不同的业务场景有不同的特点,在流程上也会有一定的差异性;

但是从实践经验来看,合理的流程机制可以直接避开很多问题;


04


【技术的核心流程;】

从真实的研发现状来说,技术都是处于业务驱动的状态下,流程上自然也不是主导位置;

在大部分的公司中,基本都是围绕业务流程,做技术面的研发和管理,在业务到达间歇性的平缓期,才会考虑技术建设的投入;

只有在大厂或者小部分的公司中,才会有更纯粹的技术研发;

但其根本依旧是对业务趋势的判断,前瞻性的解决业务可能或已经出现的问题;

也可以从技术领域直接为公司创造价值,然而技术服务也同样依赖大量的基础用户,业务问题自然也会随之而来;

从实践经验来看,技术的流程通常划分:业务、实现、架构、沉淀四大阶段;

理解「业务」与「技术」概念

业务阶段

  • 需求:深入理解每个版本需求的细节,因为细节的误差导致返工甚至重做,相信研发都经历过;
  • 现状:这可能是大部分玩家都厌烦的问题,在业务流实现过程中,必然要面对新旧两套逻辑的衔接,需要对现状做优化甚至是重构;
  • 发展:对于业务来说,场景的横向扩展,或者纵向深入,都会导致逻辑复杂度的提升,也会直接呈现在系统和数据层面;

实现阶段

  • 选型:基于业务和系统现状,不同的场景选择合理的技术组件和工具,或者第三方解决方案;
  • 时序:比较关键的是业务流程映射的系统交互时序,编码实现的逻辑时序等;
  • 设计:围绕流程的交互时序,做实现逻辑的设计,数据层面的结构设计,团队协作的规划设计;
  • 编码:通过编码实现完整的交互逻辑,从技术业务分离的角度思考,编码也分技术和业务两个阶段;

架构阶段:在业务和系统的演变过程中,架构设计也会从单服务发展到系统级的拆分;

沉淀阶段:单工程演变到分布式服务时,自然就会出现公共的技术和业务服务,以及大量的工具和数据的沉淀;

技术流程无论设计和规划的多合理,始终受限于决策层的认知和业务模式,多数情况下技术发展都会受到业务规模和周期的直接影响;

单纯站在技术实践的角度来看,架构的合理性和编码的质量可以保证系统的稳定性和持续能力,这就已经实属不易了;


05


【业务和技术的周期;】

要先捋清楚一个共识,周期的概念不论在业务还是技术场景中,都反复出现;

周期:事物在运动、变化的发展过程中,某些特征多次重复出现;

业务的发展周期:孵化期、验证期、成长期、成熟期、衰退期、转型或者消亡期;

理解「业务」与「技术」概念

对于业务不同发展阶段来说,其相应技术研发的阶段侧重也不同,协作方和责任也在持续变化;

孵化期

  • 业务:对于所属行业和市场的探索,基本模式的验证;
  • 技术:从技术视角提供业务和产品的专业评估;

验证期

  • 业务:证明当前业务具备市场价值和落地的可行性,实现产品的初步打造;
  • 技术:技术的投入巨大,实现初始的系统构建,基于数据的沉淀,再次对业务进行验证;

成长期

  • 业务:业务持续的扩张和发展,产品快速迭代,实现品牌打造;
  • 技术:完善系统的业务流程,应对业务发展带来的高并发高可用问题;

成熟期

  • 业务:实现营收增长,降低成本提高效率,即效益最大化;
  • 技术:解决业务运营的问题,保证系统的稳定性;

衰退期

  • 业务:注重公共业务的积累和沉淀,以及相应的客群维护;
  • 技术:形成可复用的技术积累和沉淀,追求技术和业务的分离;

转型||消亡

  • 业务:基于各种业务的沉淀,快速开始下个新的业务周期;
  • 技术:基于各种技术的积累,快速实现新业务的推进;

理解业务和技术的不同周期,只是基础的能力,合理把握周期中各个阶段的趋势才是关键;

看清业务的本质,判断业务的发展变化,分析其内部的问题和矛盾;

利用合理的技术手段,构建稳妥的架构设计,并随着业务的发展不断调整;

在业务的中后期,能有体系化的业务和技术层面的沉淀,在面对业务的转型时,提供可复用的解决方案;


06


【业务和技术的应对策略;】

对于业务而言;

用变化的思维,理解业务不同阶段的核心问题和矛盾;

设计合理的解决方案,支撑业务稳定和持续的发展;

分析业务本质的关键在于,理解不同参与方的需求与核心利益,这是引发矛盾和问题的根本原因;

对于技术而言;

理解业务的发展周期,在不同的阶段对于业务和技术投入要合理分配;

业务成长期,要更多的侧重业务流程的打造;

业务平稳期,要更多的侧重技术方面的构建;

在常规的业务版本迭代中,也要适当的投入技术方面的长期建设;

可以在大版本之后进行技术优化,或者版本中统筹部分技术方面的需求;如果有业务空窗期,也可以直接走单纯的技术改造版本;


07


【综合的看技术和业务;】

首先要明确基本的认知,对于技术和业务来说,不必纠结于谁更重要,显然是缺一不可;

在研发的过程中,业务能力和技术水平也会共同的提升;

合理的实现业务落地,就是技术能力的绝对体现;技术体系的架构设计,也是对业务深刻理解的映射;