作者：贺科学

技术一号位不是岗位，更多的是技术人员在公司中做事的一种心态，这个系列的文章适合所有想要对日常工作“知其然更知其所以然”的技术人，借助理论工具的指引，结合自己的实践经历，悟到自己的收获，从而加速成长的过程。大道理千千万万，有缘者得之真谛践于其行而非流于其表。

未来一段时间，阿里巴巴中间件公众号会持续发布系列文章，欢迎关注。

往期技术一号位方法论系列文章：

「技术人生」专题第1篇：什么是技术一号位？

背景

生活中每时每刻都在发生着各种各样的事情，有些与己相关，有些看似毫无瓜葛，不论事情大小，总需要分出一部分精力，或多或少，对事情进行处理解决。在处理这些事情的过程中，在和某些人接触时，总能感觉到他们对事物的认知要更深刻，更全面，听其言如同醍醐灌顶，观其行胜读十年书。这样的人解决问题往往一针见血，事半功倍；而在和另外一些人沟通时，则可能会感到对方对某个事情的认知其实流于表面，解决问题往往抓不住重点，做的很辛苦却多是无用功。那么究竟是什么造成了两种人对事物认知的差异？是否有什么途径或者方式能够消除这种差异？

作为技术研发人员，总面临着各种各样的需求，总会有前人不断强调技术的复用，强调代码的重构，可是往往是倒排的截止日期逼迫研发更快上线临时需求，造成线上拣不干净的满地鸡毛，同时留下一身还不完的技术债务。为什么面对一定会变的业务需求，研发人员似乎永远跟不上需求变化的节奏？很多时候大家本能的会怪罪产品经理没有想清楚，那么有没有人思考过，和我们每天配合的产品经理或者运营人员，究竟是什么东西没想清楚，从而导致了我们研发同学自己不断地返工？他们没想清楚的事情，我们是不是从来就没想过？这些事情，我们该不该想，能不能想清楚，有没有好处？研发人员需要掌握什么技能来应对永远都在变化的业务需求？

作为系统架构师，在面对复杂业务系统时，开局往往操作猛如虎，三年规划五年演进，可是经过若干年的建设，往往只是遗留下众多见招拆招的祖传代码，新的需求需要在旧的业务逻辑的缝隙里面找“解法”，一线开发人员不仅要避开“牵一发动全身”的各种弯弯绕绕，可能连架构本身也已经变得模糊不清了，更不用提架构的演进。这一切都会逐步失控下去直到某一天达到临界点再来一次推翻式的重构，让混乱重新回到原点，开始新一轮的技术债务周期，当然，系统一定是 2.0 或者 3.0 了（目前还没见过 4.0 的系统）。可是当年说好的架构可扩展性呢，说好的抽象程度高呢？架构本身究竟和业务有什么关系，架构的演进又和业务的发展有什么关系，如何才能让架构师打破“架构设计和演进过程被现实反复打脸”的魔咒？

作为研发团队 leader，带着自己的人做需求交付，一边忍住亲自下场写代码的冲动不得不做着项目管理的事情，一边又可能被下面的人怀疑技术能力；各种倒排的截止日期仿佛一条条排着队催债的红线，眼看着这些红线圈着自己团队的黑着眼圈的兄弟，在一个又一个的坑里面像炮灰一样摸爬滚打，而自己只能像一个大号的外包资源经理一样对这种局面在实际行动上束手无策，在思想上除了觉得要不断加人之外感觉无力回天。如何才能让团队成员在做业务的过程中不再是资源一样被消耗而是像资产一样自我增值？如何才能利用对业务发展趋势的预测打破规律提前布局，在战略上掌握主动性，从而在战役上既能先于对手做出稳定的产品，又能有足够的时间打磨产品从而提升用户的使用体验？

不同角色的技术人，不论在工作还是在生活中，面临的这一系列老生常谈的问题时，或许都希望能有一抹就灵的万金油，打一发银弹出去，就能够留下广为业内传唱的人月神话。可是在现有的生产力条件下，技术人员既没有万金油，更不存在银弹，而且人月神话永远都是神话。所有的事情，所有的问题，想要被解决，都要回到最初的原点：这件事情的本质是什么？也就是说，我们日常工作中的事情的起点不是使用什么工具解决问题，而是先认清这件事情 —— 认清一件事情的本质，是所有后续行动的前提和基础。做业务需求分析也好，做架构设计画架构图也罢，计算机语言和技术栈的选择以及相关整体解决方案的构建是一方面，而“基于对业务本质的理解进行的业务建模并结合业务发展持续演进”是极其重要的、却往往被忽视的另外一个方面。

