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