科技颠覆者 发表于 2023-2-10 12:15:53

设计「业务」与「技术」方案

三天研发,两天设计;


01


【优先做设计方案】
职场中的那些魔幻操作,研发最烦的是哪个?
作为一个数年且资深的互联网普通开发,可以来说明一下为什么是:缺乏设计;
面对业务需求的时候,可能都听过这样一句话:
这个很简单,直接开发,三天内上线;
产品听了流泪,测试见了崩溃,研发眉头一皱直呼什么鬼;
如果没有听过,那么职场的经历可能是不完美的,但是幸运爆棚;
这种魔幻般的神奇操作,逻辑在哪里?底线在哪里?唯独离谱在这里;
从实践经验上来看,产品研发抛开业务设计所带来的反伤,也许会迟到,但绝对不会缺席;
所谓的简单业务流程,仓促上线之后,后续补坑的成本可能高的离谱;
相对于完整的研发周期来说,设计、落地、一次性的高质量完成,就是成本最低,效率最高的决策;
对于研发角色,方案设计通常就是围绕技术和业务两个核心;


02


【常用的方法论总结】
在做方案设计时,必然要运用一些基础的方式方法;
有关方法的经验总结很多,但是真正常用的并不多,以下只围绕个人在工作中常用的几个来分析;

[*]本质:
理解本质的时候,必须明确在一定的空间和时间范围内,需要有边界约束;
如果范围扩大,考虑的因素太多,相互间的影响和关联过度复杂,脱离实际太远,很难得出符合现状的结论;
在工作中时常会说:透过现象看本质,理解不同事物的共性和个性,判断发展逻辑;
那么,如何理解产品研发的本质?
基于业务的供需关系,持续打造优质的产品服务;
这个描述只是个人的实践体会,对于事物的本质理解,应该简单明了,直击核心内容;

[*]矛盾
矛盾是指事物内部以及事物之间的对立统一关系,虽然概念很抽象,但现象几乎是无处不在;
用通俗的方式来理解,就是需求和利益之间的冲突且统一的关系;
以常见的平台商业形式来思考;
平台方:希望以低成本的服务获取更高的营收;
客户方:希望以低成本获得更好更优质的服务;
平台与客户双方,都希望低成本付出,获取更高的回报,矛盾就这样产生了;
但是,平台失去客户,没有持续生存的能力;客户本身又依赖平台服务,关系既统一又存在冲突;
双方的合作,随着不同阶段的核心问题被解决,即事物的不断发展变化,新的问题和矛盾也会出现;

[*]系统
理解事物的全貌,横向扩展的广度,纵向发展的深度,在时间空间的变化中,以动态的思维应对事物的变化;
简单的说就是:全面的看事物,系统的解决问题;
以实际的研发案例来分析;
面对并发业务的复杂流程时,比较经典的就是抢单场景,处理的思路有很多种;
如果资源足够,直接扩展以支撑请求处理;
如果资源不足,可以限制请求端的放行比例,服务端只处理少量请求;
或者服务端对请求异步解耦,快速失败掉大量的请求;
所以在面对问题时,不必只片面的看一个方向,围绕问题的矛盾多方,统筹寻找平衡的解决方法;

[*]周期
在周期现象中,存在事物的发展和演变规律;
即事物在运动、变化的发展过程中,某些特征多次重复出现;
比较经典的现象就是业务的发展周期:孵化期、验证期、成长期、成熟期、衰退期、转型或者消亡期;
理解事物的发展周期,可以在不同的阶段把握核心事项,解决关键问题;

[*]分治
分而治之是研发的核心能力之一,强调对复杂事物的拆解能力;
随着技术水平的成长,面对的业务问题也更加复杂,必须具备拆分能力,分而治之;
流程的分段管理;技术与业务的分离;代码工程的分层维护;系统的分布式架构;
这些都是研发过程中常用的分治手段;
面对诸多的方法论,首先围绕几个基础方法进行思考和实践,从而理解其内涵和精髓;
然后,再借鉴其他的方法,形成自己的方法体系;
基于一些核心的方法论之上,再去思考业务和技术的设计,在思路上就会成熟很多;


03


【如何分析业务】
想要分析业务,首先要深刻的理解和洞察业务整体;
在个人习惯上会考量三个层次:首先理解业务全貌,其次理解负责的业务板块,最后理解具体的业务需求;

[*]理解业务全貌
理解业务全貌,本质就是明白公司在做什么,组织架构的协作流程,团队的工作方向;
https://img2023.cnblogs.com/blog/1691717/202302/1691717-20230209220759035-1122604016.png
业务的常规定义:行业的基本模式,运作的流程,具体的事务执行;
在实际的工作中,职级越高越是需要具备对业务全貌的分析能力;
行业分析并非普通玩家所能理解的,需要极其顶级的思维和知识储备,以及对各个信息的统筹分析;
作为研发来说;
应该理解业务的投入和营收,并且能意识到这种模式是映射到产品设计或者服务中的;
必须理解业务模式所对应的产品矩阵设计,各个核心功能的流程和路径;

