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

WilliamGates
发布于 2023-5-23 15:27
浏览
0收藏

01【优先做设计方案】

职场中的那些魔幻操作,研发最烦的是哪个?

作为一个数年且资深的互联网普通开发,可以来说明一下为什么是:缺乏设计;

面对业务需求的时候,可能都听过这样一句话:

这个很简单,直接开发,三天内上线;

产品听了流泪,测试见了崩溃,研发眉头一皱直呼什么鬼;

如果没有听过,那么职场的经历可能是不完美的,但是幸运爆棚;

这种魔幻般的神奇操作,逻辑在哪里?底线在哪里?唯独离谱在这里;

从实践经验上来看,产品研发抛开业务设计所带来的反伤,也许会迟到,但绝对不会缺席;

所谓的简单业务流程,仓促上线之后,后续补坑的成本可能高的离谱;

相对于完整的研发周期来说,设计、落地、一次性的高质量完成,就是成本最低,效率最高的决策;

对于研发角色,方案设计通常就是围绕技术和业务两个核心;

02【常用的方法论总结】

在做方案设计时,必然要运用一些基础的方式方法;

有关方法的经验总结很多,但是真正常用的并不多,以下只围绕个人在工作中常用的几个来分析;

  • 本质

理解本质的时候,必须明确在一定的空间和时间范围内,需要有边界约束;

如果范围扩大,考虑的因素太多,相互间的影响和关联过度复杂,脱离实际太远,很难得出符合现状的结论;

在工作中时常会说:透过现象看本质,理解不同事物的共性和个性,判断发展逻辑;

那么,如何理解产品研发的本质?

基于业务的供需关系,持续打造优质的产品服务;

这个描述只是个人的实践体会,对于事物的本质理解,应该简单明了,直击核心内容;

  • 矛盾

矛盾是指事物内部以及事物之间的对立统一关系,虽然概念很抽象,但现象几乎是无处不在;

用通俗的方式来理解,就是需求和利益之间的冲突且统一的关系;

以常见的平台商业形式来思考;

平台方:希望以低成本的服务获取更高的营收;

客户方:希望以低成本获得更好更优质的服务;

平台与客户双方,都希望低成本付出,获取更高的回报,矛盾就这样产生了;

但是,平台失去客户,没有持续生存的能力;客户本身又依赖平台服务,关系既统一又存在冲突;

双方的合作,随着不同阶段的核心问题被解决,即事物的不断发展变化,新的问题和矛盾也会出现;

  • 系统

理解事物的全貌,横向扩展的广度,纵向发展的深度,在时间空间的变化中,以动态的思维应对事物的变化;

简单的说就是:全面的看事物,系统的解决问题;

以实际的研发案例来分析;

面对并发业务的复杂流程时,比较经典的就是抢单场景,处理的思路有很多种;

如果资源足够,直接扩展以支撑请求处理;

如果资源不足,可以限制请求端的放行比例,服务端只处理少量请求;

或者服务端对请求异步解耦,快速失败掉大量的请求;

所以在面对问题时,不必只片面的看一个方向,围绕问题的矛盾多方,统筹寻找平衡的解决方法;

  • 周期

在周期现象中,存在事物的发展和演变规律;

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

比较经典的现象就是业务的发展周期:孵化期、验证期、成长期、成熟期、衰退期、转型或者消亡期;

理解事物的发展周期,可以在不同的阶段把握核心事项,解决关键问题;

  • 分治

分而治之是研发的核心能力之一,强调对复杂事物的拆解能力;

随着技术水平的成长,面对的业务问题也更加复杂,必须具备拆分能力,分而治之;

流程的分段管理;技术与业务的分离;代码工程的分层维护;系统的分布式架构;

这些都是研发过程中常用的分治手段;

面对诸多的方法论,首先围绕几个基础方法进行思考和实践,从而理解其内涵和精髓;

然后,再借鉴其他的方法,形成自己的方法体系;

基于一些核心的方法论之上,再去思考业务和技术的设计,在思路上就会成熟很多;

03【如何分析业务】

想要分析业务,首先要深刻的理解和洞察业务整体;

在个人习惯上会考量三个层次:首先理解业务全貌,其次理解负责的业务板块,最后理解具体的业务需求;

  • 理解业务全貌

理解业务全貌,本质就是明白公司在做什么,组织架构的协作流程,团队的工作方向;

设计「业务」与「技术」方案-鸿蒙开发者社区

业务的常规定义:行业的基本模式,运作的流程,具体的事务执行;

在实际的工作中,职级越高越是需要具备对业务全貌的分析能力;

行业分析并非普通玩家所能理解的,需要极其顶级的思维和知识储备,以及对各个信息的统筹分析;

作为研发来说;

应该理解业务的投入和营收,并且能意识到这种模式是映射到产品设计或者服务中的;

必须理解业务模式所对应的产品矩阵设计,各个核心功能的流程和路径;

  • 理解负责的业务板块

