技术人生——技术业务组织的一般规律及应对策略
Posted 阿里云开发者
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了技术人生——技术业务组织的一般规律及应对策略相关的知识，希望对你有一定的参考价值。
简介：本文讨论了如何让技术一号位能够从理论上、以宏观的视角看清日常工作息息相关的事物的发展规律，从而为顺应规律办事或者创造条件打破规律提供理论依据。
往期技术一号位方法论系列文章：
本期文章篇幅较长，建议收藏阅读。
背景
本期文章将接上期《「技术人生」第3篇：解决问题的规律总结》继续探讨技术、业务、组织的一般规律及应对策略。需要注意的是，以下内容为个人实践结果的总结和分析，受限于个人能力和经验有限，在描述规律的过程中，可能会存在维度的缺失；或者当前描述的规律所涉及的维度并不是某些读者认知中的重点，因为事物不同的维度在不同角色和级别的人的认知中重要程度不同，即：PD和研发对于同一件事情的侧重点不同；P6到P11对于同一件事情，很大概率看重的侧重点不同，我们特别欢迎不同层次的同学分享你眼中的规律出来指引其他人实践。
而对于今天本文接下来要讨论的内容，需要大家辩证地去看待，并且在讨论初始需要重新对齐当前事物的讨论范围：当前对组织、业务和技术的规律的探讨，限定在“技术团队leader带领研发团队负责某个业务或负责某个业务的一部分”的情况下，“技术”一词指代研发人员使用的信息化技术；“业务”一词指代研发人员使用信息化技术解决的问题域的统称，“组织”一词指代技术团队 Leader 带领的团队（可能是跨团队的组织）。
同时仍然需要注意的是：
上述范围中提到的组织、技术、业务没有加上“规模”相关的限制，可以理解为，任何规模都符合下面探讨的规律，即我们探讨的是一般规律。同时，不同规模，即团队规模、业务规模、技术深度本质上都是特殊条件，特殊条件的存在可能会触发特殊的规律，但是还是那句话，特殊规律存在并不影响对一般规律的讨论。并且受限于本人当前实际的实践情况，不同规模所触发的特殊规律并没有全部都直观感受过（实践缺失），也没有看过类似的书籍（理论输入缺失），所以不在本文内进行相关特殊规律的探讨。不排除未来有了更多的实践会来完善，同时更欢迎有实践经验的人整理总结成规律分享出来。
上述范围中提到的分析问题的主体是技术 leader，所以对于其他角色类型的同学而言，探讨之后形成的结论需要辩证地去理解，可能有很大部分都是相通的（注意不是相同，而是相通，意味可以相互借鉴），但是同时也有一部分是不适用的，是和探讨的主体本身的特殊性相关的。而这种特殊性对于其他类型的角色并非没有意义，恰恰相反，这可能是比较宏观地、直接地了解另外一种角色的非常有效的途径。即运营一号位或产品一号位或业务一号位可以看到技术一号位所负责的事情中的一般规律和特殊规律，而一般规律大概率相通，而了解特殊规律是理解彼此差异性的在宏观层面的认知。
业务的发展规律及应对策略
业务的发展规律
业务的生命周期如下图所示：
看图时，需要注意以下内容：
图中的曲线仅用于定性分析，非定量分析的精确图表，因此生命周期中各阶段的长度、和业务规模、利润规模的比例关系也都是示意型的，而非精确的比例关系。不同的业务，生命周期长短可能不同，各阶段持续的时间也不同，业务方期望各阶段持续时间长短也不同，需要具体问题具体分析。不同的业务，利润出现的时间和业务生命周期的阶段对应关系不同，利润规模和生命周期各阶段对应关系也不同，需要具体问题具体分析。
在此基础上，我们简单用语言讲清楚业务发展过程是怎样的：
启动期
启动期可以粗略分为立项期和验证期。
立项期一般都是业务侧如PD或者运营发起，要做很多事情，例如围绕业务产生的价值是什么、目标客户是哪些、如何交付给客户、如何收取对应的费用继而维持业务运转下去，这个过程往往还需要结合大环境的要求补充更多细节，即当前事物的主要矛盾次要矛盾的分析解决要符合大环境的主次矛盾，即当前事物发展规律遵循于事物所属大环境的发展规律，因此需要结合组织战略、组织价值、业务所属大业务的战略目标等一系列大环境的要求来完成立项信息的准备。
如果继续探讨，就会涉及到这个探讨事物的本质分析，我们后面有精力的情况下会新开文章去分析，本篇内容不再展开。这个阶段的主要作用就是通过合理的业务模式设计拉通各方对新业务的认知，获取组织的支持。优秀的技术一号位会在这个阶段就介入进来，为业务发起者，通常是业务一号位，提供必需的技术视角的分析和支持。
验证期一般是在立项通过后。主要是通过快速的产品原型的实现，证明业务模式是行得通的，证明业务或产品是能解决客户问题，并且目标客户群体的客户代表是愿意为这种产品付费的。这个阶段一般会投入大量的研发人员来做对应的信息系统来支撑业务的运行。研发团队一般从这个阶段开始做深度介入，并且相较其他角色的团队而言，研发团队在该阶段是主角。
发展期
当启动期内完成了价值证明之后，接下来的重点就是如何将单个客户验证的业务模式快速地规模化复制到更多的客户场景中，从而能够让业务在一定时间内完成业务规模的爆发。研发团队在这个阶段会主要处理系统完备性的问题，因为涉及到越多的客户，新的共性的场景就会越多，为了承接规模化的用户而需要补充对应的业务场景的支撑。这些补充的业务场景，往往是技术系统核心领域的补充以及支撑。
同时，这个阶段的主角不再是研发团队，意味着研发团队的表现逐步从主要行动方逐步转变到幕后成为基础参与方，而其他团队如运营、PD、销售、客服等团队会共同入场相互协同构成当前阶段的主角。所以研发团队除了支持客户本身的业务需求外，还承担着业务上下游协作角色的需求的信息化任务，这一点往往是新手技术一号位可能会忽视的点。
平台期
当业务通过规模化复制推广形成一定规模以后，增长会逐步受限于目标客户群体规模，规模增长达到上限，逐步趋于平缓，同时利润曲线也应该在此阶段之前转正并且在当前阶段达到最大。这个阶段追求的不再是规模化增长，而是开始继续追求利润的最大化，降本提效往往变成该阶段的主旋律，而很多业务环节和参与方也往往会在“降本”提出以后，出现较多的矛盾，出现较多的问题，本质上是之前的几个业务阶段中留下的隐患，即：为了达到业务目标而采用了看似当时合情合理但是实际上对整体有害的方式。
这个问题看似是短期利益和长期利益的冲突，但是对于技术一号位而言，需要寻找既能满足长期利益又能兼顾短期利益的方案，并且一定是以长期利益为主旨的，作为主要做事原则的，而不能反过来。其他的业务参与方应该保持同样的认知，并以之作为实际行动原则。
业务进入平台期之后，随着整个业务进入成熟周期，很多流程逐步完善，组织支撑逐步形成体系，这套配套的组织和流程能让业务继续平稳地发展下去，并且尽可能维持成熟期的长度，但是同样也会带来新的问题，即组织僵化后，业务对市场、客户的变化的感知敏感度下降；针对客户、市场变化的决策被延迟或者阻滞；最终结果就是业务当初产生的价值不再能够满足目标群体的要求，如果不做任何调整和干预的话，业务进入衰退期是必然的。这个阶段，业务和技术都不是破局的关键，而是组织本身。
衰退期
业务进入衰退期没啥好说的，技术团队需要考虑的一个问题就是，业务经历完整的生命周期而做没了是自然规律，那么对应的技术是否也需要随着业务的消亡而消亡？如果技术和业务耦合度太高，那么业务消亡自然会牵连技术，而导致后续新的业务无法利用起来。
所以不论从哪个方面考虑，都需要在技术设计和实现过程中，将技术体系进行系统性的、结构性的分层，底层的通用技术和通用的业务服务本身要做到业务无关，而业务相关的部分要构建成通用的业务领域，确保业务变化以后，领域仍然是可用的，因为业务领域本身是业务内核的反馈，只对业务本质相关的事情负责；而最上层的和产品展示层相关的内容都约束到最上层的业务应用中，业务应用中对产品的展示和交互负责，对场景化的技术需求负责。
消亡期
如果业务进入消亡期没啥好说的，及时转身止损，投入合理的资源善后即可。
各阶段的主要矛盾次要矛盾分析
在整个业务开展过程中，不同阶段的主要矛盾不同，不同的矛盾需要用不同的方式解决。我们这里只探讨最基本的情况，为的是寻找规律。在实际业务的开展过程中，很可能业务属于某个阶段，但是在其他条件的作用下，主要矛盾发生了变化，这一点并不意味着我们今天讨论的内容没有意义，因为矛盾的普遍性和矛盾的特殊性本身都是客观存在的，不能因为特殊性而忽视普遍性，当然也不能因为了解了普遍性，就不再关注特殊性。
- 启动期：前半段有无是主要矛盾，业务价值证明是次要矛盾；后半段业务的价值证明是主要矛盾（业务是否可行），业务规模化发展、大规模获取收益是次要矛盾。
- 发展期：业务规模化复制从而高效创造商业价值是主要矛盾，业务成本控制和价值变现效率是次要矛盾。
- 平台期：业务成本和价值变现效率是主要矛盾，其他问题是次要矛盾（组织等）。
- 衰退期&消亡期：业务进入平台期，如果不能够基于过去的业务求变求新适应新的市场环境，则业务很快会衰落，则业务的可持续发展就成了业务的主要矛盾。
各阶段的应对策略及如何打破规律
3.1 从总体上看如何打破规律
业务生命周期的各阶段并不是一定必须要串行的，也不是有明确的界限的，所以对于某些业务，可以多阶段并行推开。
比如业务一号位可以从一开始就基于过去的业务经验和组织经验提供业务保障的流程和规范，在业务进入平台期之前即具备相关的组织保障能力；技术一号位可以在开始即构建良好的架构设计，关注业务特征，了解业务特征对技术架构的影响，也了解不同业务阶段对技术架构的影响，从而在起步阶段即完成整体设计，从而让架构设计具有前瞻性，同时基于实际情况逐步推进架构向终态的演进。简而言之，就是：既然知道了后面哪些事情必须要干，那么在最开始的时候在解决主要矛盾的时候就顺手逐步干掉，而不是非要反复地踏入业务倒逼技术架构改变的圈子里面。
在生产力有限的情况下，可以加速某些阶段，压缩这些阶段持续的时间，但是永远要知道它是无法跳过的。
作为业务一号位或者技术一号位，要知道在不掌握更高的生产力的情况下，业务每个生命周期都是不可跳过的，主观能动性不能让某个阶段凭空消失，加人进来也不能让某个阶段凭空消失，都只能是用资源成本来换时间。要么就是压缩那些投入期的环节；要么就是延长那些回报期的环节，但是无论如何不能改变这些环节原本的生命周期。
所以当决策者发现主观能动性和砸人进去都不好使，都不能达到你想要的效果的时候，很大可能不是团队执行力不够强，而是做执行的人生产力不够高，至于为什么生产力不够高，是受到了生产关系的制约，还是本身在生产力方面的投入不足所以积累有限，那就要具体问题具体分析了。
当然还有一种可能，就是决策者自己不知道自己做的事情的客观规律是什么，主观认知上达不到这个高度，所以只能出于个人意愿和想象来提出不切实际、不符合规律的要求。当然，辩证地去看，即便是这种最极端的情况出现了，也最终还是因为生产力不够先进，如果足够先进了，再夸张的要求、再不切实际的要求其实都能实现。
在生产力很先进的情况下，可以跳过某些阶段，或者延续某些阶段的持续时间，但是要关注高生产力带来的成本问题。
在生产力提高到一定程度的时候，业务生命周期内的某些环节可以借助生产力跳过，而这种跳过并不是这个环节凭空消失了，而是已经被高级的生产力做掉了。例如可以利用成熟的中间件服务来解决分布式系统中的各种问题，而不需要重复重新做一遍。先进的生产力本身形成也是有其自有的生命周期和阶段的，在初步出现阶段，先进生产力带来的各种成本肯定是高的，甚至会高到无法大规模推广，而随着先进生产力本身不断发展，随着周围环境对先进生产力的适配，先进生产力的使用成本逐步下降到合理的范围内。因此在决定使用先进生产力影响业务生命周期的某些阶段的时候，需要关注投入的成本。
随着生产力的提升，生命周期的每个阶段依然可以继续细分为多个阶段，并且生产力越高，参与业务的各方可以控制和干预的业务生命周期的粒度就会越细，可以控制的维度也越多。
如何理解这句话呢？首先要明确究竟什么是生产力。生产力不是单纯地指技术人员掌握的技术，而是以 “劳动者”——就是指人、“劳动资料”——就是指人使用的工具、“劳动对象”——就是指被人使用工具改变的对象为要素，构成的概念。
所以生产力的提升包含了人的提升、人使用的工具（对于研发同学而言就是技术，对于PD或运营同学而言就是你们的工作方法论）的提升。所以当人变得更强、工具变得更先进以后，可以改造的对象的粒度就越小，可以改造的对象的维度也就越多。
这是普世的一般规律，想想物理上化学上随着生产力的提升人类可以改造的对象的维度和粒度是如何演变的。而这个规律在业务上的体现就是技术能力更强、PD运营方法论更先进更适合业务的团队，能够感知并控制业务的更多的维度，业务的发展周期也会拆解地更细。这一点其实是最和我们日常工作最为息息相关的一个规律。
我们可以利用这个规律来针对“生产力不够先进的业务”构建结构上的优势，例如在业务的“启动期”，生产力落后的一方在解决系统有无问题时，而生产力先进的一方已经同时在着手解决塑造品牌形象等问题。
这些问题看起来不是主要矛盾甚至都算不上次要矛盾的维度的事情，之所以在同样的业务发展阶段，两种团队解决的问题完全不一样，原因就是在于生产力的差异，即：落后的一方在当前阶段解决主干问题时，先进的一方已经解决了主要矛盾并完成了多轮“由主到次”的解决过程，而每一轮“由主到次”的过程，都是拓宽问题维度、拆分问题粒度的过程。这种优势是结构性的，比时间上发力更早而形成的先手优势更高级，也更难被追上。同样的，这个规律也会在技术上同样起到作用，下面在探讨技术的一般规律的时候，会提到这个规律的具体体现。
3.2 从具体的发展阶段上看整体应对策略
- 启动期：尽可能利用现有积累或与三方合作加速或跳过启动期。
- 发展期：具体问题具体分析，与特殊规律有关。
- 平台期：做好孵化新业务的技术准备和业务准备，避免业务进入衰退期以后组织随着业务消亡而价值降低。
- 消亡期：利用转型或孵化新业务构成第二业务曲线，从而在宏观上看到当前组织的业务规模没有发生衰退。
4 从整个业务发展的规律来看，技术一号位需要具备哪些能力
从业务发展规律来看，技术一号位的能力大多数和做业务相关，同时和宏观的技术架构及落地把控能力相关，具体如下：
- 分析业务本质的能力，即能看清业务内部主要矛盾次要矛盾，能根据业务内部和外部环境的相互关联和相互影响来判断业务未来的发展趋势。
- 分析业务各参与方的核心利益诉求，能够合理利用商业模式尽可能多的平衡各方利益诉求，并从技术系统上针对这种业务模式给与支持。
- 分析业务各参与方的核心利益诉求，能够使用指标分别体现各方的核心利益诉求，并且能够以体系化的维度将指标拆解，避免看问题的片面化；同时能够分阶段理清不同阶段的重点指标并在技术支持上予以倾斜，避免看问题静态化。
- 在业务初期，能够结合业务的问题域，完成合理的业务领域建模；并且结合市场调研及业务发展趋势，合理设计系统架构，体现出架构的前瞻性和扩展性。同时要开始做技术生产力上的长线投入，借短期业务需求落地长期技术规划。
- 在业务中期，逐步完善业务支撑维度，全方位构建支撑体系。将支撑体系解决方案化，并且将业务支撑解决方案跨业务复用。同时利用业务初期投入的生产力的提升，来推动业务发展。
- 在业务末期，能够完成技术侧的沉淀，并且有能力孵化出新的技术产品。
技术的演进规律及对应的应对策略
对于技术一号位而言，技术领域是本职领域，探讨技术领域的规律时，要充分结合组织、业务对技术的影响来谈。因为组织特征、业务特征共同决定了技术特征。在我们开始谈一般规律时，先把“技术”这两个字讲清楚，不是要讲概念，而是要讲这两个字在不同语境下的侧重点，然后分别从不同的视角来探讨他们具备的规律。
我们常见的研发过程分类来看，一种是业务研发过程，一种是技术研发过程。两者在某个层面遵守同样的一般规律，同时也因为各自受生产对象的不同而分别有“各自的一般规律”。注意，这里讲“各自一般规律”是指讨论范围分别限定在各自的话题之内，而在更大的技术范围上看，它们则是特殊规律。
为了能清晰地讲清楚业务研发过程中的技术和技术研发过程中的技术究竟有什么一般规律，我们先明确二者之间的辩证关系，统一大家的认知，为后面的讨论扫清障碍。
从本质上讲，所有的研发过程都是业务研发过程，技术研发过程只是业务研发过程的一种特殊情况。业务研发过程服务的对象，是客户的业务人员，要解决的问题域集中在广泛的客户业务领域上；技术研发过程服务的对象，是客户的技术人员（请辩证地、广义地理解客户，不要狭隘的理解客户二字），要解决的问题域集中在狭隘的技术领域内。即：业务研发过程的内核是业务问题，技术研发过程的内核是技术问题，而技术问题是一种特殊的业务问题。
业务研发中的技术处理的对象是一般的客户业务需求；技术研发中的技术处理的对象是特殊的技术需求。技术研发过程中的技术的特殊性在于需求不是直接来源于客户在业务开展过程遇到的业务问题，而是来源于客户在业务开展过程中遇到的特殊领域的、专业的技术问题。
技术研发过程中的技术的一般性在于不管需求从哪来，需求类型是什么，需求有什么特征，都属于广义的业务需求，因此技术研发领域中的技术也同样遵守业务开发领域中的技术所遵守的一般规律。
业务研发过程和技术研发过程在一定的条件下和特殊的阶段是会相互转换的：业务研发过程不断由主到次地解决问题，最终问题的领域会聚焦在单一技术问题上，变成技术研发过程；而技术研发过程不断由主到次地解决问题，最终会在进行对外价值传递时变成业务研发过程。所以业务研发过程的主要问题是对外传递业务价值，次要问题是技术在某些领域的先进性；而技术研发过程恰恰相反，其主要问题是在当前技术领域的先进性，其次才是本身价值的对外传递，因为其价值本身是基于它自身的先进性的。这就是业务研发和技术研发的对立统一的过程，相互演变的过程。
当然这个演变过程不是发生在个人身上的，而是发生在组织身上的，并且随着这个过程的演变，组织内部也会分化演变，即：业务研发团队内部最终会出现专门做技术攻坚的小团队；技术研发团队内部也最终会出现专门做业务产品的小团队；这一演变规律，为所有研发人员选择团队提供了宏观的指引，要辩证地看待做业务和做技术，如果想做技术，在业务团队一样能做；如果想做业务，在技术团队也一样可以；问题就在于你个人是否能看到当前组织的技术、业务演变趋势，机会往往就出现在业务研发过程向技术研发过程转变的时候，或者技术研发过程向业务研发过程转变的时候。
业务需求对技术领域的综合度、广度的要求，构成了业务研发过程中的技术的特殊性；技术需求对技术领域的专业度、深度的要求，构成了技术研发中的技术的特殊性。
对以上内容的认知对齐以后，我们就可以分别探讨业务研发过程中的技术有什么样的一般规律、技术研发过程中的技术有什么一般规律了。
1 技术的演进规律
1.1 业务研发过程中的技术的规律
受业务复杂度和业务生命周期的影响，业务研发过程中的技术整体呈现模型复杂、支持维度多的特征，因此“复杂业务模型的领域设计”、“横跨多个业务生命周期的技术架构演进”、“多维度全方位支撑、保障、驱动业务发展”是三个明显的特点。
从单个业务生命周期来看，业务研发过程涉及到的技术从单一维度向多维度演变；除了要使用技术完成业务的数字化，还需要从研发效能、运营效能、稳定性建设、业务风险控制、财税法支撑等方面进行技术上的支撑（这些支撑，很多都是业务上下游参与方不感知的），随着业务逐步进入成熟期，应用从单体应用向微服务转化；技术的发展趋势，从简单的“把业务跑起来”，逐步形成全方位支撑业务发展的技术解决方案。技术本身也从满足“有无问题”的粗犷模式，逐步演进到解决“降本提效问题”的精细模式，这是一个由主到次的过程，也是生产力提升的一个过程。这就是业务研发过程中的一般规律。
如果一个研发团队同时负责多个业务，那么在做业务的过程中，逐步会形成一些多个业务都会复用到的业务服务，这些业务服务领域相对独立，功能通用，各种业务都需要用到，最终逐步形成业务中间件。例如文件服务（基于OSS封装或其他存储服务封装）、在线签约服务、权限服务、消息中心、待办中心等等。这个过程本质上就是业务研发过程中，技术“从单维度应用演变为多维度的解决方案”的基础上，继续从“单业务适用演变为多业务复用”的过程。
如果一个研发团队或技术一号位先后负责多个业务，那么某个业务本身的领域知识不再那么重要，“如何在没有任何业务背景和经验的前提下完成复杂业务领域建模”变成了技术一号位需要重点构建的核心能力之一。因此业务研发过程中，关于业务建模的方法论是众多技术中的一个非常重要的维度，特别是对于支撑多个不同业务的人而言，该维度的能力是核心能力，是区别于技术研发人员的核心差异点之一。当然由于业务研发过程和技术研发过程会有转换，所以不同情况下的核心维度会发生变化，需要具体问题具体分析。
以上提到的规律是和组织的生命周期相关的，组织稳定，就能沿着单个业务发展的生命周期完成技术从单维度应用到多维度应用的积累；组织有能力承接多个业务，那么就会自然而然地走上解决方案复用的道路，而解决方案的复用带来的好处就是生产力提升以后反哺业务，能够加速业务的某些阶段的发展。同时，要看到技术演进的过程和其宿主——即技术人员所在团队有关，所以A组织具备了什么样的能力，不代表B组织也会具备同样的能力，如何拉通各组织之间的生产力，在技术的多组织复用的基础上，确保各组织的创新性和独立性，是最顶层的技术一号位的核心命题之一。
不同于技术产品，很少有团队能走完业务研发过程中的技术演进过程。往往是成熟业务的团队才可能走完整个过程。例如淘系的星环目前就是处于整个过程的比较靠后的阶段。那么再往后还有么？再往后，就会继续遵循事物演变的规律，当前的主次矛盾解决以后，新的主次矛盾会出现，所以随着资源和时间的持续投入，过去不是主干的问题，会在现在成为主干问题被解决，随着问题域的不断细分，技术领域也会随之不断聚焦，最终演变为技术研发过程。所以其实星环是从业务研发过程中演进或孵化出来的技术产品。这一点（业务研发过程和技术研发过程的相互转变过程）在之前已经讲过了，不再重复展开。
1.2 技术研发过程中的技术的规律
技术研发过程中的技术，与业务研发过程中的技术相比而言，同时具备“技术性”和“业务性”。前者是其特殊性，使之有别于业务研发过程的技术；后者是其一般性，是其和业务研发过程的技术相同的部分。
技术研发过程中的技术，在“业务性”方面，有自己的生命周期，整体会按照以下规律发展：按照“能用——易用——产品化——商业化——商品化”的路径演进。是从满足使用需求，到最终能够做标准化的价值交付的演进过程。
技术研发过程中的技术，在“技术性”方面，也有自己的生命周期，整体会按照以下规律发展：由浅入深，由主干到旁支，随着持续不断的投入，技术命题的深度变深，粒度变细，成本也更大，最终会在投入与产出的平衡中演进暂停，形成阶段性的先进性。而这个过程，和技术场景支持的业务规模息息相关，二者是相辅相成的，即业务规模带来了技术演进的动力，增加了投入的成本，同时技术演进也支撑了更大的业务规模，带来更高的收益。
2 如何利用规律或打破规律
理论最大的用处，是提前对事物构建一个理性的、全面的、动态的认知，从而指导对该事物的实践过程。我们花费了这么多的篇幅来尝试分析清楚技术的规律，如果仅仅停留在理论上，那就失去了它应有的价值。下面我们就简单选几个技术人员日常最关心的几个问题，看看如何从规律的角度来分析解答，具体如下。
2.1 提到的技术规律对一般的研发同学有什么启示
- 认识到生产力形成的过程是和团队的生命周期相关的，成熟的团队生产力相对较高，技术沉淀更深入，但是由于多次的由主到次的迭代，所以一个成熟团队，需要投入精力的领域往往在技术体系上的粒度较细，面较窄，整体更深入；而新成立的团队往往生产力的积累上比成熟团队差，但是面更广。
因此一般的研发人员在挑选团队的时候，要看自己当前处于什么样的阶段，是处于积累期，还是处于已有一定积累，需要在广度上做扩展：前者适合去成熟团队，后者适合去新兴团队。
- 当然，也要认识到业务生命周期和团队生命周期之间的关系。成熟的团队做的业务往往是比较稳定的，换言之，已经稳定的业务一般是由一个比较成熟的团队来支撑的。即使这类型的团队开展了新的业务方向，但是基本盘依然是成熟业务，因此团队稳定性高。但是在这种团队中，一般情况下新加入的员工做的都是比较边缘的事情，因为核心的主要的事情已经有人在做了，并且已经做到了一定的成熟度。新兴团队做的业务往往是新立项做的，不论业务在战略上有多重要，都无法改变它不是当前时间段的主干业务的现实，所以业务能否做成、团队能否稳定存在是一个需要考虑的问题。
因此一般的研发人员在挑选团队的时候，也要考虑团队的稳定性，如果觉得稳定性最重要的，那就去核心业务部门，这样的团队相对而言比较稳定，但是要注意做的事情可能是比较细碎比较边缘的；如果是认为施展个人才华更重要，那就选择去新兴团队做新的业务，机会多，虽然开始事情比较杂，但是都是业务的重点，唯一需要考虑的就是团队的稳定性，即业务可能失败而团队被调整。
- 认识到技术研发过程和业务研发过程的客观转换规律。一般比较成熟的技术团队，技术研发过程已经逐步经过多次迭代，在技术先进性和技术深度上已经完成了阶段性的目标，在成本和支撑的业务场景没有骤变的情况下，大概率不会继续投入，而会逐步将重心调整到整个技术的对外输出上，因此会变成以业务研发过程为主；一般比较成熟的业务团队，业务研发过程逐步完成了对应阶段的业务使命，而继续发展下去生产力就会变成制约业务继续增长的瓶颈，所以除了业务能力建设以外，还会投入更多资源进行技术能力的建设，因此团队主要研发过程会从业务研发过程转变为技术研发过程。
因此一般的研发人员在挑选团队的时候，要结合自己究竟想做业务还是想做技术，然后根据目标团队当前的实际情况来看该团队究竟处于哪个研发过程中，而不是只看团队是否是技术团队或业务团队。非常实际的例子就是，在技术团队中，有大量的研发人员做的都是业务功能的开发，而和技术团队真正的核心技术领域关系并不大；在业务团队中，有一些研发人员做的事情并不是真正的客户业务需求，而是在做相关领域的技术深度建设。所以在转岗的时候，不要看团队的类型是什么，而是要看团队当前处于哪种研发过程中。
2.2 从技术的发展规律来看，如何选择广度或是深度
目前来看，技术已经出现了很多大领域的划分，从单纯的编程语言到基于编程语言构建的技术栈，再到大数据、算法这类专业技术域，再到各个场景业务领域的基础技术如电商、广告、社交等，并且随着整个技术体系的发展，越来越多的细分领域的投入也在逐步饱和，整个技术栈的深度和广度都已经到了单个研发个体无法完全掌握的程度。所以对于很多初级技术人员首先面临的问题就是：我该怎么选我的成长路径。
究竟是先深度还是先广度，一般情况下，我们都是讲先把基础打好，这是前提，也是未来深度究竟能多深、广度究竟可以多广的决定性因素。那么基础究竟打到什么程度？我个人的感觉和实践是：一定要在某个技术领域达到专家的程度，然后再去考虑究竟是横向扩充广度，还是纵向发展深度。这些是个人内在的要求。
另外一个方面就是，技术人员所在的团队类型也和发展模式有关，如果是业务研发团队，技术的广度是必然的要求；如果是技术研发团队，那么技术的深度也是必然的要求。这些是外界环境的要求。
在回答究竟是深度优先还是广度优先的时候，要结合个人内在的驱动力和外在团队的要求，眼光放长远去选择即可。
2.3 从技术的发展规律来看，如何在做业务的过程中有突破
做业务的时候，绝大多数人都是在不停地处理业务需求，并且往往陷入恶性循环：需求越做越多，越做越急，却最终越做越慢。本质原因是把业务发展和技术发展作为二元对立的过程来看的，做业务需求的时候就认为要赶快做完，PD、运营没有给留出做技术的时间所以就不做了；而在有时间做技术的时候却又一心想把各种高大上的东西用起来，满足个人的技术成长欲望、消除自己在技术上积累缓慢的焦虑。但是事实上，做业务开发和做个人技术成长是一个统一的过程。首先就是要求技术一号位能够分析清楚业务发展的趋势，提前在架构层面完成对应的前瞻性的设计，然后就是借着做业务需求的机会来做架构落地。不要觉得这是理想主义纸上谈兵，这是可以实操的，并且可以练习实践的。它究竟是不是纸上谈兵在于你个人，而不在于这个理论和方法。
我在自己的小团队内的要求就是，每次迭代技术规划落地和业务需求要3-7开，假如一个迭代十个需求，其中三个一定是技术长线规划的需求。简单来说就是技术和产品需求严格遵守一个原则，首先“你打你的，我打我的”，其次“你的就是我的，我的最终也是你的”，这就是把业务需求研发和技术研发有机地统一在一起的模式。本质上就是业务规划和技术规划双线并行，两条腿走路，同时技术规划为业务长期发展打基础，借助业务需求来阶段性落地长期的技术规划，从而最终业务需要更先进的技术能力的时候，技术已经做好了相关的准备。
所以说，想在做业务的过程中有突破，第一件事情就是要在认知上改变过去业务需求和技术发展对立的错误观念，要在思想上把做业务需求和做技术统一起来，而不是对立起来。道理很简单，难在你有没有去实践，而下面就是具体的实践方式。
当我们掌握了业务研发中的技术发展的规律的时候，就能提前知道每个业务阶段整体的对技术的要求是什么，就能完成提前的布局。单体应用的开发阶段，就将代码以领域驱动设计的方法论为指引划分为不同的领域模块，在做微服务拆分的时候，直接按照业务领域做拆分即可；在启动阶段即在满足“有无”的时候，不再是过去那种无脑地堆代码，而是结合下阶段业务发展周期对架构的要求，对长期架构设计进行最短路径地落地：即我设计好完整的架构以后，启动期需要哪些能力，我就只按照架构设计落地哪些功能，其他没有业务需求用到的部分，一律只保留代码框架不做具体的逻辑实现即可。
同时，当业务已经稳定以后，可以去主动推动业务技术在不同业务上的复用，提前把跨业务复用的部分形成业务中间件对外推广，这部分目前看，是全集团的一个空白区，难度不小，机会也不小。
最后，一定别忘了技术是第一生产力，不仅可以支持业务、保障业务，更应该驱动业务发展（我知道怎么做，并且有实践，会在其他文章里面讲清楚，这里不再细说了），同时，除了围着业务转以外，自己也可以作为孵化器来孵化出技术产品，这些，都是做业务的过程中，利用我们分析掌握的规律来创造“不可能”，创造突破。
2.4 从技术的发展规律来看，如何在做技术的过程中有突破
从技术的发展规律来看，做技术的过程中怎么突破，其实有很多可以讲，但是由于篇幅有限，我们今天只挑最困扰技术人员的一个点来分析——做技术的人最大的困扰，就是我做的东西怎么能让更多的人都愿意用起来。
技术产品本质上是所有研发人员的生产力的代表，而先进的生产力能够给“创造特殊条件，打破规律” 提供可能性，但是最重要的一点就是，要知道生产力的应用是需要付出成本的。生产力可以改造某事物的维度越多、改造某事物的粒度越细，生产力的使用就越复杂、成本越高。想要让自己做的非常先进的技术能够被更多人使用，最短的路径，就是把技术的使用成本降低，这个成本包括学习曲线是否陡峭、资源投入是否太高、产品易用性、技术支持的完备性等等这些维度。所以能看到很多沉淀多年的技术团队在产出技术系统或工具的时候，配套支撑做的非常好，这一点就是为技术产品的推广降低了成本，从而让大范围的使用成为可能性。这个点，就是利用了上面提到的一些规律得出的结论。如果你所在的团队做出了非常棒的技术产品，但是推广使用不佳，那么不用犹豫，从降低它的使用成本入手完全没毛病并且一定能改变现状有所突破。
3 从整个技术的发展规律来看，技术一号位需要具备什么样的能力
从主观上认清日常常见的两种研发过程的辩证关系，从宏观上看清两种研发过程的对立统一面、相互转换的过程、转换过程发生的条件。能够利用该认知，在恰当的时间推动两种过程的转换，从而在宏观上达到外部环境对研发团队的要求。
从主观上认清自己负责的事情需要的是哪种研发过程，针对不同的研发过程阶段进行针对性的梯队建设，避免团队人员配置单一化，导致无法顺利完成整个过程的转变，或无法支撑对应的业务或技术产品的研发。人为造成成员和做的事情的不匹配既影响业务也影响个人成长。当然，凡事要辩证地去看，有意识地培养团队成员去匹配不同的研发过程，需要让对应的人员也有同样的认知，了解不同的转变的价值是什么，变被动为主动。
在实际行动上能够宏观感知技术演进脉络，在某些节点上能够按照发展规律进行对应的布局。
在执行上，能够长期规划和短期需求有机地、辩证地结合起来，不让团队走弯路。
组织的演进规律及应对策略
1 组织符合的一些规律
组织是一群人的统称，在阿里巴巴，这群人是有情有义的，一起做一件有价值有意义的事情。探讨组织，既要从宏观层面研究它的规律，还需要从微观层面研究组成它的人，而在研究人的时候，不是单纯地研究个体差异，而是再从宏观的角度研究群体特征。除了人以外，组织还有它的使命、愿景；有约束组织内人的规章制度，有共同相信的企业文化，还有奖惩机制，最终基于人、业务、规则、文化、奖惩共同构建了组织的运转模式。
同样的，由于受限于本人个人实践经验的局限和理论输入的匮乏，所以讨论的内容需要大家辩证地去看。
1.1 组织的构建和运转符合什么规律
组织的构建和运转，本质上是围绕着组织和事、组织和人的辩证关系展开的。
- 关于组织的生命周期的规律
任何组织都是为了完成某个使命而存在的，即组织的存在是为了完成某件事情，不存在一个不为了做某个事情的组织。
组织的生存周期和其使命的生命周期是一致的。要合理的区分“组织使命”和组织在“某阶段的主要矛盾”，主要矛盾的生命周期和组织的生命周期的关系是辩证的：如果一个组织的存在就是为了解决上级组织的某个阶段的主要矛盾的，那么它很可能会因为主要矛盾的解决而消亡；如果一个组织的存在不是为了上级组织的某个阶段的主要矛盾而存在，而是为了上级组织的使命的一个维度存在的，那么这个组织就不会因为它当前解决的主要矛盾消失而消亡。
对于实际工作中，我们能感知到的大多数的组织部门都是以后者的形态存在的，即：其使命是上级组织的使命的一个维度；而那些为了某个具体的事情临时成立的项目组则是属于第一种类型的组织，这种组织的生命周期注定与其负责的事情的生命周期绑定。当然，所有的事情都需要辩证地去看，如果把项目组的使命定义为完成所有某类型的项目，那么组织的生命周期就脱离了具体的项目的绑定，变成了常见的组织部门。
这一点对于实际工作还有更大的指导意义：组织是培养人才的环境，为了尽可能降低组织变动带来的人才的流失，一个组织应该尽可能地把自己的存在绑定在上级组织的使命的一个维度上，那么只要上级组织的使命没有调整，下面组织的稳定性是能够保证的；对于项目型的团队，也要让自己的使命和具体项目解绑，让项目的完结变成组织的前进基础，而不是消亡的号角，这样不论是哪种组织，内部的人员对于大环境的感知就是稳定的，有安全感的。
越大的组织，其要完成的使命越大，越抽象、内涵越广泛、维度越多；越小的组织，其要完成的使命越小，越具体，内涵越聚焦，维度越单一。团队规模和使命大小是存在辩证关系的。组织和其使命的匹配过程，是一个运动的过程，不是静态的过程：要完成大使命的组织，开始可以很小，随着逐步的发展，组织会扩充到与其使命一致的规模；要完成小使命的组织，开始虽然可能很大，但是随着逐步的匹配过程，组织会逐步缩小到对应的规模，所以很多组织为了维持规模会寻找更大的使命。整个过程是动态的，也是辩证的、发展的。实际上，规模大的团队不一定因为其使命小就被缩小，更大概率会因为其规模大而被赋予更大的使命。在我们实际工作中，所有的组织都期望自己人越多越好，都在拼命的扩招，这是符合一个组织想要生存下去的客观规律的。在顶层设计者的考量过程中，就要充分考虑到这一点，辩证地看待团队规模的问题，拼命招人的团队不一定应该继续招人，人少的团队也不能因为现在做的事情看起来没有收益而约束其规模，真正要确保的是团队规模和其需要完成的使命大小的匹配。
- 关于“组织与事情”的运转相关的规律
组织通过愿景来明确长期的工作方向，愿景是受使命驱动的。愿景是组织在一个阶段内的长期的综合的高维度的指标，是组织在较长时间段内的工作目标，即：在什么时间点上，什么样的指标，达到什么样的值。这个目标往往是战略层面的，是某种布局完成后达到的效果。一般情况下，实际上决策者期望的是某种局势的形成，局势形成后目标自然完成，而不是真的只想要这个指标。
体现愿景的指标往往是多维度的，并且是和使命的维度相匹配的。愿景需要从各个维度去拆解，从而支撑对应维度的使命。维度的拆解和重要性也符合主要矛盾次要矛盾的规律，也符合事物演进的规律，维度的重要性会随着时间和环境的变化而变化。
任意规模的组织，都是有其愿景的，愿景的生命周期应该和使命的大小匹配；规模越大的团队，其使命越大，愿景的时间不要设定太短，要体现愿景的长期性，要认识到除非掌握了跨代的生产力，否则不可能短期即能完成大的使命；而规模越小的团队，其使命越聚焦，愿景的时间不要设定太长，要体现愿景的及时性。
这里需要注意的是，要能区分愿景和目标的区别，愿景是一个阶段内的一系列目标的结果和集合，因此要辩证地理解愿景的设定时间的长短和目标的设定的时间的长短之间的关系。大团队肩负大使命，愿景太短证明战略分析不够宏观，眼光不够长远。目标时间太短则连续性不足，要把短的目标拆解到下级团队，在上级团队的目标上要体现出长期性，要能体现出战略的定力。小团队肩负小使命，愿景太长则证明规模和使命不匹配，战略执行落地灵活性不足。目标时间太长则需要继续拆解来保障执行落地的及时性，从而保障战略的灵活性。
所有组织的行为最终都需要组织成员来执行，现阶段人是组织的组要成员，不排除未来不是。组织的运转机制中，除了宏观的使命愿景，还和微观的组织成员有极大的关系，因此人以及对人的约束和奖惩就是接下来讨论的重点了，但是不能只看到下面要讨论的内容而忽略上面讨论的内容。
1.2 组织的成员符合什么规律
组织内的成员一般都是企业员工，所以我们使用员工一次来简化“组织内的成员”的表述。
- 员工的本质是什么
定义
员工是组成组织的基本个体，以某种形式构成和其他人协作的模式，以该模式为基础进行组织使命的履行。员工以完成分配的工作来产生价值，并以此取得回报。
性质
员工同时有“组织性”和“个人性”。员工在组织内部扮演某些角色，这些角色带来的核心利益诉求会影响他的日常工作行为和决策偏好向有利于完成角色赋予的使命，则我们把这种情况称为员工在组织内的“组织性”。同时员工本人对其个人核心利益诉求的追求，也会影响他的日常行为和决策偏好，因此我们把这种现象称为员工在组织内的“个人性”。即：当员工的行为及决策偏好主要受到组织角色的核心利益诉求驱动时，员工体现出的是组织性；员工的行为及决策偏好主要受个人核心利益诉求驱动时，员工体现出的是“个人性”。一个员工的组织性和个人性是共同存在的，不是割裂的，共同构成了员工日常工作行为和决策偏好的驱动力。
员工与其他员工因为角色的不同而产生的核心利益诉求的冲突，是组织内常见的管理者与普通员工的对立统一关系的由来，也是HR与普通员工的对立统一关系的由来。员工的个人核心利益诉求和组织核心利益诉求的冲突，是员工与组织之间对立统一关系的由来。所以，一般情况下，员工与员工的对立统一关系是基于其组织内角色的矛盾的；员工与组织的对立统一关系是基于个人与组织之间的矛盾的。如果对立激化，要知道问题的根源在哪，要能辩证地分析情况，做出合理的缓解对立的举动，而避免在问题没有搞清楚的情况下就采取某种措施。
员工的成长过程的本质（内在分析）
员工在组织内扮演某种角色，并且随着员工或环境的变化，角色会发生变化，员工承担的角色逐渐变多，代表着员工处理的事情的维度变多，并最终在某个时间段完成由量变到质变的变化，由低一级的角色转变为高一级的角色。在讨论这个量变到质变的过程时，我们需要对“同一维度的角色在持续时间上的量变”和“同一纬度的角色向更多维度上的量变”有一个辩证的认知。员工扮演角色的量变到质变的变化过程，是员工成长（晋升）的本质规律。外在的员工在组织内的角色的变化只是员工成长的外在现象，本质是员工成长了，对事物的把控维度变多，对事物可操作的粒度变细。这也是为什么阿里内部讲不同级别的员工做事的演进轨迹是“点-线-面-体-局-势”，这是维度变化的体现，当然也要清晰地认知到，“点-线-面-体-局-势”没有体现出人对事物可操作的粒度变细的过程。
员工的成长，是由认知的升级开始的，以实践为基础的，同时实践会继续影响认知，从而带动新的实践，从而形成了成长的过程。本段内容会在其他文章中展开论述，这里只列出最基本的规律和过程，对于“员工成长到下一个层次”给出一个科学合理的解释，而不再是只谈现象不谈本质的各种“水到渠成”的说法。这些说法都只是在从表象上描述客观现象，而非事物本质的描述和传递，所以为什么这类信息都需要读者有悟性，根本原因在于它们看问题是表面的、片面的，而非深刻的、全面的、理论的。
需要注意的是，对于同一个员工而言，他所扮演的角色与角色之间不是单一互斥存在的，而是叠加在一起对员工产生影响的。
- 员工在组织内存在的形式
宏观层面
员工是构成组织的最小单位，单个员工在组织内以某种角色进行日常的工作，与其他若干员工以某种形式构成小的组织，小的组织与其他若干小的组织构成更大的组织，如此循环往复最终形成了完整的组织形态，这是以自底向上的认知过程看到的，这也是大多数人的认知视角。而从自顶向下的认知过程来看，我们就可以发现组织结构和组织使命的辩证关系以及两者之间相互影响的过程，可以看到组织结构与组织使命的维度和拆解粒度是匹配的。维度代表了一个事物的多面性，粒度代表了一个事物的可拆解性。
所以在一个大组织下的不同组织之间，组织角色对应使命涉及的维度，组织层级深度和粒度代表了事物的可拆解粒度。这是组织结构的一般规律，也是和组织使命的辩证关系。我们实际工作中，存在很多和这个一般规律不匹配的现象，最终具体案例具体分析来看，无外乎有两种情况，要么是组织设计不按规律办事，最终肯定会受到规律的反噬；要么是符合了某些特殊条件，触发了特殊规律，这部分我们在探讨一般规律和特殊规律的时候已经讲过了，这里就不展开讨论了。
所以从这个角度来看，当一个组织结构变化频繁的时候，说明组织使命发生变化，是顶层设计者在依据最新的发展规律做出调整，因而组织结构随着组织使命做调整，这其实是组织健康的表现，说明顶层设计者在战略上是勤奋的。当然战略上的勤奋也是一个辩证的事情，太勤奋了说明过去的战略决策思考不足，有很多没考虑到的维度，所以现实情况发生某些事情，倒逼战略不得不在原来的基础上做调整；不太勤奋说明对实际情况响应不够敏捷，对事物所处的环境的变化或者事物本身的变化感知的敏锐度不够，只能等到非预期的变化造成了一定伤害才去做处理。这个辩证关系其实还有更多内涵，比如组织形式的复杂度和战略的决策、执行、调整之间存在的规律以及如何在组织设计上避免这个规律引发的负面问题，受限于个人能力和实践有限，所以这里就不展开讨论了。
微观层面
任何一个子组织，一定是由一个管理者和若干名普通员工构成，从微观层面探讨员工在组织内存在形式的规律时，员工与管理者的对立统一的辩证关系是一个绕不开的话题，不过从目前的实际实践经验来看，管理者对组织结构规律的影响要大于普通员工。所以我们这里把讨论的重点集中在管理者的分析上。可以理解为，在组织微观层面的规律中，管理者是矛盾的主要方面，管理者和员工的对立统一关系是矛盾的次要方面。
管理者的组织性对组织的影响
管理者在组织层面扮演了双重角色，其一是组织业务顶层设计的执行者，承担着完成组织使命的责任，把被分配到的业务做好；其二是组织架构顶层设计的执行者，承担着维系组织架构和运转机制的责任，把组织内的人培养好。所以管理者的业务、组织双重角色是其内部特征，影响着外部的组织结构，同时外部组织结构的规律也会影响管理者，这就是管理者和组织之间的辩证关系和互动的过程的概述。如果一个管理者不能平衡好业务角色和组织角色，就会出现很多问题，这些问题的最直接被影响的群体就是该管理者负责组织内的普通员工。
比如实际工作中有的管理者是顾做事，不顾培养员工，员工从资产变为资源；如果有的管理者只管人事，不管业务，实际上是主次不分，本末倒置，团队无法在业务上有产出，实际上是团队无法履行它自己的使命，那么团队本身的存在也就会被人质疑了
以上是关于技术人生——技术业务组织的一般规律及应对策略的主要内容，如果未能解决你的问题，请参考以下文章