前言

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

“面对业务需求的时候，可能都听过这样一句话：

这个很简单，直接开发，三天内上线；”

朋友说：

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

如果没有听过，只能说你幸运爆棚，但职场的经历可能是不完美的；

这种魔幻般的神奇操作，逻辑在哪里？底线在哪里？唯独离谱在这里；”

我跟他说：“你说的很有道理，我看你挺想聊，上次你说的大伙看得都很开心，这次你不如再深入聊聊？”

“缺乏设计你懂吗？”朋友没理我，自顾自道。

“产品研发抛开业务设计所带来的反伤，也许会迟到，但绝对不会缺席；

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

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

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

常用的方法论总结

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

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

本质：

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

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

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

那么，如何理解产品研发的本质？

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

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

矛盾

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

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

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

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

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

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

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

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

系统

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

简单的说就是：全面的看事物，系统的解决问题；

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

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

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

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

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

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

周期

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

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

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

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

分治

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

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

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

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

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

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

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

如何分析业务

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

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

理解业务全貌

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

业务的常规定义：行业的基本模式，运作的流程，具体的事务执行；

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

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

作为研发来说；

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

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

理解负责的业务板块

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

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

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

对于产品来说，常见的拆分有两种；

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

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

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

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

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

理解具体的业务需求

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

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

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

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

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

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

理解技术架构的演进

对于技术规划来说，通常分为：业务和技术两个方向；

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

横向扩展

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

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

纵向扩展

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

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

业务研发

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

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

技术研发

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

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

在服务级别上，可以将组件服务拆分为业务（侧重业务解决方案）与技术（侧重技术解决方案）两个层次；

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

统筹技术和业务方案

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

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

业务和技术的演进

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

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

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

业务和技术的流程

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

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

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

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

业务和技术的目标

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

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

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

综合来看，对于业务和技术的方案来说；

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

后话

“回到工作实践中来，做事虽然有很多方式方法，但是从来没有绝对的标准；

业务也好，技术也罢；

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

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

“所以你懂了没？”他望向我道。