日常工作中，很多研发人员往往把注意力集中在各种计算机语言及其技术栈上，大家会花时间翻看各种技术书籍，探究各种技术方案背后的原理，然后通过业务实践提升个人技术能力，所有的促进个人成长的事情几乎都是围绕着“技术”两个字展开，但是，特别是对于常年从事业务研发的同学而言，大家是否意识到，除了“技术”以外，还需要掌握“业务”相关的知识，而其中，探究事物的本质，是最基础最核心最先需要被掌握的技能，没有之一。它是战略层面构建业务大图的基础，是排兵布阵发起关键战役的基础；也是战术层面分析业务需求的基础，做架构设计的基础，做业务领域建模的基础。技术一号位需要掌握的所有工具和方法论，所有的起点都是它，所有的理论工具和方法论最终都是它在某个领域内的应用、投射和简化。

什么是事物的本质

事物本质的哲学定义

抽象地探讨事物的本质，涉及到了哲学层面，目前本人不具备相关的能力来进行详细的理论论证，这里就直接摘抄马克思主义哲学关于事物本质和现象的对立统一的论述，来看哲学层面的事物的本质是什么：

• 本质是事物的根本性质，是事物自身组成要素之间相对稳定的内在联系。—— 《马克思主义哲学原理》（第五版，陈先达、杨耕著）

• 本质是事物的根本性质，是事物自身组成要素之间相对稳定的内在联系，是由事物本身所具有的特殊矛盾构成的。—— 百度百科

• 唯物辩证法的宇宙观主张从事物的内部、从一事物对他事物的关系去研究事物的发展，即把事物的发展看做是事物内部的必然的自己的运动，而每一事物的运动都和它的周围其它事物互相联系着和互相影响着。事物发展的根本原因，不是在事物的外部而是在事物的内部，在于事物内部的矛盾性。任何事物内部都有这种矛盾性，因此引起了事物的运动和发展。事物内部的这种矛盾性是事物发展的根本原因，事物和事物的互相联系和互相影响则是事物发展的第二位的原因。—— 《矛盾论》毛泽东

• 研究问题，忌带主观性、片面性和表面性。所谓主观性，就是不知道客观地看问题，也就是不知道用唯物的观点去看问题。这一点，我在《实践论》一文中已经说过了。所谓片面性，就是不知道全面地看问题。—— 《矛盾论》毛泽东

事物本质与现象的对立统一分析

1、本质和现象是对立统一关系。任何事物都有本质和现象两个方面。世界上不存在不表现为现象的本质，也没有离开本质而存在的现象。本质和现象是统一的，但二者又有差别和矛盾。本质从整体上规定事物的性质及其基本发展方向，现象从各个不同侧面表现本质；本质由事物内部矛盾构成，是比较单一、稳定、深刻的东西，靠思维才能把握；现象是丰富、多变、表面的东西，用感官即能感知。假象从否定方面表现事物的本质，给人一种与事物完全相反的印象，掩盖着本质。假象的存在明显表现出本质和现象的矛盾。因此不能简单地把现象与本质等同起来。—— 百度百科

2、事物的本质与现象是对立统一的，这是客观辩证法，把这种辩证法运用于人的认知过程，就要求人们既不能脱离现象去空谈事物的本质，也不能停留在事物的现象上，而要透过现象抓住事物的本质。（本文作者批注：透过现象看本质，这句话谁都懂，但是究竟怎么才能做到，是本文尝试给出的。）

为此，要在实践的基础上观察大量的现象，尽可能多地占有感性材料，这是认知透过现象抓住本质的前提条件。（本文作者批注：这就是“没有调查就没有发言权”的理论依据。）在观察社会问题时，一定要学会区分本质与现象，要抓住本质与主流，这是其一。

