<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>横向领导力 on 方糖猫Blog</title>
    <link>https://ftmao.com/blog/tags/%E6%A8%AA%E5%90%91%E9%A2%86%E5%AF%BC%E5%8A%9B/</link>
    <description>AI 视频、AI Agent 与工程实践笔记</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <lastBuildDate>Thu, 05 Sep 2024 10:00:00 +0800</lastBuildDate><atom:link href="https://ftmao.com/blog/tags/%E6%A8%AA%E5%90%91%E9%A2%86%E5%AF%BC%E5%8A%9B/index.xml" rel="self" type="application/rss+xml" /><item>
      <title>《横向领导力》与重读《矛盾论》《实践论》：没有职权时，怎么推动你认为对的事</title>
      <link>https://ftmao.com/blog/bookstore/lateral-leadership-mao-contradiction-notes/</link>
      <pubDate>Thu, 05 Sep 2024 10:00:00 +0800</pubDate>
      <guid>https://ftmao.com/blog/bookstore/lateral-leadership-mao-contradiction-notes/</guid>
      <description>&lt;h1 id=&#34;横向领导力与重读矛盾论实践论没有职权时怎么推动你认为对的事&#34;&gt;《横向领导力》与重读《矛盾论》《实践论》：没有职权时，怎么推动你认为对的事&lt;/h1&gt;
