理解「业务」与「技术」概念
技术也好，业务也罢；
【什么是业务？】
对于那些久经职场的人，也很难一句话说明白；
业务，作为工作中绝对的核心点，即便在一个公司待的足够久，对业务足够熟悉，也很难简单直接的说清概念；
业务，立足在一个行业的范畴内，比如物流、金融、电商等；
从行业向下看，延伸到工作中经常说的业务需求和价值，进行结构化的梳理；
从个人的经验中来描述业务的定义：行业的基本模式，运作的流程，具体的事务执行；
对于业务这种结构化的概念分析，只能作为了解事物的入门参考，并不在具体问题的范畴内；
核心的业务能力，要站位所处层级和阶段，体现在解决方案的设计和执行策略；
回到实践场景中来分析；
虽然对于公司来说，商业的生意模型是顶层，产品矩阵在上层，因为面向客户的是产品；
业务的核心需求对应着消费方，也就是客群；
业务的核心价值对应着生产方，也就是组织；
而产品就是业务高度聚合的可视化呈现，产品不单指互联网上的应用，也可以是商品或者服务；
而商业，通俗的说就是生意模式，是由基本的供需关系产生的，即客户和平台的之间的需求和利益；
所以业务对于公司内部来说，是绝对的核心位置，并且公司的运营和协作都要紧紧围绕业务；
在工作中要具备基本意识，产品是商业价值的关键，业务是产品的核心竞争力；
【什么是技术？】
对于一众码农玩家来说，很难一句话聊清楚软件技术的定义；
从个人实践经验来思考，肤浅的描述：软件技术就是数据的增删改查；
这种说法显然只能是内心戏，如果在工作中表述，容易把路走窄；
想要全面深刻的描述软件技术，可以对比一个经典的线下和线上的场景，比如电商；
传统的线下购物场景，就是买家（顾客）通过现金的方式，在实体门面中交易卖家的商品，流程简单高效；
对于线上交易的电商场景来说，围绕用户购买的一系列行为，都涉及数据的处理；
比如浏览行为的数据采集、存储、加工等；
基于行为数据分析出用户的画像，进行精准的推荐营销，进而实现商品销售；
这些场景的核心技术支撑，依赖软件的数据处理能力；
所以软件技术可以理解为数据的生产、采集、传输、存储、加工、交换、显示、分析，各种能力的统称；
从现象上看，就是把线下的场景映射为线上产品的能力，肤浅的表达为数据的增删改查也不为过；
但必须要强调的是，这里只是单纯的站在应用层面来描述软件技术；
实际上，当下主流的定义，是指基于信息技术实现业务的数据化、信息化、数字化、智能化的转型能力；
关于这个话题，后续会结合案例再详细总结；
对业务和技术的定义明确之后，就可以统筹性的将二者进行综合分析；
【业务的核心流程；】
流程是组织协作的最核心机制，也是效率和质量的基本保障；
尤其对于复杂度偏高的业务来说，任何一个流程节点不严谨，都可能导致损失，时间和成本投入巨大，但是效果不符合预期；
从实践经验来看，业务的流程通常划分：需求、落地、沉淀三大阶段；
需求阶段
- 调研：采集和统筹各方意见，业务的核心要围绕客户需求设计，但是协作方的利益，产品的考量，技术的分析，运营的策略等，同样重要；
- 评估：围绕市场的现状，判断成本投入，包括直接成本，时间周期，人力资源等，预估创造的价值，平衡投入与产出；
- 设计：输出业务的前期设计，包括各个参与方的协作流程，时间周期和关键节点，产品以及视觉稿的初步呈现；
- 决策：需求阶段的核心流程走完之后，得到各个协作节点的负责人认同后，并进行邮件确认，避免后续的拉扯问题；
落地阶段
- 生产：产品可以是互联网应用、商品、服务能力等，作为业务流的高度聚合产物，产品决定了价值和竞争力；
- 营销：通过相应的营销策略和手段，推广产品并放大其价值，为业务营收提供助力，当然也要考虑投入和产出比；
- 销售：将产品的价值定义转换为具体的营收，挖掘更多的付费客户，维持业务和产品的持续能力；
沉淀阶段
- 业务：当业务周期结束时，其应用服务有可能随之消失，但是很多业务是具有共性的，需要保留下来支撑新的业务流；
- 技术：在架构设计中追求技术和业务的分离，很大程度可以避免业务消失导致技术投入清空，技术的复用能力沉淀，可以降低新业务的实现周期和成本；
- 客群：客群的运营是业务流中的核心环节，对于互联网行业的产品来说，缺乏客群基础即没有流量，很难具备成长的持续性；
虽然不同的业务场景有不同的特点，在流程上也会有一定的差异性；
但是从实践经验来看，合理的流程机制可以直接避开很多问题；
【技术的核心流程；】
从真实的研发现状来说，技术都是处于业务驱动的状态下，流程上自然也不是主导位置；
在大部分的公司中，基本都是围绕业务流程，做技术面的研发和管理，在业务到达间歇性的平缓期，才会考虑技术建设的投入；
只有在大厂或者小部分的公司中，才会有更纯粹的技术研发；
但其根本依旧是对业务趋势的判断，前瞻性的解决业务可能或已经出现的问题；
也可以从技术领域直接为公司创造价值，然而技术服务也同样依赖大量的基础用户，业务问题自然也会随之而来；
从实践经验来看，技术的流程通常划分：业务、实现、架构、沉淀四大阶段；
业务阶段
- 需求：深入理解每个版本需求的细节，因为细节的误差导致返工甚至重做，相信研发都经历过；
- 现状：这可能是大部分玩家都厌烦的问题，在业务流实现过程中，必然要面对新旧两套逻辑的衔接，需要对现状做优化甚至是重构；
- 发展：对于业务来说，场景的横向扩展，或者纵向深入，都会导致逻辑复杂度的提升，也会直接呈现在系统和数据层面；
实现阶段
- 选型：基于业务和系统现状，不同的场景选择合理的技术组件和工具，或者第三方解决方案；
- 时序：比较关键的是业务流程映射的系统交互时序，编码实现的逻辑时序等；
- 设计：围绕流程的交互时序，做实现逻辑的设计，数据层面的结构设计，团队协作的规划设计；
- 编码：通过编码实现完整的交互逻辑，从技术业务分离的角度思考，编码也分技术和业务两个阶段；
架构阶段：在业务和系统的演变过程中，架构设计也会从单服务发展到系统级的拆分；
沉淀阶段：单工程演变到分布式服务时，自然就会出现公共的技术和业务服务，以及大量的工具和数据的沉淀；
技术流程无论设计和规划的多合理，始终受限于决策层的认知和业务模式，多数情况下技术发展都会受到业务规模和周期的直接影响；
单纯站在技术实践的角度来看，架构的合理性和编码的质量可以保证系统的稳定性和持续能力，这就已经实属不易了；
【业务和技术的周期；】
要先捋清楚一个共识，周期的概念不论在业务还是技术场景中，都反复出现；
周期：事物在运动、变化的发展过程中，某些特征多次重复出现；
业务的发展周期：孵化期、验证期、成长期、成熟期、衰退期、转型或者消亡期；
对于业务不同发展阶段来说，其相应技术研发的阶段侧重也不同，协作方和责任也在持续变化；
孵化期
- 业务：对于所属行业和市场的探索，基本模式的验证；
- 技术：从技术视角提供业务和产品的专业评估；
验证期
- 业务：证明当前业务具备市场价值和落地的可行性，实现产品的初步打造；
- 技术：技术的投入巨大，实现初始的系统构建，基于数据的沉淀，再次对业务进行验证；
成长期
- 业务：业务持续的扩张和发展，产品快速迭代，实现品牌打造；
- 技术：完善系统的业务流程，应对业务发展带来的高并发高可用问题；
成熟期
- 业务：实现营收增长，降低成本提高效率，即效益最大化；
- 技术：解决业务运营的问题，保证系统的稳定性；
衰退期
- 业务：注重公共业务的积累和沉淀，以及相应的客群维护；
- 技术：形成可复用的技术积累和沉淀，追求技术和业务的分离；
转型||消亡
- 业务：基于各种业务的沉淀，快速开始下个新的业务周期；
- 技术：基于各种技术的积累，快速实现新业务的推进；
理解业务和技术的不同周期，只是基础的能力，合理把握周期中各个阶段的趋势才是关键；
看清业务的本质，判断业务的发展变化，分析其内部的问题和矛盾；
利用合理的技术手段，构建稳妥的架构设计，并随着业务的发展不断调整；
在业务的中后期，能有体系化的业务和技术层面的沉淀，在面对业务的转型时，提供可复用的解决方案；
【业务和技术的应对策略；】
对于业务而言；
用变化的思维，理解业务不同阶段的核心问题和矛盾；
设计合理的解决方案，支撑业务稳定和持续的发展；
分析业务本质的关键在于，理解不同参与方的需求与核心利益，这是引发矛盾和问题的根本原因；
对于技术而言；
理解业务的发展周期，在不同的阶段对于业务和技术投入要合理分配；
业务成长期，要更多的侧重业务流程的打造；
业务平稳期，要更多的侧重技术方面的构建；
在常规的业务版本迭代中，也要适当的投入技术方面的长期建设；
可以在大版本之后进行技术优化，或者版本中统筹部分技术方面的需求；如果有业务空窗期，也可以直接走单纯的技术改造版本；
【综合的看技术和业务；】
首先要明确基本的认知，对于技术和业务来说，不必纠结于谁更重要，显然是缺一不可；
在研发的过程中，业务能力和技术水平也会共同的提升；
合理的实现业务落地，就是技术能力的绝对体现；技术体系的架构设计，也是对业务深刻理解的映射；
共有 0 条评论