其二，有了观察到的大量现象，占有了真实的感性材料，并不等于抓住了事物的本质，要透过现象抓住本质，就必须对大量的现象、真实的感性材料，以及它们之间的关系进行分析和研究，这就需要掌握科学的方法。（本文作者批注：《马克思主义哲学原理》中并没有讲明需要掌握的科学的方法究竟是什么，而这一点，恰恰是本文作者结合实际实践经验尝试给出的，同上一个批注。）

其三，事物的现象错综复杂，而且事物的本质有一个逐渐暴露，逐渐展开的过程，所以人们对事物本质的认知不是一次完成的，而是一个不断深化的过程，是一个由片面到全面、由不太深刻到深刻的过程。—— 《马克思主义哲学原理》（第五版，陈先达、杨耕著）

了解了哲学层面的本质与现象的对立统一关系，有的读者可能会问，这和业务研发有什么关系？我这里只举一个看起来非常小但是实际上问题很大的例子：我们所做的新零售业务，整个流程涵盖了供应商、平台、渠道客户、合作伙伴和消费者这些不同的业务参与方，整个业务可以让供应商入驻平台，给平台上的渠道客户供货，从而让渠道客户自己的用户能够以积分或者积分加现金的方式购买商品。

某天产品经理提了一个需求，说要“在供应商控制台中增加一个删除按钮，删掉供应商不想看到的商品”。看似非常简单的一个需求，在商品列表里面增加一个删除按钮，应该很快就能上线，但是实际上，删除商品这个动作背后真正的业务含义和场景并不是简单的技术上的把商品数据软删除，而是“停止供货”——供应商要删除的商品很大概率已经签过在线协议，以某个价格供货给某个渠道客户，这个时候研发人员如果按照需求无脑删除商品数据，就会造成已经在售卖甚至在参加运营活动的商品突然无法购买，造成渠道客户的损失或引发舆情。

所以，研发人员沟通完需求要进行技术方案评审时，被我驳回，要求相关的同学完成业务场景的分析和讨论，补全删除按钮背后的完整业务流程，将“删除”按钮的名称修改为“停止供货”按钮，并且针对已经不在任何渠道销售的商品单独提供筛选项，而不再在供应商商品管理列表里面默认展示。所以整个需求原本就是一个删除按钮 1 天的工作量，实际上分析清楚产品需求背后的业务场景和真正的业务含义以后，就变成了一个涉及到了停止供货的在线审批流程、供货协议更新、渠道在售商品下架等等一系列联动的复杂业务需求，技术方案的复杂度和原来相比更复杂，排期更长。

作为业务的技术负责人，如果不能把握业务需求背后的本质，类似这种情况会层出不穷，所有快速上线的临时方案最后都要随着需求的深入而重新投入人力和精力进行重做，这方面的成本往往会转嫁在一线研发同学身上。

探究事物本质的方法

抽象的哲学定义并不能给我们提供透过现象看本质的实际操作方法，但是却指明了事物本质的组成和关键点。我们可以基于哲学上的定义和《矛盾论》全文以及本文中特别引用内容可知，如果想要分析清楚一个事情的本质，就是要客观地去分析事物，梳理它内在的主要矛盾和次要矛盾，同时需要梳理外在的它和它所处环境内其他事物的相互联系和相互影响。

内在要分析研究目标事物的组成部分和对应的对立统一关系，从而得出对应的主要矛盾次要矛盾，理清矛盾的主要方面和次要方面。需要注意的是，相关的分析是建立在事物的某一维度上，在事物发展的某一阶段上的，随着事物的发展，相关的分析可能会出现变化。事物的内在决定了事物的本质。如下图所示：

外在要分析在一定环境下，研究目标事物和其他事物之间的相互关联关系和相互影响。事物的外在通过事物的内在关系和影响来影响事物的发展。这一点可以简单思考一个问题：一把普通的锤子可以打破一面普通的玻璃，根本原因在锤子还是在玻璃？如果觉得根本原因在锤子的读者，可以继续思考：一把普通的锤子可以打破钢化玻璃么，可以打破防弹玻璃么，可以打破钢铁么？如下图所示：

通过以上的示意图和对应的分析说明，我们可以了解到在分析问题本质的过程中的所有关键因素，关于详细操作步骤和说明指引，在本文第四章节会给出模板，方便大家在实际工作生活中使用。

分析事物本质对技术一号位的必要性

