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