当 Andrew Harmel-Law 邀请演讲者参加 QCon 伦敦大会时，他首先想到的是：“让 Diana 和 Cat 一起登台！”这完全是出于一种顽皮的冲动。
Cat Morris 是一位产品经理。Diana Montalion 是一位系统架构师。我们都专门从事软件系统和平台开发。我们都把对方视为我们所有痛苦的根源。不是个人层面的，我们从未一起工作过，但我们都认为对方所代表的角色是问题所在。
但我们也致力于改善我们的工作方式。如果我们能够消除我们之间存在的摩擦……那对每个人来说都是一件好事，对吧？
首先，我们对参与的每一个重大项目做了建模分析。我们发现，每一个项目的结局都像泰坦尼克号一样：撞上了冰山。
我们发现了以下这些改变职业生涯的真相：
我们的工作有很多重合的地方。
我们需要彼此。合作会带来更好的结果。我们思考问题的方式不同但互补。
我们要解决的不是技术问题。技术挑战不难解决。困难之处在于消除摩擦。
摩擦是阻碍变革的无形暗流。摩擦并非孤立存在的，而是一个系统性问题，其来源是人、团队与技术之间的关系。解决之道不在于 Kubernetes、云计算或人工智能，而在于改变我们的思维模式、沟通方式和组织架构。
本文描述了在每一个项目中都会反复出现的六种摩擦：
反直觉行为
拒绝改变
效率与控制
产品与技术角色之间相互指责
线性管道思维
交付能力不足
每一种摩擦都让我们忙于重写相同的代码库或重绘相同的组织结构图。摩擦导致很多无益于我们避开冰山的工作浪费。这篇文章将帮助你弄清楚如何应对这些问题。
反直觉行为
我们怪错了对象。因此，我们做错了事情。
反直觉行为，由系统科学家 Jay Forrester 定义，是指复杂的社会和管理系统倾向于用让问题变得更糟糕的解决方案来应对问题。例如，为一个处于后期的项目增派更多的工程师，加快项目进度。
面对系统性挑战时，我们人类会倾向于指责他人。遗憾的是，我们怪错了对象。我们责怪工程团队工作效率低下，或者断定是因为团队太小，却未能意识到甘特图不过是虚构的简化模型，它过度简化了复杂的动态过程。
“任何系统的输出结果都是其内在设计的必然产物。”——W. Edwards Deming
当我们改变一个系统的运作方式时，我们也需要改变塑造系统的底层模式、结构和心智模型。例如，不是在本已臃肿的数据库上放上 GraphQL 就能称之为图，而是需要重新构建我们思考数据的方式。我们需要创建异步事件，而不是把什么都塞进管道，我们需要创建反馈循环，让我们能及时知道数据在跨系统移动时出现了异常。
这可以解释为什么工程师们会工作到很晚。他们一边忙着给猪涂口红，一边又要完成甘特图上没有预料到的工作。
解决之道：理解系统
反直觉行为具有引力，会将我们吸入其中，卷入漩涡。至少，我们的感受是这样：感觉像是在行动，在前进，而实际情况是，我们就像烘干机里的衣物，在原地打转。自始至终，我们都是从同一个狭小的视角凝视问题。
解决方法是暂时停下来，找准方向再行动。
首先是确定核心领域。系统的目标是什么？对于联邦快递来说，是快速递送包裹。很可能，你所经历的反直觉行为，源于人们的说法一致但前进方向不同。
每个参与的人都清楚变革与核心领域的关系吗？怎么才能加快包裹递送而不产生负面影响？系统本身如何导致了问题的产生？当前的流程和模式会产生什么样的心态？系统中的关系如何强化了这些模式？有什么你没有看到的变革需求吗？开始绘制这些模式，确定你的核心领域，所需的变革自然便会显现。
拒绝改变
每个试图变革的组织都有这样一些人：守门人、地牢主、自封的 10 倍速工程师，他们对组织非常了解，并且拥有一个魔法词：不。
他们说，“我们已经尝试过迁移。我们已经尝试过平台迁移或重构。我们已经尝试过重组。都行不通。别费心了。”他们掌握着生产环境或管道或某个关键系统的控制权，你没法忽视他们。
对此，人们很容易把责任归咎于那人的固执性格。但他展现的行为模式，正是长期的奖励与强化所形成的。通过管理遗留系统的复杂性，他已成为不可或缺的存在。要改变他，必须改变整个组织的思维方式，否则，又会冒出另一个类似的角色取而代之。仅靠技术手段无法从根本上解决问题。
拒绝改变是会传染的。当那个人关闭了好奇心，其他人也会转向固定思维模式。人们首先做的是怀疑而不是实验。组织无法在规避风险和尝试新事物之间找到平衡。变革陷入了停滞。
“变革之所以困难，是因为人们高估了他们所拥有的东西的价值，低估了他们放弃这些东西可能获得的价值。” ——《会飞的水牛：卓越腾飞，学会让员工引领》（Belasco 和 Stayer，1999 年）
解决之道：解雇那个人
好吧，这可能有点极端。你可能无法解雇他们，但你可以限制他们的影响。你不是他们的导师、母亲或心理医生。不要陷入那种角色。
把他们装进盒子里。给他们一个静态领域，让他们可以保留自己的脚本和遗留代码，而你去改变系统的其余部分。用“是”的力量去平衡他们“不”的力量。
是的，这并不意味着认同所有观点。这意味着探索可能性。将对话引向可以向前推进的方向。找到愿意做出改变的人，并帮助他们解决自己的问题，而不是等待守门人为他们开锁。
效率与控制
效率带来安全感。控制带来责任感。二者结合，便形成了现代组织中最诱人的反模式：效率与控制。
当它们占据主导地位时，我们关注的焦点便会缩小到产出：发布特性、关闭工单、满足截止日期。工作以速度来衡量，而不是价值。组织最小化互动和反思，坚信速度等于进步。
但在复杂的系统中，只讲效率会使系统变得脆弱。你按时交付了错误的东西。你得到了与蓝图相匹配的结果，但忽略了变化的环境。你得到了短期的解决方案，而那最终会成为未来的障碍。
我们制定了一个有预算有时间表的路线图，而唯一的上下文是一堆令人困惑的架构。
要求我们增加控制，但又理不清头绪。效率不过是掩盖混乱的遮羞布。其结果是一场组织作秀：Jira 工单、自信满满的时间表，以及追踪一切却唯独忽略意义的指标。
截止日期不可更改。功能已锁定。缺的是什么呢？一个明确的目标和协同一致的成果，同时又留有空间，允许在学习过程中进行调整。包裹配送时间没有改善，客户体验也未见提升。
解决之道：设计知识流
让团队注重效能而非过度追求效率。如何确保时间、精力和注意力都用在塑造真正重要的成果上？用协同取代控制：建立能让正确信息在正确时间传递给正确人员的工作机制，让信息跨越边界自由流动，无需高管做微观管理。
思考你目前正在开展的项目。你是在度量产出还是成果？截止日期是反映了现实还是一厢情愿的想法？如何改善信息流，而不是构建一个工厂式的交付过程？做工作与交付价值不是一回事；改善知识流能让你更快地获得价值。
产品 vs. 技术
Andrew 让我们聚在一起，因为我们有类似的挫败感。我们都面临着用 Kubernetes 解决系统性问题的压力。当然，我们做不到。我们也因为反直觉行为，养成了互相指责对方角色的习惯。
工程团队不喜欢产品经理给他们施加压力，要求他们在一个紧迫的时间表内完成特性交付。他们不明白，他们正在做的改变怎么能提高代码质量。基础设施、架构和 DevSecOps 人员则抱怨说，他们需要的改进从未被优先考虑。
产品团队不喜欢工程师表现出的抵触和消极态度。他们不明白，为什么一些简单的事情需要那么长时间来构建。他们抱怨说，过度工程化浪费了大量的会议时间，而那些时间本来可以用在寻找前进的方法上。
在许多组织中，产品和工程是相互隔离的孤岛。双方对效率与控制的定义截然不同，成了两股相互对立的势力。产品部门只需将需求抛过隔离墙，便坐等可运行的代码返回；而工程部门则被要求加快编码速度，无暇顾及系统设计。
即使这两个角色坐在一起，他们相互冲突的方法和控制欲也会加剧摩擦。
解决之道：向学习驱动型转变
Carol Dweck 博士描述了两种心态：固定型和成长型。
固定型心态认为，擅长某事就意味着那件事应该很容易做到。如果某事很难，则说明你缺乏天赋。在这种模式下，人们会回避挑战，将反馈视为批评，将他人的成功视为威胁。其结果是团队很脆弱，他们要保护自己的地盘，而不是一起学习。
成长型心态认为，能力可以通过实践、反馈和坚持来提升。你不能只是做 Netflix 所做的事。在这种模式下，人们欢迎挑战，将努力视为精通之道，将挫折当作改进的数据基础。其结果是个人和团队都更有韧性，他们会适应而不是抵触。
当每个人，无论什么角色，都采用成长型思维时，他们就会一起学习。同理心是一项关键能力。它不同于单纯的同情，而是从多个角度理解情境的能力——对用户和代码的影响；产品团队与技术团队之间的流程和协作模式所导致的顽固问题。
为了共同做出有影响力的决策，我们需要成长型思维，借鉴他人的经验来丰富我们的世界观，并引导自己获得更深刻的洞察力。
线性管道思维
还记得过去软件中某个地方有 Bug 的日子吗？修复一行代码就能解决问题。现在，在微服务和分布式系统构成的复杂世界中，Bug 通常存在于各部分之间的关联关系中。系统架构的艺术和科学在于设计和编排。
每天，我们都会经历摩擦，因为我们在一个异步世界中交付线性管道。或许我们称其为平台，但真正的平台是精心设计的不同技术与流程之间的关联体系。它们能用不同的方式响应不同时间发生的各类事件。平台的各部分相互协同，达成单个组件无法独立实现的成果。这种现象被称为涌现（emergence）。
面向涌现的设计需要综合多方视角，理解如何调整整个系统以实现包裹快速配送，而又不破坏异步关系。
综合意味着不能单打独斗。你需要其他人贡献他们的专业知识，并将这些专业知识与你的知识整合在一起。当我们无法构建能整合组织知识与经验的实践体系时……我们就无法设计（或调试）平台。于是我们交付了一条管道，而所有人都将它的缺陷归咎于不充分。
解决之道：构建关系
与其用线性思维处理异步情境，不如退一步思考以下问题：
在你的系统中，关系如何产生效果？
系统各部分之间如何通过关系实现它们不直接做的事情？
信息如何在技术系统中流动？
痛点和瓶颈在哪里，以及如何优化关系以消除这些阻碍？
如果你的组织不支持这项工作，就组建一个秘密小组。无论身处何种角色，都要将多元视角融入建议的更改方案中。确保信息在人员之间顺畅流动，从而实现服务之间的无缝衔接。
当具有不同观点的团队（如架构师 Diana 和产品经理 Cat）共同构建这些模式时，一切都会变得更加轻松。与其他团队交流，观察用户使用系统的过程，向基础设施团队了解他们的痛点，并将这些洞察融入解决方案之中。
交付能力不足
我们以为我们专注于目标，而实际上我们是在专注于需求。目标是一个可衡量的成果，比如，提高包裹递送速度。如果我们提高了系统的能力，我们就实现了目标，而不是简单地添加另外一项功能。
对于内部平台团队而言，一个可能的例子是：团队被告知需将软件部署管道从 Jenkins 迁移至 CircleCI。这明确告知了操作步骤，却未说明迁移背后的原因。
这里的隐藏目标是将开发者的管道维护工作量减少百分之五十。没有这些信息，团队可能会迁移了软件交付管道却没有达到预期的结果。他们也可能有一些想法，不需要昂贵的管道迁移就能实现目标。
部署变更的能力早就已经存在。在这种情况下，交付流程会频繁出现各种断层。对于如何部署变更，每个人都有不同的想法。如果关注点是改变工具，那么这些想法将导致无尽的摩擦。
解决之道：专注于目标
制定有意义的目标，并整合实现目标的各种方案。描述需要交付的具体且可衡量的效益或成果。确保目标紧密契合核心领域，即加速包裹配送。系统的所有功能都应该服务于这个目标。每次部署变更时，我们（期望）都在提升系统履行职责的能力。聚焦目标能确保每位贡献者都理解自身工作的价值。
去尝试
现在，你可能感到不知所措。“我做不到这一切！我的工作已经很忙了！”这是真的。
幸运的是，你不需要全都做。选一件事来做就行。一个可以减少摩擦的小变革，可以是你最感兴趣的事情，也可以是给你的日常生活造成最大摩擦的事情。
系统就是这样工作的……小变革可以扩展为大改进。摩擦在细节中，解决之道也在细节中。
原文链接：