&lt;blockquote&gt;
&lt;p&gt;参考书籍：罗杰·费希尔、艾伦·夏普《横向领导力》(Getting It Done)；《毛泽东选集》第一卷《实践论》《矛盾论》（重读，只取实操部分）。
目标读者：想往架构师、CTO 方向走的工程师——你会发现越往上走，&lt;strong&gt;越多的决策要靠影响力而不是职权推行&lt;/strong&gt;，尤其跨团队架构治理。
阅读目标：回答两个真问题——&lt;strong&gt;没有职权时怎么推动人（横向领导力）；冲突和路线之争里怎么判断往哪推（矛盾论）&lt;/strong&gt;。前者管组织动员，后者管方向判断。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;这是情商系列的第三篇。第一篇（《情商》+《被讨厌的勇气》）管自己：觉察情绪、划清课题；第二篇（《关键对话》+《非暴力沟通》）管对话：保住安全感、把评判翻译成观察。这一篇管的是前两篇都解决不了的事——&lt;strong&gt;当你判断一件事是对的、但没有职位赋予你推它的权力时，怎么办&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;关于毛选部分要先说一句：2017 年我写过一篇&lt;a href=&#34;../mao-selected-works-programmer-notes/&#34;&gt;《程序员学屠龙术》&lt;/a&gt;，那篇是把《实践论》《矛盾论》当认识论总览读。这次重读换了一个更窄、也更狠的读法：&lt;strong&gt;只把两论当&amp;quot;识别主要矛盾&amp;quot;的裁决工具用&lt;/strong&gt;。团队冲突、技术路线之争、技术债该不该还——本质上都是&amp;quot;当前阶段的主要矛盾是什么&amp;quot;的问题。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;一横向领导力权威不在场时的领导&#34;&gt;一、《横向领导力》:权威不在场时的领导&lt;/h2&gt;
&lt;h3 id=&#34;11-这本书的前提等领导来协调是最贵的协作方式&#34;&gt;1.1 这本书的前提：等领导来协调，是最贵的协作方式&lt;/h3&gt;
&lt;p&gt;费希尔是哈佛谈判项目的老教授（《谈判力》的作者之一），这本书回答的问题非常具体：&lt;strong&gt;在一个你没有汇报关系的场合——跨部门项目、技术委员会、开源社区——怎么让一群人协作起来把事做成。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;书里先破了一个普遍幻觉：&amp;ldquo;我不是领导，所以领导力不是我的事。&amp;ldquo;费希尔的反驳：横向协作场景里根本&lt;strong&gt;没有&lt;/strong&gt;领导，&amp;ldquo;等领导来拍板&amp;quot;这个选项的代价被严重低估了——&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;领导的信息带宽有限，他用三十秒拍的板，质量受制于他掌握的信息量；&lt;/li&gt;
&lt;li&gt;上交决策的同时，也上交了方案的 ownership——&amp;ldquo;老板定的&amp;quot;是执行阶段最好用的免责理由；&lt;/li&gt;
&lt;li&gt;等你有了职权再学领导力，就像等起火再学消防。&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;12-方法骨架先修自己再带别人&#34;&gt;1.2 方法骨架：先修自己，再带别人&lt;/h3&gt;
&lt;p&gt;横向领导力不能直接从&amp;quot;影响他人&amp;quot;开始，书里给了一条严格的次第：&lt;/p&gt;
&lt;div class=&#34;code-block&#34;&gt;
    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;
      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;
    &lt;/button&gt;
    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code class=&#34;language-mermaid&#34; data-lang=&#34;mermaid&#34;&gt;flowchart LR
    A[&amp;#34;第一步: 修好自己&amp;lt;br/&amp;gt;五个个人技能&amp;lt;br/&amp;gt;目标、思考、学习&amp;lt;br/&amp;gt;专注、反馈&amp;#34;] --&amp;gt; B[&amp;#34;第二步: 明确共同目标&amp;lt;br/&amp;gt;把 我的方案&amp;lt;br/&amp;gt;变成 我们的问题&amp;#34;]
    B --&amp;gt; C[&amp;#34;第三步: 影响他人&amp;lt;br/&amp;gt;三招: 提问、作答、示范&amp;#34;]
    C -.-&amp;gt;|&amp;#34;别人不买账时&amp;lt;br/&amp;gt;回来继续修自己&amp;#34;| A
    style A fill:#FFD700&lt;/code&gt;&lt;/pre&gt;
  &lt;/div&gt;&lt;p&gt;五个个人技能里，对工程师最有增量的是&lt;strong&gt;思考&lt;/strong&gt;这一环——书里给了一个四象限思考框架，任何协作僵局都可以往里装：&lt;/p&gt;
&lt;table&gt;
	&lt;thead&gt;
			&lt;tr&gt;
					&lt;th&gt;象限&lt;/th&gt;
					&lt;th&gt;问题&lt;/th&gt;
					&lt;th&gt;工程场景示例&lt;/th&gt;
			&lt;/tr&gt;
	&lt;/thead&gt;
	&lt;tbody&gt;
			&lt;tr&gt;
					&lt;td&gt;数据&lt;/td&gt;
					&lt;td&gt;现状到底是什么？&lt;/td&gt;
					&lt;td&gt;接口规范的执行率到底是多少，别凭感觉&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;诊断&lt;/td&gt;
					&lt;td&gt;为什么会这样？&lt;/td&gt;
					&lt;td&gt;不是大家不配合，是规范没有迁移成本预算&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;方向&lt;/td&gt;
					&lt;td&gt;应该往哪去？&lt;/td&gt;
					&lt;td&gt;先冻结核心域接口，边缘接口允许残留&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;行动&lt;/td&gt;
					&lt;td&gt;下一步谁做什么？&lt;/td&gt;
					&lt;td&gt;本周先在一个组试点，出数据再推广&lt;/td&gt;
			&lt;/tr&gt;
	&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;这个框架的价值在于：&lt;strong&gt;僵局通常是因为各方在不同的象限里喊话&lt;/strong&gt;——有人在讲数据，有人在讲行动，听起来是争论，实际是错频。&lt;/p&gt;
&lt;h3 id=&#34;13-踩坑故事一发通知推规范响应率是零&#34;&gt;1.3 踩坑故事一：发通知推规范，响应率是零&lt;/h3&gt;
&lt;p&gt;第一次做跨团队架构治理时，我的打法是&amp;quot;把事做对&amp;rdquo;：调研两周，写了一份二十页的接口规范文档，评审通过，然后发全员通知：&amp;ldquo;自 X 月 X 日起，新接口按此规范执行。&amp;rdquo;&lt;/p&gt;
&lt;p&gt;一个月后执行率接近于零。&lt;/p&gt;
&lt;p&gt;用四象限复盘：我在自己的脑子里完整走过了数据→诊断→方向→行动，然后&lt;strong&gt;只把最后一环（行动）发给了别人&lt;/strong&gt;。其他团队看到的不是一个共同问题的解法，而是一份从天而降的约束——他们没有经历诊断过程，自然没有这个方案的情感账户和认知账户。&lt;/p&gt;
&lt;p&gt;第二次换成横向领导的打法：先不提方案，用&lt;strong&gt;提问&lt;/strong&gt;开场，一对一问了六个团队的接口人同一个问题：&amp;ldquo;你们现在的接口对接，最疼的点是什么？&amp;quot;——收获超出预期：四个团队提到的痛点就是我的规范要解决的，但&lt;strong&gt;从他们自己嘴里说出来的问题，才是他们的问题&lt;/strong&gt;。规范内容改了不到 20%，执行率反过来了。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;影响力的本质转换：从&amp;quot;我的方案&amp;quot;到&amp;quot;我们的问题&amp;rdquo;。&lt;/strong&gt; 方案可以更好，但问题必须是共同的。&lt;/p&gt;
&lt;h3 id=&#34;14-踩坑故事二等领导拍板等来一个两边都不满意的三十秒&#34;&gt;1.4 踩坑故事二：等领导拍板，等来一个两边都不满意的三十秒&lt;/h3&gt;
&lt;p&gt;两个组对服务拆分边界有分歧，我判断这是&amp;quot;需要更高层信息才能定的事&amp;rdquo;，于是把两个方案写成材料上交，等 CTO 裁决。&lt;/p&gt;
&lt;p&gt;材料在领导队列里躺了两周（他有更要紧的事），终于排到，他用三十秒拍了一个折中方案：边界按组织隶属关系切。两边都不满意——技术上是错的，但谁也没有动力再争，因为&amp;quot;老板定的&amp;rdquo;。&lt;/p&gt;
&lt;p&gt;半年后这条边界成了全系统调用链最深的重灾区。&lt;/p&gt;
&lt;p&gt;费希尔书里有一句话我这次是真读懂了：&lt;strong&gt;横向问题尽量横向解决，上交领导的决策质量受限于领导的信息带宽。&lt;/strong&gt; 领导拍板的价值不在&amp;quot;他更懂&amp;rdquo;，而在&amp;quot;他能让争议终止&amp;quot;——这是兜底机制，不是首选机制。首选机制是把争议双方摁在同一张四象限表前面，把数据象限先填满。大多数技术争议，数据填满之后自己就消解了。&lt;/p&gt;
&lt;h3 id=&#34;15-踩坑故事三复盘文化推不动直到我把自己摆上解剖台&#34;&gt;1.5 踩坑故事三：复盘文化推不动，直到我把自己摆上解剖台&lt;/h3&gt;
&lt;p&gt;我曾想在团队里推&amp;quot;故障复盘不追责&amp;quot;的文化，写了流程文档、开了宣讲会，响应寥寥——大家嘴上说好，真出故障还是甩锅现场。&lt;/p&gt;
&lt;p&gt;转折点是我自己搞砸了一次发布之后。我没有按惯例低调处理，而是写了一份公开的复盘文档，开头就是决策时间线：我在哪个节点掌握什么信息、做了什么错误判断、当时的替代选项是什么。把自己摆上了解剖台。&lt;/p&gt;
&lt;p&gt;效果出乎预料：那次复盘之后，第二个、第三个复盘开始出现，而且质量越来越高。这就是费希尔三招里的第三招——&lt;strong&gt;示范（modeling）&lt;/strong&gt;。提问是让别人思考，作答是给出你的思考，示范是直接做出你希望别人做的行为。三招里示范成本最高、威力最大，因为&lt;strong&gt;人们不怀疑你说的是否正确，他们怀疑的是你自己是否照做&lt;/strong&gt;。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;二重读矛盾论实践论裁决工具化&#34;&gt;二、重读《矛盾论》《实践论》:裁决工具化&lt;/h2&gt;
&lt;h3 id=&#34;21-矛盾论的裁决四步&#34;&gt;2.1 《矛盾论》的裁决四步&lt;/h3&gt;
&lt;p&gt;这次重读，我把《矛盾论》压缩成一个在技术争议现场可以当场跑的分析流程：&lt;/p&gt;
&lt;div class=&#34;code-block&#34;&gt;
    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;
      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;
    &lt;/button&gt;
    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code class=&#34;language-mermaid&#34; data-lang=&#34;mermaid&#34;&gt;flowchart TD
    A[&amp;#34;列出当前所有矛盾&amp;lt;br/&amp;gt;技术 vs 业务、质量 vs 速度&amp;lt;br/&amp;gt;新框架 vs 存量系统&amp;#34;] --&amp;gt; B[&amp;#34;找出主要矛盾&amp;lt;br/&amp;gt;此刻真正限制系统产出的&amp;lt;br/&amp;gt;是哪一个&amp;#34;]
    B --&amp;gt; C[&amp;#34;抓矛盾的主要方面&amp;lt;br/&amp;gt;这对矛盾里&amp;lt;br/&amp;gt;哪一方当前起主导作用&amp;lt;br/&amp;gt;撬动它才能改变局面&amp;#34;]
    C --&amp;gt; D[&amp;#34;标注阶段性&amp;lt;br/&amp;gt;主要矛盾会转化&amp;lt;br/&amp;gt;今天的正确决策&amp;lt;br/&amp;gt;下个阶段可能就是错的&amp;#34;]
    D -.-&amp;gt;|&amp;#34;阶段变化后&amp;lt;br/&amp;gt;重新分析&amp;#34;| A
    style B fill:#FFD700
    style D fill:#FFB6C1&lt;/code&gt;&lt;/pre&gt;
  &lt;/div&gt;&lt;p&gt;每一步对应《矛盾论》的一个核心概念：列矛盾（矛盾的普遍性）、找主要矛盾、抓矛盾的主要方面、标注阶段性（矛盾的发展与转化）。这套东西听起来抽象，落到技术裁决上极其锋利，看下面的故事。&lt;/p&gt;
&lt;h3 id=&#34;22-踩坑故事四技术债之争吵了三次会都没吵对地方&#34;&gt;2.2 踩坑故事四：技术债之争，吵了三次会都没吵对地方&lt;/h3&gt;
&lt;p&gt;团队为&amp;quot;先还技术债还是先赶业务需求&amp;quot;吵了三次会。还债派列代码腐烂清单，业务派列交付承诺，双方论据都很充分，会议每次都卡在平局。&lt;/p&gt;
&lt;p&gt;第三次会后我用矛盾四步重新拆了一遍：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;列矛盾&lt;/strong&gt;：代码质量 vs 交付速度、重构风险 vs 线上稳定、团队技术热情 vs 业务方耐心；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;找主要矛盾&lt;/strong&gt;：当时真正限制产出的是什么？不是代码烂——而是&lt;strong&gt;交付速度已经连续两个迭代不达标，业务方的信任濒临破产&lt;/strong&gt;。信任破产的代价大于一切技术债；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;抓主要方面&lt;/strong&gt;：在&amp;quot;质量 vs 速度&amp;quot;这对矛盾里，当前的主导方面是&lt;strong&gt;债务中直接拖慢交付的那一部分&lt;/strong&gt;——烂代码很多，但只有反复改动、反复出 bug 的三个模块真正在吞噬交付速度；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;阶段性&lt;/strong&gt;：信任修复之后，主要矛盾会转化回代码质量，届时再还其余的债。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;决策随之清晰且可辩护：冻结新需求两周，&lt;strong&gt;只还那三个模块的债&lt;/strong&gt;（这是矛盾的特殊性——不是所有债都值得还，还错地方的还债也是浪费），其余债务登记入册排期。两个月后交付恢复，业务方信任回升，剩余债务在后续迭代按计划清偿。&lt;/p&gt;
&lt;p&gt;这个案例里矛盾论真正教会我的是：&lt;strong&gt;技术裁决不是评判&amp;quot;哪个方案更好&amp;quot;，而是识别&amp;quot;当前阶段的主要矛盾是什么&amp;quot;——方案没有绝对优劣，只有是否对准当前主要矛盾。&lt;/strong&gt; 还债派和业务派都没错，他们只是各自对准了不同阶段的矛盾。&lt;/p&gt;
&lt;h3 id=&#34;23-踩坑故事五框架选型之争主要方面根本不是技术&#34;&gt;2.3 踩坑故事五：框架选型之争，主要方面根本不是技术&lt;/h3&gt;
&lt;p&gt;一次选型评审僵持不下：A 派支持沿用现有框架（稳），B 派支持引入新框架（长期收益大）。双方列的 benchmark、生态对比、社区活跃度，全是技术维度的论据，谁也说服不了谁。&lt;/p&gt;
&lt;p&gt;用&amp;quot;矛盾的主要方面&amp;quot;切进去：这对矛盾的表面是&amp;quot;两个框架的优劣&amp;quot;，但当前起主导作用的方面是什么？我列了下双方的实际约束，答案浮出来——&lt;strong&gt;是团队对新框架的熟悉度&lt;/strong&gt;。B 派的三个人玩过新框架，A 派没有人碰过。学习曲线风险，而不是框架性能，才是这个决策真正的支配变量。&lt;/p&gt;
&lt;p&gt;看清主要方面之后，决策反而容易了：给两周时间，B 派出一个人带 A 派做新框架的概念验证，用团队真实的学习速度数据来定——而不是用网上的 benchmark 来定。两周后数据出来，团队自己动手做完 PoC 的那天，争议其实已经结束了。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;技术争议僵持不下的信号，往往是双方都在论证次要方面。&lt;/strong&gt; 主要方面一旦显形，多数争议会自己消散。&lt;/p&gt;
&lt;h3 id=&#34;24-实践论没有调查就没有发言权&#34;&gt;2.4 《实践论》：没有调查，就没有发言权&lt;/h3&gt;
&lt;p&gt;《实践论》的认识循环，这次重读我把它画成了工程里的决策循环：&lt;/p&gt;
&lt;div class=&#34;code-block&#34;&gt;
    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;
      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;
    &lt;/button&gt;
    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code class=&#34;language-mermaid&#34; data-lang=&#34;mermaid&#34;&gt;flowchart LR
    A[&amp;#34;实践&amp;lt;br/&amp;gt;调研、试点、动手&amp;#34;] --&amp;gt; B[&amp;#34;感性认识&amp;lt;br/&amp;gt;一堆碎片事实&amp;#34;]
    B --&amp;gt; C[&amp;#34;理性认识&amp;lt;br/&amp;gt;抽象出规律和判断&amp;#34;]
    C --&amp;gt; D[&amp;#34;再回到实践&amp;lt;br/&amp;gt;拿判断去做决策&amp;#34;]
    D --&amp;gt;|&amp;#34;结果检验认识&amp;lt;br/&amp;gt;错了就修正&amp;#34;| A
    style C fill:#FFD700&lt;/code&gt;&lt;/pre&gt;
  &lt;/div&gt;&lt;p&gt;两条实操推论：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;**&amp;ldquo;没有调查就没有发言权&amp;rdquo;**放在技术评审里就是：没看过代码、没跑过压测、没找当事人聊过的人，意见权重应当打折。评审会上嗓门最大的意见经常是调查量最小的；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;认识必须在实践里检验&lt;/strong&gt;——所以推规范不要先写完美文档再全面铺开，先在一个组试点，拿数据，修正，再推广。我在第一篇情商笔记里写的人际复盘、第二篇里的会前利益假设，本质都是这个循环的人际版。&lt;/li&gt;
&lt;/ul&gt;
&lt;hr&gt;
&lt;h2 id=&#34;三两本书合流一个管方向一个管动员&#34;&gt;三、两本书合流：一个管方向，一个管动员&lt;/h2&gt;
&lt;table&gt;
	&lt;thead&gt;
			&lt;tr&gt;
					&lt;th&gt;&lt;/th&gt;
					&lt;th&gt;回答的问题&lt;/th&gt;
					&lt;th&gt;核心工具&lt;/th&gt;
			&lt;/tr&gt;
	&lt;/thead&gt;
	&lt;tbody&gt;
			&lt;tr&gt;
					&lt;td&gt;《矛盾论》《实践论》&lt;/td&gt;
					&lt;td&gt;往哪推：当前阶段的主要矛盾是什么&lt;/td&gt;
					&lt;td&gt;矛盾四步、实践认识循环&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;《横向领导力》&lt;/td&gt;
					&lt;td&gt;怎么推：没有职权时如何让人跟你走&lt;/td&gt;
					&lt;td&gt;四象限思考、提问/作答/示范&lt;/td&gt;
			&lt;/tr&gt;
	&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;缺了前者，横向领导力会变成高效的错误——动员能力很强，方向是歪的；缺了后者，矛盾分析会变成孤独的正确——判断很准，但只有你一个人信。&lt;strong&gt;方向判断和组织动员，是&amp;quot;影响力&amp;quot;这件事的两条腿。&lt;/strong&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;四配套练习主动认领一次得罪人的事&#34;&gt;四、配套练习：主动认领一次&amp;quot;得罪人&amp;quot;的事&lt;/h2&gt;
&lt;p&gt;理论读完，这个阶段的实修作业只有一道：&lt;strong&gt;主动认领一个有人反对、但你判断为对的技术决策&lt;/strong&gt;（偿还某块技术债、统一某个接口规范、砍掉某个半成品项目），完整走一遍下面这个剧本：&lt;/p&gt;
&lt;div class=&#34;code-block&#34;&gt;
    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;
      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;
    &lt;/button&gt;
    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code class=&#34;language-mermaid&#34; data-lang=&#34;mermaid&#34;&gt;flowchart LR
    A[&amp;#34;第一步: 私下沟通&amp;lt;br/&amp;gt;裁决前一对一&amp;lt;br/&amp;gt;听懂每个反对者的&amp;lt;br/&amp;gt;真实顾虑&amp;#34;] --&amp;gt; B[&amp;#34;第二步: 争取盟友&amp;lt;br/&amp;gt;让关键人的意见&amp;lt;br/&amp;gt;提前进入方案&amp;#34;]
    B --&amp;gt; C[&amp;#34;第三步: 会上裁决&amp;lt;br/&amp;gt;用矛盾分析陈述理由&amp;lt;br/&amp;gt;明确代价和推翻信号&amp;#34;]
    C --&amp;gt; D[&amp;#34;第四步: 事后安抚反对派&amp;lt;br/&amp;gt;承认损失 不推翻决策&amp;#34;]
    D -.-&amp;gt;|&amp;#34;全程记录&amp;lt;br/&amp;gt;写成一篇人际 ADR&amp;#34;| A&lt;/code&gt;&lt;/pre&gt;
  &lt;/div&gt;&lt;p&gt;每一步的要点，都是前面三篇笔记的工具在实战里汇合：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;私下沟通&lt;/strong&gt;：用的是关键对话的&amp;quot;从心开始&amp;quot;和非暴力沟通的&amp;quot;观察而非评判&amp;quot;。反对者在会上说的话是立场，私下说的才接近利益——故事二里那些&amp;quot;回头再说&amp;quot;，一对一的时候往往有真东西；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;争取盟友&lt;/strong&gt;：就是毛选统一战线的工程版——&lt;strong&gt;裁决前让关键人的意见进入方案&lt;/strong&gt;。方案里有他的一句话，他在会上就是你的盟友；这不是搞政治，是让方案吸纳真实约束；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;会上裁决&lt;/strong&gt;：陈述结构用矛盾四步——当前主要矛盾是什么、为什么这个方案对准它、代价是什么、什么信号出现时该推翻。最后一条最值钱，它告诉反对派：这不是我的面子，这是一个可验证的赌注；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;事后安抚反对派&lt;/strong&gt;：回到《被讨厌的勇气》——安抚是&lt;strong&gt;承认对方承担了损失&lt;/strong&gt;（&amp;ldquo;这个决定让你的组多背了两周工作量，我记着&amp;rdquo;），而不是推翻决策也不是假装没有代价。课题分离：做对决策是我的课题，消化失望是他的课题，但承认损失、记在账上，也是我的课题。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;成不成，这一遍走下来都是教科书级的一课——成了，你收获一套可复用的推动剧本；败了，人际 ADR 里会留下一次完整的归因记录。&lt;/p&gt;
&lt;h2 id=&#34;五我的思考和感悟&#34;&gt;五、我的思考和感悟&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;1. 裁决者挣的不是&amp;quot;判断正确&amp;quot;的钱，是&amp;quot;判断正确之后还能推行&amp;quot;的钱。&lt;/strong&gt; 技术判断力决定你能不能看清主要矛盾，横向领导力决定看清之后局面会不会动。我身边技术判断一流、推行能力为零的人不少，他们的共同遭遇是：正确的意见被无视，然后抱怨组织愚蠢——抱怨组织愚蠢，是用课题上交的方式逃避自己的课题。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;2. 重读毛选最大的变化，是读懂了&amp;quot;阶段性&amp;quot;三个字的分量。&lt;/strong&gt; 2017 年第一次读《矛盾论》，读出来的是热血——抓主要矛盾，大刀阔斧。这次读出来的是沉重——&lt;strong&gt;主要矛盾会转化，意味着今天无比正确的决策，明天可能就是主要障碍&lt;/strong&gt;。两年前我认为绝对正确的技术选型，今天就在还债清单上躺着。这不是当年错了，是阶段变了。裁决者必须习惯一件事：你的每个决策都自带保质期。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;3. &amp;ldquo;没有调查就没有发言权&amp;quot;是对评审文化最狠的一条建议。&lt;/strong&gt; 技术会议里意见的质量分布，和发言者的调查量分布高度相关——但和职级、嗓门、口才几乎无关。把&amp;quot;你调研过吗&amp;quot;变成评审会的合法问题，会议质量会立刻改观。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;4. 争取盟友不是搞政治，但拒绝争取盟友一定是搞砸。&lt;/strong&gt; 工程师对&amp;quot;会前串联&amp;quot;有本能的道德洁癖，觉得方案好就该在会上赢。现实是：会上才第一次听到方案的人，默认反应是防御——这和信息量无关，和安全感有关（第二篇的场）。会前一对一不是阴谋，是给对方消化信息的时间。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;5. 三篇笔记合起来的完整链条&lt;/strong&gt;：先能觉察自己的情绪（第一篇），再能在对话里听懂别人（第二篇），最后能在没有职权的情况下推动局面（第三篇）。&lt;strong&gt;这个顺序不可颠倒——自我管理是影响力的信用基础，听懂他人是方向判断的信息基础。&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id=&#34;六行动清单12-周版&#34;&gt;六、行动清单（12 周版）&lt;/h2&gt;
&lt;table&gt;
	&lt;thead&gt;
			&lt;tr&gt;
					&lt;th&gt;阶段&lt;/th&gt;
					&lt;th&gt;动作&lt;/th&gt;
					&lt;th&gt;检验标准&lt;/th&gt;
			&lt;/tr&gt;
	&lt;/thead&gt;
	&lt;tbody&gt;
			&lt;tr&gt;
					&lt;td&gt;第 1-2 周&lt;/td&gt;
					&lt;td&gt;盘点手头所有僵局，用四象限表各装一遍，找出&amp;quot;错频&amp;quot;的对话&lt;/td&gt;
					&lt;td&gt;至少 2 个僵局定位到象限错频&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;第 3-4 周&lt;/td&gt;
					&lt;td&gt;选一个推动事项，把&amp;quot;我的方案&amp;quot;改写成&amp;quot;我们的问题&amp;rdquo;，找 3 个关键人一对一&lt;/td&gt;
					&lt;td&gt;3 份对方痛点的第一手记录&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;第 5-6 周&lt;/td&gt;
					&lt;td&gt;对当前最大的技术争议跑一次矛盾四步，写出主要矛盾和主要方面&lt;/td&gt;
					&lt;td&gt;一页纸分析，能向中立方讲清楚&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;第 7-10 周&lt;/td&gt;
					&lt;td&gt;认领那件&amp;quot;得罪人&amp;quot;的事，按四步剧本完整走一遍&lt;/td&gt;
					&lt;td&gt;走完私下沟通→争取盟友→会上裁决→事后安抚全流程&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;第 11-12 周&lt;/td&gt;
					&lt;td&gt;把整个过程写成一篇人际 ADR：判断、理由、代价、结果、下次怎么改&lt;/td&gt;
					&lt;td&gt;一篇可复盘的记录，至少 3 条归因&lt;/td&gt;
			&lt;/tr&gt;
	&lt;/tbody&gt;
&lt;/table&gt;
&lt;hr&gt;
&lt;h2 id=&#34;参考与延伸&#34;&gt;参考与延伸&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;罗杰·费希尔、艾伦·夏普《横向领导力》，核心章节：五个个人技能、四象限思考法、影响他人的三招（提问、作答、示范）。&lt;/li&gt;
&lt;li&gt;《毛泽东选集》第一卷《实践论》《矛盾论》。重读建议：别从头读到尾，带着一个正在僵持的真实争议去读，读一段就往里套一次。&lt;/li&gt;
&lt;li&gt;旧文衔接：&lt;a href=&#34;../mao-selected-works-programmer-notes/&#34;&gt;《程序员学屠龙术》&lt;/a&gt;——那篇是两论的认识论总览，本篇是两论的裁决工具化，建议按&amp;quot;总览→工具&amp;quot;的顺序读。&lt;/li&gt;
&lt;li&gt;系列前两篇：《情商》与《被讨厌的勇气》（自我觉察与课题分离）、《关键对话》与《非暴力沟通》（安全感与语言精度）。&lt;/li&gt;
&lt;/ul&gt;
</description>
    </item>
    
  </channel>
</rss>
