简介
「技术人生」专题第1篇：什么是技术一号位？做了研发团队的技术 leader 以后，要处理的事情非常多，如果对自己扮演的角色没有一个清晰的认知，就会出现该做的事情没有做，不该做的事情投入了过多的精力，造成实际行动和结果既不匹配上级的要求，又不匹配下级的期望。特别是对于刚开始带领研发团队的新人 leader 而言，角色的转换和适应的过程，增加了认清自己的角色本质的难度。
任何一个工作角色，都有对应的责任，也都有履行对应责任的方法论。我们要做的，不能再像过往做普通研发的时候那样懵懵懂懂去做事，听“需求”指挥，而是要开始寻找或总结一些方法论，要自顶向下地对业务有一个清晰的认知，知道自己比过去多了哪些维度的事情要关心，知道接下来会面临什么样的挑战，要知道自己在挑战中应该扮演什么样的角色，采用什么样的手段去解决业务在不同阶段一定会出现的各种问题。
宏观导论
「技术人生」第2篇：学会分析事物的本质作为业务的技术负责人，如果不能把握业务需求背后的本质，所有快速上线的临时方案最后都要随着需求的深入而重新投入人力和精力进行重做，这种情况会层出不穷，这方面的成本往往会转嫁在一线研发同学身上。
- 理解本质
- 本质和现象是对立统一关系。任何事物都有本质和现象两个方面。世界上不存在不表现为现象的本质，也没有离开本质而存在的现象。为此，要在实践的基础上观察大量的现象，尽可能多地占有感性材料，这是认知透过现象抓住本质的前提条件。
- 有了观察到的大量现象，占有了真实的感性材料，就必须对大量的现象、真实的感性材料，以及它们之间的关系进行分析和研究，这就需要掌握科学的方法。
- 事物的现象错综复杂，而且事物的本质有一个逐渐暴露，逐渐展开的过程，所以人们对事物本质的认知不是一次完成的，而是一个不断深化的过程，是一个由片面到全面、由不太深刻到深刻的过程。
- 分析方法：面对非常复杂的事情的时候，我们需要能够有合理的理论工具来支撑自己，将复杂的情况主干脉络理清楚，分析它的组成，分析它的主次矛盾，为什么现在会是这样，过去是什么样的，在什么条件下，未来会发展成什么样，预测演化轨迹和事物发展趋势，预测事物在主次矛盾不被干预的情况下的发展趋势，判断趋势是否有利于我们的预期的达成。寻找事物的关键点，判断改变关键点对事物发展趋势的影响，从而通过影响关键部分来引导事物未来的发展方向，利用规律打破规律。
- 事物内在分析：明确事物讨论的范围；分析事物内部组成及其存在形式；分析事物内部各组成成分所扮演的角色及其职责；分析各角色在职责限定下的核心利益诉求；
- 事物与外界相互关联相互影响的分析：明确讨论范围和场景；基于事物各方核心利益诉求，分析各方之间的对立统一关系；基于分析出来的对立统一关系，确定当前阶段主要矛盾次要矛盾；基于当前阶段的主要矛盾次要矛盾，分析矛盾主要方面次要方面
- 事物内在分析：明确事物讨论的范围；分析事物内部组成及其存在形式；分析事物内部各组成成分所扮演的角色及其职责；分析各角色在职责限定下的核心利益诉求；
- 就一般的规律来看，对于任何一个事情而言，如果我们期望统一大于对立，把对立的激烈程度降低，那么整个事务的对立统一情况应该从低水平状态向高水平状态发展，即从可能伤害某一方的核心利益的状态，逐步演变为不损害任一方的核心利益诉求，在此基础上寻找合理的方法和模式，满足各方核心利益诉求。在整个演进过程中，开始是统一的模式或形式会起到决定性作用，但是随着统一的水平逐步变高，模式起到的作用释放殆尽以后，往往就需要从生产力来着手，利用生产力的提升来解决模式无法解决的问题，或者是让模式更精细化，或者是催生出新的模式基于更高生产力的模式，从而继续推动统一朝着更高的水平演变。
- 业务研发，特别是复杂业务系统的研发，实现产品经理提出的业务需求仅仅是其表象，其真正本质内涵，是使用技术手段将解决某一特定问题的逻辑数字化，利用计算机技术对客观事物做数字化的建模，以尽可能贴近事物本质的方式进行逻辑和数据的运转，从而完成现实和虚拟的映射，解决对应的问题。作为研发团队的技术负责人，如果对业务的认知的起点是产品经理输出的产品功能文档，对业务的理解来源于源源不断的业务需求，不能认清业务的本质，不能看到未来的一些可能的发展趋势，那么这样的技术负责人其实只能做到了响应业务的需求，永远无法真正的在技术架构和解决方案上支撑业务的发展，更遑论使用技术驱动业务发展了。这也是“技术一号位” 和 “研发团队 TeamLeader”的最大的区别，前者是业务的共建者。本质上是在扮演决策者的角色，而后者只是研发资源的协调者和项目进度的把控者，本质上是在扮演执行者的角色。
- 流量变现业务概论——Linkedmall 流量变现业务初步分析及系统设计概要
- 事物本质就是内部的主要矛盾次要矛盾的演变过程，同时该演变过程受外界环境其他事物的相互关联和相互影响。在普遍的情况下，一个事物的生命周期，是它的主要矛盾、次要矛盾被解决的过程体现。我们日常生活、工作中遇到问题都是先从主要矛盾入手，解决了主要矛盾、次要矛盾，随着事物发展到新的阶段，新的主次矛盾也会继续出现。当然新的主次矛盾并非凭空出现，而是过去的其他矛盾演变而来，在事物当前生命周期所处阶段，在问题所处的范围内，成为了阻碍事物继续发展的主要矛盾次要矛盾。这就构成了事物的发展过程，事物的发展过程遵守了这一规律。
-
当我们面对复杂事物时，最开始只能感知到当前事物和自己关联最紧密的某个方面，即该事物的某个维度。从这个维度入手，解决最核心的问题，即主要矛盾。随着精力和资源的不断投入，当主要矛盾的主要方面、次要方面被逐步解决，新的主要矛盾出现，事物发展会进入下一阶段。这一点告诉我们，需要深入地而不是表面地看问题。而当事物纵向发展的同时，随着纵向问题的不断解决，横向的新的维度也会逐步成为该复杂事物的主要矛盾次要矛盾，如下图所示，事物在横向发展上被感知和处理的维度变多，人们对事物的认知从单一维度向多维度转变。这个过程告诉我们，需要全面地而不是片面的看问题。要认识到横向、纵向两个过程并不是某个过程先于另外一个过程发生的，更多是同时发生的，最终我们可以从下图看到一个事物经过若干个阶段的发展形成的全貌。这一点告诉我们，需要系统地而不是零散地看问题，同时还要以发展的眼光看问题，而不能静态地看问题。深入地看问题，就是要看到事物发展过程的细节，各维度下的领域的细节，这是微观的视角；全面地看问题，就是要看到更多维度，是宏观的视角；这个过程实际上是从微观到宏观的视角切换的过程。所以解决问题的过程其实就是：问题的解决由主到次，由主干到细节，随着该过程的不断迭代，需要被处理的粒度变细，问题需要被解决的维度变多。正常情况下，所有的问题的解决，都符合这个规律，体现了解决问题的方式的普遍性。
- 根据规律存在领域的不同，可以把规律划分为自然规律、历史规律和思维规律。根据规律发挥作用范围的不同，可以把规律划分为一般规律和特殊规律（部分领域、特殊时期、特殊条件）。如果只是单纯地、抽象地讨论这个一般规律，那么对于我们实际生产生活中解决问题的指导意义太弱，而如果不讨论这个解决问题的最基本的一般规律，那么再讨论更具体的场景时，特殊的规律是如何来的，特殊规律如何被打破，就说不清了。所以二者之间的辩证关系是我们最高效地利用规律的理论基础。一般规律的影响范围大，普遍性高；特殊规律的影响范围小，普遍性低而特殊性高；同时，特殊规律需要更高的生产力，而一般规律则对生产力的要求不高。同时我们需要知道生产力的应用会带来成本，所以一般规律和特殊规律之间的转换也会涉及到成本因素。事物受特殊规律影响还是受一般规律影响是可以相互转换的，而让这种转换发生的关键是对该事物操控的生产力的水平。
- 在我们生产力水平比较低的时候，解决问题要符合事物的发展规律；
- 而在生产力水平比较高的时候，我们可以通过调整事物符合特殊规律的条件从而让事物遵守特殊的规律，或者让事物不再遵守特殊规律而回归一般规律的控制；
- 如果我们想要打破规律让看似不可能的事情发生时，不是仅仅把资源投在事情的本身上，而是同时需要投入在与之相关的生产力的提升上，二者之间的投入比例需要视实际情况做调整。我们需要辩证地理解“看起来不可能”。看起来不可能实质上是发生了“在某人或某些群体认知之外的” 的事情，在具备更高的生产力的群体来看，前者眼里的不可能大概率是稀松平常的事情，举个简单的例子：飞机对于原始部落和现代文明而言，分别是“不可能”和“平常事”，本质上问题不在于飞机，而在于不同群体所掌握的生产力的差异。对于认为“不可能”的群体，让他们打破既有认知规律的最简单的方式就是把更先进的跨代的生产力赋予对方。
- 研究规律的目的，是为了找出问题所符合的规律，然后结合规律发生作用所需要的条件，通过一定的生产力手段来创造该条件，从而利用规律的发展趋势来引导事物的发展从而达到我们期望的目的。在日常工作中，特别是做业务，对于技术一号位而言，如果只能埋头做自己手中的需求，而不了解业务发展的规律，那么就无法在适当的时间投入适当的兵力做适当的事情。这种情况下，技术一号位实际上变成了仅仅带着一个团队做需求的“包工头”，而不是可以协助业务一号位完成推动业务发展重任的技术一号位。技术一号位的职责是什么？其中，在系统架构方面，系统架构的前瞻性、可扩展性的前提就是能够把握业务发展规律而提前做了技术架构上的布局；除此之外，在兵力的投入、战役的发起等组织协同方面也都需要符合业务发展规律。如果不管业务当前阶段的问题和主次矛盾，也不管这个主次矛盾未来会朝什么方向发展，那么最终技术只能被动地响应业务需求，被业务需求推动发展。如果提需求的人把握了业务发展规律还好，一旦提需求的人眼里也只能看到客户抛出来的问题而不是业务发展趋势和规律，那么可想而知技术的投入实质上是在围绕着细枝末节做无用功。而对于那些有能力的技术一号位，做的各种技术决策不仅能支撑业务的发展，保障业务的运行，更重要的是利用生产力的提升，结合业务发展的规律来引导、驱动业务的发展。简而言之，就是通过“预测事物发展规律”，依靠规律来从事物发展中获益。
比如大多数人都能在解决问题的过程中抓住重点去解决，即便这个人并不了解马克思主义哲学，不熟悉矛盾论，这个规律需要的的条件不多，适用范围极广，所以是一般规律。解决问题的特殊规律，和问题的特殊性有关，即和具体的某一类问题有关。接下来我们就针对日常工作中接触到的技术、业务、组织问题来分析它们存在哪些一般规律和特殊规律。我们需要客观辩证地看待探究事物规律的行为，这是从知其然上溯其所以然的过程。
对于业务开发人员而言，最重要的两个事情，就是业务和技术，而对于技术一号位而言，还需要增加一个组织维度，因为在企业内任何一件事情都有对应的组织来支撑的，或者任意一个团队，都有其自身要解决的问题的。我们单纯地抛开组织来谈技术或业务问题的解决规律，就天然地会缺少一个非常重要的维度。
领域分析
「技术人生」第4篇：技术、业务、组织的一般规律及应对策略如果我们把“解决问题”分为三个步骤：“1. 弄清问题本质是什么 —— 2. 给出解决方案 —— 3. 决策使用哪种方案解决问题”，那么价值观只能在第三个阶段发挥作用，即决策者在已经搞清楚复杂问题的本质之后，面对多个解决方案时，价值观会让他选择某种符合其认同的价值观的方案来解决问题。问题的分析和拆解必须交给科学的方法论，而决策才要交给价值观。不能拿价值观来作为分析问题、解决问题的方法论，而是要清晰地认知到它的能力边界。否则就会出现看似符合价值观但是错的一塌糊涂的决策。
做业务的时候，绝大多数人都是在不停地处理业务需求，并且往往陷入恶性循环：需求越做越多，越做越急，却最终越做越慢。本质原因是把业务发展和技术发展作为二元对立的过程来看的，做业务需求的时候就认为要赶快做完，PD、运营没有给留出做技术的时间所以就不做了；而在有时间做技术的时候却又一心想把各种高大上的东西用起来，满足个人的技术成长欲望、消除自己在技术上积累缓慢的焦虑。但是事实上，做业务开发和做个人技术成长是一个统一的过程。首先就是要求技术一号位能够分析清楚业务发展的趋势，提前在架构层面完成对应的前瞻性的设计，然后就是借着做业务需求的机会来做架构落地。不要觉得这是理想主义纸上谈兵，这是可以实操的，并且可以练习实践的。它究竟是不是纸上谈兵在于你个人，而不在于这个理论和方法。我在自己的小团队内的要求就是，每次迭代技术规划落地和业务需求要3-7开，假如一个迭代十个需求，其中三个一定是技术长线规划的需求。
生产力可以改造某事物的维度越多、改造某事物的粒度越细，生产力的使用就越复杂、成本越高。如果你所在的团队做出了非常棒的技术产品，但是推广使用不佳，那么不用犹豫，从降低它的使用成本入手完全没毛病并且一定能改变现状有所突破。
技术人生第5篇——浅谈如何成为技术一号位？“环境变了你没变，或者你变了环境没变”，都需要分析环境对自己的要求是什么，要判断现有的认知驱动的行为是否能匹配这种要求；如果不能匹配，那么要分析什么样的行为可以匹配新的要求。没有悟性的同学，会任由这种不匹配继续造成无法忽视的问题以后，再去“无意识”地解决；悟性高一些的人，会通过之前的经验，在问题处于一个可以被明显感知但是尚未到达影响无法忽视的阶段即可化解。不过凭借经验并不是一个稳定可靠的办法，因为总有很多事情是没有事先经历过的，在没有经验的支撑下，还是会出现和没有悟性的同学一样的问题；悟性最高的同学，会通过现象看到本质，总结出相关的方法论，在事情来临的时候使用方法论分析问题，判断事情发展的趋势，仿佛可以站在更高的视角和维度，去旁观整个过程发生了什么，怎么避免再次发生，怎么降低这种问题的影响或者直接避免这种问题的发生。
- 一方面，人的某一类需求，在共性足够大的情况下，会形成市场，诞生了需求方；同时在另外一方面，人通过创造价值（劳动）满足别人的需求，诞生了服务提供方。最开始的简单的物-物交换的形式，逐步演变到现在“通过有组织地生产价值，有组织地保障价值交付过程、大量地使用更先进的技术提升生成经营效率”等等这样复杂的形式。简而言之，服务提供方是以“业务”的形式满足需求方的需求的，或者说，企业是以业务的形式服务于市场的。一些人通过有组织的劳动，满足另外一些人的需求，从而获取回报，并能够持续运转下去的整个过程，可以统称为业务。客户：个人或一类人，以市场的形态出现；企业：个人或一群人，常以组织的形态出现；价值载体：满足需求方需求的事物，常以广义的商品的形态出现。
- 从实践出发认知一个事物，通过接触、参与、感知得到的信息，都是具体的事物的个性的方面，但是这样的认知过程效率比较低；而从理论出发认知一个事物，通过思考归纳、演绎、客观理论的分析得到的信息，都是抽象的事物的共性的方面，这样的认知过程效率比较高，但是容易和实际有偏差，需要通过实践进行验证、修正。
- 过去做业务，从简单的供需双方的利益诉求的对立统一，变成了多方的利益诉求的对立统一过程，越复杂的业务模式，要平衡的参与方就越多，遇到的阻力和困难就越大，也越难以形成高层次的统一局面。知道这个信息有什么用呢？一方面是让现在所有的业务决策者要形成清晰地认知：以目前的社会化大生产的大背景，做业务最终是在做业务生态环境，这个环境需要被治理、需要通过合理的准入和清退汰换保障机制形成良性的运转机制。另外一方面，从哲学的角度回答了为什么有些复杂的业务“不好做”，从而让我们认清复杂业务不好做的基本面的情况下，来思考平衡各方利益诉求的时候，最基本的原则是什么，这是最重要的。
- 组成业务的几个环节
- 为什么面对一定会变的业务需求，研发人员似乎永远跟不上需求变化的节奏？很多时候大家本能的会怪罪产品经理没有想清楚，那么有没有人思考过，和我们每天配合的产品经理或者运营人员，究竟是什么东西没想清楚，从而导致了我们研发同学自己不断地返工？他们没想清楚的事情，我们是不是从来就没想过？这些事情，我们该不该想，能不能想清楚，有没有好处？研发人员需要掌握什么技能来应对永远都在变化的业务需求？作为系统架构师，在面对复杂业务系统时，开局往往操作猛如虎，三年规划五年演进，可是经过若干年的建设，往往只是遗留下众多见招拆招的祖传代码，新的需求需要在旧的业务逻辑的缝隙里面找“解法”，一线开发人员不仅要避开“牵一发动全身”的各种弯弯绕绕，可能连架构本身也已经变得模糊不清了，更不用提架构的演进。可是当年说好的架构可扩展性呢，说好的抽象程度高呢？？架构本身究竟和业务有什么关系，架构的演进又和业务的发展有什么关系，如何才能让架构师打破“架构设计和演进过程被现实反复打脸”的魔咒？
- 所有的事情，所有的问题，想要被解决，都要回到最初的原点：这件事情的本质是什么？也就是说，我们日常工作中的事情的起点不是使用什么工具解决问题，而是先认清这件事情 —— 认清一件事情的本质，是所有后续行动的前提和基础。它是战略层面构建业务大图的基础，是排兵布阵发起关键战役的基础；也是战术层面分析业务需求的基础，做架构设计的基础，做业务领域建模的基础。技术一号位需要掌握的所有工具和方法论，所有的起点都是它，所有的理论工具和方法论最终都是它在某个领域内的应用、投射和简化。PS： 很多研发人员往往把注意力集中在各种计算机语言及其技术栈上，大家会花时间翻看各种技术书籍，探究各种技术方案背后的原理，然后通过业务实践提升个人技术能力，所有的促进个人成长的事情几乎都是围绕着“技术”两个字展开。
- 事物的本质与现象是对立统一的，这是客观辩证法，把这种辩证法运用于人的认知过程，就要求人们既不能脱离现象去空谈事物的本质，也不能停留在事物的现象上，而要透过现象抓住事物的本质。要在实践的基础上观察大量的现象，尽可能多地占有感性材料，这是认知透过现象抓住本质的前提条件。有了观察到的大量现象，占有了真实的感性材料，并不等于抓住了事物的本质，要透过现象抓住本质，就必须对大量的现象、真实的感性材料，以及它们之间的关系进行分析和研究，这就需要掌握科学的方法。
- 业务研发，特别是复杂业务系统的研发，实现产品经理提出的业务需求仅仅是其表象，其真正本质内涵，是使用技术手段将解决某一特定问题的逻辑数字化，利用计算机技术对客观事物做数字化的建模，以尽可能贴近事物本质的方式进行逻辑和数据的运转，从而完成现实和虚拟的映射，解决对应的问题。作为业务的技术负责人，如果不能把握业务需求背后的本质，类似这种情况会层出不穷（产品拍脑袋想到一个方案，上线后给这个方案填坑），所有快速上线的临时方案最后都要随着需求的深入而重新投入人力和精力进行重做，这方面的成本往往会转嫁在一线研发同学身上。
- 我们面对非常复杂的事物的时候，为什么要费很大的力气去分析它的组成，分析它的主次矛盾？就是为了能够在非常复杂的局面下看清它未来可能的走向，从而提前做好一些准备，甚至主动做一些事情，从而让事情按照我们的预期来发展。在整个演进过程中，开始是统一的模式或形式会起到决定性作用，但是随着统一的水平逐步变高，模式起到的作用释放殆尽以后，往往就需要从生产力来着手，利用生产力的提升来解决模式无法解决的问题，或者是让模式更精细化，或者是催生出新的模式基于更高生产力的模式，从而继续推动统一朝着更高的水平演变。
PS：设计架构就好比开发商设计房子，户型设计留的余地大（架构），室内设计师（开发）才有大的余地满足各种各样的客户需求，否则，室内设计师可能要经常“砸墙”以满足客户需求。