> 三天研发，两天设计；

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

【常用的方法论总结】在做方案设计时，必然要运用一些基础的方式方法；有关方法的经验总结很多，但是真正常用的并不多，以下只围绕个人在工作中常用的几个来分析； - **本质**：理解本质的时候，必须明确在一定的空间和时间范围内，需要有边界约束；如果范围扩大，考虑的因素太多，相互间的影响和关联过度复杂，脱离实际太远，很难得出符合现状的结论；在工作中时常会说：透过现象看本质，理解不同事物的共性和个性，判断发展逻辑；那么，如何理解产品研发的本质？基于业务的供需关系，持续打造优质的产品服务；这个描述只是个人的实践体会，对于事物的本质理解，应该简单明了，直击核心内容； - **矛盾** 矛盾是指事物内部以及事物之间的对立统一关系，虽然概念很抽象，但现象几乎是无处不在；用通俗的方式来理解，就是需求和利益之间的冲突且统一的关系；以常见的平台商业形式来思考；平台方：希望以低成本的服务获取更高的营收；客户方：希望以低成本获得更好更优质的服务；平台与客户双方，都希望低成本付出，获取更高的回报，矛盾就这样产生了；但是，平台失去客户，没有持续生存的能力；客户本身又依赖平台服务，关系既统一又存在冲突；双方的合作，随着不同阶段的核心问题被解决，即事物的不断发展变化，新的问题和矛盾也会出现； - **系统** 理解事物的全貌，横向扩展的广度，纵向发展的深度，在时间空间的变化中，以动态的思维应对事物的变化；简单的说就是：全面的看事物，系统的解决问题；以实际的研发案例来分析；面对并发业务的复杂流程时，比较经典的就是抢单场景，处理的思路有很多种；如果资源足够，直接扩展以支撑请求处理；如果资源不足，可以限制请求端的放行比例，服务端只处理少量请求；或者服务端对请求异步解耦，快速失败掉大量的请求；所以在面对问题时，不必只片面的看一个方向，围绕问题的矛盾多方，统筹寻找平衡的解决方法； - **周期** 在周期现象中，存在事物的发展和演变规律；即事物在运动、变化的发展过程中，某些特征多次重复出现；比较经典的现象就是业务的发展周期：孵化期、验证期、成长期、成熟期、衰退期、转型或者消亡期；理解事物的发展周期，可以在不同的阶段把握核心事项，解决关键问题； - **分治** 分而治之是研发的核心能力之一，强调对复杂事物的拆解能力；随着技术水平的成长，面对的业务问题也更加复杂，必须具备拆分能力，分而治之；流程的分段管理；技术与业务的分离；代码工程的分层维护；系统的分布式架构；这些都是研发过程中常用的分治手段；面对诸多的方法论，首先围绕几个基础方法进行思考和实践，从而理解其内涵和精髓；然后，再借鉴其他的方法，形成自己的方法体系；基于一些核心的方法论之上，再去思考业务和技术的设计，在思路上就会成熟很多；

【如何分析业务】想要分析业务，首先要深刻的理解和洞察业务整体；在个人习惯上会考量三个层次：首先理解业务全貌，其次理解负责的业务板块，最后理解具体的业务需求； - **理解业务全貌** 理解业务全貌，本质就是明白公司在做什么，组织架构的协作流程，团队的工作方向； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/62d4bd6fad2e4e1c91710108932d72fa~tplv-k3u1fbpfcp-zoom-1.image) 业务的常规定义：行业的基本模式，运作的流程，具体的事务执行；在实际的工作中，职级越高越是需要具备对业务全貌的分析能力；行业分析并非普通玩家所能理解的，需要极其顶级的思维和知识储备，以及对各个信息的统筹分析；作为研发来说；应该理解业务的投入和营收，并且能意识到这种模式是映射到产品设计或者服务中的；必须理解业务模式所对应的产品矩阵设计，各个核心功能的流程和路径； - **理解负责的业务板块** 个人的工作习惯，并不是常规的流程机制；明确自己负责的业务板块，把握工作重心，不同阶段中调整能力的输入（学习）和输出（生产价值）策略； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8de26fb5eb0e464faad0322c12885df4~tplv-k3u1fbpfcp-zoom-1.image) 产品矩阵的设计与业务模式有直接关系，也是梳理自己工作板块的核心依据；对于产品来说，常见的拆分有两种；例如以端口为依据划分的C端和B端，以系统为依据划分的业务应用和数据应用；对于业务来说，拆分的模式则更加灵活；在运营概念上可能有多个业务线，但是对于研发来说，各种业务线之间存在诸多的流程交互；对于个人来说，可以从业务、技术、数据三个基础的方向梳理，或者根据具体的运营模式梳理；理解业务全貌和个人的负责板块，以此明确工作重心和方向； - **理解具体的业务需求** 理顺业务全貌与自己负责板块，更偏向于内在的务虚方向；研发对于职场的真正价值，还是在于各个版本的具体需求实现； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/64a80e2a3d56448898bf82ee8e1f2599~tplv-k3u1fbpfcp-zoom-1.image) 分析具体的业务需求时，依然有一个对齐的过程；将具体的业务需求向业务全貌对齐，理解其价值所在；将业务需求向自己的工作板块对齐，理解自己的价值所在；实现版本的业务需求，既要对齐大的业务框架，也要理清需求本身，把握版本落地的质量；