业务研发，特别是复杂业务系统的研发，实现产品经理提出的业务需求仅仅是其表象，其真正本质内涵，是使用技术手段将解决某一特定问题的逻辑数字化，利用计算机技术对客观事物做数字化的建模，以尽可能贴近事物本质的方式进行逻辑和数据的运转，从而完成现实和虚拟的映射，解决对应的问题。

作为研发团队的技术负责人，如果对业务的认知的起点是产品经理输出的产品功能文档，对业务的理解来源于源源不断的业务需求，不能认清业务的本质，不能看到未来的一些可能的发展趋势，那么这样的技术负责人其实只能做到了响应业务的需求，永远无法真正的在技术架构和解决方案上支撑业务的发展，更遑论使用技术驱动业务发展了。

这也是“技术一号位” 和 “研发团队 TeamLeader”的最大的区别，前者是业务的共建者，利用技术背景和专业技能辅助业务一号位推进业务的发展，本质上是在扮演决策者的角色，而后者只是研发资源的协调者和项目进度的把控者，本质上是在扮演执行者的角色。

面对非常复杂的事情的时候，我们需要能够有合理的理论工具来支撑自己，将复杂的情况主干脉络理清楚，然后分析它为什么现在会是这样，过去是什么样的，在什么条件下，未来会发展成什么样，然后再分析哪些关键部分是我们可以通过实际行动影响的，从而通过影响关键部分来引导事物未来的发展方向。

以下内容就是面对复杂问题的时候，基本的分析操作流程。

分析事物本质的操作步骤

事物内在分析

1、明确事物讨论的范围

明确问题讨论的范围非常重要，同一件事情，在不同的范围内讨论，得出的结论可能完全相反，原因并不是我们使用的理论工具有问题，而是随着讨论范围的扩大，讨论的事物本身的组成和外界的相互联系和相互影响都会变化，所以就会有不同的，甚至是相反的结论出来。所以为了解决某个固定的问题，我们首先要确定的就是这个问题的范围是什么，它所处的环境是什么，讨论的问题的场景是什么。这些是展开所有的分析的基础，如果多人讨论的情况下，不把这部分内容对齐，就会非常容易导致讨论的时候各方论点风马牛不相及。

2、分析事物内部组成及其存在形式

在明确好事物的范围以后，我们需要分析清楚这个事情中的各个组成部分，每个组成部分是以什么样的形式存在的。

3、分析事物内部各组成成分所扮演的角色及其职责

事物的每个部分，在这个事物中，都扮演了某种角色，这个角色是某个部分的职责和行为的抽象，所有的行为都体现着该部分的核心利益诉求。

4、分析各角色在职责限定下的核心利益诉求

在分析完事务内部各组成的角色以后，接下来就是分析该事物内部组成在对应角色的要求下的核心利益诉求了。需要注意的是，在讨论核心利益诉求的时候，需要结合场景，明确讨论范围，否则所很多事物最终的核心利益诉求都会被过渡抽象化，但是很多时候一个问题是一个具体的、有范围的利益诉求展开的。只泛化地讨论经过抽象后的利益诉求，既不方便分析矛盾点，又不能具体的解决实际问题，所以在讨论对立统一的时候，明确核心利益诉求要限定范围和场景，不能一味只做抽象，只去看矛盾的普遍性而不看矛盾的特殊性。

事物组成 1

• 核心利益诉求

讲清楚该事物组成 1 的核心利益诉求是什么

• 核心利益诉求的由来分析

讲清楚该事物 1 的核心利益诉求为什么是这样的

事物组成 2

• 核心利益诉求

讲清楚该事物组成 2 的核心利益诉求是什么

• 核心利益诉求的由来分析

讲清楚该事物 2 的核心利益诉求为什么是这样的

事物与外界相互关联相互影响的分析

以毛泽东的《矛盾论》中的理论为依据，我们要想分析清楚事物的本质，还需要分析清楚它和外界其他事物的关系，因此我们会针对这部分内容作简要分析。

事物所处的大环境是什么

从影响事物本身的多个维度去分别梳理，从而能够建立起来一个多维度的大环境的画像。

事物所处的大环境内的关键事件是什么

分析每个维度发生的关键事件，这些事件可能和事物内部有各种关系。

事物所处的大环境内的关键事件对事物内的影响是什么

分析每个关键事件对事物内部的影响是什么。

事物所处的大环境未来可能有哪些变化