个人的工作习惯,并不是常规的流程机制;

明确自己负责的业务板块,把握工作重心,不同阶段中调整能力的输入(学习)和输出(生产价值)策略;

设计「业务」与「技术」方案-鸿蒙开发者社区

产品矩阵的设计与业务模式有直接关系,也是梳理自己工作板块的核心依据;

对于产品来说,常见的拆分有两种;

例如以端口为依据划分的C端和B端,以系统为依据划分的业务应用和数据应用;

对于业务来说,拆分的模式则更加灵活;

在运营概念上可能有多个业务线,但是对于研发来说,各种业务线之间存在诸多的流程交互;

对于个人来说,可以从业务、技术、数据三个基础的方向梳理,或者根据具体的运营模式梳理;

理解业务全貌和个人的负责板块,以此明确工作重心和方向;

  • 理解具体的业务需求

理顺业务全貌与自己负责板块,更偏向于内在的务虚方向;

研发对于职场的真正价值,还是在于各个版本的具体需求实现;

设计「业务」与「技术」方案-鸿蒙开发者社区

分析具体的业务需求时,依然有一个对齐的过程;

将具体的业务需求向业务全貌对齐,理解其价值所在;

将业务需求向自己的工作板块对齐,理解自己的价值所在;

实现版本的业务需求,既要对齐大的业务框架,也要理清需求本身,把握版本落地的质量;

04【理解技术架构的演进】

对于技术规划来说,通常分为:业务和技术两个方向;

可以分析一个复杂系统的迭代过程,从而理解技术方案在规划设计上的演变规律;

  • 横向扩展

从架构的概念来描述:单服务、集群模式、分布式服务、系统级分拆;

设计「业务」与「技术」方案-鸿蒙开发者社区

横向扩展,其映射的是业务流程和模式的复杂度,随着业务的不同发展阶段,需要进行不同级别的服务拆分;

  • 纵向扩展

从单个系统架构的纵向来分析:展现层、应用层、业务层、组件层、存储层;

设计「业务」与「技术」方案-鸿蒙开发者社区

纵向深入,其映射的是业务逻辑的复杂度,在纵向上进行分层设计,可以降低逻辑管理的难度;

  • 业务研发

基于常规的分布式系统来看,业务研发在演变的过程中,也会拆分为应用级业务,公共业务两大板块;

应用业务实现的是具体需求场景,而公共业务则是大多数应用都依赖的基础业务能力;

  • 技术研发

基于常规的分布式系统来看,合理的架构设计,必然会追求技术与业务的分离;

在代码工程的分包上,可以独立封装技术层面的组件应用,以便于统一维护和升级;

在服务级别上,可以将组件服务拆分为业务(侧重业务解决方案)与技术(侧重技术解决方案)两个层次;

分析业务,把握技术架构的演进历程,将二者进行统筹结合,就是方案设计的主线;

05【统筹技术和业务方案】

设计研发方案,自然需要把握业务的整体,规划技术架构,确保业务和技术双线推进;

方案的核心则是围绕当前阶段的具体业务需求,设计实现流程、目标、指标;

设计「业务」与「技术」方案-鸿蒙开发者社区

  • 业务和技术的演进

分别把握整体与阶段的核心目标,作为方案设计的基础指导原则;

从业务整体上看,系统建设与技术架构应该围绕大的业务目标去考量,支撑或者驱动业务发展;

从业务阶段上看,把握当前阶段的业务本质,关键问题与核心矛盾,在版本需求中有序解决;

  • 业务和技术的流程

分析业务的运转流程和特征,映射为技术的实现过程,作为方案设计的核心思想;

业务的运转流程,围绕客户、产品、组织协作来设计,侧重于场景的分析;

业务映射的系统流程,将业务流程和特征转化为系统实现的流程,侧重于两者的统筹分析;

核心逻辑的实现流程,围绕具体需求,设计逻辑时序图,侧重于关键问题的分析;

  • 业务和技术的目标

围绕具体需求,设定相应的目标和指标拆解,作为方案执行结果的考量标准;

版本需求立项之时,就对结果有明确的预期,目标贯穿业务需求的完整周期,在组织协作中是关键导向;

指标用来衡量目标达成的执行过程和最终完成度,侧重于对目标进行验证;

综合来看,对于业务和技术的方案来说;

有业务的整体思考,技术的系统性架构,具体需求的核心设计与落地执行,以及目标和指标的衡量标准;

06

最后,回到工作实践中来,做事虽然有很多方式方法,但是从来没有绝对的标准;

业务也好,技术也罢;

在周期演进的过程中,始终受到组织架构和团队人员的最根本影响;

所以在输出业务和技术方案时,要围绕环境的真实现状,做出相应的调整优化,把握核心即可;



文章转载自公众号: 知了一笑

分类
标签
已于2023-5-23 15:27:15修改
收藏
回复
举报
回复
    相关推荐