【理解技术架构的演进】对于技术规划来说，通常分为：业务和技术两个方向；可以分析一个复杂系统的迭代过程，从而理解技术方案在规划设计上的演变规律； - **横向扩展** 从架构的概念来描述：单服务、集群模式、分布式服务、系统级分拆； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d33f8659f4ad4c17804d53d310845084~tplv-k3u1fbpfcp-zoom-1.image) 横向扩展，其映射的是业务流程和模式的复杂度，随着业务的不同发展阶段，需要进行不同级别的服务拆分； - **纵向扩展** 从单个系统架构的纵向来分析：展现层、应用层、业务层、组件层、存储层； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/069e802ef72948c8857e98bf409212ed~tplv-k3u1fbpfcp-zoom-1.image) 纵向深入，其映射的是业务逻辑的复杂度，在纵向上进行分层设计，可以降低逻辑管理的难度； - **业务研发** 基于常规的分布式系统来看，业务研发在演变的过程中，也会拆分为应用级业务，公共业务两大板块；应用业务实现的是具体需求场景，而公共业务则是大多数应用都依赖的基础业务能力； - **技术研发** 基于常规的分布式系统来看，合理的架构设计，必然会追求技术与业务的分离；在代码工程的分包上，可以独立封装技术层面的组件应用，以便于统一维护和升级；在服务级别上，可以将组件服务拆分为业务（侧重业务解决方案）与技术（侧重技术解决方案）两个层次；分析业务，把握技术架构的演进历程，将二者进行统筹结合，就是方案设计的主线；

【统筹技术和业务方案】设计研发方案，自然需要把握业务的整体，规划技术架构，确保业务和技术双线推进；方案的核心则是围绕当前阶段的具体业务需求，设计实现流程、目标、指标； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f2c1161110a045ed8e4a482d367b6b55~tplv-k3u1fbpfcp-zoom-1.image) - **业务和技术的演进** 分别把握整体与阶段的核心目标，作为方案设计的基础指导原则；从业务整体上看，系统建设与技术架构应该围绕大的业务目标去考量，支撑或者驱动业务发展；从业务阶段上看，把握当前阶段的业务本质，关键问题与核心矛盾，在版本需求中有序解决； - **业务和技术的流程** 分析业务的运转流程和特征，映射为技术的实现过程，作为方案设计的核心思想；业务的运转流程，围绕客户、产品、组织协作来设计，侧重于场景的分析；业务映射的系统流程，将业务流程和特征转化为系统实现的流程，侧重于两者的统筹分析；核心逻辑的实现流程，围绕具体需求，设计逻辑时序图，侧重于关键问题的分析； - **业务和技术的目标** 围绕具体需求，设定相应的目标和指标拆解，作为方案执行结果的考量标准；版本需求立项之时，就对结果有明确的预期，目标贯穿业务需求的完整周期，在组织协作中是关键导向；指标用来衡量目标达成的执行过程和最终完成度，侧重于对目标进行验证；综合来看，对于业务和技术的方案来说；有业务的整体思考，技术的系统性架构，具体需求的核心设计与落地执行，以及目标和指标的衡量标准；

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