01【设计方案的优先级】职场神奇的操作，开发哪一个最烦？作为一个有几年经验的普通互联网开发者，我可以解释为什么是这样：缺乏设计；面对业务需求，你可能听过这样一句话：这个很简单，直接开发，三天上线；产品听哭了，测试崩溃了，R&D皱着眉头喊什么鬼；如果你没有听说过，那么职场经历可能并不完美，但运气是压倒性的；这个神奇操作的逻辑在哪里？底线在哪里？唯一令人发指的是在这里；从实践经验来看，产品开发可能会晚，但如果没有商业设计带来的抗伤害，它永远不会缺席；所谓简单的业务流程，仓促上线后，后续修复的成本可能高得离谱；相对于完整的研发周期，设计、实施、一次性高质量完成是成本最低、效率最高的决策；对于研发角色，方案设计通常围绕技术和业务两大核心展开；02【常用方法总结】做方案设计时，必须要用到一些基本的方法和方法；相关方法的经验总结很多，但常用的不多。下面只会重点介绍个人工作中常用的几个。;本质：理解本质时，必须在一定的空间和时间范围内清晰，需要边界约束；如果扩大范围，考虑的因素太多，相互影响和关系太复杂，离实际太远，很难得出符合现状的结论；在工作中，我常说：透过现象看本质，了解不同事物的共性和个性，判断发展逻辑；那么，如何理解产品开发的本质呢？基于业务的供需关系，持续创造优质的产品和服务；本说明仅为个人实践经验，对事物本质的理解要简单明了，直击核心内容；矛盾是指事物内部和事物之间的对立统一。概念虽然抽象，但现象几乎无处不在；通俗地理解，就是需要和利益的矛盾又统一的关系；以通用平台业务的形式思考；平台方：希望通过低成本的服务获得更高的收益；客户方：希望以低成本获得越来越好的服务；平台和客户都希望以低成本支付并获得更高的回报，这样就产生了矛盾；但是，平台失去了客户，就没有继续生存的能力；客户自身依赖平台服务，既统一又矛盾；双方的合作，随着不同阶段的核心问题得到解决，即随着事情的不断发展变化，也会出现新的问题和矛盾。紧急情况;系统地认识事物的全貌，横向拓展的广度，纵向发展的深度，在时空的变化中，以动态的思维应对事物的变化；简单地说：全面地看待事物，系统地解决问题；分析实际研发案例；面对复杂的并发业务流程，比较经典的就是抓取有很多方法可以处理单个场景；如果资源充足，直接扩展支持请求处理；如果资源不足，可以限制请求者的释放比例，服务器只处理少量请求；或者服务端对请求进行异步解耦，失败很快因此，面对问题时，不能只片面的看一个方向，而是要围绕问题的矛盾寻找平衡的解决方案；在周期现象中，事物有其发展演化的规律；在运动变化的发展过程中，某些特征反复出现；比较经典的现象是企业发展周期：潜伏期、验证期、成长期、成熟期、衰退期、转型期或消亡期；了解事物的发展周期，可以把握不同阶段的核心问题，解决关键问题；分而治之是研发的核心能力之一，强调将复杂事物拆解的能力；随着技术水平的增长，面临的业务问题也更加复杂，必须具备分裂、分而治之的能力；过程的分段管理；技术与业务分离；代码工程分层维护；系统的分布式架构；方法论，首先围绕几个基本方法进行思考和实践，从而理解其内涵和本质；然后，借鉴其他方法，形成自己的方法体系；基于一些核心方法论，去思考业务和技术的设计，思维上会成熟很多；03【如何分析业务】要想分析业务，首先要对业务整体有深刻的理解和洞察；在个人习惯上，你会考虑三个层次：首先了解业务的整体情况，然后了解负责的业务科室，最后了解具体的业务需求；了解业务全景，了解业务全景，本质是了解公司在做什么，组织架构的协同过程，团队的工作方向；业务的常规定义：行业的基本模型，运作的流程，具体到实际工作中，职级越高，越需要具备分析业务全貌的能力；行业分析不是一般玩家能看懂的，需要极其顶层的思维和知识储备，以及对各种信息的整体分析；至于研发；你应该了解商业投资和收入，并意识到这个模型映射到产品设计或服务；必须了解业务模型对应的产品矩阵设计，每个核心功能的流程和路径；了解负责业务部门的个人工作习惯，不是常规的流程机制；明确自己负责的业务板块，把握工作重点，调整能力在不同阶段的输入（学习）和输出（产值）策略；产品矩阵的设计与商业模式直接相关，也是梳理工作板块的核心依据；对于产品，有两种常见的拆分方式；例如，C端和B端按端口划分，业务按系统应用和数据应用划分；对于业务来说，拆分的方式更加灵活；从概念上讲，可能有多个业务线，但对于研发来说，各个业务线之间有很多流程交互；梳理运营模式；了解业务全貌和个人职责分工，明确工作重点和方向；了解具体业务需要理清业务全局和负责人的板块，更倾向于向内退的方向；研发对于职场的真正价值，还是在于实现各个版本的具体需求；在分析具体的业务需求时，还有一个对齐的过程；使特定的业务需求与业务的整体情况保持一致并理解其价值；将业务需求与自己的工作版块对齐，了解自己版本的价值；实现版本业务需求，不仅要对接大业务框架，还要明确需求本身，把握版本实现质量；04【理解技术架构的演进】对于技术规划，通常分为：业务可以分析复杂系统的迭代过程，从而了解技术方案在规划设计中的演进；横向扩展可以从架构的概念来描述：单体服务、集群模式、分布式服务、系统级拆分；横向扩展，映射了业务流程和模型的复杂性。随着业务发展的不同阶段，需要进行不同层次的服务拆分；纵向扩展从单一系统架构的纵向分析：表现层、应用层、业务层、组件层、存储层；垂直深度，映射业务逻辑的复杂度，垂直分层设计，降低逻辑管理难度；业务开发基于常规的分布式系统，业务开发在演进过程中，也会拆分为应用级业务和公共业务。应用业务实现特定的需求场景，而公共业务是大多数应用所依赖的基础业务能力。技术研发是基于常规分布式系统的角度，合理的架构设计必然追求技术与业务的分离；在代码工程分包中，技术层面的组件应用可以独立打包，方便统一维护和升级；在服务层面，可以将组件服务拆分为两个层面：业务（专注于业务解决方案）和技术（专注于技术解决方案）；分析业务，把握技术架构演进过程，将两者结合起来是程序设计的主线；05【统筹技术与业务方案】设计研发方案自然要把握整体业务，规划技术架构，保证业务与技术双线推进；方案的核心是围绕现阶段具体业务需求设计和实施流程、目标和指标；业务演进和技术演进分别把握整体和阶段的核心目标，作为程序设计的基本指导原则；从业务整体的角度，围绕大的业务目标来考虑系统建设和技术架构，以支持或驱动业务发展；从业务的角度分阶段，把握现阶段业务的性质、重点问题和核心矛盾，并版本需求有序解决；业务和技术流程分析业务操作流程和特点，映射到技术实现流程，是方案设计的核心思想；围绕客户、产品和组织协作设计业务运营流程，注重场景分析；业务映射系统流程，将业务流程和特性转化为系统实施流程，重点对两者进行整体分析；核心逻辑实现流程，围绕具体需求设计逻辑时序图，重点分析关键问题；业务和技术目标围绕具体需求，设定相应的目标和指标进行拆解，作为程序执行结果的考量标准；版本需求项目建立时，对结果有明确的预期，目标贯穿业务需求的完整性周期，是组织协作的关键导向；指标用于衡量目标的执行过程和最终完成情况，侧重于对目标的验证；全面的业务和技术解决方案；有整体的业务思维，技术的系统架构，具体需求的核心设计和实现，目标和指标的衡量标准；06最后，回归工作实践，虽然做事的方式方法有很多，但从来没有一个绝对的标准；业务也不错，技术好；在循环演进的过程中，总是受到组织结构和团队成员最根本的影响；因此，在输出业务和技术方案时，需要根据环境的真实情况进行相应的调整和优化，抓住核心。;
