设计m6米乐「业务」与「技术」方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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