[*]理解负责的业务板块
个人的工作习惯,并不是常规的流程机制;
明确自己负责的业务板块,把握工作重心,不同阶段中调整能力的输入(学习)和输出(生产价值)策略;
https://img2023.cnblogs.com/blog/1691717/202302/1691717-20230209220801941-887993710.png
产品矩阵的设计与业务模式有直接关系,也是梳理自己工作板块的核心依据;
对于产品来说,常见的拆分有两种;
例如以端口为依据划分的C端和B端,以系统为依据划分的业务应用和数据应用;
对于业务来说,拆分的模式则更加灵活;
在运营概念上可能有多个业务线,但是对于研发来说,各种业务线之间存在诸多的流程交互;
对于个人来说,可以从业务、技术、数据三个基础的方向梳理,或者根据具体的运营模式梳理;
理解业务全貌和个人的负责板块,以此明确工作重心和方向;

[*]理解具体的业务需求
理顺业务全貌与自己负责板块,更偏向于内在的务虚方向;
研发对于职场的真正价值,还是在于各个版本的具体需求实现;
https://img2023.cnblogs.com/blog/1691717/202302/1691717-20230209220806626-711524578.png
分析具体的业务需求时,依然有一个对齐的过程;
将具体的业务需求向业务全貌对齐,理解其价值所在;
将业务需求向自己的工作板块对齐,理解自己的价值所在;
实现版本的业务需求,既要对齐大的业务框架,也要理清需求本身,把握版本落地的质量;


04


【理解技术架构的演进】
对于技术规划来说,通常分为:业务和技术两个方向;
可以分析一个复杂系统的迭代过程,从而理解技术方案在规划设计上的演变规律;

[*]横向扩展
从架构的概念来描述:单服务、集群模式、分布式服务、系统级分拆;
https://img2023.cnblogs.com/blog/1691717/202302/1691717-20230209220809788-1819845988.png
横向扩展,其映射的是业务流程和模式的复杂度,随着业务的不同发展阶段,需要进行不同级别的服务拆分;

[*]纵向扩展
从单个系统架构的纵向来分析:展现层、应用层、业务层、组件层、存储层;
https://img2023.cnblogs.com/blog/1691717/202302/1691717-20230209220812603-904416792.png
纵向深入,其映射的是业务逻辑的复杂度,在纵向上进行分层设计,可以降低逻辑管理的难度;

[*]业务研发
基于常规的分布式系统来看,业务研发在演变的过程中,也会拆分为应用级业务,公共业务两大板块;
应用业务实现的是具体需求场景,而公共业务则是大多数应用都依赖的基础业务能力;

[*]技术研发
基于常规的分布式系统来看,合理的架构设计,必然会追求技术与业务的分离;
在代码工程的分包上,可以独立封装技术层面的组件应用,以便于统一维护和升级;
在服务级别上,可以将组件服务拆分为业务(侧重业务解决方案)与技术(侧重技术解决方案)两个层次;
分析业务,把握技术架构的演进历程,将二者进行统筹结合,就是方案设计的主线;


05


【统筹技术和业务方案】
设计研发方案,自然需要把握业务的整体,规划技术架构,确保业务和技术双线推进;
方案的核心则是围绕当前阶段的具体业务需求,设计实现流程、目标、指标;
https://img2023.cnblogs.com/blog/1691717/202302/1691717-20230209220815903-1770212942.png

[*]业务和技术的演进
分别把握整体与阶段的核心目标,作为方案设计的基础指导原则;
从业务整体上看,系统建设与技术架构应该围绕大的业务目标去考量,支撑或者驱动业务发展;
从业务阶段上看,把握当前阶段的业务本质,关键问题与核心矛盾,在版本需求中有序解决;

[*]业务和技术的流程
分析业务的运转流程和特征,映射为技术的实现过程,作为方案设计的核心思想;
业务的运转流程,围绕客户、产品、组织协作来设计,侧重于场景的分析;
业务映射的系统流程,将业务流程和特征转化为系统实现的流程,侧重于两者的统筹分析;
核心逻辑的实现流程,围绕具体需求,设计逻辑时序图,侧重于关键问题的分析;

[*]业务和技术的目标
围绕具体需求,设定相应的目标和指标拆解,作为方案执行结果的考量标准;
版本需求立项之时,就对结果有明确的预期,目标贯穿业务需求的完整周期,在组织协作中是关键导向;
指标用来衡量目标达成的执行过程和最终完成度,侧重于对目标进行验证;
综合来看,对于业务和技术的方案来说;
有业务的整体思考,技术的系统性架构,具体需求的核心设计与落地执行,以及目标和指标的衡量标准;


06


最后,回到工作实践中来,做事虽然有很多方式方法,但是从来没有绝对的标准;
业务也好,技术也罢;
在周期演进的过程中,始终受到组织架构和团队人员的最根本影响;
所以在输出业务和技术方案时,要围绕环境的真实现状,做出相应的调整优化,把握核心即可;

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
页: [1]
查看完整版本: 设计「业务」与「技术」方案