简单预测大环境中每个关键事件未来可能演变的走向，从而分析未来可能对事物本身的影响。

事物内部对立统一分析

明确讨论范围和场景

再次明确讨论事物内部对立统一的范围。

基于事物各方核心利益诉求，分析各方之间的对立统一关系

基于之前分析的事物各方的核心利益诉求，进行两两分析，分析每 2 个组成事物时间的对立统一关系，在必要的时候，可以继续分析三方、四方的对立统一关系。我们需要明确的是，所有的对立统一都是在围绕着核心利益诉求展开的，核心利益诉求的满足有低级的方式，也有高级的方式，如果各方的核心利益诉求是通过低级的方式满足的，那么说明各方的“统一”处于低水平的状态；如果各方的核心利益诉求是通过高级的方式满足的，那么说明各方的“统一”处于高水平的状态。

基于分析出来的对立统一关系，确定当前阶段主要矛盾次要矛盾

基于已经分析清楚的对立统一关系，明确当前事物现阶段的主要矛盾次要矛盾。

基于当前阶段的主要矛盾次要矛盾，分析矛盾主要方面次要方面

明确主要矛盾和次要矛盾以后，就要看下，矛盾主要方面是什么，次要方面是什么，分别给出解决办法即可。并且确定矛盾主要方面以后，就要优先解决矛盾主要方面，而不是哪个简单先解决哪个，或者最起码要讲清楚在主要矛盾方面做了哪些事情来缓解，否则就会给人造成一种感觉：解决问题隔靴搔痒，不切中重点。

1、矛盾的主要方面的分析和解法

2、矛盾的次要方面的分析和解法

事物发展规律的预测和干预

我们面对非常复杂的事物的时候，为什么要费很大的力气去分析它的组成，分析它的主次矛盾？就是为了能够在非常复杂的局面下看清它未来可能的走向，从而提前做好一些准备，甚至主动做一些事情，从而让事情按照我们的预期来发展。

1、基于当前主次矛盾的分析，分析主次矛盾的解决办法

分析解决办法，确定如何解决主要矛盾，次要矛盾。在解决主要矛盾和次要矛盾的时候，要遵守至少一个非常明确的原则：当前事物的主要矛盾和次要矛盾需要遵循其所在环境的主要矛盾和次要矛盾的演变规律。

2、预测演化轨迹和事物发展趋势，寻找可以影响事物发展趋势的关键点，利用规律打破规律

就一般的规律来看，对于任何一个事情而言，如果我们期望统一大于对立，把对立的激烈程度降低，那么整个事务的对立统一情况应该从低水平状态向高水平状态发展，即从可能伤害某一方的核心利益的状态，逐步演变为不损害任一方的核心利益诉求，在此基础上寻找合理的方法和模式，满足各方核心利益诉求。在整个演进过程中，开始是统一的模式或形式会起到决定性作用，但是随着统一的水平逐步变高，模式起到的作用释放殆尽以后，往往就需要从生产力来着手，利用生产力的提升来解决模式无法解决的问题，或者是让模式更精细化，或者是催生出新的模式基于更高生产力的模式，从而继续推动统一朝着更高的水平演变。

就我们日常具体的事情来看，主要做到以下几点进行分析即可：

• 预测事物在主次矛盾不被干预的情况下的发展趋势，判断趋势是否有利于我们的预期的达成。

• 寻找事物的关键点，判断改变关键点对事物发展趋势的影响，从而让事情向我们期望的方向演变。

分析事物本质的案例分享

以下内容，是本人利用该方式进行复杂业务的分析的案例。

1、在没有做任何调研，只依靠 “流量变现” 几个字，结合自己做的电商业务，进行脱离实际业务的单纯的理论分析，这个分析主要的作用就是让毫无任何业务背景和经验的我，能够在理论上看到业务和技术演进的大脉络，从而为后续的调研、架构设计和最终的系统落地提供整体方向性的支撑。为什么要这样做，因为未来很可能接手的业务是毫无经验的，如何能够把业务做好，这是基础之一。

2、在做了大量的调研的基础上，继续按照该方式分析流量变现中的某一个业务参与者他的核心利益诉求，并根据核心利益诉求进行关键业务指标的拆解，从而在业务开展过程中以此指标及其拆解后的指标指引业务的发展。