“我认为这本高度实用且可以立即应用的书，就像是我们最强大、最有效的敏捷工具的失落说明书，而这个工具我们甚至没有意识到自己拥有：对话(Conversations)。如果你想在敏捷中取得成功，RTFM：阅读这本精彩的手册。”
—Alberto Savoia，Google首任工程总监，《The Right It》作者
“《敏捷对话》为如何进行关键讨论提供了急需的指导，这些讨论是建立强大而有韧性的工作关系的基础，同时还提供了一个工具箱，里面装满了当对话出现问题时进行故障排除的技术。这本书充满了实用的真实案例，对于任何曾经对工作中的互动感到沮丧或困惑的人来说，都是必读之作。”
—Elisabeth Hendrickson，技术高管，《Explore It!》作者
“许多书籍都在讨论如何改进公司的流程和产品。我很高兴这本书终于解决了人的方面：学会提出困难的问题，抛开你的偏见，通过这本实用指南改善你自己的沟通。如果某件事很难，就更要多做！”
—Patrick Debois，DevOpsDays创始人，《The DevOps Handbook》联合作者
“这本书提供了一种工程师的方法来监控、故障排除和调试对话……像问题分数(Question Fraction)这样的启发式方法(Heuristics)非常棒——既简单又令人难忘，同时又极具洞察力。阅读这本书，将你的沟通技能转化为超能力。”
—Gojko Adžić，作家，Neuri Consulting合伙人
“对于任何担任领导角色或有兴趣改善工作文化的人来说，这是必读之作。”
—Andy Skipper，CTO Craft首席教练
“如果你正在寻找一个实用的框架和技术来帮助修复破碎的团队沟通和功能失调的文化，那么你应该阅读《敏捷对话》。超越简单的诊断，这本手册将引导你完成五个对话(Five Conversations)，你需要接受这些对话才能将破碎的文化转变为健康和高绩效的文化。”
—Paul Joyce，Geckoboard创始人兼首席执行官
“Squirrel和Jeffrey敏锐的写作和经过实战检验的技术，使这本书成为现代工程领导者的必读之作，他们希望在我们都面临的复杂性爆炸中取得成功。”
—Chris Clearfield，《Meltdown: What Plane Crashes, Oil Spills, and Dumb Business Decisions Can Teach Us About How to Succeed at Work and at Home》联合作者
“这是一本非常明智但又易读的书。作者抓住了要害，将更好的对话作为将理论转化为组织改进的方式。”
—Rich Koppel，TIM Group联合创始人兼首席执行官
“这是行业内一个不可告人的小秘密：我们大多数的’技术’问题实际上是人的问题。在《敏捷对话》中，Jeffrey和Squirrel断言，通过更好的对话可以解决这些问题，并以一种技术同行会觉得令人放心的结构化和分类的方式呈现他们的建议。”
—Jon Topper，The Scale Factory创始人兼首席执行官
“改变公司文化需要信念和技能。《敏捷对话》提供了路线图，帮助你鼓起勇气，避免成功路上的危险！对于任何想要建立协作、合作型组织的CEO来说，这是一部杰作！”
—Brent Delehey，转型专家，首席执行官
“这本书是一本非常有用的实用指南，教你如何解读自己字里行间的意思，并让其他人安全地揭示他们字里行间的恐惧。”
—Rebecca Williams，QA Chef软件工程师
25 NW 23rd Pl, Suite 6314 Portland, OR 97210
版权所有 © 2020 Douglas Squirrel 和 Jeffrey Fredrick
保留所有权利。有关复制本书选段的许可信息，请联系 Permissions, IT Revolution Press, LLC, 25 NW 23rd Pl, Suite 6314, Portland, OR 97210
第一版
美国印刷
25 24 23 22 21 20 1 2 3 4 5 6 7 8 9 10
封面和书籍设计：Devon Smith
美国国会图书馆出版物编目数据
名称：Squirrel, Douglas，作者。| Fredrick, Jeffrey，作者。
标题：敏捷对话：转变你的对话，转变你的文化 / Douglas Squirrel 和 Jeffrey Fredrick 著。
描述：第一版。| 波特兰，俄勒冈州：IT Revolution，[2020] | 包含参考书目。
标识符：LCCN 2019045822（印刷版）| LCCN 2019045823（电子书）| ISBN 9781942788973（平装）| ISBN 9781942788669（epub）| ISBN 9781942788676（kindle版）| ISBN 9781942788683（pdf）
主题：LCSH：管理沟通。| 工作场所团队。| 信息技术管理。
分类：LCC HD30.3 .S698 2020（印刷版）| LCC HD30.3（电子书）| DDC 658.4/5—dc23
LC记录可查阅：https://lccn.loc.gov/2019045822
LC电子书记录可查阅：https://lccn.loc.gov/2019045823
ISBN: 978-1942788973
电子书ISBN: 978-1942788669
Kindle ISBN: 978-1942788676
Web PDF ISBN: 978-1942788683
有关批量采购的特别折扣信息或预订作者活动的信息，请访问我们的网站 ITRevolution.com。
为保护隐私，示例对话和故事中的姓名已更改。
如何组织本书
阅读本书的多种方式
第一部分
侧边栏：Cynefin框架
侧边栏：对话的类型
Nell的信任故事
Nell的信任故事（续）
Tara的恐惧故事
Tara的恐惧故事（续）
Bobby的为什么故事
Bobby的为什么故事（续）
Mandy的承诺故事
侧边栏：倾斜滑块
Mandy的承诺故事（续）
侧边栏：中世纪的问责制
Nicole的问责故事
Nicole的问责故事（续）
结论：如何持续学习
对话评分：实用指南
延伸阅读和资源
参考文献
注释
致谢
关于作者
第一章 图1.1：Cynefin框架
第二章 表2.1：认知偏差示例
表2.2：模型I与模型II行动理论对比
图2.1：不同沟通模式的有效性
图2.2：四个R
图2.3：Norbert的注释对话
第三章 图3.1：推理阶梯
第四章 表4.1：偏差常态化示例
表4.2：打破一致性实践
图4.1：恐惧图表
第五章 表5.1：立场与可能的利益
表5.2：产品洞察
第六章 图6.1：倾斜滑块
第七章 表7.1：X理论与Y理论
图7.1：Bungay的三个差距
作为公司的领导者，你全力支持转型，组织也已经认同。你请来了咨询顾问，他们培训了团队，流程也已就位。唯一缺少的就是承诺的结果。为什么情况没有好转？
作为贡献者——工程师、产品负责人、Scrum Master、系统管理员、技术负责人、测试人员或任何其他”实干者”——你接受了培训，编写了工单，参加了会议。你已经认同并准备看到改进。唯一缺少的就是承诺的结果。为什么情况没有好转？
经过多年研究和多次失误，我们认识到成功的关键不仅在于采用实践，还在于进行困难的对话，这些对话能够培育适合这些实践发挥作用的环境。你、你的管理者和你的团队缺少正确的关系，而这只能通过正确的对话来建立。好消息是，你可以开始一场对话转型，为你想要做的任何其他改进奠定基础，改变你的对话，改善你的关系，最终获得结果。
我们见证过这一切的发生。我们两人总共为一百多家组织提供过咨询，涉及各种主题和所有层级。令我们惊讶的是，无论我们与CEO交谈还是与最初级的开发人员交谈，无论是跨国银行的董事总经理还是在线零售商的运维工程师，无论是产品负责人还是项目经理，设计师还是开发人员，我们都会听到：“为什么他不能做得更好？为什么她不改变？我无法强迫他们。我无能为力。”
员工对自己无法改变现状的挫败和绝望存在于所有层级，几乎存在于我们合作过的所有组织中——我们感同身受，因为我们自己也会陷入这种模式。
所以，我们一直以来都非常高兴能够提供一个替代方案：基于透明度和好奇心的对话所具有的巨大力量。
我们经常且可靠地看到，当个人、团队和整个组织解锁了他们的对话超能力时，他们能够摆脱困境并开始看到比他们认为可能的更快的改进：一家儿童图书出版商让艺术家和营销人员进行对话，并利用创意灵感实现了成功的销售；一家AI初创公司让每个人都参与制定战略，用户满意度得到了显著提高；一家金融服务公司通过对其失败进行艰难的讨论稳定了其系统。
当你了解到对话不仅仅是说话，而是一种需要技巧的活动时，就会获得出色的结果。对话中不仅包含你能看到和听到的内容，还包括未说出口的东西——我们说出和未说出的话语背后的想法和感受。
当我们在对话中变得更加熟练时，我们会更加意识到我们想什么和感受什么，以及我们为什么会这样想和感受。因此，我们在与他人分享这些信息时会变得更好。我们也会更加意识到我们没有心灵感应——我们实际上并不知道我们的对话伙伴拥有什么信息——所以我们会更善于提问和倾听答案。这些技能是如此基础，却又如此被忽视，以至于当我们在这些方面变得更好时，我们的对话会变得更有成效，我们的文化会变得更加协作。
市面上不乏告诉你如何诊断文化问题的书籍，它们提供详细的案例研究和故事、诊断测试、大量要遵循的实践、协作的劝告以及要使用的工具。但很少有书籍对如何真正治愈这些问题——如何做出改变以及当你陷入困境时该怎么做——说出任何有意义的内容。
例如，Patrick Lencioni的《团队协作的五大障碍：领导力寓言》详细描述了虚构公司DecisionTech的衰落和崛起。通过这个企业寓言，Lencioni发展了一个功能失调层次理论：对结果的忽视源于逃避责任，而逃避责任又根植于缺乏承诺，以此类推，包括害怕冲突和缺乏信任。Lencioni的功能失调模型很有帮助，它启发了我们的五种对话中的四种（你将在本书后面了解到）。但关键的是，Lencioni几乎没有提供一旦发现功能失调如何消除它的实用建议。
为了建立信任，他说，你可以做五件事中的一件：分享你的个人历史、讨论团队成员最重要的优点和缺点、提供反馈、进行人格类型分析或参加绳索课程。虽然这些可能会让你的团队更加友好或亲密，但Lencioni没有提供任何证据或论证表明它们实际上会建立信任，他也没有提供任何替代方案，以便在这些方法失败时建立信任。
Lencioni并不是唯一以这种方式让读者失望的人。商业寓言、数字化转型指南、敏捷手册——所有这些都告诉你你的文化有什么问题，但没有告诉你如何解决它。结果，我们看到一家又一家公司实施了所有正确的实践，但未能看到结果，因为他们没有修复他们的文化粘合剂，而这正是使其他实践发挥作用所必需的。
本书和我们对话方法的使用将教会你和你的团队不仅诊断你的文化问题，而且实际治愈它们。我们一次又一次地看到，以透明度和好奇心的态度进行艰难的对话确实有助于团队建立持久的信任、减少恐惧并做出其他关键改进；而且很容易解释这种方法如何以及为什么有效，这就是我们在本书中要做的。
如果你有兴趣，你可以发展技能，让你能够接受创造团队蓬勃发展环境的痛苦而坦诚的沟通。在任何时候，发展这些技能都不会容易。用我们的朋友Mark Coleman的话来说，它将在每个阶段都要求你进行”艰难的、情感上的工作”。你将不得不面对自己对痛苦话题的恐惧——而且不止一次，与其承担又一次具有挑战性的讨论，你会希望你可以只是请一位顾问，或者完善你的燃尽图，或者添加一些监控。但我们可以向你保证，没有什么比在一个成员掌握了所有五种对话、并且对卓越的永无止境的追求成为习惯和乐趣的组织中工作更有回报的了。
我们期待你加入我们，学习、发展和实施让你达到目标的对话技能。
继续对话， Jeffrey和Squirrel
我们将本书分为两部分：第一部分描述了支撑我们将在第二部分介绍的对话工具的想法和理论。
第1章是一段软件历史。如果你想直接了解技术，可以跳过这一章；但如果你对敏捷、精益和DevOps的起源感到好奇，这一章适合你。我们将审视在过去二十五年中改变了软件行业的巨大变化，回顾我们所经历的，包括进步和沿途的失误。
在1990年代，大规模制造范式为”软件工厂”提供了智识模型。正如工厂工人被期望成为可互换的单元，被束缚在装配线上，软件专业人员也被期望成为可互换的单元，遵循文档驱动软件开发方法的指令。当这个模型在实践中被证明存在灾难性缺陷时，它为一系列以人为中心的方法论的兴起创造了空间，以及席卷软件组织的变革浪潮，如敏捷(Agile)、精益(Lean)和DevOps。
具有讽刺意味的是，尽管这些变革被广泛实施，但它们往往忽略了以人为中心的核心，对流程和实践的官僚主义关注使组织陷入缺乏文化的仪式中。为了进步，组织需要利用对话这一独特的人类力量，通过学习进行困难但富有成效的对话来克服他们的认知偏见(cognitive biases)。
第2章提供了我们方法的核心技术:四个R(Four Rs)提供了帮助我们从对话中学习的步骤,两列对话分析法(Two-Column Conversational Analysis)为我们提供了贯穿全书用于记录对话的格式和从中学习的方法。我们建议在继续阅读之前,至少阅读关于这些技术的两个部分和”分析对话”部分。
我们通过展示你已经知道需要去哪里来开始本章。跟随杰出的社会科学家克里斯·阿吉里斯(Chris Argyris),我们将向你展示,你的”表述理论”(espoused theory)已经表明,最佳决策需要所有参与者的协作、透明度和好奇心。不幸的是,你的”使用中的理论”(theory in use),即你在对话中的实际行为,却完全不同。我们将向你展示一种称为”四个R”的方法,这是一套技术,允许任何人和任何团队提高他们在对话中处理困难话题的技能,这将帮助你从对话中学习并为接下来的内容做准备。
在第二部分,第3章到第7章,我们将我们的经验、学习成果和错误提炼成五个对话(Five Conversations)的”使用手册”:关于所有高绩效团队共享的五个关键特征的关键讨论——不仅仅是软件团队,而是所有人类团队。
五个对话是:
信任对话(Trust Conversation): 我们相信与我们共事的人,无论是团队内部还是外部,都分享我们的目标和价值观。
恐惧对话(Fear Conversation): 我们公开讨论团队及其环境中的问题,并勇敢地攻克这些障碍。
为什么对话(Why Conversation): 我们分享一个共同的、明确的、激励我们的目标。
承诺对话(Commitment Conversation): 我们定期可靠地宣布我们将做什么以及何时完成。
问责对话(Accountability Conversation): 我们向所有相关方传达我们的意图,并公开解释我们的结果如何与承诺相符。
这五个对话解决了赋予团队充分利用现代以人为中心实践所需的一切的属性。有了它们,就有可能实现精英级别的交付速度,无畏地即时调整,并承诺向真实客户展示解决其问题的可工作软件。这些正是我们今天经常看到的团队所缺少的特征,在那里站会(standups)成为隐藏进度而非分享进度的地方,估算成为徒劳无功的练习,团队的目标迷失在一堆工单中,而沮丧是组织上下共同的情绪。
从信任对话开始,继续进行关于恐惧、为什么、承诺和问责的对话,我们将详细逐步向你展示如何改善团队中这五个关键属性。无论你是初级开发人员还是高级主管,你都能够使用这些方法,我们将解释这些改进如何直接转化为敏捷、精益和DevOps实践的改进结果。我们将通过每个主题对话的实际示例来说明这些方法在现实生活中的运作方式。
第3章到第7章各章分为相似的部分:
• 动机部分,解释为什么本章的特色对话很重要。
• 故事部分,介绍一位经历这种类型问题对话的主角。
• 一个或多个准备部分,教你本章对话中介绍的方法。
• 解释性部分(“对话”),描述举行本章对话的一种方式。
• 故事延续部分,我们的主角从问题对话中学习并产生更好的结果。
• 几个示例对话,说明本章对话的变体。
• 案例研究,讲述一个更长的故事,说明本章的对话如何帮助组织改进。
但读完这本书只是开始。在学会如何处理每个关键对话后,实践所学内容将取决于你。如果你这样做,我们相信你会发现这些努力会得到多倍的回报。当你转变你的对话时,你就转变了你的文化。
Perl 开发者有一个朗朗上口的缩写词：“TIMTOWTDI”，即”做一件事有多种方法”。这就是我们的理念，正如你将在本书中看到的；只要你以某种方式处理好五个对话(Five Conversations)，我们对你使用哪些实践方法并不做硬性规定。我们认为，诸如迭代应该多长时间、是否需要站会、或者使用什么颜色的规划扑克牌这类问题的答案，不如你如何得出这些答案来得重要。同样，我们试图以这样的方式编写本书，使你可以根据自己的学习风格、需求或心情以多种方式使用它。
因此，这里有一些关于如何阅读本书的建议，但”做一件事有多种方法”，所以如果你想出自己的方法，我们也不介意！
线性阅读。 如果你喜欢在第一次遇到每个想法时就完全理解它，这个方法适合你：从第一页开始阅读，一直读到最后一页。我们试图在使用每个新想法或技术之前先定义和说明它，尽可能避免前向引用。因此，如果你在信任对话(Trust Conversation)中掌握了人际测试驱动开发(Test-Driven Development for People)，那么当它在两章后的原因对话(Why Conversation)中出现时，你不会有任何困难。在每一章中，你会发现你喜欢的那种逻辑递进：首先是进行该章对话的原因，然后是使用它的技术，接着是对话本身，最后是实际示例。通过使用四个R(Four Rs)来处理每章末尾的示例对话和你自己的例子，以强化你的学习。如果可以的话，让一个或多个朋友参与你的循序渐进学习。
技术优先。 “不要用故事让我困惑；直接告诉我可以使用的方法。”如果这就是你，那么从每章的准备部分开始，在那里我们解释了你可以立即开始练习的技术，以改善你的对话，从而提高你团队的表现。继续阅读主要对话的解释部分，它将这些技术整合成一个整体，直到你读到示例对话，这些示例展示了对话的实际应用，你可以从中提取短语和方法。选择了这条路径后，我们建议你以每周不超过一种方法的速度推进，并在每周刻意练习日常对话中的方法。在每天结束时，统计你能够应用每种方法的次数，并选择一个对话使用四个R进行分析。虽然表面上缓慢而稳定，但如果你坚持下去，这种反思性实践(reflective practice)将迅速建立技能。
社交学习。 正如我们在结论中所描述的，其他同样有兴趣学习这些技能的人可以极大地帮助学习这些材料。使这些对话变得困难的认知偏见(cognitive biases)也使我们更难发现自己的错误。其他人则不会有这样的困难！如果你有幸拥有这样一个学习小组，我们建议作为一个团队，你们遵循与前一页技术优先方法类似的路径。每周最多涵盖一章，记录并分享你能够应用该章方法的次数，然后在小组会议中讨论和分析你的一个对话。角色扮演和与他人互换角色将帮助你对自己的表现建立信心；向他人提供反馈的实践将帮助你发现改进自己对话的机会。
无论你采取何种方法阅读本书，值得强调的是，仅仅理解是不够的；你需要通过练习来建立技能。别无他法。
* 五个对话中的四个受到了 Patrick Lencioni 识别的五个功能障碍(Five Dysfunctions)的启发。第五个，即原因对话，受到了 Simon Sinek 的《从为什么开始：伟大的领导者如何激励每个人采取行动》的启发。我们为每个对话添加了自己的经验和方法，并感谢这两位作者的启发。
根据《数字螺旋：转变你组织的 DNA 以在数字时代繁荣发展》一书的作者 Michael Gale 所说，84% 的数字化转型(digital transformations)失败。试图理解为什么另外 16% 会成功，他发现成功需要”人们思考方式的根本转变，包括他们如何互动、如何协作和工作，如果你不花时间改变人们的行为，不花时间改变文化和人们做决策的方式，所有这些都会失败。”
我们实现这一根本转变的方法是转向人类最独特的能力：对话。人类拥有独特强大且灵活的语言。为了充分利用它，我们需要学习对话的技巧，以及如何克服我们与生俱来的偏见，这些偏见会妨碍协作和连接。当我们改变我们的对话时，我们就改变了我们的文化。
为了理解我们需要的变革,理解我们所来自的文化会有所帮助。正如我们在本章中所描述的,我们仍在从软件工厂的大规模制造范式中走出的过程中。这种纯文档模型代表了一种没有对话的沟通尝试。软件工厂模型的失败为以人为本的新模型(如敏捷、精益和DevOps)的兴起创造了空间。但是当关注点放在流程和方法上时,试图采用这些新模型的善意尝试就会失败,在更小的规模上重复了软件工厂的一些相同错误,创造了John Cutler所说的”功能工厂”。
我们俩都在上世纪90年代的中型软件公司开始了职业生涯,在巨大的台式电脑上处理C代码,与数十或数百名做同样事情的同事一起工作。我们是嵌入在一个更大系统中的小部件。这并不奇怪,因为我们所处的系统是二十世纪哲学思想泰勒主义(Taylorism)的表达。
Frederick Winslow Taylor是一位机械师和机械工程师,他领导了一场反对浪费和低效的职业运动,在此过程中成为最早的管理咨询顾问之一。在Taylor看来,浪费的核心是工作执行方式在不同工人之间的巨大差异。他推理道,如果每个人都学会正确的方法,然后工人们毫不偏离地遵循这种方法,那会好得多;任何其他方法必然效率更低。那么谁来确定正确的方法呢?专业经理和像Taylor本人这样的顾问。
“科学管理”(Scientific Management)是Taylor最积极倡导的哲学,它认为管理者的工作是设计和理解最佳工作方式,然后强制执行毫不动摇的标准化。通过他1911年极具影响力的著作《科学管理原理》,Taylor为基于流水线的大规模制造提供了知识基础,低技能工人在管理者的监督下一遍又一遍地做同样的简单任务。
Taylor的世界观创造了一种非常独特和非人性化的职场文化。工厂被设想为一台巨大的机器。管理者是机械工程师,设计所有部件应该如何工作并检查它们是否正常运行。工人仅仅是可替换的零件:他们在规定的容差范围内运作,否则就是有缺陷的,应该被丢弃。沟通是自上而下的,仅限于命令和纠正。不需要对话。不需要协作。除了做你被告知要做的工作之外,不需要思考。
我们在90年代加入的软件行业已经把Taylor从工厂移植到了隔间。顾问和销售人员向管理者承诺,他们兜售的新工具、新流程和新方法能带来便利和效率。“软件开发遇到麻烦?被Bug和延期困扰?不用担心!我们有写好的最佳实践,随时可用。”管理层可以直接购买现成的系统,并告诉开发人员照着做。当工作流经每个定义好的检查点和流程门时,你可以确信能按时按预算完成。这就是承诺。
由于缺乏机械流水线,软件行业用纸张创造了一条流水线。管理者采用或发明了逻辑模型来描述单一的、正确的工作方式,并将它们编入带有分步说明和流程图的文档中。这种文档驱动开发(documentation-driven development)旨在通过指定最终程序每个部分的功能以及每个软件工作者为实现它要做什么,来消除任何出错的可能性。有营销需求文档、产品规格说明、架构文档、实现规范、测试计划等等——没有任何人类活动被遗漏。厚厚的手册详尽地规定了每个数据结构的属性、可以使用哪些语言构造,甚至注释的格式。精心制作的软件设计送到设计师的桌上,每个数据库列都被指定,每个验证都被定义,每个屏幕都被仔细地说明到最后一个像素。
但这是有逻辑的。每个人都知道在软件交付给客户后修复缺陷成本更高。事实上,我们越早发现Bug,修复成本就越低。修复设计师的流程图比修复代码更省力,而更新规格文档又比修改流程图更省力。不可避免的逻辑要求我们应该在前期花时间把一切都做对,然后机械地实施,以节省下游的时间和金钱。这一切都非常合理,非常理性。
不幸的是,它并没有很好地发挥作用。
Standish Group在其臭名昭著的1994年CHAOS报告中记录了这个系统运作得有多糟糕,该报告揭示了软件项目中令人震惊的失败水平。作者指出,与桥梁、飞机或核电站的失败不同,“在计算机行业中……失败被掩盖、忽视和/或合理化。”因此他们着手确定”项目失败的范围”、“导致软件项目失败的主要因素”以及”能够减少项目失败的关键要素”。报告得出结论,美国31%的软件项目被取消,使美国软件公司损失了810亿美元。只有16%的项目按时按预算完成。该报告揭露了泰勒主义方法的失败以及它们所造成的软件危机。
随着危机得到广泛认可,不乏寻找答案的人。一个思想流派体现在卡内基梅隆大学软件工程研究所的能力成熟度模型(CMM, Capability Maturity Model)中。CMM旨在帮助美国国防部评估软件承包商,它进一步强调了文档和流程的重要性。这种方法的拥护者在追求可预测性的过程中实施了更严格的监督、更多的检查和额外的规范。“一个处于统计控制之下的软件开发过程将……在成本、进度和质量的预期范围内产生预期结果,”他们断言。
来自整个软件行业的其他人,包括一线的软件从业者和与他们一起工作的人,在其他地方找到了灵感和想法。由于身处项目前线,他们的伤疤表明,这种理想化的机械方法,无论听起来多么合理,都无法解释软件项目为何成功或失败。他们观察实践中有效的方法,而不是从第一原理出发。在试图理解他们的经验时,他们发现答案无法用大量文档来捕获。它不是你可以购买的工具,也不在于流程的机械应用。而是人!
Alistair Cockburn博士是软件实践的敏锐而雄辩的观察者,他在论文《将人描述为软件开发中的非线性一阶组件》(Characterizing People as Non-Linear, First-Order Components in Software Development)中捕捉到了这一洞察。标题就说明了问题。与CMM形成鲜明对比,Cockburn说他”现在认为流程因素是次要问题。“他发现主要是人使项目成功或失败,并建议我们将改进努力集中在利用人的独特属性上。例如:
人是沟通的存在,面对面、当面、实时问答时表现最佳。
人难以在一段时间内保持一致的行为。
人是高度可变的,每天和不同地点都有变化。
人通常希望成为好公民——善于观察周围、主动行动,并做”任何需要的事情”来使项目成功。
这种对人的看法与泰勒主义将人视为机械的、可互换部件的观点截然相反。期望他们如此行事忽视了人性,注定会失败。实证发现是,人们如何相互联系以及他们如何在项目中沟通的文化是重要的。从业者可以看到,我们应该围绕人而不是流程来设计方法和项目。如果我们想提高成功的机会,我们需要进行正确的对话,建立正确的文化。
人是软件方法的核心关注点这一想法引发了一场延续至今的转型,自世纪之交以来重塑了软件构建方式。精益制造(Lean manufacturing)颠覆并改变了先前占主导地位的泰勒主义大规模制造范式,通过改变工厂文化在生产力和质量方面取得了巨大收益。精益制造不是将工人视为可替换的部件,而是依赖于”既高度熟练又高度积极的劳动力”,一支能够预见问题并设计解决方案的劳动力。
敏捷软件开发(Agile software development)、精益软件(Lean software)和DevOps同样颠覆并改变了软件工厂。这些方法各自针对工厂的不同元素,但它们都始于与非人性化的大规模制造方法的决裂。它们通过打破劳动分工并引入协作来取代僵化流程,从而改变了文化。
正如我们将在以下章节中说明的,每个运动的早期倡导者都隐含地支持两个基本价值观,透明度(transparency)和好奇心(curiosity),这使他们倡导发展成功软件团队的部分或全部五个关键属性的方法:高信任、低恐惧、理解原因、做出承诺和承担责任。这些价值观和属性都是关于人际联系、信息流动、消除障碍和协作——所有软件工厂所不具备的东西。
每一次新运动带来的初期成果都令人惊叹：早期采用者报告称，他们的产品上市时间大幅缩短，缺陷率显著降低,团队士气明显提升。例如,精益创业(Lean Startup)的倡导者宣称”每天向生产环境发布五十次这种不可能的事”。毫不奇怪,许多人包括我们两位,也加入了这股潮流,尝试这些新方法,看看能否取得同样的成果。
问题在于——也是本书写作的原因——在敏捷开发(Agile)、精益软件和DevOps爆发式发展期间,后来的采用者忽视了人际互动的重要性。领导者认为他们可以像以前一样行事——保持工厂思维模式——认为向他人强制推行变革就足够了。结果,他们只关注那些容易监控、更表面化的流程变革:站会、在制品限制、工具选择。
缺少人的因素,缺少正确的对话,这些变革根本无效。因此,我们在数百个组织中反复看到,失望的高管和沮丧的团队宣称敏捷开发(或精益软件或DevOps)就是行不通。
总结来说,他们用机械化的视角来看待这场以人为中心的变革,忽视或否认了关系的重要性,然后困惑为什么没人配合,什么都做不成。
相比之下,本书完全聚焦于让你成功所需的基本人际互动。让我们从回顾每个运动的历史开始,这将帮助我们了解一个简单的技巧,你需要掌握它来让人们重新参与到你的流程中:对话。
到1990年代末,反抗软件工厂的运动催生了各种替代软件开发方法的寒武纪大爆发。这些新运动的成员反对主流的”文档驱动、重量级软件开发流程”范式,倡导一些异端实践,如即时设计、频繁交付可工作的软件,以及让真实客户参与软件生产。最极端的是一种文化变革,呼吁大幅减少计划活动,转而支持实际工作者之间的协作互动。对于习惯了软件工厂主流实践的人来说,这些领导者看起来像是一群疯狂的暴民,一心想制造混乱。然而,在那些勇于尝试这些新方法的团队中,却有着令人惊叹的成果故事——士气提升、快速交付、高质量。
1991年2月,十七位”轻量级软件”运动最知名的倡导者聚集在犹他州雪鸟滑雪胜地。据James Highsmith记录,这是一个多元化的群体,包括极限编程(XP)、SCRUM、DSDM、自适应软件开发(ASD)、Crystal、特性驱动开发(FDD)、实用编程等方法的创始人和倡导者。问题是,他们能找到共同点吗?
事实证明,他们找到了,结果就是Martin Fowler所说的”号召行动”、“战斗口号”:敏捷宣言(Agile Manifesto),这份宣言在近二十年后仍被广泛使用。
敏捷软件开发宣言
我们通过亲身实践和帮助他人来探索更好的软件开发方法。在这个过程中,我们建立了如下价值观:
• 个体和互动 高于 流程和工具
• 可工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划
也就是说,尽管右侧的内容有其价值,我们更重视左侧的内容。
这个小组在宣言之后还制定了一套常被忽视的十二条配套原则。这套原则对于追求敏捷性的组织来说,仍然是一个有用的参考点。
我们遵循以下原则:
我们最优先要做的是通过尽早和持续交付有价值的软件来满足客户。
欢迎对需求提出变更——即使在开发后期。敏捷流程利用变化来为客户创造竞争优势。
频繁交付可工作的软件,交付间隔从几周到几个月不等,越短越好。
业务人员和开发人员必须在整个项目过程中天天一起工作。
围绕有积极性的个体来构建项目。给他们所需的环境和支持,并信任他们能完成工作。
在团队内部及团队之间传递信息,最有效的方法是面对面交谈。
可工作的软件是衡量进度的主要指标。
敏捷流程提倡可持续的开发。责任人、开发人员和用户应该能够保持恒定的节奏。
对技术卓越和良好设计的持续关注将增强敏捷性。
简洁——最大化未完成工作量的艺术——至关重要。
最佳的架构、需求和设计出自自组织团队。
团队定期反思如何变得更有效,然后相应地调整其行为。
2003年，也就是雪鸟会议通过敏捷宣言催生敏捷软件开发的几年后,两位经验丰富的程序员和软件团队领导者(他们恰好是夫妻)在他们的著作《精益软件开发:敏捷工具包》中将精益制造的理念引入敏捷圈。Mary和Tom Poppendieck深入研究了丰田生产系统的及时制造、减少浪费的制造方法来寻找洞见,并将它们转化为软件世界的语言。
Poppendieck夫妇将精益软件的精髓提炼为一套具有挑战性的原则:
Poppendieck夫妇强调了全面优化、通过频繁交付快速学习以及系统调优和系统思考等主题。这些主题没有一个与软件工厂兼容,许多主题建立在敏捷原则之上,而这些原则在2003年Poppendieck夫妇写第一本书时就已经在削弱现状。
很快,精益思想和实践开始传播。精益软件团队:
• 在流程中寻找并消除瓶颈(bottlenecks)，从最初的功能构思一直到客户交付和采用。
• 致力于限制在制品(work in progress)，例如，QA团队只接受十个新功能进行测试，而不是积累大量无法处理的工作积压。
• 强调从一个流程步骤向下一个步骤”拉动(pulling)“功能，而不是”推送(pushing)“；因此，如果没有人可以审查程序员的工作，她可能会暂停编码，而不是继续积累更多未审查、无法发布的代码”库存”。
随着越来越多的公司接受精益软件原则，更多的精益制造理念显示出其实用性，包括用于管理瓶颈的约束理论(Theory of Constraints)和看板方法(Kanban method)，后者甚至取消了”冲刺(sprints)“的轻量级时间盒，转而直接应用拉动工作来调节流程。精益软件始终致力于”看到整体”，其范围扩展到涵盖各种规模组织的运营，从初创企业(如Eric Ries的《精益创业：当今企业家如何利用持续创新创造极其成功的业务》)到跨国公司(如《精益企业：高绩效组织如何大规模创新》)。
乍一看，与敏捷宣言不同，Poppendiecks的原则或精益实践中明确表明我们需要非常担心混乱、不方便的人及其沟通困难的内容很少。看看这些原则，我们发现除了第二条(放大学习)和第五条(赋权团队)之外，其他都是关于流程和效率的。很容易得出结论，我们所需要的只是价值流图(value stream maps)的技术分析和冷静、有计划地消除浪费——许多精益方法的采用者正是这样做的，并为此付出了代价。
但正如Mary和Tom Poppendieck在《精益软件开发》中所说：“尊重人的基础是提供一个环境，让有能力的员工积极参与运行和改进他们的工作领域，并能够充分利用他们的能力。”这当然听起来更像Cockburn的”非线性、一阶组件”，即人！如果我们继续深入研究，我们会看到与透明度和好奇心这些基本的、以人为本的价值观有更多联系：
• 要消除浪费、整合完整性并与整个系统协作，我们需要对在创造低效率方面的错误保持透明，并对系统整体如何运作(以及如何不运作！)保持透明。
• 要放大学习并快速交付，我们必须对实现目标的选项保持好奇，甚至可能同时尝试多个选项(这是快速学习的经典精益策略)。
• 要赋权团队，我们需要对他们透明我们试图实现什么以及他们可以在哪里做出贡献，我们需要鼓励他们对客户和业务的各个方面保持好奇。
事实上，我们见过的成功的精益软件团队在很大程度上依赖于充满活力、坦诚、持续的沟通，包括直接的客户反馈、信息辐射器(information radiators)(如构建状态指示器和大型可见的业务相关图表)，甚至丰田式的安灯系统(Andon lights)(团队成员使用的个人红/绿/琥珀色指示器，用于广泛宣布他们遇到困难或被阻塞)。这些基于透明度和好奇心的工具和实践被用来激发关于持续改进的富有成效的对话。
问题在于，与敏捷开发一样，太多组织采用了实践却没有内在精神。我们看到有些组织将精益六西格玛绿带认证(Lean Six-Sigma Green Belt certifications)钉在隔间墙上，但缺乏协作和持续改进的文化。根据我们的经验，这是高管们认为转型是可以购买的东西的症状，然后想知道为什么价值流图和拉动系统被丢弃和闲置。
到2009年，人文主义软件运动扩大的时机已经成熟，没有人比比利时的沮丧顾问和项目经理Patrick Debois更了解这一点。他很烦恼，因为在一个又一个项目中，他看到开发人员和系统管理员之间的责任鸿沟是如何阻碍进步的。尽管许多开发团队正在消除软件工厂的负面遗产，但他们在与部署和运行其代码的运维人员互动时继续采用老一套做法——最少的沟通、低信任度和回避困难的对话。正如它们在开发团队内部所做的那样，这些行为减慢了进度，并阻止每个人交付正确的可工作软件。很明显，敏捷开发需要向下游延伸：“运维团队需要敏捷，并且需要整合到项目中。”
Patrick 开始尝试寻找对他所谓的”敏捷系统管理”感兴趣的人。起初应者寥寥——在一次会议上,只有两个人参加了关于这个新主题的讨论。20 但也有其他人在思考同样的问题,特别是 John Allspaw 和 Paul Hammond,他们分别是 Flickr 的运维主管和工程主管。他们的演讲”每天 10 次以上部署:Flickr 的开发与运维协作”热情地呼吁开发人员和运维人员之间的协作与信任,并迅速在敏捷圈子中传播开来。21 Patrick 怀着越来越激动的心情观看了他们演讲的直播,此后不久,他在根特发起了第一届”DevOpsDays”会议。拥有强大价值观和技术工具的 DevOps 运动就此诞生。
DevOps 没有权威,也从未有过类似 Snowbird 的 DevOps 会议,因此没有确定的 DevOps 原则清单。但那场开创性的 Flickr 演讲是我们所知的关于 DevOps 目标最清晰的陈述之一,可以作为试金石来评估那些声称专注于 DevOps 的团队是否真正如此行事。该演讲后半部分的原则如下(为便于列表呈现而进行了轻微编辑):
尊重
不要刻板印象
尊重他人的专业知识、意见和职责
不要只说”不”
不要隐瞒事情
信任
相信每个人都在为业务尽力而为
分享运维手册和升级计划
提供调节和控制手段
对失败持健康态度
失败必然会发生
培养应对失败的能力
举行消防演练
避免责备
不要指责他人
开发人员:记住损坏的代码会把人吵醒
运维人员:对痛点领域提供建设性反馈22
注意 Allspaw 和 Hammond 对信任、尊重和协作这些关键要素的明确表达;这显然是一场关于人而非机器的运动。
这并不是说没有关键的 DevOps 技术和团队实践。这些实践包括:
• 跨职能团队(Cross-functional team):开发人员和运维人员在单个团队中一起工作,而不是在不同的组中将完成的代码从一方交接给另一方。
• 牲畜而非宠物(Cattle, not pets):对于专注于 DevOps 的团队来说,服务器不是具有独立身份和自定义配置的特殊雪花,而是无差别的、相同的、可替换的机器,可以随时更换。
• 基础设施即代码(Infrastructure as code):系统管理员不再手动配置服务器,而是编写程序(使用 Puppet、Chef 或 Kubernetes 等工具提供的专用语言)来设置和测试他们的机器。
• 自动化部署(Automated deployment):一旦服务器运行,系统管理员和开发人员一起编写更多代码,使部署到该服务器成为一键操作。该部署可以由持续集成工具触发,进一步加强与开发人员及其工作的联系。
• 共享指标(Sharing metrics):以 DevOps 思维方式运作的团队将让工程师和系统管理员共同关注系统正常运行时间、错误率、用户登录和许多其他运营健康指标,并一起解决任何指出的问题。
在 20 世纪 80 年代,Simon Travaglia 为在线出版物 The Register 创造了终极系统管理员漫画形象。23 来自地狱的混蛋运维人员(Bastard Operator from Hell,简称 BOFH)鄙视开发人员和用户,并把无限增加他们的痛苦作为自己的目标。当然,Travaglia 为了喜剧效果而夸张了,但他触及了传统组织中开发人员和系统管理员之间深刻的怀疑和不信任,团队之间有着不可逾越的隔阂。
因此,毫不奇怪,上述 DevOps 原则和实践如此明确地要求首先协作:分享你的运维手册,展示你的指标,讨论你的失败(透明度)。并通过避免指责和了解你的行为产生的影响来尊重另一”方”(好奇心)。通过关注共同关切并让开发人员和系统管理员相互对话而不是相互讨论,DevOps 摆脱了流水线思维,以人为本的价值观和属性支撑着 DevOps 运动——至少在最初构想时是这样。
令人困惑的是,在一些企业中,最近出现了一种趋势,即任命一个独立于开发和运维的特殊团队:“DevOps”团队。DevOps 的全部意义在于在不同专业之间创造统一和协作,而不是更多的孤岛。我们甚至看到招聘”DevOps 工程师”的广告,他们显然是与普通工程师和系统管理员不同的特殊品种。发生了什么?我们认为这是流行词宾果管理方法的结果。组织没有培养”个人和互动”,而是希望避免重新思考如何运作,而是通过重新配置软件工厂来勉强应付。令人惊讶的是,许多组织已经实现了这个可疑的目标。
敏捷开发、精益软件和 DevOps 在改变软件格局方面的成功是不可否认的。曾经看似极端的想法现在被认为是正常的。在一天内完成一个功能或在一周内完成一个史诗级任务不再令人惊讶,即使在最大的公司中也是如此。正如 IBM 项目总监 Eric Minick 所描述的那样,
从历史角度来看，最让我印象深刻的是交付实际上已经变得更好了。只需看看发布节奏就知道。团队曾经满足于年度发布周期。当敏捷(agile)进入企业后，他们为能够实现季度发布而自豪。如果你现在还是季度发布，那就比平均水平慢了。月度发布现在更为常见。几乎每个大型企业都有一些云原生团队每天或更频繁地发布。今天的节奏比15-20年前快了一到两个数量级。还不错。24
虽然我们项目的时间表和范围都发生了很多变化,但有时我们会感到似曾相识。大型组织经常陷入这样的困境:几个敏捷(Agile)、精益(Lean)或DevOps流程与旧方法不协调地共存,形成一种奇怪的实践组合——一个”瀑布-Scrum-瀑布”的混合体。25我们还遇到过许多小型组织和初创公司,虽然展示着精益、敏捷和DevOps的实践,但设计师、开发人员和运维人员却将自己描述为在”功能工厂”中工作,有着与以前一样的微观管理和破坏自主性的做法。就好像巨大的软件工厂用不同名称的更小部件重新组装了。虽然带来了实际的好处,但这并不是激励Richard Sheridan写下《欢乐公司》(Joy, Inc)这本激进标题书籍的”热情、紧密的协作团队合作、卓越的客户联系和有意识的设计思维”。26发生了什么?
答案的一部分来自Niels Pflaeging,他在文章《为什么我们无法从丰田或Semco学到任何东西》中探讨了这个问题。Pflaeging思考为什么这么多在先锋组织中行之有效的实践案例产生的变化如此之少。他的洞察是,阻碍转型的是缺乏”那个神奇的成分……我们对人性的看法,我们如何看待周围的人,以及是什么驱动着他们。“27***
组织已经接受了敏捷转型创造的流程和工具,但泰勒主义(Taylorist)的工厂思维模式依然存在。需要编写的文档少了很多,需要阅读的规格说明也少了,几乎没有强制性的签字批准,但这些实践仅仅被无休止的计划会议和项目管理工具中的许多页面工单所取代——这些实践仍然提供泰勒主义的承诺,即为管理层提供他们要求的洞察力和控制力,因为管理者的角色仍然是确保正确的事情得以完成。
那么做实际工作的人呢?还记得软件开发中那些非线性的一阶组成部分吗?它们仍然是一阶的,仍然是非线性的。Cynthia Kurtz和David Snowden的Cynefin框架(见第20页的侧边栏)为我们提供了讨论它们的语言。28功能工厂想要把人类放在右下角的”显而易见”象限:“如果我们让每个人都参加计划会议、站会和回顾会,那么他们就会协作。”这种对协作的货物崇拜式方法对人类不起作用,人类的本质恰恰在左上角的”复杂”象限。刻意培养有效组织的动态需要更多的工作和更多的技能,而不仅仅是把一群人紧密地放在一起就称之为团队。
如果我们理解组织中的个人和团队本身就是复杂系统,那么我们应该做什么?根据Cynefin框架,在复杂场景中导航的适当方式(没有保证正确的答案)是”探测-感知-响应”。29那么,我们如何与人类进行探测-感知-响应?那就是对话——这是走出工厂的出路。
侧边栏:Cynefin框架
Cynefin是一个框架,其目标是让共同理解浮现出来并改进决策(见[图1.1])。
图1.1:Cynefin框架
虽然Cynefin社区中有一套丰富的活动和应用,但该框架的第一课是,适当的行为取决于你所处的领域。
•当情况是显而易见的(Obvious)(原因及其影响已被充分理解),诸如流程图之类的工具是有用的,因为可能性有限,当前状态决定了下一个正确的步骤。
•当情况是复杂的(Complicated)(原因和影响是已知的,但仅限于专家),具有复杂的需求,例如排查复杂机器中的意外行为,你需要发展相关知识,要么通过自主分析,要么引入专家。
•当情况是复合的(Complex)(原因和影响只能在回顾时才能理解),具有不可预测的部分,例如项目过程中团队动态的演变,其他情境(其他团队)中的过往经验不足以指导下一步该做什么;相反,你需要进行实验并发展多种视角来理解存在的模式,然后再决定如何响应。
•在混乱(Chaotic)情况下(原因和影响之间没有联系),例如分布式系统中的故障,首先采取行动是合适的,试图将情况带入因果关系正常适用的状态。
作为一套理论体系,Cynefin框架(Cynefin)与软件和人类的相关性体现在多个层面。我们构建的软件系统至少属于复杂(Complicated)范畴,并且经常会出现(计划外的)复合(Complex)涌现行为。构建软件系统的团队本身就是复杂系统。Cynefin框架进一步认识到,人类本身就是复杂的,不受简单规则的约束。这个框架为我们提供了很好的语言来描述为什么将软件开发视为大规模制造的方法——由所谓可互换的工人执行简单工作——会产生如此灾难性的结果。
[*] Jeffrey在Borland公司,Squirrel在Tenfold公司。两家公司早已被更大的公司收购。
[**] 事实上,Alistair Cockburn和他的许多同事已经开始指导公司采用一种方法论无关的方式,提供这些简单的指导原则,称为”敏捷之心(Heart of Agile)“。
[***] 参见第7章”准备:X理论和Y理论(Theory X and Theory Y)“以了解更多关于这一关键要素的内容。
本章将为你准备关键的关系建立对话技巧,这些技巧是你逃离功能工厂所需要的:信任对话、恐惧对话、为什么对话、承诺对话和问责对话。然而,在你处理这些具体对话之前,重要的是学习如何分析和构建你的一般对话技巧。你将了解为什么对话是人类独特的超能力,以及如何通过学习和实践有效地利用这种力量。
本章还将描述改进我们对话的核心挑战,即我们的行为与我们的信念不匹配,而我们却没有意识到这种差距。为了解决这个问题,我们将提供一个帮助你提高意识的过程:四个R。我们将向你展示如何记录(Record)你的对话,如何反思(Reflect)它们以发现问题,如何修改(Revise)它们以产生更好的替代方案,以及如何角色扮演(Role Play)以获得流畅性。最后,我们将提供一些示例对话,让你看到这个过程的实际应用。
一旦你掌握了四个R的基础,你就可以准备好阅读本书的第二部分,在那里你将学习如何进行每种具体的对话。
在他的著作《人类简史》(Sapiens: A Brief History of Humankind)中,尤瓦尔·诺亚·赫拉利探讨了是什么让人类成为地球上的主导物种。他的答案是,我们拥有一种特殊的沟通方式,这在动物中是独一无二的。
许多动物可以通过吠叫、鸣叫或动作来传达”快逃离狮子!“这样的想法。在此基础上,人类和动物沟通的发展似乎是由分享关于同一物种其他成员信息的需求所驱动的——即八卦的需求。八卦使我们作为社会性动物能够相互理解并建立声誉;而这反过来又使我们能够在更大的群体中合作并发展更复杂的协作。事实上,理解其他人类、发展”心智理论(theory of mind)“是如此重要,以至于哲学家丹尼尔·丹尼特在《从细菌到巴赫再回来:心智的演化》(From Bacteria to Bach and Back: The Evolution of Minds)中提出,我们自己的意识是作为理解他人心智的副产品而产生的。
尽管我们的八卦能力超越了其他物种,但赫拉利说,人类语言真正独特之处在于我们讨论不存在事物的能力。通过这种特殊能力,我们能够创造和相信共享的虚构。这些虚构使我们能够在巨大的规模上进行合作,并且跨越从未见过面的人群。通过这种方式,一个社区对鳄鱼头神的信仰可以在尼罗河上创建洪水控制工程,正如赫拉利在他的另一本书《未来简史》(Homo Deus: A Brief History of Tomorrow)中所描述的。而对持续改进的共同信念可以让我们创建学习环境和绩效导向的文化(performance-oriented culture),而不是权力导向或规则导向的文化,正如Nicole Forsgren、Jez Humble和Gene Kim在《加速:精益软件和DevOps的科学:构建和扩展高绩效技术组织》(Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations)中所描述的。
对话使合作成为可能,但不是必然的。我们并不生活在一个普遍接纳、和平和理解的世界里。真诚和善意的人可以产生分歧,甚至将另一个人视为敌人,视为”他者”。除了我们惊人的对话能力之外,我们还配备了预先存在的、内置的缺陷——我们所谓的认知偏差(cognitive biases)(参见表2.1了解我们最喜欢的一些偏差示例,以及Daniel Kahneman的《思考,快与慢》(Thinking, Fast and Slow)了解更多)。这些偏差似乎是内置在我们大脑的功能中的。而这些认知偏差抑制了我们的语言所使可能的那种合作。
| 名称 | 扭曲 |
|---|---|
| 自我中心偏见(Egocentric bias) | 为积极结果不当地归功于自己 |
| 虚假共识效应(False consensus effect) | 认为个人观点被普遍持有 |
| 赌徒谬误(Gambler’s fallacy) | 认为随机事件会受到之前结果的影响 |
| 控制错觉(Illusion of control) | 高估对外部事件的控制力 |
| 损失厌恶(Loss aversion) | 更重视保留现有物品而非获得更有价值的东西 |
| 天真现实主义(Naïve realism) | 认为个人对现实的看法是准确且无偏见的 |
| 负面偏见(Negativity bias) | 更容易回忆起不愉快的事件而非积极事件 |
| 正常化偏见(Normalcy bias) | 拒绝为新型灾难做计划 |
| 结果偏见(Outcome bias) | 根据结果而非决策过程的质量来判断决策 |
表2.1：认知偏见示例
我们的认知偏见对采用敏捷(Agile)、精益(Lean)或DevOps方法构成威胁，因为它们会严重损害协作、关系和团队生产力。
在前面的章节中，我们描述了透明度和好奇心如何融入以人为本的实践中，但这些都会被大量认知偏见所破坏。一个例子是虚假共识效应，我们认为自己的观点被普遍持有。这种偏见使我们不太可能分享自己的推理或询问他人的推理。当我们认为已经达成共识时，还有什么意义呢?天真现实主义，即相信我们看到的现实就是原本的样子，没有偏见，这对团队动态的腐蚀性更强，因为我们会将任何分歧视为对方不知情、不理性、懒惰、有偏见，或者可能所有这些都是!在这些和其他认知偏见的影响下，敏捷、精益和DevOps实践可能无法实现承诺的收益。
社会科学家克里斯·阿吉里斯(Chris Argyris)在耶鲁大学和哈佛大学商学院漫长而辉煌的学术生涯中研究组织行为，特别是企业中的组织行为。他的研究领域包括个人和组织学习，以及”促进规范和价值观层面学习”的有效干预措施。谦逊的对话是阿吉里斯用于调查团队有效性和改善组织绩效的核心工具。阿吉里斯发现，对话以及参与者未表达的想法揭示了他所研究的人员和组织的”行动理论(theories of action)“所需的一切信息。
阿吉里斯和合作者唐纳德·舍恩(Donald Schön)使用”行动理论”一词来描述我们行动背后的逻辑——即”主程序(master program)“。根据阿吉里斯和舍恩的说法，我们都有想要实现的结果，并使用我们的行动理论来选择采取哪些步骤。如果我的行动理论专注于学习，那么我会采取产生信息的行动，比如分享我所知道的与情况相关的一切，并询问他人他们所知道的。如果我的行动理论以实现自己的方式为中心，那么我只会分享支持我立场的信息，并且不会问我不知道答案的问题。
一般来说，我们不会明确思考我们的行动理论；然而，正如我们刚刚提供的两个例子一样，我们可以通过检查我们的行动选择来事后理解它们。阿吉里斯和舍恩的发现之一是，在我们说我们会在某种情况下做什么(信奉理论，espoused theory)和我们实际做什么(使用理论，theory-in-use)之间往往存在差距。
在继续阅读之前，请考虑这个问题：如果你必须作为一个团队做出重要选择，你会建议团队如何做出决策?
当我们向听众提出这个问题时，我们得到了非常一致的答案。典型的回应是这样的：“我会让每个人分享他们拥有的所有信息，解释他们的想法和推理，然后看看我们是否能就最佳方式达成一致。”
如果你的答案听起来像这样，恭喜!你已经信奉了阿吉里斯和他的同事所称的模型II行动理论(Model II Theory of Action)，或”生产性推理(productive reasoning)“。你声称重视透明度，分享你的推理和信息。你还声称重视好奇心，听取每个人的想法以了解他们的推理以及他们拥有而你没有的信息。最后，你声称重视协作和共同设计如何推进。虽然你可能使用了不同的词语，但这些是普遍理解和接受的增加学习和做出更好决策的实践。事实上，在没有威胁的情况下，当没有重要的事情处于危险之中时，你可能确实会以这种方式行事。不幸的是，如果你像阿吉里斯研究的超过10,000人一样，跨越所有年龄和文化(以及我们遇到的那些人!)，当话题是重要的事情时——比如引入公司战略或领导文化转型——你的行为将不会与你的言语相匹配。
Argyris及其同事发现,尽管几乎每个人都声称采用生产性推理(productive reasoning)的方法和行为,但当情况可能具有威胁性或令人尴尬时,情况就会发生变化。在这些情况下,人们实际上做的事情与一个非常不同的使用理论密切相关,Argyris将其称为模型I行动理论(Model I Theory of Action),或”防御性推理(defensive reasoning)“。
我们在表2.2中对比了这两种行动理论。当使用防御性推理心态时,人们会采取行动来消除威胁或潜在的尴尬。为此,他们倾向于单方面行动且不分享他们的推理过程,他们以输赢的方式思考问题,他们避免表达负面情绪,并试图表现得理性。
| 模型I | 模型II | |
|---|---|---|
| 支配价值观 | 定义并实现目标 赢;不输 压抑负面情绪 保持理性 |
有效信息 自由和知情的选择 内在承诺 |
| 策略 | 单方面行动 独自承担任务 保护自己 单方面保护他人 |
共享控制 共同设计任务 公开检验理论 |
| 适用于… | 数据易于观察 情况易于理解 |
数据存在冲突或隐藏 情况复杂 |
基于Argyris, Putnam和McLain Smith
表2.2:模型I和模型II行动理论对比
我们的声称理论(espoused theory)与使用理论(theory-in-use)之间的这种差距触及了团队生产力悖论的核心。理论上,我们重视多元化团队,因为我们理解多元性可以成为一种优势。经验的多样性、知识的多样性,甚至思维模式的多样性——理论上,这些都使团队更强大,因为每个新元素都为团队提供了更多信息和更多想法,因此有更多选择来做出更好的决策。
我们应该从多元性中寻求的是生产性冲突(productive conflict),通过它我们利用差异来创造新想法和更好的选择。实际上,我们倾向于将意见分歧视为威胁和潜在的尴尬,因此我们会做出防御性反应。我们的防御性推理导致我们压制自己声称重视的多元性,并避免我们声称寻求的富有成效的思想交流!
这种防御性推理在实践中是什么样的?我们将在整本书中用例子来说明防御性推理的多种形式,但借用托尔斯泰《安娜·卡列尼娜》的话来说,每一次富有成效的对话都是相似的,而每一次防御性对话都有其各自的防御方式。也就是说,存在共同元素;对话中的防御性推理往往以隐藏动机、不可讨论的议题以及对所说内容做出反应而非产生关联为特征——所有这些特征都会抑制学习并侵蚀关系。
那么,为什么人们选择这些适得其反的防御性行为,而不是我们都认同会产生更好结果的行为呢?答案是我们并非有意识地选择。在日常活动中,我们声称的理论与我们使用的理论之间的差距对我们来说是看不见的。我们通过多年的实践轻松地产生防御性行为——事实上如此轻松,以至于我们没有意识到自己在做什么,无论这对我们来说有多么适得其反,或者它与我们声称的生产性推理理论有多么矛盾。更糟糕的是,我们对自己的防御性推理如此缺乏意识,以至于如果别人试图引起我们的注意,我们会否认自己的防御性行为。
好消息是Argyris发现,对对话的反思使参与者能够意识到并改变他们的行为。通过定期的努力和实践,你可以学习透明度(transparency)和好奇心(curiosity)的行为,这将促进共同设计和学习;跨组织边界的知识共享;以及共享和解决困难的、以前是禁忌的问题。坏消息是这需要大量的努力,更糟糕的是,这种努力涉及困难的情感工作。
难点在于它需要认识到你的行为正在对问题产生影响。你是否愿意考虑自己可能正在导致会议效率低下和关系防御性增强?并非每个人都愿意付出这个代价。最后,即使你愿意保持谦逊并付出努力,发展这些新技能也需要时间。Argyris及其同事描述克服我们的常规行为”大约需要像打一场不太像样的网球比赛那样多的练习。“如果这听起来令人生畏,记住你每天在解决组织中的实际问题时都有机会练习,这可能会有所帮助。如果你有改进的动力,我们可以为你提供练习的技能。
在本章后面,我们将向你展示如何通过从今天的对话中学习来练习生产性推理(productive reasoning)。除了提供从对话中学习的核心技术(四个R),我们还将提供示例供你练习分析。在本书的其余部分,你将一次又一次地使用同样的四个R方法来学习信任、恐惧、为什么、承诺和问责对话的具体内容。这五种对话解决了阻止我们使用我们所倡导的生产性推理的常见陷阱。这些陷阱是:
当我们缺乏信任时,我们不会保持透明和好奇。
当我们有未说出口的恐惧时,我们会有意识或无意识地采取防御行为。
当我们缺乏共同的目的时,我们将无法产生有效的冲突。
只要情况让人感到威胁或尴尬,我们就会避免明确的承诺。
如果我们不愿意承担责任,我们将无法从经验中学习。
只有在克服了这些挑战之后,我们才能真正进行高绩效组织所需的有效学习对话。
从头到尾,这本书都是关于对话的,所以值得花点时间解释一下本材料适用的对话类型范围。
当我们说”对话”时,首先想到的画面可能是两个或更多人在同一个房间里面对面的交流。然而,我们大多数人都有许多其他类型的定期使用的沟通渠道。电子邮件无处不在。Slack、Microsoft Teams和IRC(互联网中继聊天)等聊天系统正在被大量采用。带视频的分布式会议越来越普遍,比纯语音电话会议有了很大进步。
我们相信本书中的材料在所有这些对话模式中都很有用,尽管值得考虑不同选项固有的权衡。图2.1基于Alistair Cockburn的模型,为这些权衡提供了有用的视觉参考。
正如Cockburn所说,“最有效的沟通是人与人之间、面对面的,就像两个人在白板前一样。”这种场景最有效,因为除其他属性外,它为两个参与者提供了最大可能的非语言信息和最快的响应速度。然而,当你学习进行困难对话且一方或双方感受到强烈情绪时,这些相同的属性也可能使事情变得更加困难。红着脸是额外的信息,但它也可能令人生畏和分心。
作为学习机会,异步渠道可以提供一些好处。一个好处是你可能会有更好的记录,记录每一方实际说了什么,这对以后进行对话分析会有很大帮助。更好的是,异步渠道允许我们在回复之前进行多次草稿。例如,我们已经将四个R应用于电子邮件草稿,使我们能够使用我们正在学习的技术,并将见解纳入我们最终发送的电子邮件中。
最终你追求的技能是能够面对面、实时应用这些技术的能力;充分利用异步沟通的学习机会可以帮助你获得这种能力。
经验给我们提供了学习的机会,但大多数人不会花时间真正从中学习。我们应用四个R—记录(Record)、反思(Reflect)、修订(Revise)和角色扮演(Role Play)—作为我们从对话中学习的首选方法。(如图2.2所示,还有两个额外的R可能会在此过程中出现:重复(Repeat)和角色反转(Role Reversal)。)
要开始使用四个R,你需要以书面形式记录一段对话。在下一节中,我们将描述我们首选的方法,即两栏对话分析法。可能很容易避免使用笔和纸,只是”在脑海中”思考对话,或与朋友讨论它。不要这样做!将文字写在纸上的行为是这个过程的固有部分,因为它迫使你的大脑保持一定距离思考对话,就好像它发生在别人身上一样。这种距离对于通过反思和修订获得见解至关重要,我们稍后会看到。
在你记录(Record)对话之后，就该反思(Reflect)它了，特别关注你当时尝试使用的工具或技巧。对于每一个五个对话(Five Conversations)，我们都会推荐特定的工具。随着时间和练习，你将根据对话需要在这些工具间切换，但一开始，我们建议你一次只使用一个工具或技巧。我们会为你提供如何使用该工具为你的对话打分的指南，这种反思将引导你找到可能的改进方向。
在为对话打分后，修订(Revise)你的对话，尝试产生更好的结果。你怎么知道自己是否有所改进？重复：拿出你修订后的对话，再次反思。你的分数比第一次提高了吗？你可能会惊讶地发现，你的修订版本实际上并没有比原版得到更好的分数！不要灰心——这很常见，尤其是在你学习新技能的时候。可能需要尝试六次或更多，才能产生一个符合该技巧所有要求的修订版本。
在为替代对话创建了对话内容后，还有一个重要步骤：角色扮演(Role Play)。找一个愿意帮忙的朋友，尝试大声说出你的对话，让你的朋友扮演你的对话伙伴。大声说出这些话的感觉如何？通常书面上看起来还可以的内容，说出来可能会感觉不自然。也许需要改变措辞，或者你只是需要练习用不同的方式说话。
另一个检验进步的好方法是另一个隐藏的R：角色反转(Role Reversal)。在对话中交换位置，让你的朋友说你的台词。站在对方的立场上，听到你修订后的语言，感觉如何？通常，听到自己的话会给你线索，告诉你如何进一步调整对话，使其感觉更自然，同时保持你试图练习的技巧。
对单个对话遵循所有四个R(Four Rs)的步骤，将从那次经历中获得最多的学习。对一系列对话遵循这些步骤，将大幅增加你整体学习的量和速度，并且应该能迅速为你和你的团队带来实质性的实际收益。
正如我们刚才解释的，四个R的第一步是记录你想要改进的对话。我们即将向你展示一种由Chris Argyris发明和使用的卓越技巧，用于捕捉对话的关键要素。我们特别喜欢这个方法有两个原因：首先，它有明确的规范和机械性，这吸引我们的工程师思维；其次，它非常自然地适用于其他三个R：反思、修订和角色扮演。
起初，对话分析可能看起来过于简单而没有价值。但它是获得重要见解和改进对话的最快途径。我们在整本书中使用它来说明如何使五个对话中的每一个都取得成功。
一张普通的书写纸（不要准备超过一张，我们稍后会解释原因）。
一支笔、铅笔或其他书写工具。
就这些，真的。（我们告诉过你这很简单！）再次提醒，不要以为可以在脑海中想象或记住内容就跳过写下来的任务——把它写在真正的纸上。当你的距离感帮助你获得关键洞察时，你会很高兴自己这样做了。
想一个你想要改进的对话。这可以是你最近进行的对话，但不必如此：你可以分析很久以前发生的对话，或者（这是我们最喜欢的）一个尚未发生但你担心的对话。
接下来，将纸张纵向对折，创建两列。在右侧列中，写下对话中每个人说的话。不必担心每个字是否正确；你的目标是对话的音调和风格，而不是准确引用。另一方面，要努力不要评论或添加任何内容。你试图记录的是一个中立的听众或机械录音设备会听到的内容。
在左侧列中，写下对话内容后，写下当时说这些话时你的想法。这里不要有所保留；在困难的对话中，你的想法往往与你说的话非常不同，所以包括所有闪过你脑海的东西，无论看起来多么无关紧要或不公平。重要警告：你绝对不能写对方想的任何东西。
我们发现，对话分析方法的新手经常写得远超过需要，试图捕捉可能很长对话的每一个字。这几乎肯定是不必要的。如果你专注于对你来说情绪最激烈的对话部分，很可能你能够将那个关键部分写在一张纸的一面上，这正是我们告诉你只准备一张纸的原因。
像这样保持案例非常聚焦，可能意味着你需要从对话的中间开始，而不是从头开始。不必担心；可以安全地假设读者知道对话的背景和参与者之前说的话，因为主要读者将是你！
如果你发现很难将案例保持得这么短，试着让它更短，只有半页。这种对长度的限制将帮助你创建一个更有价值、更适合分析的案例。
让我们看一个作者之间使用双栏分析技术的真实对话。这个例子简明扼要地展示了对话分析的所有关键特征：它简短，包含了想法和实际话语，通过观察两栏之间的差异可以获得丰富的学习机会。
当你阅读别人记录的对话时，按照记录的顺序阅读各栏：先阅读右栏以理解口头对话，然后回过头来同时阅读两栏，这样你就能理解伴随外部对话发生的内部对话。如果你只是跳入并像英语的自然习惯那样从左到右、从上到下阅读，你会看到 Squirrel 在 Jeffrey 宣布他将离开之前就担心 Jeffrey 的缺席。如果你大声朗读，可以添加一个提醒来区分想法和言语：“Jeffrey 说，‘我们下次预定的在线培训时我将不在国内。’” Squirrel 想，[哎呀！Jeffrey 通常负责设置电话和软件连接]，等等。我们通常不会意识到内部和外部对话之间的区别，这使得这种格式很有帮助，但一开始有时难以掌握。请耐心：在你自己记录几次对话之后，分析会变得容易得多。
| Squirrel 的想法和感受 Jeffrey 和 | Squirrel 说的话 |
| 哎呀！Jeffrey 通常负责设置电话和软件连接。我们现在怎么办？ Jeffrey：我们下次预定的在 | 线培训时我将不在国内。 |
| 看起来没戏了。我想我们只能放弃了。 Squirrel：好的， | 这意味着我们不能在你的办公室做了，我猜。我们应该取消吗？ |
| 当然可以，但我怎么让技术正常工作呢？Jeffrey 操作时总是看起来很繁琐。 Jeffrey：哦不，我肯定可以 | 拨入。那样你就可以待在家里，不用来办公室了。 |
| 这是个好观点——我将省去通勤压力。 Squirrel：是的，我想你 | 可以通过电话加入，这对我来说意味着更少的旅行。但我从来没有做过软件和电话设置。 |
| 我远没有 Jeffrey 那么自信。 Jeffrey：别担心。组织者 | 给我们发了一个非常有用的教程链接。你不会有任何问题的。 |
| 如果我搞砸了怎么办？数百名参与者会因为我耽误了他们付费参加的会议而对我大发雷霆。我想我只能试一试了。 Squirrel：好吧，我想我可以试一试。 |
如果你只阅读右栏，你会看到一个相对平静的对话，Squirrel 只表达了轻微的怀疑。如果你当时在房间里和我们在一起，这确实是你会观察到的。但左栏揭示了更多关于 Squirrel 内心恐惧和担忧的内容，“没戏了”和”大发雷霆”等词语说明了他感受的深度。这些未表达且可能无法讨论的想法和感受，正是我们在使用即将展示给你的技术分析案例时要集中关注的内容。
一旦你将对话写在纸上，就该把它拆开，理解它是如何运作的，并寻找改进的方法——这是四个 R 的反思(Reflect)、修订(Revise)和角色扮演(Role Play)步骤。在你批评对话时，你需要根据标准来检验自己。我们建议检查对话中是否有透明度(transparency)和好奇心(curiosity)的证据，因为这些是协作的基本要素。同时尝试注意适用于多个对话的行为模式。
当我们反思对话时，我们将标记对话内容以帮助指导我们后续的修订（见第 44 页的[图 2.3]）。考虑换成红笔（或其他颜色）以使你的标记更明显。
图 2.3：Norbert 标注的对话
我们将从 Norbert 分析的对话开始，他是一家中型组织的系统管理员。他和他的老板 Quinn 正在尝试决定在新项目中使用哪种虚拟化软件最好。
提醒：先阅读右栏，然后回过头来从右到左阅读。
| Norbert 的想法和感受 | Norbert 和 Quinn 说的话 |
| 源显然是正确的选择。 Norbert: 我认为我们有当你把”等待支持电话”算作有效利用我的时间时。 Quinn: 但这不是我们的标准。Virt-A 为什么总是推崇闭源解决方案? Norbert: 好吧,但我们一直说!他们都已经了解KVM了,至少是基础知识。 Quinn: 是的,但想想际上不需要太多培训——每个人在他们的副项目中已经在使用它了。 Norbert: 我们为什么不问问团队不是刚才还说希望我们有更多自主权吗??你真是个伪君子! Quinn: 不幸的是,像这样关键的预算决策型的管理者,不愿意承担任何风险。对于你已经做出的决定,争论毫无意义。 Norbert: 好吧,但我认为你错过了一个真正的机会。 | 应该使用KVM。它最灵活，最适合我们的需求。 pp在我们所有现有项目上都运行得很高效。在等他们修复问题,这太糟糕了。难道你不想掌控局面,这样我们可以自己解决问题吗? 再培训成本。我不认为我能获得额外预算让每个人学习新工具。 ?我相信他们愿意自学。我不能交给团队。 |
| 对这次对话不太满意,” Norbert后来说。“Quinn否决了我偏好的解决方案,更糟糕的是,我感觉被操纵同意使用Virt-App,Quinn的最爱。”我 | 们可以在Norbert对话记录的左栏中看到这种负面观点的发展,它以讽刺开始,以宿命论结束。 |
| rbert如何改变这次对话以获得不同的结果?下面,我们描述他如何分析对话以发现更有效的选择。这些是你可以用于任何对话的基本分析步 | 骤。当你在本书中学习更多技巧时,我们将建议进一步的方法来评分和从对话中学习,当你使用特定技巧时。 |
| 反思好奇心:问题比例 | |
| 们寻找的高效推理的第一个原则是好奇心;为了评估我们有多好奇,我们从问题比例开始。为了找到这次对话的问题比例,Norbert首先查看 | 了他的右栏并圈出了所有问号,发现了两个。他把这个写在右栏顶部作为分数的分母:。 |
| 在是困难的部分:Norbert问自己,“我的每个问题都是真诚的吗?”一个真诚的问题具有以下特征: | |
| 你真的想知道答案。 | |
| 答案可能会让你感到惊讶是合理的期待。 | |
| 你愿意根据得到的答案改变你的观点或行为。 | |
| 比之下,非真诚问题是用来表达观点而不是学习新东西。它们通常是伪装的陈述,或试图引导对方得出某个结论。律师特别擅长引导性问题 | (leading question),旨在迫使不情愿的证人给出特定答案:“你中午开车去了Bob的房子吗?邻居看到你砸门并愤怒地喊叫,不是吗?当他开门时,你掏出了枪,不是吗?” |
| 键是,你不能仅仅通过听问题来区分真诚和非真诚问题。相同的话在一个情境中可能是真诚的,在另一个情境中可能是非真诚的。区别的关 | 键在于提问者的想法,通常是未表达的。例如,如果我问你,“你修复了那个关键bug了吗?”我可能真的想知道修复的状态,或者我可能试图向你施压去处理它,或者我可能在微妙地抱怨你还没有开始处理我认为最重要的功能。只有我的左栏(我的想法)会揭示我的真实动机。 |
| 思他问题的真诚性,Norbert说,“很难承认,但从我的左栏可以看出,我的两个问题都不是真诚的。我问第一个问题,关于掌控,是因为我想推 | 动Quinn使用开源。当我建议我们问团队时,我在引导证人——我知道他们会偏好KVM,这是为我这边获得更多证据的方法。” |
| 于他的问题都不是真诚的,Norbert在他的分数分子中填入零:。“哇,我想确实很明显我对Quinn的想法不太好奇。我没有问一个真诚的问题 | 。” |
| 申一下,当你分析你的对话时,加总你问的问题数量;这是你的分母。然后分析你的问题中有多少是真诚的;这是你的分子: | |
| 题比例帮助你理解你在对话中展示了多少好奇心。你可能相信你以开放的心态进行了对话,但如果你没有问真诚的问题,你就没有展示那种 | 好奇心。当你进入修订步骤时,这将是有价值的输入。 |
| 反思透明度:未表达的想法和感受 | |
| 下来，诺伯特转向他的左栏。在困难的对话中通常如此，这一栏有许多未出现在右栏中的陈述和问题；换句话说，它包 | 含了未分享的想法，代表了未表达的思想和感受。 |
| 对话中分享情绪对人们来说特别困难。我们不仅缺乏这方面的练习，而且谈论情绪也违反了防御性思维模式的两个标准原则：避免表达负 | 面情绪，以及表现得理性。 |
| 我们思考如何有效地分享情绪时，值得考虑马歇尔·罗森伯格在其著作非暴力沟通：生活的语言中关于分享感受的指导原 | 则：19 |
| 区分感受和想法。我们经常说”我感觉”后面跟着一个想法，比如”我感觉我们做错了选择。“如果我们可以用”我认为”替换”我感觉”，那么 | 我们就不是在表达情绪。 |
| 区分我们的感受和我们认为自己是什么。“我感觉自己像个骗子”是在分享关于我们认为自己是什么的想法，而不是情绪。 | |
| 区分我们的感受和我们认为他人如何反应或对待我们。这可能是这些指导原则中最难应用的，因为当我们说”我感觉被忽视了”或”被误解了 | “或类似的话时，我们实际上是在陈述关于其他人的观点——他们正在忽视或误解我们。我们并没有分享情绪。 |
| 建立感受词汇。说”那件事发生时我感觉很好”不够具体，“那件事发生时我感觉很糟”也不够具体。英语有数十个词来描述特定的情绪状态 | 。（参见非暴力沟通中心提供的实用”感受清单”。20）花些精力找到最准确表达你感受的那个词。 |
| 些指导原则之所以困难，是因为这些陈述虽然不是直接的情绪表达，却都会在我们内心唤起强烈的情绪。因为这些情绪对我们来说强烈而 | 清晰，我们就假设它们对其他人也同样明显。这种认知偏差被称为”透明度错觉”(Illusion of Transparency)，是真正透明的障碍之一。我们为什么要分享那些显而易见的东西呢？当我们反思对话时，重要的是要记住，如果我们没有明确分享我们的情绪，那么我们就没有做到透明。 |
| 我们审视未分享的想法时，也值得记住罗森伯格的另一个建议：区分评价和观察。21 我们的 | 本性是即刻且毫不费力地为我们从他人身上看到的行为赋予意图，就像诺伯特给奎因贴上”伪君子”的标签一样。这些评价产生得如此之快，以至于很容易将它们误认为事实。同样，我们将情绪解读到他人身上，并且对自己的判断过度自信（又是透明度错觉）。当我们注意到这些对意图的归因，或对方并未陈述的情绪时，它们应该成为好奇心的触发点——触发我们去询问对方实际上是如何思考和感受的。 |
| 虑到这一切，诺伯特在左栏（他的想法）中每个未在右栏中表达（即使是部分表达）的句子下划线。 | |
| 前两行我给了自己怀疑的余地，“诺伯特说。”在对话的后面，我确实间接地表达了对开源的支持，在解释我反对Virt-App时也确实提到了 | 等待，尽管我没有完全说出我多么强烈地讨厌在与他们通话时浪费时间。在接下来的几行中，我的想法变得越来越消极和轻蔑，而我没有分享任何这些感受，所以我给其他所有内容都划了线。看着我划线的所有内容，我可以看出我对奎因并不够透明。我没有分享我掌握的所有事实，也没有分享我当时感受到的任何情绪。” |
| 反思模式：触发点、信号和习惯 | |
| 在诺伯特在对话中寻找他个人的触发点(triggers)、信号(tells)和习惯(twitches | )。这些是个人化的，因此，当你分析了几次对话并注意到重复的行为模式时，它们往往会变得明显。 |
| 触发点是你之外的行为、陈述或其他事件，通常会导致你产生强烈反应。例如，当一位经验较少的开发者听到”初级工程 | 师”这个词用在他身上时，可能会变得沮丧并退出对话，因为这让他觉得自己对团队的价值较低。 |
| 信号（就像扑克中一样）是你展现出的行为，表明你没有以透明和好奇的态度行事。例如，当一位经理感到沮丧并认为 | 他的团队没有接受他的指导时，他可能会开始在会议室里踱步。 |
| 习惯是你本能的默认反应，无论具体情况的细节如何。例如，一个人可能倾向于快速做出决策然后再调整，而另一个人 | 可能倾向于延迟决策直到掌握所有事实。 |
| 解你的触发因素、信号和惯性反应可以帮助你提高自我意识,让你在当下的回应中有更多选择。我们两人都从这类分析中受益匪浅。Squir | rel发现了一个触发因素,他注意到当一位非常高的同事站在他面前时,他会感到焦虑和防御;他通过在与高个子同事交谈时站起来进行了调整。Jeffrey通过分析自己的对话发现,在描述一些并不明显的事情之前,他会说”obviously(显然)“并举起左手;现在,当Jeffrey发现自己这样做时,他会说”这并不明显”,然后解释他的想法。 |
| 有哪种惯性反应是错误的;然而,也没有哪种惯性反应在所有情况下都是正确的。当你注意到自己按照惯性反应行事时,这可以作为一个有用 | 的提示,让你考虑这种惯性反应是否适合当下的情境。 |
| 在这段对话中发现了一个触发因素和一个信号,“Norbert说。”首先,我对Quinn拒绝咨询团队的反应非常强烈,在我的左栏中称他为伪君子。 | 当人们直接拒绝看似合理的请求时,我经常这样做,所以这是一个触发因素。 |
| 外,我用了两次’okay(好的)’,但实际上我一点都不觉得好。第二次时,我在左栏中抨击Quinn,而在右栏中却同意他。我希望将来注意这个信 | 号,当我说’okay’但感觉不是这样时要警觉。” |
| 你在对话中识别出触发因素、信号或惯性反应时,圈出位置并标记它。在对话中标记它将帮助你完成修订步骤,也会帮助你以后回忆起它,无 | 论是在对话中还是在未来的分析中。 |
| 修订:创建更好的替代方案 | |
| 后,Norbert该重写对话了,以解决他发现的问题,使用他标注的对话记录作为指导。 | |
| 想要更有好奇心,使用更多真诚的问题,“Norbert说。”我还认为我应该更加透明,将一些挑战性的想法和感受从左栏移到右栏,用建设性的方 | 式表达。我想针对我识别出的触发因素和信号设计预先计划的行动。我的目标是练习我学到的新技能,更多地了解Quinn的想法,并确保Quinn听到他的管理风格让我有多不舒服。” |
| 下是Norbert修订后的案例: | |
| # Norbert和Quinn的修订讨论 | |
| Norbert的想法和感受 | Norbert和Quinn说的话 | ——————–|———————-| 开源似乎是正确的方向,但我也想听听Quinn的想法。 | Norbert: 我认为我们应该在这里使用KVM,因为它非常灵活。你怎么看? | 这是个有挑战性的答案。我不认为”等待技术支持”是有效利用我的时间! | Quinn: 它确实很灵活,但不是我们的标准。Virt-App在我们所捕捉到我的信号了!Quinn是否同意我们过度依赖供应商? | Norbert: Okay—嗯,实际上不okay,因为Virt-App对我们请求的响应效率太低培训是需要考虑的事情,但我们已经搞定了。 | Quinn: 这是个好观点。我不知道他们的响应时间这么差。但再培训成本呢?我觉得我无法实际上不需要太多培训—每个人在他们的业余项目中已经在使用它了。 | Norbert: 实际上,几乎每个人都已经了解KVM了。我可以和他们你不是刚说想让我们有更多自主权吗??这是我的触发因素之一,所以我会尝试直接提出自主权的问题。 | Quinn: 获得信息当然很好。但不我希望我们能就增加自组织(self-organization)进行有意义的讨论。 | Norbert: 你知道,这让我不太舒服,因为我认为我们需要更多自主 | |
| 绝不是一次完美的对话,“Norbert在反思他的修订时说。”但我设法分享了大部分左栏的顾虑。我还问了三个真诚的问题,并且捕捉到了我的 | 触发因素和信号。” |
| 尝试使用问题占比工具或通过划线标注透明度、抽搐、暗示和触发点来重新评分第二个案例，看看你是否同意Norbert的观点——它更有效。 | 当你自己尝试时，预计反思和修订一开始会很困难，因为你正在学习的技能很容易描述但难以掌握。事实上，多次修订同一个案例、反思修订内容并重新评分是非常正常的。可能需要多次迭代才能得出满意的替代方案。 |
| 角色扮演：练习产生更好的对话 | |
| 色扮演——四个R中的第四个——对于让这些新技能变得自然非常有帮助，所以试着与朋友、同事甚至镜子一起朗读你修订后的对话。当你说出 | 这些台词时，考虑说它们的感觉，并调整对话直到感觉自然舒适。作为最后的测试，与你的朋友互换角色，考虑听到这些话语对你说的感觉。我们的经验是，人们在每个步骤中都会获得不同的见解并做出不同的调整：写作、说话和倾听。 |
| 声说出对话比我预期的要难得多，“Norbert反思道。”即使在角色扮演中，我也能感觉到自己对团队无法参与这种决策感到愤怒。当我们进 | 行角色互换，我听到对话回放时，我意识到我没有真正分享我对当前状况有多沮丧。我做了最后的修订，明确地分享我的感受，这听起来更有效了。” |
| 示例对话 | |
| 可以通过以下示例练习对话分析。尝试按照我们上面描述的方式评分，然后重写对话以解决分数揭示的问题。如果你觉得这很难，不要担 | 心——每个人一开始都是这样，在本书的其余部分会有大量的技巧可以尝试和练习的机会。我们将引导你完成第一个示例。 |
| # Tanya和Kay：限制在制品数量 | |
| nya说：“我刚上了一门精益创业(Lean Startup)课程，为我们的敏捷软件团队绘制了一张价值流图(value stream map)，我是产品负责人 | (product owner)。我认为我们需要开始限制在制品数量(WIP)，因为我们的开发流程中有几个步骤存在明显的缓冲。一个大障碍是我们总是等待Kay——我们的测试员——验证最新的变更才能发布。我确信很容易说服她应该限制WIP以提高效率。” |
| # Tanya和Kay的实际对话 | |
| 醒：先阅读右侧栏，然后回过头从右到左阅读。 | |
| Tanya的想法和感受 | Tanya和Kay说的话 | —————–|——————| Kay真的会喜欢这个的！ | Tanya：我有一个解决方案给你！我们终于可以不用一直催促你在冲刺(sprint)发布前完成测试了。 | 在瓶颈处增加产能不可扩展，而且我们也没有预算。我来解释一下。 | Kay：太好了！我们要再招一个测试员吗？我们显然需要一个。 | Kay应该能看到好处，我很确定。我只是不知道我们应该从哪里开始设置WIP限制。 | Tanya：嗯，实际上比招人更好。我们要做的是限制嗯，她需要更多解释。 | Kay：等等。这不是会让工程师们更烦恼吗？他们会在流程早期积累更多变更。 | 我们在课程中看到了一个很好的图表，应该能说清楚。 | Tanya：不，这就是它的妙处。他们一开始会处理更少的工单，因为有一种叫”拉我太失望了！她理解错了。她为什么不让我解释WIP限制会让她的工作轻松多少？ | Kay：我很怀疑。高管们一直说我们需要完成更多工作我不明白——这里出了什么问题？ | Tanya：好的，也许明天的站会(standup)之后？ | | |
| 于第一个示例，我们将提供我们的评分和修订后的对话，但在你自己尝试这个过程之前，尽量不要看我们的结果。如果你得到非常不同的 | 分数或截然不同的修订对话，不要担心。这里没有正确答案；只有对你有效的改进。(回顾如何找到问题占比、未表达的想法和感受、以及触发点、抽搐和暗示，见第39-43页。) |
| 问题比例。** 在Tanya的右栏中有一个问号：“三个是否合适?” 所以我们在问题比例的分母上加1。这是一个真实的问题吗?只有Tanya自己 | 确切知道,但我们怀疑不是。她确实想知道限制应该设在哪里(她在左栏中这样说了),但很难相信她会接受一个令人惊讶的答案——想象一下如果Kay说零、一百,或者”五个,但只能是用德语写的”会发生什么。当Kay确实给出令人惊讶的回应时,Tanya显然对改变自己的信念或行为不感兴趣,而是继续更清楚、更有力地解释她的想法。所以我们认为她有零个真实的问题,最终得分为0。 |
| 未表达的想法和感受。** 据我们所见,几乎没有什么内容进入右栏,所以左栏中几乎所有内容都被划了线。Tanya认为Kay会喜欢这个解决方 | 案,认为招聘行不通,认为Kay只需要对WIP限制有足够清楚的解释。在对话结束时,Tanya感到失望和困惑,但她没有与Kay分享这些。 |
| 触发点、信号和抽搐反应。** 在没有更多例子的情况下,很难明确识别Tanya可以使用的信号。但一个可能的信号是她在左栏中反复断言K | ay只需要更多解释,我们将把它圈出来并标记为可能的信号。当她注意到自己以这种方式思考时,她可能想要替换为另一种行为。 |
| Tanya和Kay修改后的对话 | |
| 下是对话的修改版本。尝试对它进行评分,然后判断你认为它是否更有效。或者你会用不同的方式处理Tanya的情况吗? | |
| Tanya的想法和感受 | Tanya和Kay说的话 | —————–|——————| 让我们看看Kay是否有兴趣了解WIP限制。我认为这真的会帮助她。 | Tanya: 我刚从精益创业课程回来,我有一个新想法,我想你会喜欢。太好了! | Kay: 当然。但我确实有一个测试要完成。 | 让我们慢慢开始。她是否像我一样看待这个问题? | Tanya: 是的,关于那个——实际上工程师似乎总是在sprint结束时等待你的测试。你是嗯,各占一半。她提议招聘,但我们没有预算。 | Kay: 当然。这就是为什么我一直说我们需要另一个测试人员。 | 我想解释这个,但我正在学着不跳到解释上。让我们先检查一下——她对另一个解决方案持开放态度吗? | Tanya: 我理解,但我认为除了招聘哇!我没意识到这对Kay来说是一个情绪化的问题。 | Kay: 坦白说,不会。我不认为任何疯狂的新计划能帮我处理每个sprint最后时刻被堆 Kay的情绪比WIP限制更重要。如果她愿意,我想先谈谈那些。 | Tanya: 听起来你对工作量和分配给你测试的方式感到不满。现在这比工作 | |
| 结论:轮到你了 | |
| 在尝试使用你在本章学到的四R技术(Four Rs technique)分析你自己的困难对话:记录(Record)、反思(Reflect)、修订(Revise)和角色扮 | 演(Role Play)。这些技术将帮助你与对话保持一定距离,这样你就能像其他人一样看待它。 |
| 了帮助学习进展得更快,考虑与其他人一起审查你的对话——他们肯定会像其他人那样看待它!如果你感觉非常勇敢,考虑与对话中的另一个人 | 分享你的分析,以发现他们的观点,并征求他们的建议,了解你如何修订对话以更有效地与他们沟通。 |
| 你分析你的对话时，请记住你已经知道你追求的结果：你想要进行那种你所倡导的富有成效的对话。正如我们在本章开头所展示的，Chri | s Argyris 发现我们几乎普遍知道能够产生最佳决策的行为——这些行为表明我们在分享信息和推理时是透明的，并且我们对他人的信息和推理感到好奇。当我们能够采用这种行动理论时，我们就能够利用我们多样性的力量。然而，当面临富有成效的冲突挑战时，我们本能地回避机会，转而采用防御性推理(defensive reasoning)思维模式，试图最小化威胁和尴尬。 |
| 然这种防御性反应是可以理解的，但对于我们这些想要获得成功转型收益的人来说是不可接受的。转型需要我们作为一个组织在行为方式 | 上进行根本性转变。除非我们满足于加入那84%尝试数字化转型但失败的公司，否则我们需要学会通过首先进行对话转型来利用我们的沟通超能力。 |
* 录制你在白板前的面对面对话视频以供后续审查是一个很好的实践，我们推荐这样做，尽管在我们合作过的大多数团队中这种做法未被充分使用。
** 这种距离感的极端版本由我们的朋友和老师 Benjamin Mitchell 实践过，他使用录音机来记录他的对话。他告诉我们，当他第一次在录音带上听到自己的声音时，当他注意到自己犯的错误时，他会对着录音机大喊：“Benjamin！不要那样做！”
*** 有两个例外：首先，如果你与他人共同撰写案例，你可以包含对方的想法——这可以是一个非常有益的练习，也是一个令人恐惧的练习（参见第5章的例子）。其次，如果你已经发展出心灵感应能力，这个规则对你不适用。但如果你真的能读心，那么坦率地说，这本书的大部分内容对你不会有太大用处！
**** 我们最近在更短的”两行”案例中取得了成功，只包含你的一句话和对方的一句话。即使在非常简短的交流中，关键的洞察仍然可以被发现，我们向你保证！
建立信任是帮助你的团队摆脱泰勒主义(Taylorist)特性工厂并建立高绩效文化的最基本步骤。一个相信员工没有善意行事的高管将无法接受承诺或提供支持来实现这些承诺。一个向团队隐瞒信息的技术负责人将永远无法克服恐惧。而一个怀疑同事怀有不可告人动机的开发人员或产品经理将无法提出或就有效的Why达成一致。
因为它是在其他对话中取得成功的绝对先决条件，我们通过调查信任的要素、分析破坏信任和建立信任的对话，以及构建信任对话的有效配方，来开始我们的”使用手册”。
在本章结束时，你将能够：
• 通过找到不一致的故事来识别低信任关系，
• 传达脆弱性和可预测性以保持透明并为建立信任铺平道路，以及
• 通过使用”人的TDD”来发现推理差异并将你的故事与他人的故事保持一致，从而释放你的好奇心。
让我们通过在隐藏的、不明显的地方寻找信任来开始我们对信任的考察。我们将遇到一家陷入困境但虚构的科技初创公司的一些关键员工。他们的困境各不相同，但他们都不知道一个隐藏的问题——缺乏信任——是所有困难的根源。
两位创始人每周五都在甘特图上争吵。
“我们可以在六周后开始Facebook集成。”
“不，我们需要把它移到三月初。我们必须先做视频上传功能。”
“但是新的身份验证系统怎么办？”
当然，这些几周后的事件从未按计划发生——有人生病了，或者出现了一个关键的bug，或者某个功能必须重建。但他们仍然为未来争吵，就好像他们可以控制它一样。最近，他们一直在想，更好的路线图工具或一些估算培训是否能帮助他们获得更准确的预测。
技术负责人已经到了崩溃的边缘。在多家公司的一线工作多年后,他非常清楚团队需要什么才能按时交付:好的规格说明、准确的估算、再多一个QA。他一遍又一遍地仔细清楚地解释这些,但似乎没有取得任何进展。他从开发人员那里得到的是闷闷不乐的、部分的服从,从财务部门得不到招聘预算,还遭到产品经理的公开反对。似乎没有人理解他负责交付,其他人需要配合他的计划。他正在制作一个责任矩阵来向大家展示各自的角色,他认为这最终能让所有人朝同一个方向前进。
产品经理正试图降低bug率。开发人员似乎从来不理解整个系统是如何组合在一起的。每个冲刺(sprint),她都给他们越来越详细的规格说明来工作。尽管如此,缺陷积压还是不断增长,所以最近她也开始编写测试计划配合规格说明,但没有明显效果。昨晚,她又在熬夜写一份复杂的功能描述时,趴在桌子上睡着了,梦见一只巨大的bug怪物在吃掉她的产品。在回家的火车上,她决定明天要在白板上画一张大的思维导图,展示系统组件的相互联系,这样每个人都能看到每个变更可能产生的影响以及在哪里测试。
这些团队成员遇到的问题很常见。如果你在软件团队待过一段时间,很可能遇到过其中一个或多个问题。他们打算采用的解决方案正是敏捷教练、Scrum会议和软件供应商推荐的那种:另一个流程、不同的工具、更多的信息流。有些书籍和课程会逐步详细地告诉他们每个人如何实施他们的计划。他们可以引用敏捷宣言(Agile Manifesto)和Scrum原则来为他们的提案增加分量。事实上,这些解决方案本身都没有问题,除了一点:每一个都注定会失败。
让我们换一种方式再说一遍——我们的主角们无论自己做什么都无法获得更好的交付或更少的bug。证书挂在墙上看起来不错,更短的冲刺会带来更频繁的发布,更长的回顾会议会产生更多的行动项,但这些改变都不会对重要的结果产生影响。
要看清真正发生了什么,让我们检查一下每个参与者的内心独白——也就是他们对自己讲述的故事:
创始人:“我们不可能理解技术问题,但一定有某种方法可以更快。”
技术负责人:“我知道该做什么,我只需要其他人跟随我实施显而易见的前进道路。”
产品经理(PM):“开发人员无法理解整个产品;我必须给他们完成工作所需的数据。”
开发人员(还记得他们吗?):“没人告诉我们任何事情,因为没人关心我们。我们应该埋头继续编码。”
有了这种(想象中的)读心术,我们可以开始看到为什么这些单方面的改变不会起作用。创始人认为他们无法理解技术,会在他们闪亮的新路线图软件中输入垃圾假设,然后得到垃圾预测。产品经理不认为角色定义是个问题——她在解释功能方面的角色非常清楚——所以她不会参与技术负责人的责任矩阵。而开发人员确信他们完全被排除在外,所以产品经理的思维导图将成为又一个要忽略的墙上装饰。
根本问题在于这次对话中团队成员的内心故事没有对齐(align)。每个故事都以连贯的方式解释了情况,对他人的行为做出预测,并帮助讲述者制定解决方案——但这些故事彼此不一致。就好像托勒密、牛顿和爱因斯坦一起建造一艘飞往火星的宇宙飞船!再多的流程创新或巧妙的工具都无法让那枚火箭到达正确的目的地。
我们有一个词来描述对齐的故事:信任(Trust)。如果我说我信任你,我的意思是我对你会做什么有预期,这些预期以前得到过满足,我相信将来还会得到满足。当我信任你时,我可以使用我们认同的故事来预测你的行为并评估我可能的行动,这样我们就能有效合作。我们很可能会制定共同设计的计划并同步执行,我们也可以向其他人解释我们的共同故事,这样他们也能与我们保持一致。
我们对信任的定义比通常的定义更强;如果你在字典里查这个词,你会发现类似于相信对方是诚实的、可靠的或有能力的解释。这样的信念对于在团队成员之间建立牢固、信任的关系当然是有帮助的,但这还不够。我可以相信你是真诚和可靠的,但仍然对你的行为和动机持有阻碍我们故事对齐并破坏我们合作能力的信念。
相比之下,如果我们的故事完全对齐,你永远不需要担心我误解或破坏你的努力。有了对齐的故事,创始人将能够让开发人员参与他们的优先级讨论,以保持目标的现实性和可实现性;技术负责人会发现他并不掌握所有答案,团队成员可以与他一起更有效地改进结构和流程;产品经理会发现她可以用与积极主动的开发人员的对话来替代详细的规格说明。
在本章的其余部分，我们将详细解释如何与团队合作，通过信任对话(Trust Conversation)来对齐你们的故事，首先帮助你变得脆弱和可预测，然后向你展示如何使用Chris Argyris的推理阶梯(Ladder of Inference)。
正如企业敏捷/DevOps主管、教练和管理者Brad Appleton所说：“首先要建立的是信任！”
我是Nell，一家小型在线零售企业的CTO。CEO Ian似乎不信任我；他总是在各种决策上推翻我。我们最近的一次互动真的让我很恼火，所以我决定分析一下这次对话。我从第一个R开始：记录(Record)。
提醒：先阅读右侧栏，然后从右到左阅读。
| Nell的想法和感受 | Nell和Ian说的话 |
|---|---|
| 又来了。你为什么不能让我们清静一下？ | Ian：我受够了我们的支付提供商。我们必须更换他们。 |
| 他们是业内最好的。任何替代方案都会更糟。 | Nell：我们为什么要这么做？我们才用了他们三个月。是有一些磨合问题，但现在一切运行顺利。 |
| 如果他们像我们培训的那样输入正确的数据，收入就会被正确分类。垃圾进，垃圾出。 | Ian：顺利？不可能。他们每个月都把我们的发票搞砸了。财务部不得不手动核对。又来了。 |
| 我们不会仅仅因为会计们不能阅读基本说明就去惹恼客户和我的整个团队。 | Nell：唉。我之前就告诉过你，他们没有正确设置报告。支付集成一直很可靠，客户投诉也大幅下降了。如果我们只是获取正确的产品元数据— |
| 又在施压！既然你要自己决定所有事情，为什么还要雇用我？ | Ian：完全不能接受。财务是这家公司的命脉，如果他们不满意，我们就必须更换供应商。就这么定了。 |
| 在第一次集成三个月后又来一次支付集成。我该怎么向团队解释这件事？ | Nell：好吧，如果你坚持的话。 |
与Ian的信任已经降到了最低点。他似乎认为我不称职，而我确信他在微观管理，并通过向财务部屈服来玩弄政治。我感到被困在这种情况中，无法摆脱他的控制行为。我想建立信任来摆脱这种痛苦的经历，但我不确定从哪里开始。
在信任对话中对齐故事将要求你做一些非常困难的事情：分享你当前的故事。这意味着向别人敞开你的感受和想法。这样做，你有可能受到伤害——这是我们在引言中告诉过你要预期的艰难情感工作的一个突出例子。
如果你事先已经确立了自己愿意变得脆弱——你自己会更习惯这样做，其他人也会认为你平易近人——认为你在邀请他人分享他们的故事，这将有助于你进行信任对话。
为了克服保护自己故事的本能，试着让自己脱口而出”不安全”的事情；例如，问”愚蠢”的问题或分享你对如何得出特定结论的疑虑。当你对自己知道什么和不知道什么保持透明时，你就在变得脆弱，因为你可能不会显得像你希望的那样理性和知识渊博。相比之下，试图感到安全和避免脆弱——比如假装知道你没听说过的事情——通常会提供虚假信息，使你们的故事进一步分离；如果你被发现了，这向你的对话伙伴表明你对自己不诚实。这证实了你们的故事确实不一致，并削弱了他们对你的信任。
在《勇敢站起来：重置能力如何改变我们生活、爱、养育和领导的方式》(Rising Strong: How the Ability to Reset Transforms the Way We Live, Love, Parent, and Lead)中，Brené Brown在分享内部推理时使用了这样的短语：“我告诉自己的故事是……”。例如：
“我告诉自己的故事是，这里没有人在乎洗碗，所以办公室厨房总是很臭。”
“我告诉自己的故事是，我们的用户是吝啬鬼，要求最便宜的选项。”
“我告诉自己的故事是，你没有在做这个项目，因为它很无聊。”
这句话帮助你保持”学习心态”，因为它意味着对自己和他人明确表示，你的推理基于有限的证据，而且你的推理可能是错误的。这是对Daniel Kahneman在《思考，快与慢》中描述的”你看到的就是全部”这种本能观点的有用解药[3]; 它提醒你有很多你看不到的东西。它还有助于在听者中建立同理心，因为他或她可以理解你的故事从何而来，而不会受到叙述的威胁。
这些不熟悉的技巧一开始可能显得笨拙，但通过练习，分享你内在推理的想法，同时也分享你并不执着于它，会变得自然。你将在本章末尾的示例对话中看到这种行为的几个例子。
仅有脆弱性是不够的。如果你想让你的故事与他人的故事保持一致，那么你还必须给他们证据，证明你的故事实际上是有预测性的，它与你的行动相匹配。
相反的行为随处可见，通常以无意的虚伪形式出现：诚恳的节食者一边讨论他最新的减肥计划，一边吃着满配汉堡；出租车司机一边抱怨糟糕的司机，一边闯黄灯并强行变道；墙上的海报宣称”我们尊重我们的员工”，而老板们站在下面斥责他们的下属。
在你认为这些只适用于他人之前，我们建议你仔细思考自己的理论和行动——如果你是人类，我们确信你自己的生活中也有几个故事-行为不匹配的例子。
为信任对话做好充分准备，意味着尽可能克服这种人类的自然倾向，并调整自己的行为和理论以展示可预测性。当你不可避免地未能做到这一点时，承认你的错误并请求他人帮助你在未来更好地调整。
将你的行动与你自己的故事保持一致已经够难的了。但即使当你真正按照自己的信念行事时，你可能仍然需要做更多来说服他人你是可预测的。
Billy，我们几年前认识的一位程序员，对他的老板有一个坚定的理论：他们想对付他，给他不可能完成的任务和幻想般的截止日期，任何新举措都必定是那些讨厌的经理的狡猾伎俩。当他的团队聚集在一起举行第一次敏捷规划会议时，他展示了这一理论，该会议的目的是梳理可能的项目，并选择那些可能适合第一个冲刺(sprint)的项目。当十个潜在功能的列表出现在白板上时，甚至在团队在最高层面估算任何故事之前，Billy就大声宣布这次会议是最后一根稻草，他要辞职了。困惑的经理把Billy拉到一边问发生了什么事。“没有人能在一个冲刺中完成所有十个项目！”Billy叫道。“你只是想让我们累死，这样你就可以用外包的机器人替换我们。”
Billy对管理层的负面故事根深蒂固，以至于他真的听不到他的经理在规划会议开始时的解释，即团队只会选择那些能够舒适地适应冲刺的故事。还有更多的证据，以规划会议本身以及正在引入的其他敏捷实践(Agile practices)的形式，表明Billy可以依靠他的经理来照顾团队的需求，但他还不能将其与他告诉自己的故事保持一致。
通过与Billy的信任对话，我们了解到他的理论已经通过在多个虐待性工作中的就业得到了坚定的强化，包括一份高级领导定期从看板(kanban board)上删除团队估算并用他们自己的估算替换的工作（“我确信我们可以在周五之前完成这个十点故事，”他们会说）。Billy经历了许多次声称尊重团队需求，然后实际上执行了这种尊重的经理的重复经历，才与Billy建立了信任并创建了一个替代的共享故事。
我们经常发现，你可以通过小的、高度可见的步骤建立初始的可预测性，这些步骤不一定直接与信任对话的主要问题相关。例如，在Billy的程序员团队中，一个持续的烦恼是非技术人员反复要求修复打印机或互联网连接。他的经理宣布这种做法将结束，当无法足够快地找到外包IT服务时，他自己开始在地板上爬行，追踪电缆并重置路由器。这清楚地向Billy和他的同事表明，当经理做出承诺时，它会被兑现，这有助于建立明确的可预测性声誉，这在其他领域建立信任方面非常有用。
Kent Beck说，测试驱动开发(TDD)，与代码同时编写测试的实践，给了他”一种舒适和亲密的感觉”[4]。这正是我们希望你在信任对话中拥有的感觉，帮助你实现这一目标的工具是推理阶梯(Ladder of Inference)，这是Chris Argyris及其同事提出的另一个概念（见图3.1）[5]。
改编自Peter Senge，《第五项修炼》
图3.1：推理阶梯
请注意，阶梯讲述了一个连贯的故事：从数据中，你得出意义，这给你带来假设、结论和信念；从这些，你决定你的行动。信任对话(Trust Conversation)的目标是将你的故事与对话伙伴的故事对齐，而阶梯提供了一种明显的方式来构建这种对齐：首先在最底层对齐，然后是第2层，依此类推，直到你们的故事匹配。
如果双方的阶梯都是可见的，这会很容易，但正如你从图3.1中看到的，只有最底层（观察）和最顶层（行动）存在于你的头脑之外，其他人可以看到它们。其他一切都是不可见的——这就是TDD for People的用武之地。正如Argyris、Putnam和McLain Smith所说：
应该清楚的是，不同观察者在解释上的差异可能性随着推理阶梯的上升而增加。因此一些基本规则是：从推理阶梯的最低层开始，陈述下一个更高层的意义并检查是否达成一致，只有在较低层达成一致时才继续到下一个更高层。这些规则不仅适用于行动科学家，也适用于日常生活中的行为者，无论何时他们处理重要和具有威胁性的问题。6
当使用TDD编写代码时，你以自信的小步骤缓慢前进。类似地，当使用推理阶梯时，你将以经过测试的小步骤上升，每一步都会增加你的信心。在每一步，你都会向你的伙伴提出一个关于她在该层推理的真诚问题，如果需要，也会解释你自己的推理。（我们在第2章中更详细地描述了真诚问题。）这将逐层揭示双方的阶梯，这样你就可以理解它们的差异所在。当你的测试失败时——也就是说，当你对问题的答案感到惊讶或不理解，暴露出不对齐时——你会停下来，重构你的理解，然后重试测试。最后，你和你的伙伴将更紧密地对齐你们的阶梯，因此也对齐了你们的故事；在你们仍然不完全同意的地方，你至少会理解彼此的动机。因此，你将为未来建立实质性的信任。
让我们通过一个例子：假设你的团队正在开发一个为客户设定和调整价格的系统，你注意到一位最近加入团队的成员Helen抱怨定价算法过于复杂而难以维护。由于包括你在内的其他人都在愉快地处理这段代码，你认为存在一种影响信任的不对齐，因为Helen的抱怨削弱了士气，她拒绝所有改进问题代码的建议。你开始怀疑她和可能其他人将拒绝更新价格，直到整个子系统被重写，而你认为公司现在无法承担这样的成本。
第1层：可观察数据。“Helen，我在站会上听到你说定价代码过度工程化了。我理解正确吗？”
“是的，任何人都能看出它难以理解。”
你已经为对话建立了基础——Helen看到了复杂性问题。你的测试是绿色的；继续下一步。
第2层：数据选择。“明白了。对我来说，任何复杂代码的重要部分是它的架构——它如何划分为块——因为这是最难改变的。这也是你最关心的领域吗？”
“绝对是。我的意思是，注释和变量名很糟糕，但我们可以随着时间推移进行重构来改进这些。但我看不出任何新加入者如何能够理解我们现有的这么多微小类。”
在听到你的推理后，Helen确认了一致。再次绿色。（注意我们不必同意Helen认为架构实际上客观上是复杂的——只是她这样感知。）
第3层：意义。“好的。所以这对我来说意味着你会发现很难向系统添加新价格。对吗？”
“当然！这就是为什么我要求被重新分配到编辑页面设计。”
你们的故事继续匹配；Helen同意感知到的复杂性是她工作的障碍。绿色测试：继续前进！
第4层：假设。“那么你是在假设定价算法对你来说太难处理了吗？”
“当然，但不仅仅是我——Ramona说她也搞不懂。”
一个新事实：Helen在对代码的评估上并不孤单。但这是另一个绿色测试——你们的故事继续匹配。你可能开始想知道不对齐在哪里，或者它是否存在。
第5层：结论。“我猜你在想我们应该重写那段代码了。”
“什么？不，那会浪费时间。你和其他专家可以继续研究它，而我们这些新手坚持做用户界面。”
红色！这就是不对齐。你以为Helen在争取一次昂贵的全面改造，但她建议只有经验丰富的团队成员才能处理复杂的算法。是时候重构了！
第5层：结论，再次。“啊，我没有理解你的想法。你的结论是定价复杂性意味着像你这样的新加入者不能处理那段代码，对吗？”
“当然；这就是我一直在说的。我们只是没有足够的经验来安全地进行更改。”
现在我们又是绿色了；我们理解了Helen的想法，即使我们与它导致的行动不一致。继续下一层，但有了新的理解。
梯级 6: 信念。“所以听起来你相信，对新团队成员设置一些任务限制是个好主意。但我有不同的信念——我认为我们应该提升每个人的技能,让他们能够参与任何功能的开发;这样每个人都能学习,我们也能最大化每位开发者的价值。你怎么看?”
“我确实认为自己必须坚持做简单的部分。但如果我们能负担得起,我可以支持培训这个想法。”
这就是实时发生的协调。现在你们的结论一致了,Helen 更容易让她的信念与你的保持一致。成功!
梯级 7: 行动。“太好了!我愿意安排我们的定价专家 Maria,让她在下周培训你和 Ramona 学习定价算法。这样可行吗?”
“当然!我不知道还有这个选项。我愿意试一试!”
通过协调我们的故事,我们达成了 Helen 认同的行动。更棒的是,Helen 可以将这个共同的故事应用到其他可能具有挑战性的领域,请求培训或帮助来提升技能,而不是抱怨无法做出贡献。换句话说,我们与 Helen 建立了信任。
为 TDD for People 打分
要为考虑 TDD for People 的对话打分,请在任一列中标注你的陈述和问题对应的梯级。如果你从梯子的底部开始,从数据、选择和意义开始,然后随着对话的进展向上移动到假设、结论和信念,那你就走对了。但如果你大部分时间都在梯子的顶部,考虑在继续之前有意识地让自己回到较低的梯级。
让我们回到 Nell 的对话(见第 57-58 页),看看她能否使用 TDD for People 进行一次更真诚的对话。
Nell 的信任故事续集
反思、修改和角色扮演
我首先对我的对话进行了基本打分。我有一个不真诚的问题,问这个问题只是为了让 Ian 改变主意——这是一种单边的、模型 I 的方法,并没有奏效。我只分享了左栏中的一两项内容。而且我中途的”啊”显然是一个明显的信号,表明我正在沮丧地放弃。
然后我为 TDD for People 对对话打分,结果更糟糕。我几乎把所有时间都花在结论或更高层级上,只偶尔访问数据或意义来支持我的论点。在这里我显然不太透明也不太好奇。
最后,我决定下次采取一些修改后的行动。我会尝试强迫自己在进一步上梯子之前先询问数据、意义和假设。我还会尝试更多地分享我的推理,并注意到我何时开始感到沮丧。我尝试与我的朋友——也与 Ian 有冲突的销售总监进行角色扮演,这让我们都有机会练习慢慢地上梯子。
改进后的对话
Ian 提议我们采用 Blaze 作为新的支付提供商。在我以太难合作为由拒绝后,他还是安排了与 Blaze 团队的会议。我很生气他不信任我做决定并再次推翻我,但我也想通过尝试在分析中开发的技巧来理解他的推理。
Nell 和 Ian 的修改后对话
| Nell 的想法和感受 | Nell 和 Ian 的对话 |
| 首先把事实弄清楚——保持在梯子的底部。 Ne | ll: 我看到 Blaze 团队周三要来,对吗? |
| 真是浪费时间!他们的推荐评价很糟糕。等等,我跑得太快了,开始感到 Ia 沮丧了——我应该专注于下一个梯级。 | n: 是的。我想我们应该亲自看看这个系统。 |
| 好吧,他确实邀请了他们。让我们弄清楚这意味着什么,同时分享它对我 Nel 的意义。 | l: 这意味着他们仍然有可能成为我们的新供应商,对吗? |
| 至少他读了我的报告。 I | an: 嗯,不完全是。他们现在的用户告诉你他们的支持很糟糕,不是吗? |
| 这说不通。他是不是在搞什么名堂? Ne | ll: 是的,但现在我真的困惑了。既然我已经排除了他们,你为什么还要预约访问? |
| 我从没听说过把供应商当作练习目标。这样可以吗?? Ia | n: 嗯,我想确保我们对接下来几个候选者有一个可靠的筛选流程,我想我们可以用 Blaze 练习一下。 |
| 嗯,这不是我担心的。他的意思与我想的不同。 Ne | ll: 我明白了——有点像预演。 |
| 这对我的团队确实有好处——他们中的一些人以前从未做过任何软件选型。 Ian | : 没错。其他供应商不能亲自访问,我想在电话前与面对面的人一起试验问题对我们团队来说会更容易。 |
Blaze会怎么看这件事？ Nell: 有道理。不过这对供应商似乎不太公平。 Ian: 也许吧，但销售代表确实有机会在拜访时给我们留下深刻印象，改变我们的看法。不过我会很惊讶他们能做到。天哪，澄清了Ian的想法后我感觉好多了。他根本不是在否决我！ Nell: 我也是！
哇，这完全改变了我的想法。我只是在推理阶梯上走了一小段距离，到达意义(Meanings)阶段，就突然意识到了。现在，我开始相信”Ian会倾听我的意见，并希望我的团队学会如何选择供应商”，而不是最初的故事——“Ian不听话，只做自己想做的事”。
如果我们继续确认这个共同的故事，将来我会更容易信任他，我们也能共同设计解决合作伙伴管理问题的方案。
现在让我们更深入地看一些信任对话(Trust Conversation)的实际案例。
Ursula说：“作为我们创业公司的创始人，我初步决定雇用一位新的CTO，尽管他在与大部分开发团队的现场面试中表现很糟糕。我想向团队——Al、Betsy和Carlos——解释我的想法，并回答我预料中会从不满的工程师那里得到的尖锐问题。”
Ursula与开发人员的对话
| Ursula的想法和感受 | Ursula和开发人员说的话 |
|---|---|
| 最好一开始就全盘托出。 | Ursula: 我决定雇用Zeb作为我们的新CTO。我知道这不会受欢迎，但我想解释一下为什么做出这个决定。 |
| 哎哟。Al不会外交辞令——但如果他对Zeb的看法是对的呢？ | Al: 你疯了。他说我们的主要产品很糟糕，必须重建。 |
| 不能回避事实。 | Ursula: 我知道Zeb在面试中的表现很糟糕。你们愿意听听我是如何在这种情况下做出这个决定的吗？ |
| 正如我预料的，这是一群持怀疑态度的人。 | Betsy: 好吧，但这最好有充分的理由。 |
| 让我们从可观察的数据开始。我有遗漏什么吗？ | Ursula: 很好。我认为Zeb经验非常丰富，而且很有主见。你们是这样看他的，还是有不同看法？ |
| 很高兴Zeb的技能确实展现出来了。 | Carlos: 当然，他确实很懂行。 |
| 我们真的需要专业知识——团队中的大多数人以前从未构建过像我们产品这样的东西。 | Ursula: 对我来说，这意味着他可以给像我们这样缺乏经验的团队带来很多东西。 |
| 一个很好的问题。 | Betsy: 是的，但当他一直表现得像个混蛋时，他怎么能教我们任何东西呢？ |
| 我确信我能让Zeb软化他的方法，但我想知道团队是否认同我的信心。 | Ursula: 我的假设是，如果我亲自指导他，他可以学会建立关系和良好管理。你们认为这有可能吗？ |
| Al反对并不意外；他承受了Zeb的大部分批评。 | Al: 你是一位很棒的教练，Ursula，但即使对你来说，Zeb也无药可救了。 |
| 我们能同意保留不同意见吗？ | Ursula: 我尊重你的观点，Al；但我指导过许多难相处的人，我看到Zeb有巨大的学习潜力。你愿意让我试试吗？ |
| 很高兴Al愿意给我一个机会。 | Al: 如果你能成功，我会很惊讶，但好吧。 |
| 其他人怎么样？ | Ursula: 当然，Al，你可能是对的。你们其他人呢？如果我经常给予他个人指导，你们是否同意我的结论，认为Zeb值得一试？我会将他的试用期延长到三个月，让我们所有人都能看到他的表现。 |
| 好的。 | Carlos: 当然。 |
| Betsy: 我愿意试试。 | |
| 既然我们有了共同的推理，现在可以继续前进了。 | Ursula: 太好了，谢谢你们。我相信我们很快就能发现Zeb是否适合我们。我会每隔几周检查一下你们的感受，好吗？ |
Ursula 本可以轻易地将自己的意愿强加给团队，单方面宣布 Zeb 的入职日期。相反，她分享了自己的推理过程，并部分地将她的故事与团队的故事对齐。并非所有人都同意，尤其是 Al，他的期望仍然与 Ursula 的期望有很大不同。但现在这些差异可以讨论了，团队也知道 Ursula 将对 Zeb 的辅导进展向他们负责。
Isaac 说：“Erin 负责运营，而我是开发人员。我们经常构建一些功能，这些功能本应让她的团队工作更轻松，所以我们经常交流。她作为’个人回顾’的一部分向我征求反馈以进行自我改进，我给了她反馈——但对话的发展方向与我预期的不同。”
| Isaac 的想法和感受 | Isaac 和 Erin 的对话 |
|---|---|
| 我想帮助她。她需要知道接近她有多难。 | Erin：谢谢你帮我提供反馈，Isaac。我应该在哪些方面改进？ |
| 我会缓和一下打击——实际上，我们大多数人甚至不再尝试询问更多细节了。 | Isaac：嗯，你可以帮助你的团队提交更清晰的 bug 和功能请求。正如你可能知道的，我们中的一些人避免向你询问澄清，因为你可能有点令人生畏。 |
| 哇！为什么反应这么强烈？她确实要求反馈，那她期待什么？ | Erin：令人生畏？！这是从哪来的？ |
| 她确实名副其实。我会从推理阶梯(Ladder of Inference)的底部开始。 | Isaac：我注意到你的脸红了，说话声音也更大了。这是—— |
| 至少不只是我一个人看到这种模式。 | Erin：当然是这样！我一直听说我”很吓人”，但我竭尽全力保持可接近性并获取反馈。 |
| 好吧，与其猜测，我会明确地了解她的反应意味着什么。 | Isaac：听起来听到这个真的让你很担心。对吗？你感觉如何？ |
| 她怎么能看不到她是如何吓跑别人的？ | Erin：烦恼和沮丧——我无法摆脱这个不应得的名声。这与我想要的和我观察到的相反。有没有一个我吓到别人的真实例子？ |
| 这次对话就是一个很好的例子！ | Isaac：嗯，我现在因为你的反应感到有点害怕。 |
| 嗯，我实际上想不出另一个例子。这意味着什么？ | Erin：这很公平，我很抱歉。这个反馈真的很难听。但当有人要求我澄清 bug 报告时，这种情况不会发生。 |
| 我没想过，但实际上我们从来不直接问 Erin。总是 Maria 告诉我们走开。 | Isaac：实际上，你说得对。我想起来了，通常是你团队中的 Maria 有最不屑一顾的反应。 |
| 这是个合理的问题。 | Erin：那你为什么认为我是令人生畏的那个人？ |
| 她确实把责任推给了 Erin。 | Isaac：我猜是因为她说是你告诉她不要花时间帮助我们。 |
| 这出乎意料地有帮助。 | Erin：我想我们可能找到了问题所在——我对 Maria 和团队其他成员的指示不够清晰。谢谢你和我一起思考这个问题。 |
信任对话(Trust Conversation)并不总是你可以计划的事情；在这里，它在 Isaac 没有预料到的时候悄然而至。对 Erin 的爆发以同样的方式做出反应本来很容易，比如”你又来了，抨击一个只是想帮助你的人”，但那将直接跳到推理阶梯(Ladder of Inference)的顶端，不会建立信任。相反，Isaac 设法停留在底部的阶梯(数据、选择和含义)，经过反思后，发现他自己的看法和反馈并不像他想象的那样准确。Erin 和 Isaac 现在对 bug 报告和 Erin 希望做出回应有了共同的故事，这应该有助于他们以更大的信任一起工作。
“我只是想让开发人员开心，”Geckoboard(一家仪表板软件制造商)的创始人 Paul Joyce 说。“生产力和利润可以稍后再说。现在，我只想看到他们享受自己的工作。”我(Squirrel)点了点头，想知道是什么让工程师们如此沮丧。
显然，在来到现场仅一天后，我就发现 Geckoboard 这个由十人组成的小型技术团队有些不对劲。在宽敞的技术室里，堆满了桌游和 Ruby 书籍,每天有四次站会,但每次汇报的内容却很少。回顾会议生硬且没有成效。会议拖延数小时,却几乎没有什么活力或产出。关于技术或流程的冲突即使有表达,也是间接的。正在进行的项目很多——几乎和负责执行这些项目的开发人员一样多!——但没有一个项目显示出很快会完成的迹象。讽刺的是,公司自己的一个仪表板挂在技术室的墙上,显示着一张巨大的图表,表明收入一直顽固地持平,错过了今年迄今为止的每个月度目标。
毫不奇怪,类似的倦怠感也困扰着公司的其他部门,他们的办公桌挤在伦敦小办公室的另一个房间里。客户服务团队成员试图积极地谈论产品,但无法告诉用户何时可以期待错误修复。市场和销售部门想要宣传新功能来吸引关注,但却没有什么可以宣扬的。Paul 自己感到失望和孤立,看不到让组织启动的方法。事实上,唯一能看到的欢快存在是 Mr. White,这只办公室的狗,它吠叫着宣布访客的到来,并在走廊上追逐玩具。
当我看着 Mr. White 来回奔跑时,我注意到一些奇怪的事情:它穿过两个房间之间的门口,但其他人却不这样做。这两个群体被一堵墙隔开,不仅是物理上的,也是心理上的。他们每天到达时几乎不互相打招呼,随着一天的推进也很少说话。与 Mr. White 不同,他们各自待在自己的房间里,很少冒险进入对方的领地。我想知道,是什么分隔了这两个群体?为什么他们不能合作?
我决定第一步是展示可预测的进展。我们合并了站会,关闭了除一个项目外的所有项目,这个项目是与一个热门产品的集成,似乎很可能让客户兴奋并支付更多费用。在这个单一结果上增量交付,在开发团队中建立了活力和兴趣,生产力和情绪开始提升。一位天生的领导者 Leo 从团队中脱颖而出,并开始清除障碍、提高效率。逐渐地、小心翼翼地,开发人员和产品经理之间开始建立信任。他们必须展示脆弱性来做出最初的承诺,但最终小胜利的可预测交付增加了他们彼此之间的信心。
即便如此,Mr. White 仍然是公司两半之间唯一的定期通勤者。工程师们向我描述了他们关于公司其他部门的负面故事:“没有人关心修复错误”,“他们不告诉我们接下来会有什么销售”,“Paul 不关心员工。”Paul 告诉我他感到孤立、无力和不参与,即使开发人员开始交付更多。显然还有更多工作要做。
首先,我们创造了互动的机会——为销售部门举办展示会,邀请支持人员参加回顾会议。至关重要的是,我们让 Paul 参加站会,在那里他能够通过分享自己的孤立感和对停滞不前的财务指标的沮丧来展示一些脆弱性。我还为每个人主持了一个关于 TDD for People 的简短会议,期望这个工具能帮助双方分享故事并增加信任。
关键的突破出现在 Leo 和 Paul 坐下来进行后来被证明是信任对话(Trust Conversation)的时候。Leo 和我进行了角色扮演来准备,他知道他想从询问对他来说最大的信任障碍开始:最近两名关键员工看似突然的离职。通过提出诸如”你什么时候决定他们必须离开?““他们做错了什么?”和”他们的离职对你意味着什么?“这样的问题,Leo 能够分享他的故事——Paul 快速而草率地解雇了这两个人——并理解 Paul 的故事,其中包括在不眠之夜后做出痛苦的决定,以及比 Leo 想象的更多的幕后谈判和讨论。
到对话结束时,Leo 开始相信 Paul 的行为比他之前想的要富有同情心和考虑周到得多;Paul 终于明白了为什么技术团队中的一些人认为他”扣动扳机很快”,准备随心所欲地解雇人,从而远离他,拒绝他试图激励和领导的尝试。
毫不夸张地说,Leo 和 Paul 之间的信任对话是改善整个组织关系和绩效的转折点。在 Leo 的支持下,Paul 能够与开发人员更密切地接触,然后将”非技术”房间的其他人带入演示和设计会议,进行成功的互动。工程师们,无论是单独还是集体,都能够就以前的决定询问 Paul,建立起他和业务其他部门的人不是任意行事的信心。随着时间的推移,两”方”之间更大的合作带来了更好的产品决策和改进的客户满意度。
今天,四年后,Leo 现在是工程副总裁,与 Paul 在相互信任的关系中密切合作。员工定期使用推理阶梯(Ladder of Inference),开发人员和非技术人员之间的协作很常见;一些支持人员甚至学会了编程并组建了自己的开发团队。客户参与度提高了,收入正朝着正确的方向发展。
哦,Geckoboard 去年搬到了新办公室——中间没有墙。
在本章中，你学习了内在故事的重要性，如何通过脆弱性(vulnerability)和可预测性(predictability)向他人展示你愿意并能够改变你的故事，以及用于将你的故事与他人对齐以建立信任的”人际TDD”技术。对齐的故事使我们能够安全地采用成功的对话式转型所需的透明度和好奇心。你可以通过多种方式使用信任对话，包括以下几种:
高管领导者可以与员工建立信任关系，让各方都有信心，确信文化转型正朝着正确的方向前进，而无需微观管理和持续监督。
团队负责人可以与她的团队对齐故事，消除无效的内斗和争论，转而合作实现冲刺目标和产品目标。
个人贡献者可以提升与同事之间的信任，实现更有效的协作，这样他就能在代码审查、估算和结对编程等协作活动中获得和提供更多帮助。
我们从未见过一个既充满恐惧又取得成功的敏捷(Agile)（或精益(Lean)或DevOps）团队。恐惧是转型的最大障碍之一。一个组织可能遭受对错误的恐惧、对失败的恐惧、对构建错误产品的恐惧、对让管理者失望的恐惧、对暴露糟糕领导力的恐惧，以及对其他任何数量的灾难的恐惧。无论其特定主题是什么，恐惧会使团队瘫痪，抑制创造力和合作。一个顺从、恐惧的团队很适合泰勒式(Taylorist)工厂，在那里不需要思考；但要在工厂之外的协作、高绩效文化中运作，你不仅需要在上一章建立的信任，还需要你将在本章构建的心理安全感(psychological safety)。
因此，我们继续我们的操作指南，提供一些方法来帮助你发现自己的恐惧，定位和理解他人的恐惧，并领导一场恐惧对话来缓解各方的恐惧。无论你是试图组织跨职能团队却遭遇抵制的CTO，还是渴望帮助团队培养勇气尝试新消息传递模式的系统架构师(system architect)，或是害怕提出可能不受欢迎的用户旅程的设计师，你都会发现这些技术很有益处。在本章中，你将学会对你和你团队的恐惧保持透明，并对如何缓解它们保持好奇。
当你掌握这些技术后，你将能够:
• 识别团队中不安全但已被接受为”我们的做事方式”的实践和习惯。这种偏差常态化(normalization of deviance)是一个信号，表明存在需要被发现和解决的隐藏恐惧。
• 通过使用一致性破坏(Coherence Busting)来克服你自然而然、不费力地跳到结论的倾向。你的大脑毫无疑问地接受的连贯故事几乎肯定会让你对看待事件的替代方式视而不见，包括影响部分或全部团队的合理恐惧。
• 共同创建一个恐惧图表(Fear Chart)，通过使用前两种技术生成候选恐惧来发现团队恐惧，然后，最重要的是，有效地缓解这些恐惧。
想象一下我们两个农业时代之前的祖先，Og和Ug，他们的部落靠从灌木丛中采摘或用石头砸死的任何东西为生。有一天，两人一起出去狩猎兔子，但一进入树林中的空地，猎人们就僵住了。高草丛正在分开，有比兔子大得多的东西正在穿过，两人都能听到巨大的脚踩在泥土上的微弱但逐渐增强的声音。
Og想:我想知道那只大动物是什么?可能是鹿——整个部落的食物! 充满好奇，Og大步向前迎接未知的野兽，高举着石头。
Ug想:哦不，是一只大动物——可能是一只饥饿的熊!我们应该躲开它! 惊恐万分，Ug爬上了最近的树。
你当然可以自己完成这个故事。重点是我们所有人都是Ug的后代。如果你在面对新的和未知的数据时默认采取好奇态度，那么你在森林中活到高龄的几率不大。相反，如果你默认采取恐惧态度，你可能会活着生很多孩子，并将你本能的恐惧传给他们。
“Ug遗产”的问题在于它非常不适合现代社会，在现代社会中，鹿（学习的机会）远远多于熊（实验灾难性后果的出现）。你的团队在遇到客户对新版本的反对或来自市场部的意外需求时，很可能会像优秀的Ug后裔爬树者那样做出反应——推迟发布或拒绝新功能请求。我们身边没有多少勇敢的Og，他们会本能地找到方法让软件发布出去或将用户故事插入到冲刺中。因此我们左右都在失去学习的机会，我们想知道为什么我们的团队没有像我们认为应该的那样迭代和改进。
在Amy Edmondson的《团队合作：组织如何在知识经济中学习、创新和竞争》中，Edmondson将Og状态称为”心理安全感”（psychological safety）。具有这一特征的团队拥有”开放的氛围”，能够毫无畏惧地讨论问题并尝试实验来解决这些问题。例如，她发现，尽管你可能认为报告很少操作错误的护理小组是表现最好的，但事实恰恰相反；那些报告更多错误的小组获得了更多学习的机会，因此获得了更好的结果。Kent Beck在《极限编程解析：拥抱变化》中也敦促敏捷团队”重视勇气”，采用诸如持续重构和频繁反馈等实践。正如你可能从第1章回忆起的，Allspaw和Hammond敦促DevOps实践者无畏地接受”失败将会发生”。
恐惧对话（Fear Conversation）将通过揭示恐惧并允许缓解它们来帮助你在团队中创造心理安全感和勇气。困难的情感工作在于分享你和对话伙伴的恐惧——需要诚实和脆弱性——并发现信息，使你们双方都能缓解让彼此感到恐惧的风险。
我们合作过的一个团队在多年代码疏忽的重压下工作——执行某些重要但未知功能的难以理解的模块；功能耦合如此紧密以至于手动测试都不可能，更不用说运行（不存在的）单元测试；标注着”不要按这个按钮”的按钮。一位开发人员无辜地打开一个网页查看它是做什么的，结果它运行了一个不可见的脚本，将网站上许多价格降低了一千倍！
可以理解的是，这种环境释放了团队内心的Ug，整个团队都因为担心任何改变，无论多小，都可能引发灾难而陷入瘫痪。由于害怕因造成bug而感到尴尬，他们拒绝提交和发布代码，创建越来越大批量的工作，而不是小而频繁的交付。反复告诫”请求宽恕，而不是许可”的话充耳不闻，进展充其量只能说是缓慢的。
恐惧对话揭示了开发人员认为如果他们的行为结果不好会受到训斥或被解雇，而且有充分的理由相信这一点，因为高管之前曾因失败而惩罚个人或整个团队。然而事实也证明，该组织实际上非常友好于风险：错误的结果甚至停机都几乎没有后果，而且肯定没有任何后果会超过延迟改进的成本。
一旦各方通过恐惧对话揭示了他们的恐惧，我们就可以开始创造性地制定风险缓解措施。我们将开发人员的座位移到客户服务团队附近，客户服务团队总是第一个听到网站问题的，并同意程序员会留意来自隔壁办公桌的问题。我们还提供了一个大红色按钮，按下后可以立即恢复最近的发布。最后，我们在白板上用大字写上”YES”，当有人问我们是否应该发布时，默默地指向它。结果，经常能听到呼叫中心传来”网站宕机！“的声音，几秒钟后工程部门就传来”恢复了！“的声音，因为他们兴高采烈地按下了大红色重置按钮。
发布开始每天进行，然后一天多次；内部和外部客户都对我们解锁的快速进展感到高兴。通过恐惧对话创造心理安全感使团队能够全面显著改善他们的结果。
接下来，我们将探讨如何通过寻找”偏差常态化”（normalization of deviance）并创建一个框架来指导对话，为恐惧对话做准备。
我是Tara，一家小型创业公司的两位创始人之一，该公司向销售团队提供反馈跟踪产品。每周我都害怕与我的联合创始人Matt进行规划会议，Matt负责我们的技术团队。我担心我们会让客户失望，我很生气我们没有构建他们期望的完整、功能性的产品。规划会议只是证实了这些恐惧，因为Matt为不构建客户需要的东西找了一个又一个借口。
在上次规划会议期间，我感到非常不安，以至于身体都不舒服了。我希望分析这次对话能帮助我找到摆脱这种情况的方法，从下面我们所说的话的记录开始。
提醒：先阅读右栏，然后从右到左阅读。
| Tara 的想法和感受 | Tara 和 Matt 的对话 |
|---|---|
| 真是一场灾难！ | Matt：我们这个冲刺(sprint)无法完成新报告的排序或筛选功能。 |
| 我们必须加入这些功能——用户们强烈要求。 | Tara：什么？！你不想让人们使用它吗？用户研究非常明确地告诉我们，用户至少期望能够排序。 |
| 这只是你不够在意、不愿完成的借口。 | Matt：我当然在意。但我们能交付什么受到时间和技能的限制。静态报告是我们估计到周五可以交付的。 |
| 实际情况是你没有足够努力地推动。 | Tara：为什么？团队不能更努力工作吗？他们不够有动力吗？ |
| 这太荒谬了。工程师们很懒惰，而你在纵容他们。 | Matt：这不是问题所在，Tara。更努力工作实际上会适得其反——他们会犯愚蠢的错误，速度反而更慢。我们必须接受这些估算。 |
| 如果我们的开发人员不能振作起来，也许外部的人能够向他们展示如何完成。 | Tara：好吧，那也许我们应该雇一个承包商。这样能完成报告吗？ |
| 你否决我提出的所有建议。你显然已经决定这不会发生了。 | Matt：不行。还记得上一个承包商吗？她花了好几周才上手。新加入的人会让我们这个冲刺变慢，而不是加快。 |
| 我准备了两篇博客文章和一场网络研讨会来推广这个功能。我不得不全部推迟，正当我们迫切需要新的销售角度时。我完全泄气了。 | Tara：我想没有出路了。我们只能等待才能开始推广新报告。 |
这次对话后我感觉非常不舒服——恶心、胸口狂跳——以至于我以为自己心脏病发作了。为什么 Matt 一直忽视来自客户的明确反馈，拒绝要求工程师做更多工作？我以为他和我一样关心这项业务，但我真的开始怀疑了。如果我们找不到办法完成这些功能，我们将无法达成目标并破产，这让我非常恐惧。
恐惧对话的目标是发现隐藏的恐惧并使其可以讨论。但它们是如何被隐藏起来的呢？
部分答案在于哥伦比亚大学一个不起眼的候诊室，研究人员 Bibb Latané 和 John Darley 让一组学生填写问卷，作为心理学实验的一部分。几分钟后，烟雾开始从墙上的通风口流入房间。每个人都继续写字；没有一个学生说话。更多烟雾涌入，变得很难看清。什么也没发生。没有人采取行动寻求帮助，甚至没有询问发生了什么。最终，刺鼻的烟雾导致咳嗽和流泪，一名参与者打开了窗户——但这些顽强的学生继续写字，直到实验人员介入并终止实验时，才讨论正在发展的危机或寻求帮助。
这里展示的现象被称为旁观者效应(bystander effect)，或者我们更喜欢的术语，多元无知(pluralistic ignorance)。个体对某个事件或观察感到不舒服，但由于其他人没有采取行动，他们（错误地）认为其他人都认为情况正常和安全，因此自己也不采取行动。一种共同的恐惧被部分或全部相关人员感受到，但这种恐惧的表达被群体其他成员的表面共识所抑制。换句话说，人们宁愿在火灾中死去，也不愿成为第一个报告烟雾的人。这就是多元无知的强大程度。
烟雾实验告诉我们人们如何对单一的可怕事件做出反应，但如果一个引发恐惧的事件反复发生却没有任何应对措施，会发生什么？在《挑战者号发射决策：NASA的风险技术、文化与偏差》一书中，Diane Vaughan调查了1986年的航天飞机爆炸事件；Richard Feynman在罗杰斯委员会报告的附录中，分别分析了NASA对在寒冷天气下航天飞机发射期间观察到的问题的应对措施。两人都观察到Vaughan所说的偏差常态化(normalization of deviance)现象：由于航天飞机在寒冷条件下一次又一次地成功发射而没有发生灾难，NASA得出结论认为在此类飞行中在助推器部件上观察到的裂纹不是问题。虽然O形圈本不应该出现任何裂纹，但由于裂纹尺寸较小，一些工程师认为它们构成的危险很低。其他人有担忧——有什么理由相信下一次的裂纹会和之前的一样小？——但没有大声说出来以阻止飞行。
事实上，NASA管理层如此坚信航天飞机发射的安全性，以至于他们决定在1986年1月28日的挑战者号飞行中安排一位平民教师登机是个好主意。那天早上，发射塔上结着冰柱，助推器正如工程师们担心的那样发生了爆炸，导致全体机组人员遇难。
在软件开发团队中，闪烁测试(flickering tests)或随机失败的测试现象说明了偏差常态化如何影响团队，尽管后果没有那么严重。开发人员构建自动化测试套件，并在每次代码更改时运行它。他们观察到少数测试大多数时候成功，但在看似随机的时刻失败。自然的结论是测试是错误的——它们偶尔会因为某些测试异常而”闪烁”——如果失败可以重新运行。如果尝试几次后成功，就可以继续发布。正如我们许多人太了解的那样，结果是当闪烁测试实际上在提醒我们一个真实但间歇性的故障时，生产环境会出现故障。
在这两种情况下，无论是O形圈裂纹还是闪烁测试，我们都有团队公开宣称的规范(espoused norm)：“不要在设备损坏时飞行”和”测试失败时不要发布”。但与这一规范的偏差的反复经验——“带着开裂的环安全飞行”和”尽管间歇性失败仍然发布”——导致产生新的实际使用规范(norm-in-use)，组织忽视了自己的警报系统。由于多元无知(pluralistic ignorance)，对新规范危险性的恐惧表达被压制，一切都为灾难性结果做好了准备。
| 症状 | 公开宣称的规范 | 实际使用的规范 |
|---|---|---|
| 生产环境中明显的bug | 持续通过测试 | 测试有时可以失败 |
| 系统每小时报警 | 及时清除警报 | 忽略已知的无害警报 |
| Sprint结束日期延长 | 干净利落按时结束sprint | 延长sprint以塞入更多内容 |
| 站会时间过长 | 保持站会简洁快速 | 提供冗长的状态报告 |
| 代码质量低 | 频繁重构 | 经常走捷径 |
| bug过多 | 完整的测试覆盖率 | 测试是可选的 |
| 迭代最少 | 频繁发布 | 只在确定时才发布 |
| 管理员过多 | 仅在需要时授予权限 | 根据请求授予管理员权限 |
| 改进行动未完成 | 有效使用回顾会议 | 太忙而无法执行行动 |
| 用户困惑和沮丧 | 在设计中让客户/用户参与 | 跳过用户研究 |
表4.1：偏差常态化的例子
恐惧对话(Fear Conversation)帮助揭示团队中隐藏的恐惧，用快速注意和纠正错误所需的心理安全取代偏差常态化。为此做准备时，寻找组织中危险的偏差规范的例子。为了帮助你入门，请参阅表4.1中的例子，我们列出了一些你可能观察到的症状，以及对于每个症状，正在被违反的公开宣称的规范和实际遵循的实际使用规范。
从表中可以看出，这种偏差可能出现在任何地方——在你的软件、敏捷流程、产品设计、执行团队中。它们可能看起来容易发现，但在实践中，它们并不那么明显；根据定义，偏差常态化意味着整个团队，包括你在内，很可能已经对公开宣称的规范的偏差视而不见。
让团队外的同事或朋友与你一起寻找偏差，因为他们的外部视角可以帮助你识别从内部看不到的问题。如果你的团队经历中断、严重bug或其他严重故障，与你的同事一起分析这些事件，寻找违反规范的例子。反思这些事件之前可能存在哪些偏差，并确定你的团队可以采用哪些实践来避免它们在未来发生。
信任对话是对未知领域的探索。你试图理解对话伙伴的故事，这些故事你一开始无法知晓，并将你的故事与他们的故事对齐。相比之下，恐惧对话更具方向性；由于你在前一部分的工作，你可能已经对偏差常态化(normalization of deviance)的位置有了一些想法，并且你将寻找这种常态化背后的恐惧。危险在于你可能会过度引导恐惧对话，只关注从你的角度看来似乎可能的恐惧和原因。
在本节中，我们将向你展示一种我们开发的技术，用于释放你内在的好奇心并克服你的假设：连贯性破解(Coherence Busting)。作为额外的好处，当应用于你在上一节中发现的常态化偏差的例子时，这项技术将为你在恐惧对话本身中创建的恐惧图表提供良好的开端。
为了应用连贯性破解，想象你自己正在做一个重大提案——一个你真正想要向听众推销的提案。当你在讲话时，你注意到主要利益相关者——你最希望说服的人——短暂地瞥了一眼她的手腕。你会做什么？为什么?
在继续阅读之前，花一分钟左右的时间列出一个简短的清单，列出你可能采取的行动以及你在这种情况下采取这些行动的原因。正如你稍后会看到的，非常重要的是你不要花太多时间思考这些行动；只需记下任何浮现在脑海中的想法。
完成了吗？你的回答几乎肯定类似于以下这些：
• 我会加快速度，因为她要去其他地方。
• 我会问我是否在讲正确的内容，因为她一定觉得无聊。
• 我会跳到我最有说服力的幻灯片，因为她一定在质疑我的论点。
如果你的答案与这些接近，恭喜你！你的系统1运作完美——但它很可能在这种情况下背叛你。
我们引入手腕一瞥场景是为了让你体验丹尼尔·卡尼曼(Daniel Kahneman)在他的书《思考，快与慢》中描述的决策启发式。卡尼曼将我们的意识建模为包含两个系统：我们快速、自动、无意识的系统1，以及我们缓慢、深思熟虑、需要努力的系统2。系统1之所以快速，部分原因在于它使用的捷径。其中两个捷径在手腕一瞥的例子中持续出现。第一个是我们假设一个连贯的故事一定是正确的。第二个是我们将事实限制在我们能立即回忆起的内容，卡尼曼称这个过程为”WYSIATI”，即”你所看到的就是全部”。
我们无意识地为这一瞥的含义构建了一个连贯的故事——例如，“她要去其他地方。”这个故事基于我们对这一瞥可能意味着什么的第一个想法(WYSIATI)。我们故事中的连贯性给我们一种我们的故事是真实的感觉。然后我们根据我们编造的这个故事设计我们的行动，例如，“我会加快速度。”这是手腕一瞥例子的关键教训：我们感觉我们在回应情况的现实，因为WYSIATI和连贯性导致我们将单一合理的故事误认为真相。但我们经常是错的——是危险的、灾难性的错误。事实上，回看我们对手腕一瞥的描述。我们写的是利益相关者短暂地瞥了一眼她的手腕。我们从未提到手表，但你几乎肯定假设有一只手表。
这就是为什么我们需要连贯性破解。
回到手腕一瞥练习，现在考虑手腕一瞥的其他可能含义——所有可能的原因：一个紧张的习惯、她智能手表上的警报、她手上的皮疹，还有更多。花更多时间思考可以让你激活系统2并想出一长串可能的原因。这就是连贯性破解。
我们发现特别有帮助的是让自己扩展思维，甚至包括极不合理的解释：她手上写着她的世界统治计划，这一瞥是给她秘密社团成员的隐藏信号，等等。事实上，我们建议你从这些极不可能的解释开始你的连贯性破解，因为它们天生具有幽默感，而笑声本质上与你在考虑系统1为你发明的基于恐惧的、危险连贯的故事时可能感受到的战斗或逃跑反应不兼容。
连贯性破解的关键不在于有很多选项，而在于这些选项是相互矛盾的。一旦我们能够想象相互冲突的解释，我们就不再被原始的连贯故事所困。这些选项一直都在那里，但我们需要系统2，即我们有意识和需要努力的思维过程，来将它们浮出水面。当我们觉得我们已经有了一个好的解释时，这不是我们自然而然会做的事情，但这对于成功的恐惧对话至关重要。
你可以在任何时候使用连贯性破解来帮助你准备一场可能困难的对话，特别是当你感觉到你可能对你的对话伙伴的想法和感受有一些假设时。(如果你像我们一样，你几乎总是有这样的假设！)在表4.2中，我们提供了一些在实际情况下使用连贯性破解的例子。
在准备恐惧对话时，连贯性破坏(Coherence Busting)可以帮助我们以更加好奇、开放的态度进入讨论，这将帮助我们发现和减轻那些我们从未想象过的恐惧。在准备过程中，列出尽可能多的恐惧，这些恐惧可能是你在上一节中提出的每个常态化偏差的根源。尽可能广泛地思考,运用你的系统2(System 2)去想象那些看似不太可能或完全愚蠢的恐惧。你可能想把你的想法写在便利贴或索引卡上,以帮助你在下一节中制定恐惧图表(Fear Chart)。
| 如果你认为: | 考虑这些替代可能: |
|---|---|
| 我的团队太懒了,不愿意编写测试。 | CEO命令所有团队停止测试。 团队编写完美的代码,所以测试是多余的。 有人告诉他们测试是无用的。 他们以前尝试过测试,发现很困难。 |
| 销售人员不关心质量,只关心截止日期。 | 销售团队正在设立一个赌局,看它能把开发目标定得多么荒谬。 销售人员认为代码总是有bug的,所以质量无关紧要。 截止日期是由高管商定的,销售部门无法控制。 |
| 我们的数据库供应商知道我们无法更换提供商,正在尽可能地从我们身上榨取每一分钱。 | 某个流氓高管试图通过荒谬的定价赶走客户来摧毁公司。 定价矩阵中有一个错误,我们实际上应该获得大幅折扣。 我们的客户经理知道我们资金紧张,协商了全球费率上涨50%的减免。 |
表4.2:连贯性破坏的实际应用
连贯性破坏的评分
要对以连贯性破解(Coherence Busting)为目标的双栏对话分析进行评分，请在左栏中查找尽可能多的关于他人想法或动机的无根据结论。寻找像”显然”或”明显”这样的信号词，以及在右栏中没有坚实基础的陈述——例如，在没有明确声明的情况下断言对方贬低你的工作，比如”我认为你的项目不够好”。要检查你是否识别出了一个无根据的结论，可以应用一些连贯性破解，尝试为导致你得出结论的观察想出替代解释；如果你成功开发出了合理的替代方案，那么该结论就一定是不成立的。每找到一个无根据的结论就给自己一分。你的目标应该是让你的得分尽可能低。
掌握了偏差常态化(normalization of deviance)和连贯性破解之后，我们就准备好进行恐惧对话(Fear Conversation)了。
我们在恐惧对话中的第一项任务是让所有能想到的恐惧变得可讨论。这就是连贯性破解能发挥作用的地方——尤其是如果整个团队都能够做到这一点。(如果他们还没有，可以考虑在对话开始时引入连贯性破解的概念，邀请每个人花五分钟启动他们的系统2来产生想法。)然后我们将继续筛选关键恐惧，最后缓解这些恐惧。在这个过程中你将构建一个恐惧图表(本节末尾第90页的图4.1展示了在此练习结束时你的图表可能的样子)。
步骤1. 将到目前为止识别出的所有恐惧(由你单独或整个团队)可视化。我们喜欢使用便利贴，因为可以轻松移动它们，但在白板上书写或将索引卡放在桌子上也可以。通过询问已识别恐惧的更极端版本(“如果一个bug很糟糕，那么系统宕机会更糟吗?”)或询问已识别恐惧的反面(“我们担心会失去员工。我们是否也担心团队增长太快?”)，从小组中征集更多恐惧。
步骤2. 询问小组是否有更多项目要添加或如何合并现有卡片。添加新的恐惧而不编辑它们——我们的目标是识别出小组的所有想法，而不是过滤掉任何一个。
几乎总是，一些已识别的恐惧会相互强化，或者一些会完全不兼容。通过将卡片彼此靠近放置或叠放，或使用标记箭头连接卡片组，或使用任何其他帮助你看到连接的方法来反映这一点。确保不要遗漏安静的团队成员。具体询问提出分组的成员该分组是否合适。
步骤3. 现在是时候从那些我们可以安全接受的项目中筛选出值得追求和缓解的项目了。我们喜欢使用点投票(dot voting)来识别我们想要缓解的恐惧，但如果你愿意也可以使用其他方法。那些帮助激活你系统2的更离谱的想法，比如那些涉及外星人或秘密社团的想法，几乎肯定不会在这个过程中存活下来，它们在鼓励创造力方面已经完成了使命。你最终会得到小组想要处理的恐惧子集——那些最令人担忧或最重要的恐惧。
步骤4. 如果我们能够识别出有助于减少每个目标恐惧的缓解措施，我们就能实现恐惧对话的目标。缓解措施可能包括以下内容：
• 对有缺陷的发布会激怒客户的恐惧：
∘ 与客户或其内部代理讨论质量与速度的权衡，并就期望达成一致。
∘ 增加手动和自动化测试覆盖率。
∘ 与高管达成一致，在团队改善质量期间，他们将处理任何愤怒的客户。
• 对错过截止日期的恐惧：
∘ 了解截止日期的驱动因素，并通过与市场营销或销售部门对话协商减少范围或更改日期。
∘ 在客户批准下减少范围。
• 对无法掌握新方法或技术的恐惧：
∘ 定义掌握程度和通往成功掌握的里程碑，以显示进展。
∘ 增加培训和学习机会。
列出每个恐惧、其缓解措施，以及(这很关键!)负责确保你执行缓解措施的某个人。
步骤5. 最后，如果你愿意，可以在图表中添加与每个即将被缓解的恐惧相对应的公开规范(espoused norm)，以清楚地展示缓解措施的预期积极结果。
图4.1(见第90页)提供了你完成的恐惧图表可能的样子的示例，但仅仅创建一个恐惧图表本身是不够的；你需要确保它被发布(理想情况下张贴在墙上，尽管wiki或其他内部文档存储也可以)并定期讨论，并确保缓解措施得到执行。(参见第7章中的”问责对话”，了解确保后者的方法。)
图4.1：恐惧图表
创建恐惧图表对团队来说可能是一次变革性的体验，让他们能够讨论隐藏的担忧并有效地解决它们。但这不是一次性的事情；随着团队及其环境的持续演变，你需要至少每六个月定期重新审视和修订你的恐惧图表。
现在让我们看一些恐惧对话在实践中的例子，从Tara的例子开始。
反思与修订
反思我的基本对话评分，我发现我有五个问题，但每一个都是诱导性的，而不是真诚的；我迫切希望Matt同意某件事——任何事——以完成关键功能。我在对话早期分享了左栏的事实，但没有分享我对开发人员和Matt日益负面的看法。Matt关于又一次延迟的陈述显然是一个触发点，我砰砰的心跳和恶心感是非常明显的信号。
在连贯性破坏(Coherence Busting)评分中,我在左栏中数出五个结论,全都缺乏支持。例如,开发人员可能没有达到目标,但不是因为他们懒惰;可能是因为:
• 他们在秘密为一个企图摧毁我们公司的邪恶超级反派工作。
• 他们不理解这些功能的重要性。
• 他们没有足够的经验来做出好的估算。
因为我能想出这些替代场景,我可以看到我的结论”开发人员很懒”是缺乏支持的。事实上,这是防御性推理(defensive reasoning)的一个例子——我受到潜在延迟的威胁,所以我试图通过责怪工程师来”获胜”。
我可以做些什么不同的事情来修订(Revise)?首先,我要和Matt制作一个恐惧图表(Fear Chart),帮助我们发现和缓解让我们担忧的事情。我还计划注意左栏中的结论,并尝试为它们想出其他解释。我已经用上面的列表开始了。
与Matt的恐惧图表对话进行得非常好,我们发现我们共同担心没有为客户做足够的事情,尽管我们还不确定如何缓解它。在上周的规划会议中,我决定在感到恐惧时描述它,这样我们就可以一起制定缓解措施。
Tara和Matt的修订对话
| Tara的想法和感受 | Tara和Matt说的话 |
|---|---|
| 又来了——又一个我们必须解释的捷径。 | Tara: 得了吧,你知道这个功能只是故事的一半。用户甚至无法在工作流程结束时保存他们的项目! |
| 我感到胸口砰砰跳。我害怕什么?我想是我们将不得不再次推迟销售电话,失去收入。 | Matt: 当然,但这是我们在这个冲刺(sprint)中能做的。我们会在下一个版本中完成其余部分,包括保存进度。 |
| 如果我们不销售,我们很快就会没钱。而我们不能像这样销售。为什么会发生这种情况? | Tara: 但我们不能按现状销售它。为什么我们说我们构建有价值的功能,却从来没有真正做到? |
| 我们总是宣称每个冲刺都提供”价值”,但我认为我们已经将偏离这一原则正常化了。 | Matt: 我很困惑。我以为我们每个冲刺都构建了有用的东西。识别价值并构建它不就是这些规划会议的目的吗? |
| 我们的团队比以前大了,但他们工作不够努力;或者他们被催眠以慢速工作,或者他们不理解功能,或者他们需要更多培训。嗯,看来我观察到的现象有很多可能的解释。我会询问Matt的意见来帮助我们解决这个问题。 | Tara: 嗯,它们没有为我服务于那个目的。我认为我们说我们在构建有价值的增量,但由于某种原因,我们一直在做半吊子的功能,无法销售。你认为这是为什么? |
| 嗯,当我思考Matt的问题时,我一直回想起整个夏天消耗了每个人时间的数据库项目。也许那才是真正让我害怕的。 | Matt: 这话听起来很难受,Tara。你以前为什么没说?我不知道我们因为遗漏功能而伤害了销售。如果你告诉我,我们本可以做出调整至少完成其中一些。 |
我对Matt有足够的信任来分享我的恐惧，现在我自己也理解了这种恐惧。
Tara：这是个合理的问题。我想我担心的是，如果我这样做，你的团队会转入地下工作，就像他们重建数据库时那样，几个月都没有发布任何东西。
这正是我想讨论的——权衡以增加价值。
Matt：我不知道你有这种恐惧。自从数据库构建以来，我们学到了很多，我确信我们现在可以做得更好。例如，我们能跳过步骤7，改为放入一个可用的保存按钮吗？那样的话可以放进这个冲刺(sprint)中。
这次会议毕竟可能会很有成效。
Tara：当然可以！
连贯性破解(Coherence Busting)在这个关键阶段帮助了我，因为我能够通过思考其他解释来避免假设开发人员应该为进度放缓负责。事实证明，我实际上也是问题的一部分。在规划期间，我并不总是分享我的恐惧，也没有解释我认为缺失功能会对销售产生什么影响。(回顾我和Matt的第一次对话。那种恐惧在左栏中随处可见，但从未进入右侧的实际对话中。)现在我们把这种恐惧摆到台面上，我很高兴地说，我们的规划会议更加有效了，对改变范围以推动销售有了有益的讨论。而且我也不再有那种心脏病般的惊险时刻了！
Tom说：“Ken是技术负责人和直线经理，直到我被引入担任人员负责人。我很快注意到发布流程似乎是bug和烦恼的来源，但没有人愿意准确告诉我原因——这似乎是一个不可讨论的、引发恐惧的话题。我决定在与Ken和工程团队的其他成员的会议上了解更多信息，首先促使他们思考与发布相关的恐惧。我预期这将帮助我们发现偏差常态化(normalization of deviance)的例子。”
| Tom的想法和感受 | Tom、Ken和工程师们说的话 |
|---|---|
| 让我们把当前情况变得可见和可讨论。 | Tom：好的，我想我们现在已经在白板上记录了发布流程。我们遗漏了什么吗？ |
| 我对”应该”这个短语感到怀疑。 | Dean：是的，这是我们应该遵循的流程。 |
| 这些重要的词是什么意思？ | Tom：你说”应该”是什么意思？ |
| 更多有问题的词——“当然”？？ | Ellie：嗯，当然Ken不会遵循它。 |
| Tom：为什么说”当然”？ | |
| 啊，这可能就是为什么每个人都对发布问题小心翼翼的原因。 | Ken：Ellie说得对。我有时会跳过代码审查(code review)和QA步骤，直接发布到生产环境。 |
| 让我们看看能否触及潜在的情绪。 | Tom：为什么会这样？你能分享一下驱动这种行为的恐惧吗？ |
| 做得好，Ken！当你昨天告诉我这个恐惧时，我希望你能在这里分享它。 | Ken：有很多可怕的旧代码只有我理解。我猜我担心其他人会被它搞糊涂并犯错。 |
| 我不能反驳Frank的观点。但他之前没有告诉我或其他人这个担忧。 | Frank：这对我们不公平，Ken。我们应该知道整个应用程序是如何工作的。而且，你未经检查的发布无论如何都会导致bug。 |
| Tom：Frank，你之前没有分享过这个观点——为什么？ | |
| 又是一个有很多解释的情感化短语：“他的代码。”不过我很高兴Frank能谈论这种恐惧。 | Frank：我担心的是，如果我们要求查看他的代码，Ken会不高兴。 |
Tom在白板上展示了公开宣称的规范——团队”应该”遵循的流程。这帮助小组讨论他们如何以及为什么偏离了那个规范，以及是什么恐惧驱动了这种偏离。随后进行了恐惧对话(Fear Conversation)，之后创建恐惧图表(Fear Chart)来识别这些恐惧的缓解措施就容易多了。Tom后来报告说，在这次成功的对话之后，团队更加严格地遵守了他们公开宣称的发布流程。
“四个月，”Thierry想。“他们永远做不到。”
那是2018年9月，比利时联邦养老金服务局刚刚告诉Thierry de Pauw——一位敏捷团队顾问，它最后一次季度重大软件发布将在12月进行。之后，它将每两周发布新版本，实现”持续交付”(continuous delivery)，并大幅降低成本和风险。
该机构拥有超过120名开发人员和一个庞大的、有十五年历史的应用程序，为每个比利时人计算和支付养老金，它必须改变十五个开发团队根深蒂固的习惯，每个团队都会对单体代码库进行潜在相关的更改。每个季度，构建和发布团队都会费力地合并所有团队的所有更改，以产生一个拼凑在一起的大爆炸式发布，应该包含每个人的新功能。但由于每个团队的代码都是独立编写的，有些部分无法协同工作。他们发现，稳定和交付一个可工作的应用程序需要大约330人天，这是他们无法承受的成本，因此他们决定是时候做出改变了。
当然，和许多组织一样,季度发布实际上并不是季度发布;复杂且高度手工的发布流程通常导致错过最后期限和部署延迟，因此该机构实际上平均每年大约发布两次。延迟意味着每个新版本必须交付更多功能，这只会增加复杂性和风险。
在领导软件团队的二十年里，Thierry从未见过如此大规模的组织如此快速地转向持续交付。而关键是该机构聘请他来帮助实现这一目标。
Thierry与一个雄心勃勃的内部变革倡导者”核心团队”使用联合设计(Joint Design)(更多内容参见第5章中的为什么对话(Why Conversation))，创建了价值流图(value stream maps)，捕获了从开发人员完成代码到功能在应用程序中上线的整个当前流程。这些价值流图帮助该机构开始识别改进候选项。例如，这个练习揭示了每两周进行一次更快的”补丁发布”流程;它是为现有功能的快速修复而设计的，但也偶尔且越来越多地用于新功能。
“看那个！”他说，检查价值流图。“令人惊讶的是，他们将所有发布流程都压缩到补丁的两周内。”他想，这可能导致用新流程顺利替换旧流程，下一个重大发布被几个小发布替代。
但进一步的调查揭示了威胁阻碍进展的几个恐惧中的第一个：对复杂性的恐惧。与每次发布一样，团队创建了各种代码”分支”(软件的版本，每个版本都包含一个团队最近的更改)，它们之间存在复杂的依赖关系。将这些混乱解开成单独的、可发布的部分需要非常仔细地从多个分支中精选。在仅创建一个补丁发布时这经常出错，更不用说捕获六个月更改的一系列此类发布了;在进行如此复杂的中途调整时出错的风险实在太大。因此，Thierry和核心团队叹了口气，同意通过坚持12月的重大发布计划来缓解这种恐惧。一月份他们将清理分支，并以更简单、更小的功能单元重新开始。
随着他们继续朝着新流程努力，Thierry带领小组进行了一系列恐惧对话。通过这一系列恐惧对话，团队发现了更多恐惧：脱离、技能差距、遗漏关键步骤、最后期限和错误。接下来我们将更详细地探讨每一个。
脱离参与的恐惧。十五个团队中的大多数都在共同努力实现持续交付，但有几个团队几乎看不到踪影，几乎没有做什么明显的准备工作。他们会及时行动吗？他们会拒绝加入新流程吗？为了减轻这种恐惧，核心团队确保采用持续交付模型的步骤简单且文档清晰；这样，一旦脱离的团队意识到变化真的要发生时，他们就能轻松赶上。有些后期采用者已经是补丁发布流程的重度用户，这对他们有所帮助，因为他们能够相对快速地适应。
技能差距的恐惧。新流程要求的变更增量比以前小得多。团队能否适应并将工作分解为可以在短短两周内完成的有价值的变更？Thierry在许多其他组织中看到工程师每天都在交付价值，对此并不担心——但他的信心并没有起到作用。团队需要他们自己能够相信的缓解措施，他们通过同意设置一个安全网来获得这个缓解措施——如果他们未能在两周时间内完成变更，可以使用特性分支跳过一次发布。
遗漏关键步骤的恐惧。漫长的发布流程包含许多仪式，例如代码冻结和全团队”通过-不通过”决策会议。这些仪式会丢失吗？它们提供的风险降低也会丢失吗？这里的缓解措施相对容易：核心团队开发了每个仪式的压缩版本，可以在两周的发布周期内执行，既保留了它们的价值，又加快了整体流程。
截止日期的恐惧。作为政府的一部分，该机构有法律规定的截止日期；错过这些截止日期不是一个选项。当新流程如此紧凑时，团队如何确保能够达到这些硬性目标？单次失败不会让整个流程脱轨吗？一个后备程序可以解决这种恐惧：在硬性截止日期临近时，团队可以选择在测试失败的情况下发布，如果他们设计了足够的变通方法和缓解措施。
bug的恐惧。这是最大的恐惧，特别是对高管而言；一个足够严重的问题可能会让他们登上比利时每家报纸的头版，损害他们的声誉，并让机构花费巨额资金来修复。这种恐惧是有充分理由的：许多自动化测试容易出现假阴性，测试经常与代码不同步，因为它们是分开存储的，而且手动测试难以协调和组织。结果，许多bug通过了测试流程，每次主要发布的大部分时间都花在检查和重新检查发布候选版本上，试图挤出所有bug。
“主要发布让人们关注质量，并给我们足够的时间进行测试，”团队说。“我们怎么可能在短短两周内进行足够的检查，以确保不会发生灾难？”核心团队大力投入解决这种恐惧，通过隔离不可靠的测试（手动检查或缓解失败的测试），将测试提交到与代码相同的仓库以保持它们同步，并更仔细地规划手动测试，重点关注每两周发布中的一小部分变更。
在缓解了这些恐惧，并完成了12月的最终主要发布后，核心团队获得了高管的许可，推出了新流程。他们屏住呼吸进入了2019年：他们的缓解措施足够吗？他们能在新年仅两周后完成完整的发布吗？
答案是响亮的YES！第一次发布并不完美，但它按时发布了；核心团队准备好在下一次发布前解决问题。最初脱离的小组参与进来了，团队学会了如何发布部分变更而不是整个功能，压缩的仪式起作用并降低了风险，自动化和手动测试程序协同工作，保持了高质量，并在截止日期按时发布。让恐惧可讨论，然后缓解它们，提供了足够的保护，让机构能够按计划进行第一次发布。此后每两周，发布都像时钟一样运行。
当然，没有什么是完美的，核心团队仍有很多工作要做；对十五个团队的倾听巡回显示，仍然需要许多修复和改进，但也表明新流程受到了普遍欢迎，为整个组织提供了透明度。Thierry记得一位核心团队成员在新流程准备阶段总是看起来很悲伤：“她确信需要变革，但担心它们永远不会发生。在初始发布后的第一次访问中，她平常的长脸变成了从耳朵到耳朵的笑容。”
在本章中，你学习了如何使用偏差常态化(normalization of deviance)提供的线索来识别恐惧；如何使用连贯性破解(Coherence Busting)来发现你自己可能看不到的恐惧；以及如何使用恐惧图表来缓解恐惧。通过减少你自己和他人的恐惧，你将帮助消除威胁、尴尬和干扰对话转型(conversational transformation)的防御性推理(defensive reasoning)。你可以通过多种方式使用恐惧对话，包括以下方式：
执行领导者可以让她的组织承担更多风险，并找到更多方法来消除实现公司目标的障碍——如果心理安全文化允许有关障碍和风险的信息有效地向上和向下流动。
团队负责人可以发现他的团队在冲刺规划、每日站会或回顾会议中没有探索哪些选项，以及他可以做什么来鼓励更多参与和创造力。
个人贡献者可以识别出那些正在抑制她采用创新能力的恐惧，比如基础设施即代码(Infrastructure
as Code, IaC)或可执行规范(executable
specifications)，并在同事和管理者的帮助下有效缓解这些恐惧。
* 自然地，成功的恐惧对话的先决条件是信任——如果你没有这个，你的团队将不愿意讨论恐惧。如果你的团队缺乏构成信任的一致故事，请参阅上一章。
** 千倍的价格降低一旦被纠正，实际上让市场部门很高兴，他们迅速发布了一份幽默的新闻稿，宣传由工程错误带来的惊人优惠，并对由此产生的流量增长大肆宣扬。
*** 群体的影响力在拉塔内和达利尝试的烟雾实验的一个变体中得到了清楚的展示：如果你让一个学生单独在同一个房间里等待，同样的烟雾从通风口冒出来，她会迅速采取行动寻求帮助。
**** 在本节中，我们将假设你正在与一个群体进行恐惧对话，比如软件团队中的开发人员或更大组织中的一组管理者。然而，这只是为了让我们的描述更容易理解；你应该完全可以与几个同事或与另一个人进行恐惧对话。我们描述的方法在较小的群体中同样有效。
***** 要使用点投票，告诉小组每个人将有几票(我们通常使用三票或五票，但任何小数字都可以)。每个人来到白板前，在他或她认为重要需要缓解的一个或多个恐惧旁边做一个点或计数标记。参与者可以随意分配他们的选票——他们可以将所有选票投给一个非常重要的恐惧，或者分开投票，或者为几个恐惧各投一票——但他们的总票数不得超过你在开始时分配给他们的数量。
到目前为止，我们已经在对话工具包中添加了可以帮助我们建立信任和减少恐惧的工具。这些技术解决了阻碍协作和减少问题解决的问题，这些问题可能会将任何团队困在工厂思维模式中。消除成功障碍是我们的第一个目标，但通过下一个工具，我们开始构建一个积极的框架供我们的团队在其中工作。建立一个”为什么”为我们的公司提供了指导大小决策的战略方向，并为成功提供了强大的动力。独立决策和团队动力在非协作的工厂中不是关注点，但一旦我们摆脱工厂模式并开始自主运作，它们就至关重要。
本章的核心信息是，你构建的”为什么”不仅要解释你作为团队集体行动的动力，而且要共同创建，所有相关人员都要参与。一位高管从上面强加一个”为什么”——或者更糟糕的是，只有虚假的咨询——弊大于利。共同创建目标意味着首席架构师可以专注于指出云是下一个演进步骤，技术负责人可以让她的整个团队支持季度目标，测试人员可以自信地决定接下来应该为哪个组件自动化测试。
当你完成这些方法的学习后，你将能够：
• 区分利益和立场，并在陷入涉及后者的无休止辩论的对话中揭示前者。
• 结合倡导和探询，让你既能对他人的观点保持好奇，又能透明地分享自己的观点。
• 共同设计一个解决方案——比如团队的Why——通过将前两种技术与清晰的决策和限时讨论相结合，让所有参与者都能发声，产生一个每个人都可以说自己做出了贡献的结果。
Simon Sinek在有史以来观看次数最多的TED演讲之一中热情地论证,要想成功,组织必须始终以其Why为先导,即其存在和行动的核心原因。“What”和”How”,即定义其通往Why之路的战略和战术,则是后续的事情;要想成功,客户、员工和投资者需要首先听到、理解并认同组织的目标。[1]
在他的演讲和后续著作《从Why开始》中,Sinek引用了许多例子来支持他的论点:
• 探险家Ernest Shackleton在1914年尝试首次穿越南极之前,据报道用这样的方式招募人员加入他:“招募人员参加危险旅程。工资微薄、严寒酷冷、数月完全黑暗、持续危险、安全返回难料。如果成功将获得荣誉和认可。”[2]
• 在1997年的一次重大品牌重塑中,苹果公司的广告敦促我们”不同凡想”,根本没有提及他们的产品。通过如此清晰地向客户确立公司使命,并且以一种完全脱离其现有计算机产品的方式,使他们在接下来的十年中主导了新的品类,如音乐播放器、智能手机和平板电脑。
• Martin Luther King Jr.博士在1963年发表的鼓舞人心的演讲中描述了一个新世界的愿景,在这个世界里,人们将”……不是根据肤色而是根据品格的内涵来评判”[3]。King几乎没有谈论他的听众将如何到达这片应许之地——至关重要的是,这篇演讲被称为”我有一个梦想”,而不是”我有一个计划”。然而,King博士仅仅通过谈论他的信念,就设法吸引并说服了超过25万人的观众。
在每个案例中,一位大胆的领导者通过对团队目标的令人信服的论述吸引了追随者和信仰者,并取得了巨大的成功,而没有纠结于战略或战术。根据我们的经验,一个强大的Why也以同样的方式帮助实现较小的战术性变革。
似乎自然而然地得出结论:如果我们希望我们的团队达到类似的高度,我们需要与他们分享对鼓舞人心的Why的真诚承诺。有了明确的方向和内在的承诺,他们将能够像Shackleton、苹果和King一样自组织并取得成功。对吗?
怀着最大的敬意,我们不得不不同意。从Why开始是危险的,不太可能成功。
是的,如果一个团队要有效地使用迭代交付和定期反思改进等技术,就必须就明确的目标达成一致。是的,对这一目标的一致必须在我们就范围、里程碑、截止日期、目标以及使敏捷引擎运转所需的其他一切达成一致之前。这就是为什么接下来的两个对话,Why和承诺,按照这个顺序进行;我们将在两者中详细讨论如何建立内在承诺,以便就团队和组织的Why达成一致。
但是太多时候,我们看到领导者试图在没有首先进行信任和恐惧对话的情况下激励他们的团队——结果令人沮丧。如果没有一致的故事让每个人分享预期行为的模型,没有人准备好相信有人在掌舵,更不用说相信有人准备就方向达成一致了。当无约束的恐惧主导团队思维时,他们无法为构成Why对话核心的目标共同设计腾出空间。
我们想起了我们与一个团队合作的经历,就在一个软件即服务(SaaS)产品发布之后,该产品的构建花费了近一年时间。缺乏迭代和客户参与意味着该产品举步维艰,销售人员甚至无法完成一笔交易。团队成员看起来并感到士气低落,似乎没有人知道如何修复软件使其适销对路。看起来很明显,这个团队需要的是一剂Sinek式的Why,帮助他们重新与客户互动并迭代出一个解决方案。
但当我们深入挖掘时,我们很快发现存在信任和恐惧的潜在问题,这意味着这个团队绝对没有准备好进行Why对话。领导者单方面做出了关于团队组织和产品营销的不受欢迎的决定。这导致了关于他们动机的严重不一致的故事。跳过代码审查和在没有产品负责人参与的情况下推送功能等捷径导致团队对代码和发布质量产生了可理解的恐惧。在这个时候试图给这个团队一个鼓舞人心的Why,就像是布莱船长在《邦蒂号》叛变前夕向船员发表激励演讲一样。
在与组织进行了大量紧张的工作之后,我们发现了一些有助于改善信任和减轻恐惧的行动,包括:
• 重新定义团队主管的角色,并在协作式领导方面对他进行辅导,包括做出承诺并履行将整个团队纳入决策的承诺。
• 使质量恐惧可讨论,并重塑发布流程以解决这些问题。
• 撤换一位行动破坏了信任的无效高级领导。
只有在采取这些行动之后,团队才能进行有意义的Why对话(Why Conversation),讨论公司和团队目标,以及产品发布如此惨败的原因,然后开始通过迭代交付(iterative delivery)来解决缺失功能的过程(这不再是恐惧的来源)。该产品现在销售火爆。
从这个例子可以看出,没有Why的团队可能会失去方向和一致性,而强大的Why能提供心理安全感(psychological safety)和明确的目标一致性。这些共同设计强大Why的技巧依赖于坚实的信任基础和减少的恐惧,这样团队就可以在前几章学到的技能上工作和构建,比如一致性破解(Coherence Busting)和人员测试驱动开发(TDD for People)。
因此,在继续之前,请确保你已经打好了这些基础。如果已经准备好了,让我们开始吧!
我是Bobby,纽约一个团队的负责人,我们负责开发运行在儿童电子学习平板电脑中的嵌入式软件。Darius是我在硬件方面的对应负责人,负责构建平板电脑本身。我们两人共同负责发布产品的新版本,从芯片到固件再到应用程序。问题是Darius在七个时区之外,所以我们几乎从来没有机会实时交谈。我认为他的团队应该调整工作时间,这样我们就能有更多重叠时间。我一大早就起床通过电话与Darius讨论这个问题,但谈话很快就出了岔子。我已经记录下来,并将分析它以找出哪里出了问题。
提醒:先阅读右栏,然后再从右到左阅读。
| Bobby的想法和感受 | Bobby和Darius说的话 |
|---|---|
| 你肯定会看到增加沟通的好处。 | Bobby: 我们必须增加团队之间的重叠时间。你愿意晚开始晚结束来实现这一点吗? |
| 好吧,拖延不会让我们有任何进展。 | Darius: 不,那是不可能的。 |
| 我不认为圣诞老人会为我们调整送礼日期。我们的使命是让孩子们快乐和聪明;错过圣诞节两者都实现不了! | Bobby: 什么?!但我们的沟通必须改善。产品必须准时为圣诞节做好准备,延误正在破坏我们的计划。 |
| 我不敢相信。我们的文档非常清楚!他的工程师只是不想阅读它们。 | Darius: 你不明白。当问题出在糟糕的文档上时,加班不会解决延误问题。 |
| 我会再次尝试说明理由。 | Bobby: 如果确实是文档的问题——我不认为是——如果我们不多交流,我们怎么能找出哪里出了问题? |
| 我同意,和你交谈没有帮助。你让一堵砖墙看起来都透明了! | Darius: 这没有帮助。如果我们得到好的规格说明,我们就能按照它们来构建。这是唯一的方法。 |
| 我没有其他选择了。当你固执己见时,我什么都做不了。 | Bobby: 我放弃了。如果你不愿意自愿调整工作时间,我将不得不请我们的CEO让你这样做。 |
Darius在电子邮件和聊天中言简意赅且不善沟通,但我以为他会在电话中敞开心扉。天哪,我错了!他在现实中更加固执。在我看来,我们在延误的原因、如何更好地沟通,甚至为什么要制造这些平板电脑方面都没有达成一致。我不知道我怎么能和Darius一起工作。
你在信任对话(Trust Conversation)和恐惧对话(Fear Conversation)中的目的是揭示并使之前隐藏的想法(分别是故事和恐惧)可以讨论。你可能会认为Why对话会更容易,因为你只需要告诉同事他们工作重要的所有鼓舞人心的理由。对吗?
遗憾的是,这不太可能奏效,因为你鼓舞人心的理由很可能对团队中的部分或全部成员没有意义。我们知道银行业的一位高管花了多年时间告诉每个人,他的公司存在是为了提高市场效率。这是真的,公司确实非常成功地消除了金融低效率;但这个Why对产品设计、招聘或员工激励没有产生任何影响,因为它对在那里工作的大多数软件开发人员和产品经理来说根本不重要。
相反，我们建议你做一些更困难的事情：为你的组织[共同设计]Why。这比看起来更难，因为这意味着谈判和妥协，后退一步再前进两步（我们希望如此）——看似浪费时间。这也更难，因为它意味着各方自我的消亡；我们不能再相信自己是工作生活中唯一的真理和方向来源。对于真诚地相信自己是唯一知道或应该知道组织正确方向的高管或创始人来说，这尤其困难。但共同设计(Joint Design)是在团队中创建内部承诺和自组织的唯一方法。
我们将在下一节描述共同设计本身，但在此之前，我们提供两种具体技术：关注利益而非立场和结合倡导与探询。这两种技术在任何需要与他人在争议领域合作的情况下都很有用。
人道主义组织美慈组织(Mercy Corps)的谈判代表Arthur Martirosyan讲述了一个使用《谈判力：不让步也能达成协议》一书中”关注利益而非立场”技术的成功谈判案例：一家石油公司在战后伊拉克发现了大量新储量，并准备立即开始钻探。不幸的是，石油正好位于佃农耕种的田地下方，而他们还没准备好放弃庄稼。更不幸的是，他们威胁要武装自己并向公司办公室开枪，这在一个仍在从内战中恢复并被教派暴力撕裂的社会中完全可信。这似乎是一个难以解决的僵局，双方都不愿意放弃他们的[立场]：石油公司想要钻探，而农民想要耕种。僵持！
然而，Martirosyan发现了一个将讨论重新聚焦于各方[利益]的机会：他观察到石油不会消失，但农民的收获近在眼前。
石油公司能否等待一小段时间再接管土地？[可以]，因为他们的利益是保护自己的权利并在未来多年开采资源。
农民能否收获后再离开？[可以]，因为他们的利益是出售他们辛苦种植和培育的庄稼。
一旦对话转向利益，解决方案就显而易见了：庄稼成熟，农民收获，[然后]钻机进场，就在拖拉机离开之后。一些农民甚至在油田找到了工作！
你组织中的困难对话不太可能涉及驱逐租户或躲避（真正的）子弹，但你的同事可能拥有与石油公司和农民一样根深蒂固的立场，甚至更甚。在任何困难对话之前，尝试识别这些立场以及一些可能对应的利益非常重要。（别忘了你[自己的]立场和利益！）像往常一样，寻求组织外部人员的帮助通常可以帮助你识别这些，因为[你]可能对它们视而不见。
表5.1提供了一些立场及其对应利益的例子。
| 立场 | 可能对应的利益 |
|---|---|
| 我们必须在本季度发布功能X。 | 跟上竞争对手 兑现对客户的承诺 保护按时交付的声誉 |
| 我们必须消除技术债务。 | 交付高质量产品 保持开发人员满意度 招募新技术人员 |
| 我们必须停止缓冲传入的功能请求。 | 提高交付可预测性 改善团队吞吐量 跟上行业实践 |
| 我们需要使用容器进行部署。 | 减少部署失败 更快诊断生产问题 |
| 学习新技术 | |
| 我们需要一个薪酬等级体系。 | 确保公平对待员工 |
| 避免法律诉讼 | |
| 留住员工 | |
| 我们必须解雇Jane。 | 快速解决绩效问题 |
| 强化我们的文化和价值观 | |
| 削减人员预算 |
表5.1：立场与可能的利益
在对话中区分立场和利益，通常可以帮助你和团队其他成员避免陷入无休止且毫无成效的争论。如果你看到出现了僵化和对立的立场，或者感到自己的立场变得不可动摇，那就应该努力识别并分享导致这些立场的推理和利益。
例如，三位创业公司创始人中的两位正在激烈争论应该采用什么销售策略——一位热情支持在现有客户中扩张，另一位则同样坚定地主张用新产品开拓新市场。第三位创始人沉默地旁观了一会儿，直到我们邀请她插话。此时，她在白板上画了一个图表，展示了一种理解另外两位创始人利益的新方法(见表5.2)。通过引入纵轴，她让我们所有人都能看到，向现有客户和新客户提供多种选择是一个共同的利益，从他们熟知和喜爱的功能到完全来自研究的全新功能。辩论转向了一个更有成效的话题：当前的产品组合是什么，以及它应该是什么。
表5.2：产品洞察
为了具体准备为什么对话(Why Conversation)，试着创建一个类似表5.1的表格，其中立场是你认为同事可能会倡导的具体团队或组织目标，而利益则描述了他们倡导背后可能的更广泛原则。
正如我们在第2章中提到的，我们的自然倾向是单方面控制和强力倡导；我们相信，如果我们只是告诉别人我们的观点是什么，他们就会被逻辑和我们出色的修辞所迫而同意我们(反正我们是对的)。Argyris告诉我们，关注我们的对话将帮助我们摆脱这个习惯，而像TDD for People和Interests, Not Positions这样的方法会引导我们从这种单向倡导转向透明和好奇。我们不是唯一拥有真相的人；提出真诚的问题将帮助我们理解他们如何看待情况，让我们能够一起想出新的解决方案。
但过度倾向于纯粹的探询也存在危险。考虑一下我们其中一人如何与同事Sergiusz就如何获取用户对新报告的输入展开对话。因为Jeffrey和Sergiusz都做了对话分析(conversational analyses)，所以我们可以看到双方的想法——一个独特的三栏对话分析。Sergiusz和Jeffrey一起记录了这段对话，因此，他们两人的想法都被记录下来了(Sergiusz的在左栏，Jeffrey的在右栏)。实际说的话出现在中间栏。
注意：先阅读中间栏。
| Sergiusz的想法和感受 | Sergiusz和Jeffrey实际说的话 | Jeffrey的想法和感受 |
|---|---|---|
| 我认为我们应该与Rob进行后续会议，但我不认为追求其他人是有用的。 | Sergiusz：我认为我们应该把分析发送给Rob。他的评论会告诉我们是否在构建正确的东西。 | 我不太确定。我认为他对这个话题很感兴趣，但他只是众多利益相关者(stakeholder)中的一个。 |
嗯，好吧。让我们看看这会走向何方。 Jeffrey：是什么让你这么说？ 也许有一些我不知道的事情。我没有参加之前与 Rob 团队的会议。我认为他管理着那些将要阅读报告的用户。 Sergiusz：因为我得到的印象是他的团队运行类似的报告，他会知道它们应该是什么样子。 我不认为他是经理；只是一个感兴趣且直言不讳的用户。这正在变成一场决斗，而不是讨论。我不认为这些是真诚的问题。 Jeffrey：嗯，还有其他人也感兴趣。这份报告是给谁的？ 我怀疑 Rob 上面有一位做真正决策的高管。我不确定你是否有足够的理解来开始构建。我会先测试我的理解，确保我们在客户和目标上保持一致。我真的不认为这是我们应该讨论的问题。我们只需要获得反馈，而不是重新讨论报告的目的。 Sergiusz：是给运营经理的，那些保持系统平稳运行的人。 我很困惑，有点担心。你认为他们在解决什么问题？我不同意。但也许如果你得到这一分，我们可以继续决定如何获得反馈。 Jeffrey：不对，是给业务发起人的，控制预算的那个人。她收到报告后会做什么？我们一开始为什么要构建它？ 你只是在编造东西吗？你似乎根本不了解客户需求。这真的要失控了。你为什么要盘问我？你是想让我难堪吗？我希望我能逃到一个会议上，或者去做根管治疗什么的。 Sergiusz：我不确定。这可能不会让她做任何不同的事情。 她不会做任何不同的事情？那我们为什么要构建它？？我认为我们在这里真的不一致。这是一个很好的机会来确保我们意见一致。好在我可以在这上面再花些时间和你讨论。
如你所见，尽管 Jeffrey 认为他通过提出一系列问题来努力达成对情况的共同理解(mutual understanding)，但 Sergiusz 觉得自己被”引入歧途”，并且越来越担心 Jeffrey 有隐藏的议程。这次对话产生了完全意想不到的效果：它没有增进相互学习(mutual learning)，反而导致了 Sergiusz 的不信任和恐惧。
我们称之为 Perry Mason 陷阱(Perry Mason Trap)。当我们在没有解释我们的推理或陈述这些问题背后的观点的情况下提出一系列问题时，我们就会冒这样的风险：我们的对话伙伴会认为我们——就像那位 20 世纪的电视律师——正在引向某个不愉快的惊喜。（“啊哈！所以你承认你开一辆亮粉色跑车——正好和在犯罪现场看到的那辆飞驰而去的车一样！”）
为了避免这个陷阱，目标是将倡导(advocacy)你自己的立场与探询(inquiry)对话伙伴的立场相结合，正如 Peter Senge 在《第五项修炼：学习型组织的艺术与实践》中所提倡的那样。这需要大量练习才能熟练地做到，所以这里有一些实现这种困难组合的示例方法：
• “在我看来，我们必须削减招聘预算以匹配这些减少的收入。你的看法不同吗？例如，我们还有其他可以考虑削减的领域吗，或者削减是错误的应对方式？”
• “我想知道我们可以通过多少种不同的方式提供这个产品。我想到了两种——在主屏幕上和在结账时作为附加项。你还能想到什么其他想法？”
• “我听说我们的一些客户实施落后于进度，我在想我们是否应该延迟其中一些。你更接近交付团队；你如何看待这种情况？你会建议什么解决方案？”
将倡导和探询结合起来的一个幸运副作用是，你也提醒自己在对话中包含你自己的观察和想法，分享你的推理阶梯(Ladder of Inference)——一旦你开始追求更大的相互学习，这是一件非常容易忘记的事情。一旦你成功地对自己的观点保持透明，并对他人的想法保持好奇，你就在从冲突中挖掘更多价值的道路上走得很好了。
蛋糕预拌粉发明后不久,其早期制造商之一注意到一个问题:许多家庭主妇拒绝购买它。这很奇怪,公司高管们想;当人们只需要往盒装粉末中加水就行时,为什么还有人会偏爱那种需要测量、过筛和搅拌的繁琐过程呢?
这个问题困扰了公司一段时间,直到有人想到了一个绝妙的主意:直接去询问一些顾客。他们发现蛋糕预拌粉的方法太简单了——如果只需要遵循一个步骤,就感觉不像是在烘焙。顾客们希望为家人制作甜蜜美味的东西时能感到自豪;但使用预拌粉时,他们没有参与感。他们觉得还不如直接去面包店买一个现成的蛋糕。
解决方案显而易见:去掉蛋粉,要求顾客自己打入并搅拌一个真正的鸡蛋。盒子正面印上”加入你自己的鸡蛋”这句话,给了顾客足够的参与感和主动性,让整个过程重新有了真正烘焙的感觉,销量随即飙升。
我们经常看到团队试图以集中化、非协商的方式做出决策——关于流程、估算、工具、预算,甚至是谁坐在哪里。追求效率和正确性的领导者做出基本决策,然后传达给团队,期待新计划能得到热情采纳。但太多时候,就像蛋糕预拌粉的顾客一样,反应明显不那么积极,最好的情况是勉强遵从,最坏的情况是直接拒绝。当然,当这涉及到最基本的决策——定义团队的驱动性Why时,这是灾难性的。
相反,对于大大小小的决策,应该使用联合设计(Joint Design)的流程,让团队的每个成员都”加入自己的鸡蛋”。流程如下:
• 尽可能多地包含参与者
• 提出真诚的问题(参见第2章)
• 邀请相反的观点
• 设定讨论时间限制
• 确立并沟通谁将做出最终决策(称为决策规则)
首先,注意到前一节的技巧——关注利益而非立场,以及结合倡导与探询——在联合设计讨论中会非常有用。当你提出真诚的问题时,倾听并探询你听到的答案背后的利益。当你邀请相反的观点时,记得也要适当地进行倡导。如果你能做到这一点,即使只是部分成功,你也会帮助每个人提供有用的信息,并感觉自己是决策的一部分。
注意,联合设计流程不需要等同于民主或共识驱动的流程。决策规则可以意味着不需要每个人都同意该决策,甚至不需要大多数人支持它;而时间限制——为讨论设定的固定时间——确保我们不会陷入无休止的辩论。关键要素是包容性(“我是决策的一部分,我的反对意见被听到了”)和信息流动(“我能够分享我所知道的”)。我们一次又一次地看到,当我们遵循这个流程时,我们会做出更好的决策,并赢得有意义的内部承诺。
要对联合设计的双栏对话分析进行评分,查看上面列出的五个要素,每观察到一个就给自己打一分。你是否包括了所有相关且可用的人?你是否提出了真诚的问题并鼓励与你不一致的观点?讨论是否同时受到约定的时间限制和决策规则的限制?得分五分满分意味着你成功做出了一个可能获得所有人内部承诺的决策。
联合设计有许多变体。我们见过它在两人小组和两百人大组中使用,在短会议和持续数周的讨论中使用,用于小决策和大决策。为了说明其中一种变体,考虑我们合作过的一个15人工程团队,他们的发布流程容易出错且缓慢。每个人都同意一些自动化和纪律会有所帮助,我们对改进后的流程应该是什么样子有相当好的想法。简单地设计一个新的部署协议并实施它会很容易。
相反,记住蛋糕预拌粉的教训,我们把团队聚集在一起,在白板上画出当前的流程,用红色标记出摩擦和低效的区域。我们设置了一个计时器并发布了这个公告:
“这是今天的发布流程,这里是你们告诉我们运作不良的部分。在接下来的20分钟里,我们会倾听任何和所有提出的变更建议;使用这块橡皮和笔,我们会相应地更新步骤。当计时器响起时,我们将发布白板上的任何内容作为我们的新发布流程,并请你们所有人尝试它。如果这是一场灾难,两周后我们请所有人喝啤酒。谁想先开始?”
想法从四面八方涌来,包括一些我们根本没想到的,还运用了我们不知道的工具,以及来自QA和系统管理等多个专业领域的上下文信息。此外,事实证明我们并没有正确理解现有流程,我们不得不在图表中增加几个步骤才能让它正常运行。仅仅几分钟内,我们就在白板上得到了一个比我们自己想出来的要好得多的设计——房间里的每个人都觉得自己是这个设计的一部分。他们热情地实施了新系统——事实上确实比旧系统更流畅、bug更少——而且我们不需要请任何人喝啤酒。
我们相信”添加你自己的鸡蛋”对于成功确定团队的激励性Why至关重要。现在让我们看看这是如何运作的。
组织通常如何定义他们的目标、决定他们的战略,或开始重大转型?根据我们的经验,这通常是由董事会、一小群领导者或几位高管来处理的任务。他们以某种方式retreat(撤退)(到董事会会议室或场外地点),争论、辩论和思考,然后返回来呈现使命宣言、路线图或价值观定义。然后公司的其他人被期望礼貌地鼓掌并回去工作。
如果你一直关注前面几节,你可能不会惊讶我们对这种方法持非常怀疑的态度。首先,决策小组可能缺少那些外部人员持有的重要信息,因此他们的决策很可能在重要方面存在缺陷。此外,也许更重要的是,组织的其他成员对这个决策几乎没有或完全没有投入,所以他们很容易忽视它或只是口头上说说——这很难成为一个激励人心、被积极拥护的Why。
问题在于,对于可怕的场外会议,没有明显的实用替代方案。小组应该对其使命进行投票吗?讨论直到达成共识?从帽子里抽选方案?当组织中有超过两三个人时,这些方法很快就会变得笨拙和低效。
这就是为什么我们主张对Why对话采用Joint Design(联合设计)方法,无论你的团队是小还是大,正如我们上面概述的那样。尽可能包容。邀请不同的观点,并使用真诚的问题结合advocacy(倡导)和inquiry(探询)。建立决策规则,并(如果合适)限制讨论时间。
这看起来是什么样子?好吧,考虑我们的一个客户,他们在经历重大扩张后开展了Why对话来设定新的指导价值观。该组织确立了为新增长阶段重置公司方向的总体目标,并解释了计划扩张背后的业务驱动因素。然后他们做出了重大努力来征询每个人的观点——对于一个小型HR团队来说,覆盖有新员工的多个办公室绝非易事——最终得到了一份包含一百多个价值观想法的清单,员工参与度超过60%。然后较小的小组讨论和辩论这些价值观,引导者提出问题并确保每个人的观点都被听到。在设定的讨论时间后,董事会开会,审查主要想法,并为公司选择了三个价值观,受到了热烈欢迎。
与此同时,公司内两位密切合作的产品经理正在重塑他们自己的Why。在我们遇到他们之前,这两个人在一个相当于feature factory(功能工厂)的环境中充当订单接收者(见第1章),将高管的请求传递给开发人员,几乎没有过滤或反馈。通过温和的鼓励和大量真诚的问题,我们帮助他们发现他们想要扮演一个更具指导性的角色。
有趣的是,通过让开发人员和利益相关者参与并倾听每个人的利益,他们发现更多的过滤和产品方向正是他们的团队和经理想要的。他们只用了一两周时间就开始使用他们的新目标来定义和专注于新的产品方向。结合公司Why中价值观和目标的整体更新,产品经理更清晰的产品和个人Why带来了更快的周期时间、显著增加的客户反馈,以及在不到一个月内推出的新产品。
是时候通过对我与Darius的对话打分来Reflect(反思)了。我有两个问题,但它们都是leading(引导性的)而不是genuine(真诚的),因为我试图让他接受我的观点,即我们应该调整工作时间。我没有分享我对Darius和他的团队的负面看法,即使在最后我真的很沮丧时也没有。当我认为有人在忽视我或拒绝沟通时,我的反应真的很糟糕,就像Darius早期似乎的那样;这是一个twitch(习惯性反应)或trigger(触发因素),我应该注意。
转到Joint Design(联合设计),我可以给自己一分timebox(时间限制),因为不方便的时间为讨论提供了自然的停止点。但我没有得到其他任何分数:我本可以包括Darius团队的其他成员;我已经注意到我没有问真诚的问题;我完全忽略了Darius关于文档的意见;我们当然没有商定的决策规则,因为我最后觉得必须升级给CEO。五分之一不是很好。
要Revise(修订)我的对话,我肯定想要更加好奇并找出Darius的真实观点是什么。如果我能让他敞开心扉,我们可能能够想出更好的东西;避免我认为自己被拒绝时大喊大叫的倾向应该有所帮助。理解是什么激励他也会很有用——例如,他为什么如此坚决反对增加沟通?
我飞过去见Darius，认为面对面交谈会更好。在飞机上，我练习了对话的双方角色扮演，并加入了我的修改。到达后，我试图让Darius团队的其他人参与讨论，但他让他们不要来。我担心我们会再次争吵，我的旅程会白费。
Bobby和Darius的修订对话
| Bobby的想法和感受 | Bobby和Darius说的话 |
|---|---|
| 这对我来说似乎很明显，但让我们确保Darius和我看到同样的问题。 | Bobby: Darius，你同意我们在协调硬件和软件方面遇到了一些问题吗？ |
| 好的，我们同意有些地方不对劲。 | Darius: 当然——三个月后我们仍然无法发布新产品。 |
| 我要分享我的立场，这样我们就可以讨论它。 | Bobby: 确实。长期以来我的立场是我们需要多交流。 |
| 这是我从这边每个人那里不断听到的。为什么这会很困难呢？ | Darius: 我知道，但你似乎不明白这对我们来说非常困难。 |
| Bobby: 是时差让这变得困难吗？ | |
| 啊。我没意识到团队认为语言是障碍。他说得对，他们的英语确实很差，但我以为他们想提高。我敢打赌这就是他没让他们来参加这次会议的原因。 | Darius: 不完全是。我们可以而且经常按照你们的时间表工作。但我们大多数人，除了我，英语说得很少。 |
| 让我确保我清楚理解了Darius的立场。 | Bobby: 所以你的立场是我们应该避免面对面讨论？这包括让其他人来参加这次会议吗？ |
| 我不是第一次听到这个了。 | Darius: 是的。如果我们听不懂你说什么，我们试图多交流就没有意义。只要把详细的规格说明发给我们，我们会按照它们来构建。 |
| 让我们试着找出Darius立场背后的利益。 | Bobby: 这就是我们一直在尝试的，但似乎不起作用。告诉我，你为什么说”发送规格说明”？这样做会带来什么好的结果？ |
| 太好了，我绝对认同这个利益。 | Darius: 我们可以尽可能高效地继续进行硬件构建。 |
| Bobby: 我不能反驳这一点。看起来我们都对效率有强烈的兴趣。对吗？ | |
| 她确实非常注重效率——在这个国家雇人是她的主意，这样硬件设计师就能靠近工厂。 | Darius: 当然。我们的CEO似乎只谈论这个。 |
| 我有一个巧妙的想法。这对Darius有用吗？ | Bobby: 嗯。如果规格说明更容易阅读，会更高效吗？ |
| 听起来更好的规格说明确实会更高效。 | Darius: 当然。我们在这边浪费了很多时间讨论需求的含义。但我们怎么做到这一点？ |
| 我们可能必须坚持书面沟通，但有了翻译，我们可以消除理解的一大障碍。 | Bobby: 嗯，我在考虑聘请一位技术翻译将文档转换成你们的语言。 |
| 哦，这对我的利益来说听起来也很有希望。 | Darius: 我喜欢这个！翻译也可以帮助我们在视频通话中理解你。 |
Bobby: 我之前没想到这一点，但这是个好主意。我们一起写份招聘广告吧?
我们发现彼此对效率有共同的兴趣——我们共同的Why是高效构建产品。一旦聚焦于此，我们就找到了创造性的解决方案来应对沟通挑战，这个方案同时满足了我们双方的利益。翻译现在帮了我们很大的忙，我们还找到了一位能说硬件团队语言的新工程师——她正在教我们其他人也学会这门语言。
Theresa说：“我是新聘请的工程团队负责人，坦白说这个团队已经偏离正轨有一段时间了。公司需要他们开始交付业务优先级，而我需要他们内部对新方向的承诺。
“我决定召开一次Why对话会议，与开发人员和产品经理一起商定并共同设计前进的方向。”
| Theresa的想法和感受 | Theresa和团队的对话 |
|---|---|
| 我要先制定基本规则：我需要每个人的信息流动，最后要有明确的决策。 | Theresa:
谢谢大家的到来。我们将在接下来的一个小时里制定团队方向。我期望每个人都参与并提出想法，但如果需要，我可能会介入做出决策。一小时结束时，白板上写的内容将成为我们下个月的方向。大家明白了吗？ 工程师们：是的，我们明白了。 产品经理们：好的。 |
| 让团队从一开始就参与设置议题。 | Theresa: 好的，我和产品经理们一起准备了这些便利贴，描述了我们可能要做的各项工作。首先，看一下所有这些，告诉我是否有任何不值得考虑的。如果缺少重要的，请添加你自己的便利贴。 |
| 好观点。很高兴他参与进来了。 | Patrick: 我们忘记了单点登录(single sign-on)。 Theresa: 请添加上去。还有其他的吗？ |
| 我同意，但我可能遗漏了什么，特别是因为我刚加入团队。 | Quentin: 测试自动化(test automation)在上面，但它不应该是编码的常规部分，而不是一个项目吗？ |
| 倡导(advocacy)和探询(inquiry)似乎在这里起作用了。 | Theresa: 我倾向于同意，但其他人怎么想？我看到有人点头，所以我把它删除了。其他想法？ |
| 很好的观察。很高兴她参与进来。 | Roberta: 有三个可用性(usability)变更几乎是相同的。 |
| 让我们继续进行分类。 | Theresa:
这是个好观察。让我们把它们归类到”可用性”标题下。还有什么其他类别有意义？ [在接下来的几分钟里，出现了六个类别。] |
Terrence 说：“我是我们休闲在线游戏产品线的产品经理。我刚刚向执行团队展示了一个开发新游戏的新计划，CEO 和首席设计师 Barry 和 Victor 留在房间里要和我进一步谈谈。这可不是什么好兆头……”
| Terrence 的想法和感受 | Terrence, Barry 和 Victor 说的话 |
|---|---|
| 我以为你让我把流程简化！ | Victor: 我们不应该自动化开发新游戏的流程！ |
| 你不是告诉我要让流程更简单吗！ |
我们不应该限制这个小团队关注超过三个领域——这是我想明确设定的限制。在我看来，我们确实需要改进可用性来阻止客户流失，但我真的对其他想法也很感兴趣。
Theresa: 考虑到我们有限的能力，下个月我想只专注于其中三个方向。我认为可用性至关重要，但对其他两个没有强烈的看法。你会选择哪三个？如果你不同意我的看法，我特别想听听你的意见。
Sam: 我会选择自动化、导入新用户数据(onboarding imports)和简化定价。这三个都能降低运营成本。
Roberta: 为什么不选可用性？
Sam: 很简单——它不能降低成本。
Theresa: 我很好奇。有什么我不知道的强烈理由必须降低成本吗？其他人怎么想？成本是我们这个月的主要考虑因素吗？我是这么看的；不知道有没有人不同意？
Patrick: 我不这么认为。成本确实重要，但我们更需要收入。
Sam: 嗯。我们刚融资了一百万美元。我不确定这个判断是对的。我们始终需要节约现金。公司不能靠空气运转。
Roberta: CEO 昨天说我们需要拿下潜在客户，而且我们都知道，当潜在客户不会因为糟糕的可用性和过多的点击而感到沮丧时，他们才会转化。
Theresa: 这是一场很好的辩论，我很高兴我们进行了这次讨论。我要介入并说——抱歉 Sam！——像自动化这样的纯粹降本举措这个月必须排除。[我移除了自动化的便利贴。] 我们首先追求新销售，我们愿意承受一些不舒服的成本来获得它们。
Quentin: 那导入功能呢？它们有助于转化客户，同时也让运营人员的设置更加顺畅。
Theresa: 非常好的观点！Sam，你怎么看？
Theresa 在这一小时内一直以这种方式进行；尽管最后不是所有人都同意，但他们都理解了小组做出选择背后的原因(Why)。所有人都愿意朝着留在白板上的三个重点领域努力，并且理解了——即使他们仍然不同意——为什么其他领域暂时被排除了。Theresa 通过结合倡导(advocacy)和探询(inquiry)的真诚提问，确保了信息自由流动，每个人都能参与。一开始就设定的时间限制和决策规则保证了及时做出决定。团队已经准备好开始构建了！
我没想到Barry会同意。这事很严肃。Barry: 是的,你的计划会危及可玩性和质量。
我要试着通过在探询的同时表达主张来找到立足点。Terrence: 慢点——我有点困惑。我以为更简单的产品设计体验能帮助我们更好地迭代。我是不是漏掉了什么?
Victor: 我们当然希望有更好的设计流程,但不是一个能一键部署整个游戏的按钮。
我会继续探询。他们的利益点是什么?Terrence: 我还是很困惑。游戏不会上线给真实客户,只是内部使用。这不是能帮我们更快地测试和改进吗?
啊哈,这就是问题所在。Barry: 是的,但对我们来说重要的流程部分是故事板和离线实验。你的按钮会促使美术和程序员过早地提交代码和设计。
我没意识到设计师想要离线工作。Terrence: 我明白了。所以当前流程比理想情况慢,但你们重视这种慢节奏。
Victor: 没错。在早期阶段我们需要找到游戏的感觉。
Barry: 一旦我们在创意上批准了,那时我们就能加速并自动化。
让我确认一下我的新理解。他们确实想要自动化,但是针对运营人员,而不是设计师——对吗?Terrence: 我想我明白了。我们在消除部署新游戏过程中重复性工作这一点上有共同利益,但最初的创意步骤需要保持离线和深思熟虑。
Victor: 完全正确。让我们与众不同的是我们花时间设计,不像竞争对手每周匆忙推出两三个糟糕的游戏。
就是这样。我忽略了离线工作的需求,但我关于自动化价值的看法是对的。Barry: 我首先要说的是我们应该降低成本和延迟。但不是通过削减趣味性和原创性。
好,让我在这里试试一个解决方案。这符合我们在哪里使用自动化才合理的新共识吗?Terrence: 我绝对同意强调质量而非数量。我们能否使用新的部署机制,但只在运营部门使用,而不是创意部门?
Victor: 我没问题。只是别让设计师接触它。
Barry理解了——在不影响质量的情况下节省成本。Barry: 自动化会节省系统管理员运行脚本浪费的大量精力,对吧?
Terrence: 完全正确。我今天下午会给你们一个修订后的计划。
Terrence以为他和高管们在为什么(Why)这个问题上达成了一致,但突然发现情况并非如此。他专注于共同利益,并不断结合主张和探询,最终发现了不一致的根源。然后三个人能够重新达成一致,对自动化在游戏设计流程中的恰当位置有了共同理解。
Michelle正遨游在数据的海洋中。在一家小型创业公司工作了几年,只有少数客户之后,她加入了一个致力于打造全球最大市场之一的团队,拥有数百万全球用户。作为一名产品经理(product manager),她感觉自己仿佛升入了天堂。不再需要哄用户参加研究会议,或者凭直觉和祈祷发布新功能;现在她可以直接深入数据,根据真实付费用户的实际点击和购买来定位改进机会。
在为期一周的入职培训后的头几天,她开始调查所提供的各种产品。正如你在一个广泛使用的零售服务中所预期的那样,少数”鲸鱼”产品极受欢迎,而”长尾”中那些不太受欢迎的商品单独购买的次数很少,但总体上远超鲸鱼产品。随着模式和假设开始浮现,她一遍又一遍地对产品数据库进行分类和查询。
与此同时,她也在了解她的团队,一个由经验丰富的工程师组成的小团队。尽管她认识他们的时间还不长,但她能看出他们紧密团结、运作良好,有高度信任和低恐惧。事实上,尽管他们的服务有很高的可见度,她惊讶地看到他们勇敢地对推荐引擎(recommendation engine)等核心组件进行重大更改,愿意运行实验,如果不奏效就立即回滚。“这是我喜欢的地方,”她想。“我可以真正快速做出一些改进。”
一个假设从米歇尔运行的几乎每个查询结果中跳了出来：她确信许多产品一定是重复的。毕竟，它们是由普通用户输入的，只有简单的验证，一个人的”红色”肯定会是另一个人的”勃艮第色”或”樱桃色”。从本地聚合数据库的查询很难确认这一点；她需要一位工程师在大型服务器集群上编写和运行一个函数，以便在真正的PB级数据集上检查她的猜测。但如果这是真的，它将解锁许多机会来合并产品并大幅提升销售额，实现更有效的营销和推荐。她自信地走向工程师们的办公桌。
“嘿，艾伦，”她对这位开发人员说道，因为他正在吃午饭，看起来最容易被打断。“我想运行一个大型查询来查找重复的产品。这是我在本地一直在做的事情。你能把这个请求放到你的待办事项中并运行它吗，比如说，本周晚些时候？”
艾伦停止咀嚼，怀疑地看着米歇尔。“为什么？”他问道。
“嗯，”她回答说，“如果我们能合并相同的产品，推荐将会——”
“这不是我问的，”他说。“我问的是’为什么？’”
“我正在试着告诉你。一旦我们知道什么是重复的，我们就可以合并它们，然后——”
他向她挥了挥手中的披萨，她停了下来，感到困惑。“我觉得你没在听我说话。我想知道为什么我们应该调查重复项。”
“因为如果我们知道它们，我们就可以修复它们！这不是显而易见的吗？”
“不，”他说，“并不是。在你能告诉我为什么值得做这件事之前，我不会处理这个问题。”说完这些，他咬了最后一口，打开他的编辑器，开始打字，对话显然结束了。
米歇尔感到震惊。她以前从未被开发人员如此直接地挑战过。但当她仔细想想时，她不得不说他可能是对的。她真的无法确切地说为什么修复重复项比艾伦此刻正在做的事情更有价值；这对她来说只是感觉是对的。她决心找出答案，并给他一个令人信服的”为什么”。
米歇尔回到她的办公桌，开始思考艾伦的问题。你不会故意设计一个有重复项的系统，对吧？她想。但我猜它们可能是无害的，或者对销售的损害比我们可以修复的其他东西要小。在没有运行需要工程帮助的昂贵查询的情况下，我怎么能证明情况并非如此呢？
然后她想到了一个主意：前五十个”鲸鱼级”产品占市场收入的巨大百分比，而且因为它们非常重要，米歇尔在她的笔记本电脑上就有它们的销售数据。如果其中一个或多个受到重复的困扰怎么办？在一张纸上快速计算证实了米歇尔的怀疑：即使对重复率进行非常保守的估计，仅为几个最受欢迎的产品合并匹配记录所产生的收入增长就会超过团队整个季度的目标。
她冲回艾伦那里，把她的计算结果扔到他的键盘上。“看！这就是为什么我们需要这个查询，”她叫道。
艾伦读了计算结果并抬头看着米歇尔。“你确定这是对的吗？”他惊讶地问道。“为什么我们还没有开展这项工作？”
“我认为没有人想到要检查，”她回答说。“我解释这个推理解释得足够清楚了吗？”
“我敢说！”艾伦说，开心地笑着。“我会放下我当前的项目，在今天结束前完成这个查询。”
事实证明，艾伦不仅发现了严重的重复问题，而且还发现了许多可以解决它的快速胜利。工程师们从各个方向投入其中，编写代码、测试和部署更改，对收入和客户满意度产生了立竿见影的影响。公司现在有一个专门致力于去重工作的整个团队，确保米歇尔和艾伦设想的收益得以保持。而这一切都是因为米歇尔和艾伦能够共同找到一个令人兴奋、激励人心的”为什么”。
在本章中，你学习了如何通过从利益转向立场来解决对话僵局；如何通过结合倡导和探究，以透明度和好奇心推进对话；如何与你的团队共同设计决策；以及如何使用上述技巧与你的团队确定一个他们内在承诺的激励性”为什么”。在共同设计的”为什么”的统一下，你和你的同事将能够进行富有成效的冲突，而不是无休止的辩论——这是你对话转型的关键一步。你可以通过多种方式使用为什么对话，包括以下方式：
执行领导者可以探索对团队目标和组织目标的技术或产品贡献，这些贡献他可能自己没有考虑过。
团队负责人可以就诸如采取哪些技术捷径或优先考虑哪些功能等主题为她的团队提供有效的指导，使用商定且理解清楚的团队和公司目标来解释她的决策。
个人贡献者可以将他在测试、部署和/或编码方面的经验应用于团队流程或方向的变更，通过他自己和他人的内在承诺做出更好的决策。
* 此外,你可能需要定期更新你的Why,因为团队成员会来来去去,环境也会发生变化。这更说明了掌握Why对话技巧的重要性!
** 还记得信任对话(第61页)中的推理阶梯吗?像这样基于立场的争论通常涉及大量来自阶梯顶端的行动倡导,而没有分享导致不同结论的推理过程(包括利益)。我们听到这被恰当地称为”决斗阶梯”。
*** 虽然通常认为是Duncan Hines,但最新研究表明匹兹堡的P. Duff and Sons实际上是第一个意识到这一点的。7
**** 对我们的性别化语言表示歉意。这是在二十世纪中叶,当时大多数蛋糕烘焙者确实是家庭主妇;这也是当时营销人员谈论他们客户的方式。8
***** 有关旧蛋糕粉盒子上的示例,请访问 https://www.thissheepisorange.com/office-psychology-let-your-people-add-an-egg/
****** 虽然这个故事广为人知,但我们要感谢Gerald Weinberg的Secrets of Consulting提供了这个版本,以及那句令人难忘的短语”添加你自己的鸡蛋”。10
[F]{._idgendropcap}在本书中,我们第一次要讨论如何更好地执行。使用本章介绍的工具将帮助你的团队做出有效、可靠的承诺。执行通常是我们在诊断问题团队时听到的第一个关注点:“我们的流程臃肿,拖慢了我们的速度。”“用户已经好几个月没看到改进了。”“我们就是完成不了多少工作。”那么我们为什么等了这么久才来解决它?
正如我们将详细解释的,原因是如果你还没有首先建立信任、减少恐惧并就Why达成一致,执行只会让你更快地到达错误的目的地。这正是我们在第1章中讨论的软件工厂的失败模式—详细的计划和严格的职责分离给人一种控制和精确的错觉,但实际交付远远达不到团队的潜力,因为缺少基础要素。高管们对未能交付感到困惑,因为计划看起来如此精确;团队负责人争先恐后地去达成他们无法向团队解释的不可能的截止日期;而个体贡献者则被吓得工作到很晚,或者周末加班,或者干脆为一个全新的雇主工作。
好消息是,通过应用我们迄今为止介绍的经验,你现在已经准备好使用本章的技巧来做出有效的、可信的承诺,这些承诺将受到热情、自主的团队的欢迎。在将这些方法添加到你的个人对话工具包后,你将能够:
• 识别关键词和短语并就这些关键要素的含义达成一致,确保每个人以相同的方式理解团队承诺。
• 使用Walking Skeleton(行走骨架)为一系列承诺提供框架,并展示每个承诺的进展。
• 结合这些技巧以及前几章的工具和技术,定义并就你的承诺达成一致,同时避免常见陷阱。
“我真的很喜欢我们能够在做出承诺之前明确范围并研究新工具,”我们认识的一个团队的系统管理员Bianca在对她团队安装新容器管理系统的回顾中说道,该系统已经以最小的停机时间完成了安装。“我们知道我们必须做什么,我们知道我们将如何处理它。这让我们能够承诺交付,而新系统非常出色。”
另一个团队的开发人员Carlos对他的管理层采用敏捷方法的举措毫无信心。“他们说他们希望我们改变工作方式,”他说。“但他们真正关心的只是达到截止日期。我们现在会按照他们的要求做这件事,但在几个月内会出现某种危机,所有这些敏捷的东西都会消失。”Carlos正在按照计划参加配对、测试和估算的培训,但实际上根本不打算改变他的日常工作习惯。
我们可以从Bianca的评论中看出,她参与了一次成功的承诺对话—在这个对话中,每个人都创建并承诺了一个共同的定义,即项目”完成”意味着什么以及如何实现它—但Carlos绝不是承诺的。Bianca知道她在签约做什么,并且参与了切换容器系统的决定,而Carlos的经理只是做出决定并下达命令开始使用敏捷方法。Bianca支持她团队的新流程,而Carlos只是在等待直到他不必再遵循他的流程。
我们总是听到关于”承诺”的讨论。通常团队会承诺一个截止日期,但也存在其他类型的承诺。一位高管可能要求她的部门承诺抽象的理念和价值观,比如专业性或诚信。监管机构可能要求公司承诺非常具体的行动,比如在五个工作日内编写操作程序文档。我们自己也经常询问人们是否愿意”存异求同并承诺”。为什么会有这么多承诺的请求?
这是因为我们想避免另一种选择:服从。
服从就是按照别人说的去做。乍一看,这似乎不是件坏事;毕竟在许多工作场所,服从是期望的行为,让稳定有效的流程保持顺畅运行。然而,服从恰恰在流程不稳定时失效,在需要创造力时失效,在团队需要识别和克服未知障碍时失效——也就是说,当你需要通过接受新挑战来创造新的业务价值时,恰恰是敏捷(Agile)、精益(Lean)和DevOps软件开发方法旨在解决的情况。
没有承诺的服从只是走过场。从外部看,它可能看起来一样,但团队成员知道缺少了某些东西。服从是出现;承诺是全身心投入。服从是填补空间;承诺是参与。服从对于日常例行任务可能足够;服从不足以产生变化、改进、卓越。如果这些是你的目标,你需要承诺。
承诺从何而来?一个人可能出于许多个人原因而承诺。有时承诺产生于某人亲身经历的问题。Jeffrey培训的一位测试开发者说,她的动力是能够在周五按时回家,而不是修复最后一刻的bug。对其他人来说,这是掌握能力(mastery)的问题:他们相信某项技能是成为称职专业人士的一部分,因此他们被驱使去拥有这项技能。这些独特的个人承诺来源很重要,但就其本质而言,它们难以规划或依赖;你的团队中不太可能每个人甚至大多数人都以这些方式达成承诺。好消息是,有一种非常成功的方法可以向每个团队和每个人寻求承诺:我们可以在承诺对话(Commitment Conversation)中请求它,正如我们将在本章中解释的。
成功的承诺对话建立在我们迄今为止描述的其他对话之上:
如果你的团队信任度低,他们会像Carlos那样行事,这位开发者表面上遵循流程,但实际上没有真正改变任何东西。没有与请求承诺的人一致的故事,Carloses们会默认采取愤世嫉俗的信念和无效的行动。“如果我们努力工作以实现这个结果,他们下次只会要求我们更加努力工作,”他们说。
如果你的团队对未能兑现承诺的后果怀有未缓解的恐惧,那么他们会变得过度规避风险,严格遵循命令。毕竟,如果事情不顺利,这并不真的是他们的错;是别人告诉他们去做那些没有意义的事情。对于选择这种心理防御的人来说,微观管理者(micromanager)是一个完美的解决方案。一个人喜欢下达详细命令,而另一个人喜欢被精确告知该做什么。结果通常不太令人印象深刻,但这是一次舒适的旅程——通往无处。
如果你的团队被排除在设计承诺的原因之外,他们不会完全理解它或真正相信它。没有机会对提案进行拷问,找出其所有弱点和边缘情况,他们为什么要相信这是一个能够在未来困难中存活并交付结果的计划?“只是顺应管理层下达的任何东西并等待它失败要安全得多,”他们会说。
但如果你克服了所有这些障碍,你就准备好进行承诺对话了。
我是Mandy,一家中型软件公司的产品经理。我们技术精湛的开发者关系团队正在构建一个新的API(应用程序编程接口——程序员自动化与我们服务交互的一种方式),营销部门对此非常兴奋。在我们上次的冲刺规划会议上,我试图让团队估算一个交付日期来帮助营销部门,但这在我面前爆发了。我想我应该尝试记录(Record)这些对话之一并分析它,以帮助我和我的团队就确定的截止日期达成协议和承诺。
提醒:先阅读右栏,然后返回从右到左阅读。
| Mandy的想法和感受 | Mandy和开发者所说的话 |
|---|---|
| 每个人都在等这个——版本1真的显示出它的老化了。 | Mandy: 好的!我们下一个要估算的项目是API的版本2。 |
| 这听起来不太好。 | Zeke: 是啊,对。一根绳子有多长? |
| 我原本指望在营销活动之前就完成这个。它有风险吗? | Mandy: 真的吗?我以为我们计划在本次冲刺中完成它。 |
这根本说不通。 Xavier: 这不太可能。首先，我们刚发现底层数据无法通过验证。如果所有客户都在使用，数据必须是好的。 Mandy: 真的吗？那版本1是怎么工作的？我不太确定客户真的需要我们在新API中提供完全有效的数据。他们中的很多人已经有清理脚本了。 Walter: 它不保证有效性，但v2应该做到。我以为版本2只是一次早该进行的整理。为什么会更复杂？ Xavier: 还有很多复杂的测试用例。在我们尝试几个之前，无法给你估算时间。也许我可以从他们那里得到某种承诺，即使确实需要比我们希望的更长时间。 Mandy: 那你认为我们什么时候能真正准备好？这绝对不可接受。 Zeke: 无法知道。不确定因素太多了。我这里有个大问题。没人会想听到这个。 Mandy: 真的吗？我觉得市场部的朋友们不会喜欢这个答案。
我以为这会是一次简单的估算，就像我们在冲刺前会议中做的所有其他估算一样，但我大错特错了！团队对新版本似乎非常消极，他们认为完成这项工作有多难让我非常惊讶。没有估算将真正打乱市场部的时间表。他们难道看不出我需要他们做出承诺以便我们进行规划吗？
Jeffrey认为他说得很清楚。“新登录页面会在周五完成吗？”他在周一早上的计划会议上问道。“绝对会的。我们估算需要五天，没有理由不能在那之前完成，”开发人员回答说。
在接下来的周一，团队回顾了上周的进展。“我看到新登录页面在生产环境中还没有工作，”Jeffrey说。“为什么没有像你们预期的那样在周五完成？”
“但我们确实完成了计划要做的事情，”他们回答说。“代码已经上线了。所有测试用例都通过了。我们只是暂时禁用了它，因为单点登录集成出了问题，客户团队正在处理。它已经完成了——只是还没有开启。”现在我们看到了这个承诺的经典问题：我们没有就”完成”的含义达成一致。
团队进行了一次非常简单的承诺对话(Commitment Conversation)，但Jeffrey没有充分准备。他知道自己说”完成”时的意思，在他脑海中一切都很清楚。他没有做的是收集并表达他对承诺到底期望什么的想法。他想知道的是，“周五我能在生产环境中使用这个吗？”他实际问的是，“这会完成吗？”Jeffrey如果问第一个更具体的问题会做得更好，或者在第二个问题之后追问，“五天后客户能够使用什么？”
我们针对这类误解建议的解决方法是，在承诺对话之前和期间，非常仔细和明确地与对话伙伴对齐我们的语言。正如Roger Schwarz在《聪明的领导者，更聪明的团队：如何让你和你的团队摆脱困境以获得结果》中所说，我们应该”使用具体示例并就重要词汇的含义达成一致。“这在任何困难对话中都有帮助，但在讨论承诺时尤其如此，因为误解的代价可能非常高：除非我们精确阐明我们承诺的内容，否则任何误解可能直到完成时才会显现，也许是几周甚至几个月后，在浪费了大量精力之后。这正是Jeffrey和他的团队发生的事情。
请注意，我们并没有说在Jeffrey的案例中，团队应该就完成的单一公开定义(DoD, Definition of Done)达成一致，这是Scrum团队特别使用的敏捷实践。我们当然认为完成的定义可能非常有帮助，它确实可能帮助了Jeffrey和他的团队，但它不能保证避免承诺沟通的误解。例如，团队可能将”完成”定义为”通过所有单元测试，产品经理验证功能，代码在生产环境中”，按照这个定义，登录页面确实完成了。问题一如既往是人际关系问题；Jeffrey在提问时对”完成”的想法与开发人员的想法不同；我们所知道的揭示这种不一致的唯一方法是问这样的问题：“你所说的’完成’究竟是什么意思？”
“完成”是一个重要的词，您需要在承诺对话(Commitment Conversation)中讨论和明确其含义，但可能还有许多其他词汇也需要澄清。例如,要捕捉复杂软件功能的目标行为非常困难,比如价格计算:“每平方米5美元,但花岗岩饰面是6美元。会员享受10%折扣。但周四是15%折扣。还有…”很容易遗漏某个特殊情况或在细节中迷失。幸运的是,我们有Gojko Adžić的实例化需求(Specification by Example, SBE)等技术,它为我们提供了一种结构化的方式来讨论功能使用的实际案例,并确保我们在功能应该如何工作方面完全一致。
当您要求对流程或文化变革做出承诺时,通过使用具体示例来统一语言含义就更加重要了。Sofar Sounds是一家在全球数百个城市举办小型音乐会的初创公司,在”DIY”(自己动手)的含义上遇到了这个困难。最初,参与者会把现金放在帽子里来支持活动组织,音乐家的表演是无偿的——这是一种非常非正式的DIY体验。当公司转向固定价格售票,并与Airbnb合作销售门票时,它试图向广泛分散的社区传达其对DIY精神的持续承诺,额外的收入使Sofar能够向演奏者支付一些费用并资助进一步的推广。但对许多艺术家来说,这种语言的含义并不相同,他们认为自己以低费用表演,而想象着大量门票收入流向了遥远的中央总部;这似乎不再是DIY,而更像是”为他们做”。只有当Sofar分享活动收入和支出的详细示例时,他们才能克服这些异议。通过展示收入主要用于推广和改进设备等本地活动,他们证明了活动仍然是DIY性质的;有了这种共同理解,他们能够重新获得表演者对他们演出的承诺。
因此,当您准备承诺对话时,考虑哪些词汇和概念容易被误解,并与您的团队就这些词汇进行明确、详细的讨论。如果需要,为关键词汇和短语制作词汇表或海报,写明商定的定义。并在每次承诺对话开始时重新检查这些定义。
共享含义分数
当您想检查在含义达成共识方面的进展时,可以通过圈出对话中最重要的词汇,并验证您和对话伙伴已确认对每个词汇定义的共同理解,来为对话评分。重要词汇通常包括命名您正在讨论的活动关键要素的名词(“用户”、“价格”、“偏好”、“订阅”),以及描述这些要素如何交互的动词和形容词(“安全”、“有效”、“认证”、“购买”)。创建一个分数,显示有多少词汇具有已确认的共享含义(分子)占重要词汇总数(分母)的比例:
承诺是脆弱的东西,容易做出也容易违背。承诺应该不仅仅是一个诺言——它是您以信念和知识做出的,并以创造力和技能执行的东西。如果您能做到两件事,就能做出更强大、更自信的承诺:尽可能缩小每个承诺,以及使用一个框架来轻松地一次又一次地交付您的小承诺。行走骨架(Walking Skeleton)技术为您提供了这两个优势。
Alistair Cockburn在20世纪90年代创造了”行走骨架”这个短语,用来描述他在早期迭代交付团队中观察到的重复模式。正如他在《敏捷软件开发:协作游戏》(Agile Software Development: The Cooperative Game)中所述,一位项目设计师告诉他这个故事:
我们有一个大型项目要做,由系统之间以环形方式相互传递消息组成。我和另一位技术负责人决定,我们应该在第一周内将这些系统连接起来,使它们能够在环中传递单个空消息。这样我们至少让环运行起来了。
然后我们要求,在每周结束时,无论在该周开发了什么新消息和消息处理,环都必须完好无损,能够无故障地传递前几周的所有消息。这样,我们就能以可控的方式发展系统,并保持不同团队之间的同步。
在这里,承载消息的”环”就是行走骨架。就像真正的骨架一样,它从一开始就为系统提供了有意义的结构,您可以从中辨别出最终的预期形态——您可以看着一副骨架,立即分辨出它属于鱼还是青蛙,即使您无法准确判断它是哪个物种。仅从上面对环系统的描述,您就可以快速确定它将涉及某种网络间通信。但与真正的骨架不同,环系统”行走”是因为它实际上执行了一个功能,传递消息,即使最初只是简单的消息。
由于步行骨架(Walking Skeleton)的这两个特性——它的结构和功能——它还提供了一种描述承诺的语言和交付承诺的机制:“到周五,我将让支付消息在环中传递,尽管可能还没有验证。”它让团队保持每个变更都非常小且可以立即交付;你可以从一个空消息开始,然后逐步添加内容、额外的类型和路由,直到最终得到最终系统。
在现代软件设计中,步行骨架可能表现为一个客户端界面,通常在浏览器中,与一个非常简单的后端系统通信,该系统带有数据库和与第三方的适当集成。例如,总部位于伦敦的初创公司Unmade帮助服装公司使用与其零售和制造运营集成的软件提供可定制的服装。在最近的一个项目中,他们的步行骨架有一个精简的用户界面——只不过是几个颜色选择器——和一个以单一格式发送给服装制造商的基本输出文件,尺寸和版型等参数都是固定值。尽管很简单,但这足以生产出一件具有用户选择颜色的实际服装。从这个简单的界面开始,Unmade能够在每个迭代周期(sprint)中添加越来越多的定制选项、尺寸和格式,生产出越来越好的服装,直到他们准时交付了项目。
说了这么多,在创建步行骨架时需要记住两个约束:
不要漏掉任何肢体;不完整的骨架还不如没有。如果Unmade的系统完全遗漏了定制选择或生成输出文件的能力,它就无法作为他们承诺的框架发挥作用,因为他们将无法制作真正的衬衫或裤子。如果内部和外部客户无法查看和穿上实体服装,他们如何验证沿途的每次交付都在增加价值并履行承诺呢?
不要将步行骨架与最小可行产品(MVP, minimum viable product)混淆。没有人会从只有一个尺寸的商店购买商品,所以Unmade产品的第一个骨架版本距离商业可行性还有很长的路要走。然而,它成功地运行了最终软件系统的所有组件,产生了巨大的信心,并提供了一个交付机制,在实现最终目标方面效果极好。你可能希望在向骨架添加功能的过程中的某个时候生产和使用MVP,但你的初始骨架可以简单得多。
那非软件承诺呢?步行骨架在这里也很有用,只需进行适当的修改。一个常见的DevOps模式是开始监控和发布关于系统特性的信息(比如内存使用情况),然后将其用作步行骨架,通过一系列小承诺来逐步削减这个指标,减少5%的占用空间,然后是10%,依此类推。另一个例子:我们使用每月的管理学习小组作为步行骨架,帮助一个组织首先研究新的管理方式,然后逐步引入一个又一个这样的变革,在学习小组会议中相互评估其进展。
倾斜滑块(如图6.1所示)说明了团队在做出承诺时在完美可预测性和总体生产力之间做出的权衡。一个高度可预测的组织的例子是NASA,它交付极其可靠的、安全关键型软件,以行星和卫星的运动设定的刚性截止日期为准,但其生产力与大多数开发人员相比是冰川般缓慢的——每个开发人员每年只有几百行代码。
图6.1:倾斜滑块
相比之下,一些发布前的初创公司拥有微小的开发团队,生产力极高,因为他们几乎不需要任何流程,可以改变优先级而不必担心惹恼他们的(不存在的)用户。但这些初创公司从未听说过路线图或截止日期,在交付方面通常绝对不可预测。
很少有团队处于滑块的任一极端,但每个人都处于这个光谱的某个位置。将滑块移向可预测性必然意味着更多的流程、更多的规划和更少的编写代码。将滑块移向生产力意味着放弃一些你可以做的估算和前瞻性规划,转而支持快速迭代和反馈来纠正错误。
这个滑块最不寻常的方面当然是它是倾斜的。这是因为有一种引力将你的团队拉向光谱的可预测端。这种力量是人类对控制的自然渴望。一个常见的错误是应用诸如正式需求和变更管理之类的控制方法,而实际上,你可以用更接近滑块生产力端的方法获得足够的控制。
在适当的情况下,倾斜滑块可以帮助你进行承诺对话。如果你提议的承诺涉及交付特定功能或在指定截止日期前完成工作,请尝试确定你的团队目前将其倾斜滑块设置在何处:更接近可预测端、生产力端,还是正好在中间?与团队中的其他人讨论这个问题,以协调你们对当前设置的看法。这个设置是否有效,还是你想移动它?当前设置意味着你正在做出什么权衡?当前设置对你团队的速度意味着什么?你的输出质量呢?你的结果的可预测性呢?理想情况下,在开始承诺对话之前,你将对这些问题有共同的看法,这样你就可以调整你的计划,以适应你预期的生产力或可预测性水平。
有了你现在已经建立的对话技能，成功的承诺对话的步骤很容易——看似容易——总结。首先，就对话中将使用的词语的含义达成一致，可能使用一些TDD for People或Coherence Busting来克服误解和恐惧。然后使用你的Walking Skeleton来定义一个或多个小步骤，并与你的对话伙伴就这些步骤达成承诺。最后，明确确认承诺，可能通过要求所有参与者重申和接受承诺，或将其公开发布在看板或维基页面上。
成功的承诺对话的三个步骤是：
就承诺的含义达成一致。
就要承诺的下一个成果达成一致。
重申承诺。
这些步骤看起来很直接——但障碍正等着绊倒你。
第一个障碍是文化性的：自愿承诺有价值的想法在你的环境中可能是一个威胁性的、不受欢迎的概念。在这种情况下，服从是当务之急，因为管理者更喜欢这样的幻觉：他们所需要的只是员工做他们被要求做的事情。毕竟，他们不必要求机器做出承诺。正如我们在第1章中指出的，将人类视为一种机器使管理工作变得简单得多：你不必面对团队不信任你，或者你担心它不能很好地完成工作，或者那些讨厌的人类带来的许多其他混乱问题。
如果我们相信人们按照被告知的去做就足够了，管理确实会简单得多。如果我们认为开发人员是可互换的资源(interchangeable resources)，其中一个可以立即无痛地替换另一个，那么配置项目就更容易了。如果我们相信一个工程师可以在两个、三个甚至更多项目之间高效地分配她的时间，那就更容易了！这些关于可替代性和无摩擦任务切换的信念符合泰勒主义(Taylorist)、人即机器的模型。然而，人类不是这样的，承认这一点可能会削弱管理文化的基础，迫使我们面对那些只是更容易忽略的困难的人际关系问题。
如果你怀疑你对承诺有文化偏见，或者如果你遇到的阻力表明这种偏见确实存在，你还没有准备好进行承诺对话。首先返回前面的章节来解决信任、恐惧和为什么等潜在这种阻力的问题，然后你会发现对话本身要容易得多。
第二个障碍，矛盾的是，是你的团队使用的现有承诺流程，可能是sprint计划、详细设计文档，或者只是在老板给你最后期限时点头。无论你使用什么方法，你的团队可能对它太舒适了——太愿意接受不清楚的语言和过于激进的最后期限，而不参与关于你所有选择以及生产力、向内投资与向外投资的富有成效的承诺对话。
如果这描述了你的经历，尝试共同设计摆脱这种情况的方法，这样你的团队就参与了设计和举行一个对他们有效的承诺对话。你可能还会发现使用我们在第7章中描述的Directed Opportunism “简报”结构很有帮助，以帮助你的团队识别他们在帮助塑造承诺时可以行使的约束和自由。
最后一个障碍是部分接受。无论你尝试什么，你可能会发现团队的一些成员仍然停留在服从模式中，由于冷漠、敌意或纯粹的顽固，就是无法做出承诺。幸运的是，你不需要每个人的承诺！你确实需要一些有内在承诺的人或团体来做出真正的尝试。这些人，如果他们取得了一定程度的成功，可以成为冠军和传道者，然后促成其他人的承诺尝试。例如，我们从未见过一个成功的文化或流程转型项目，在一开始没有至少几个有承诺的个人的坚定努力。
当你克服了这些障碍并进行了顺利的承诺对话时，感觉会很棒！我们记得几年前我们的一次团队会议：那年夏天，我们在一个炎热的会议室里规划一个漫长的项目。每个人都争论出了所有的含义，并在通往我们想要做出的更大承诺的道路上定义了许多小步骤，我们在白板上加起来我们的估计，得出了大约五个月后的总体交付日期。沉默降临了，因为没有人想对这个实质性的承诺发表评论，直到一位勇敢的工程师从后面发声。
“大家，这里没有什么可害怕的。我们理解任务，我们知道每一个任务单独来说都是简单和可实现的。事实上，如果我们不能在那个日期之前完成这组任务，甚至更早，我们应该转行了。”
我们对团队进行了民意调查，他们看起来松了一口气，因为每个人都同意这些任务肯定是可以实现的。然后我们一起走进凉爽的空气中，成为了一个有承诺的团队。
反思和修订
我将开始尝试通过反思来理解我的对话并为其评分。我问了两个问题，反思后，我确实认为这两个问题都是真诚的——我真的很想知道为什么版本2比版本1复杂得多，以及该功能何时才能真正准备好。另一方面，我的左栏显示我对开发人员所说的话有很多疑虑，但我完全没有分享这些疑虑。我还注意到，当我感到惊讶或不满时，我经常说”真的吗？“，这似乎是一个明显的信号。
那么达成意义共识的情况如何？我圈出了五个对主题特别重要的词或短语：“估算”、“完成”、“验证”、“复杂测试用例”和”准备好”。我左栏中的一些疑虑是关于开发人员用这些词的意思，但我从未具体询问或澄清它们。所以在这方面我得零分。
为了改进和修正，我主要想更好地分享疑虑。我可以尝试注意到我们在意义上可能存在分歧时，立即表达我的担忧，而不是压抑它们。这应该能帮助我获得更清晰的承诺——至少我希望如此！
我找到了David，开发者关系团队的技术负责人。我想看看我们能否找到一种方法，共同创建一个团队和其他人都能相信的承诺。
| Mandy的想法和感受 | Mandy和David说的话 |
|---|---|
| Mandy：团队对新API估算的反应真的让我很惊讶。 | |
| 是的，我没有做梦。这里确实有问题。 | David：是的，我也注意到了。这不是他们第一次表达这些担忧。 |
| 我特别重视David的观点。他认为我们有问题吗？ | Mandy：你能告诉我更多关于这些担忧的信息吗？你自己怎么看？ |
| 真奇怪。3月4日是从哪里来的？ | David：这比我们想象的要困难得多。营销部门说要在3月4日之前完成，没有例外。团队不知道如何在那之前完成，坦白说，我也不知道。 |
| David能告诉我更多关于这个的信息吗？ | Mandy：这对我来说是个新消息——而且是一个奇怪的具体日期。 |
| 啊，我明白了。还没有人要求我承诺在三月初完成，但我敢打赌这样的请求即将到来。 | David：我也这么想，直到我看到他们在布置座位。他们租了一个大厅，邀请了所有客户来吃午餐，展示全新的、功能齐全的API！ |
| 我会提醒Dave，功能在我们作为团队达成一致之前不算承诺。我想知道我们离营销部门的目标到底有多远？ | Mandy：好消息是我们实际上还没有承诺任何事情，尽管听起来营销部门已经承诺了。团队可能接受什么交付日期作为合理的？ |
| 哎呀。那可是很长时间。但我不理解最后那句话的意思。 | David：绝对不会早于六月；七月会更好。数据需要大量过滤才能准备好给客户使用。 |
| 我认为这里不需要”客户就绪”，只需要”足够好来演示”。 | Mandy：等等，“客户就绪”？你这是什么意思？ |
| 啊，我们对这个词有相同的理解，但对承诺有不同的理解。 | David：嗯，显然所有验证都必须到位，以及所有边缘案例的测试。我们不能给客户提供错误数据。 |
| 这个区别很重要——如果我们能在需要什么上达成一致，我敢打赌他可以提出简化范围的方法。 | Mandy：我不确定我们在谈论同一件事。我们需要的承诺是针对我们可以在销售演示中展示的东西，比如在你提到的这个午餐会上，或在潜在客户拜访时。这符合你的理解吗？ |
| 是的，现在他明白了。 | David：我想我明白你的意思了。我们只需要能够展示基本工作流程，而不是整个完整的集成。 |
| 我需要分享这个约束：我们必须保护客户数据免遭无意泄露，否则监管机构会严厉处罚我们。 | Mandy：没错。这个降低的约束有帮助吗？我们可以采取合理的捷径，只要我们不让真实数据面临风险。 |
| 啊，我真的很喜欢这个，尤其是虚拟数据。 | David：嗯，我们可以首先跳过验证。我们甚至可以使用我们知道易于显示的虚拟数据。 |
让我们看看是否已经清除了承诺障碍。
Mandy：这两个范围变更都可以接受。这样能帮助团队对3月4日做出有信心的承诺吗?
这听起来很有希望!
David：我非常确定我们可以找到一种方法，在没有验证或真实数据的情况下交付。我会在今天下午询问团队，明天早上之前告诉你我听到的反馈。
我想就时间和范围与David达成一致，但我们首先必须澄清几件事：为什么团队会担心，市场部的目标是什么时候以及他们为什么选择这个时间，以及团队朝着目标工作时有哪些约束。澄清”客户就绪”的含义帮助我们朝着一个知情的承诉前进——既满足外部约束(在3月4日之前交付)，也满足内部约束(不暴露客户数据)。我对这次对话的进展非常满意!
Nash说：“我是一家大型零售商IT部门的非技术高管。我们需要在全球七个国家设立新站点，以支持我们本季度推出的新产品线。技术团队目前的估算是六个月才能启动新的在线服务，这太慢了；他们告诉我最大的阻碍是设置服务器。我正在拜访我们开发团队的三名系统管理员Abdul、Becca和Molly。我的目标是找出我们有什么选择可以快速启动这些站点!”
| Nash的想法和感受 | Nash和系统管理员说的话 |
|---|---|
| 让我们把问题摆到台面上。我想先确认一下我的信息是否正确。 | Nash：工程主管告诉我，我们能够让七个新站点上线的最早日期是2月。这对吗? |
| 好的，确认了坏消息。 | Becca：是的，那是我们最好的估算。我们有信心承诺到那时配置好所有服务器。 |
| 我们不能更快真是太烦人了。技术上肯定是可能的吧? | Nash：啊，真令人沮丧!问题是，2月大约晚了三个月。为了圣诞节，我们最迟需要在11月之前让站点上线。我们有什么选择来满足这个目标? |
| 我很高兴Molly至少信任我的动机。 | Molly：我相信你，我很想说我们能做到，但这确实不可能。即使建立备份也需要很多周。 |
| 这听起来确实效率低下。我想知道他们为什么没有对此采取任何措施。 | Abdul：更不用说所有的手动配置了。这个流程很笨拙，但我们知道它是有效的。 |
| 我假设有某种方法可以解决这个问题。我应该验证一下我是否正确。 | Nash：我不是技术人员，但这些听起来像是我们可以自动化的事情。我遗漏了什么吗? |
| 这就是我所想的。为什么内部障碍这么高? | Becca：当然!有很多工具可以让你快速且可重复地建立服务器。但IT风险和信息安全部门还没有批准它们。 |
| 这可能是让Walking Skeleton运行起来的一种方法。 | Nash：这是事实，但只针对生产站点，对吧?我们能否更快地建立内部服务，然后稍后通过正常的审批流程添加补丁管理、备份等? |
| Abdul：当然可以，但这有什么帮助呢? | |
| 一系列小的承诺，每个都得到履行，应该会建立很大的信心。 | Nash：嗯，如果站点上线了，开发人员可以更快开始编码和部署，我们可以向市场部展示真正的进展。 |
| Molly说得对，但我也许能帮上忙。 | Molly：但这并不能让我们达到你的截止日期。我们会在内部更快上线，但仍然需要经历所有的流程才能让服务器准备好生产环境。 |
Nash: 让我来担心这个问题。我认为展示有规律的、可见的进展会让审批更顺利。使用新工具，我们能在本周部署基础版本的机器吗？
比我想的要好！
Abdul: 可以；实际上我们可以在全部七个国家都完成部署。
太好了！Becca也理解了。像这样的计划能帮我在技术部门的其他地方找到优化点，也能让市场营销团队开始行动。
Becca: 同意。更重要的是，我确信我们可以快速制定一个路线图(roadmap)，展示未来两个月使用新工具进行增量设置的每周计划进展。不过，我不确定更长远的计划，而且我认为到那时我们不会完成全部工作。
我想我们现在达成一致了。是时候对计划和承诺做最后确认了。
Nash: 我们不必全部完成；我们可以边做边重新规划，随着开始使用新设置，我们会学到更多。我说得对吗，你们都愿意承诺一个为期两个月的部分路线图，每周交付成果？
嗯，我没有得到圣诞节前确定交付的承诺，但一个有明确承诺的团队加上清晰的执行计划是相当不错的替代方案。
所有人: 是的！
Nash最希望的是立即得到在圣诞节前交付全部七台服务器的自信承诺。不过，他很高兴他们努力建立的心理安全(psychological safety)文化意味着团队能够告诉他这不现实。Walking Skeleton(行走骨架)替代方案看起来很有希望（对于DevOps挑战来说通常如此），但可能需要他进行一些干预才能获得增量部署的许可——这是Nash对团队做出的对等承诺，如果没有承诺对话(Commitment Conversation)，他不会知道这是必要的。Walking Skeleton让团队能够朝着一系列更容易承诺的增量里程碑(milestone)努力，这给了Nash足够的条件来启动其他团队。这是一个多方共赢的场景！
Julie说：“最近，我发现和Erik合作真的很困难，他是CEO也是我的老板。他喜欢参与决策，比如我们下一步要构建哪个功能或是否再雇佣一名开发人员，但有时在我看来，参与这种低层级的决策对他或我的团队来说都不是很高效或健康。对我来说——以及其他与Erik共事的人——很难判断什么时候应该让他知情或参与决策，什么时候不需要他参与。我开发了一个文档模板，我认为可能有助于组织我们的联合决策。它列出了哪些决策需要Erik的意见，哪些不需要，为呈现选项提供了空间，并提醒我们收集每个选项的数据，比如成本和执行所需时间。我正准备和Erik谈谈，承诺使用这个新流程。”
| Julie的想法和感受 | Julie和Erik说的话 |
|---|---|
| Julie: 你有机会读那份决策文档了吗？ | |
| 这是个好开始！ | Erik: 读了，我喜欢！我做了一些修改。我很高兴你在做这件事。 |
| 让我们先检查一下对基本想法的认同。 | Julie: 太好了！我稍后会看那些改动。更根本的是，决策流程(process)这个想法对你来说有价值吗？ |
| 哎呀。这是真的，但我认为他没抓住重点。 | Erik: 当然。它应该能帮助我让我们保持在正轨上并保持一致。我可以阅读所有细节，并对你做出的每个决策给你反馈。 |
| 深呼吸——对这样挑战他有点忐忑。 | Julie: 我很高兴你这么说，因为我不确定我是否同意。 |
| Erik: 真的吗？你什么意思？ | |
| 让我在这里用一个问题放慢节奏。我们对基本假设达成一致了吗？ | Julie: 嗯，这个流程对我来说最大的价值在于，它能帮助我知道是否要让你参与某个特定决策。你同意我在没有你的情况下做一些决策是好的吗？ |
几个月前我不会相信这个答案，但我们的故事现在更加一致了。我确实认为他想要授权。
Erik：是的，当然。随着公司的发展，我不可能做所有事情；我必须有时让其他人掌控局面。
这是我的关键点。
Julie：好的，我们在这方面肯定是一致的。所以我最希望达成一致的部分是，在我不需要让你参与的情况下，我们将如何使用决策文档。
Erik：嗯，我不太明白。在那种情况下，你为什么需要填写它？
Julie：嗯，顶部的这一部分描述了何时使用该文档。如果一个决策不符合这些标准，我们就停止，完全不使用该文档。
我很高兴我进行了探询和澄清。现在我更有信心我们是一致的。
Erik：啊哈，因为它的级别足够低，我不需要参与。我之前没有完全理解那一部分，但现在我明白了。
最后检查——我们现在是在做出承诺吗？
Julie：所以你同意我和其他人使用这些标准作为过滤器吗？
听起来像是一个承诺！
Erik：当然，尽管其中一些需要稍微调整。例如，预算限额可以更高。但我绝对希望现在开始使用这个。
请注意信任(Trust)是如何在一个关键时刻进入的。考虑到Erik的微观管理历史，Julie本可以轻易地不相信他关于希望她独立做出一些决策的断言，但在经历了一次恐惧对话(Fear Conversation)之后——其中Erik的时间被确定为公司增长的可能限制因素——她选择相信她一致的故事，即他真的想要。这是在早期对话的基础上建立承诺对话(Commitment Conversation)。就意义达成一致也非常重要——他们两人本可以很容易地在没有Erik完全理解该流程包括授权标准的情况下”同意”该流程，这意味着他承诺不做某些事情。这肯定会导致很多困惑和挫折。我们很高兴地报告，Erik和Julie采用并仍在使用该决策框架，效果很好！
Anna Shipman，《金融时报》客户产品技术总监，在她的博客中概述了一个合规问题。没有什么明显的问题。在担任技术总监七个月后，她的五十五名工程师团队成功运营着该报的主网站，以及卫星品牌和Android和iOS应用。拥有近一百万付费用户遍布全球，该网站必须持续更新最新新闻，在所有设备上即时加载，并每天添加新功能。随着持续部署(continuous deployment)和A/B测试全力运行，该团队每周提供数百次改进，不停地进行实验，并跟上内部和外部客户的需求。
但Anna知道仍有一些东西阻碍着团队。她能在自己的日常工作中感受到这一点，当她向五位首席工程师分配任务时。无论她是在每周会议上、通过Slack或电子邮件，还是当面这样做，一种挥之不去的感觉告诉她有些不对劲。“我仍然在控制任务的流程，”她说。“我觉得一定有更好的方法来做这件事，让首席工程师们知道问题……我需要帮助的问题(也知道我不知道的问题)。”简而言之，她想要承诺(commitment)，而不仅仅是合规(compliance)。
像许多管理者一样，Anna发现当你告诉员工该做什么时，他们就会去做——而这与他们的敏捷实践(Agile practices)能够支持的创新、创造性团队恰恰相反。相反，她的目标是让她的管理团队自组织和自主，以便”他们每个人都是接替她工作的好候选人。“而当她仍然扮演首席任务分配者的角色时，这无法实现。
在向同事和同行寻求关于如何给予首席工程师更多自主权的建议后，Anna决定与他们进行我们所说的承诺对话(Commitment Conversation)。她的目标是共同设计一种更好的互动方式——一种让他们自己承诺任务的方式，而不过度依赖她。
她首先解释说，她一直在过滤来自业务其他部门的上下文信息，如收到的功能请求、其他团队的状态报告和财务结果。她说她”不想让团队淹没在电子邮件中”，所以她保护他们免受这种来自外部的输入海啸。对她来说，这些电子邮件和请求是她需要保护团队免受的干扰。
但首席工程师们的回应出人意料：他们要求获得更多未经过滤的信息，而不是更少。这样可以让他们做出明智的优先级排序和优化决策。此外，如果有人提出问题，他们会对此很熟悉，而不是感到困惑；他们能够做出明智的承诺并兑现。外部输入对他们来说意味着完全不同的东西：这是宝贵的上下文信息。
“本质上我以为我在保护他们并帮助他们完成工作，”Anna后来说，“但实际上我是在阻碍信息流通，让他们更难完成工作。”
一旦他们通过承诺对话就传入的上下文信息达成共同理解后，Anna和她的首席工程师们承诺采取几个步骤来分享上下文：
• 他们建立了一个邮件列表，并要求其他人使用它来提出请求，而不是只给Anna发邮件。她也会将她认为该小组可能会觉得有用的邮件转发到这个列表。这形成了一个步行骨架(Walking Skeleton)，使小组能够承担其他工作。
• Anna带一名或多名首席工程师参加相关会议，有时甚至派他们代替她出席。与会者会在会后在邮件列表上与小组其他成员分享会议记录。
• 小组延长了他们的周会时间，并使用彩色编码的看板来跟踪任务并分享相关信息。
• Anna花更多时间在团队的Why上，在邮件列表、内部维基和外部会议演讲中分享她的思考结果。
承诺分享更多上下文的结果是显著的。小组电子邮件地址成为大多数请求的目的地，使其所有成员都能获得更多信息，以便他们能够做出相应反应。首席工程师们能够在过载时将工作传递给彼此的团队，增加了成功交付的可能性。而且”很多时候，“Anna说，”有人会通过电子邮件或提到……他们发现并解决的问题，而我甚至还没听说过这个问题。“他们发现并利用了开发组织中未开发的潜力——这一切都要归功于承诺对话。
在本章中，你学会了识别关键概念并明确其含义，使用步行骨架为你的承诺提供结构，以及使用这些技术和前几章的技术有效地做出承诺。你的对话转型所促进的富有成效的模型II推理为有效的承诺创造了正确的环境，而对这些承诺的兑现则促进了信任并减少了恐惧，从而进一步推动转型。你可以通过多种方式使用承诺对话，包括以下方式：
执行领导者可以通过期望每个部门（如工程部和销售部）做出可信且易于跟踪的承诺，并跟踪这些承诺的进展，来调整多个部门之间的工作文化。
团队负责人和她的团队可以自信而热情地做出承诺，如冲刺目标和构建-测量-学习目标。
个人贡献者可以参与定义承诺并为其实现做出贡献。
在功能工厂(feature factory)内，完全透明地交付及其挑战是难以想象的——既然我们在每一个转折点都被僵化的命令所束缚，何必费心呢?同样缺乏自主权使得对改变目标和策略的选项保持好奇变得毫无意义，因为无法实现任何变化。但随着我们建立了信任、消除了恐惧、定义了Why并履行了承诺，我们变得更加自主和不受约束；现在通过我们的最后一个对话——问责对话，这种透明度和好奇心水平已经成为可能。
高管们会发现，问责制能让他们的部门更早、更高效地发现和纠正错误，比如优先处理了错误的功能或在云服务器上超支。团队负责人将使用问责对话来明确冲刺和团队目标，发现实现这些目标的选项，并传达他们团队在功能构建和架构变更方面的意图。个人贡献者将不再说”我们被困在支持旧浏览器上”或”某个白痴告诉我们跳过测试”。他们将知道工作的约束和自由是什么，以及在哪里可以发挥创造力来实现目标。
吸收本章的思想后，你将能够:
• 使用Y理论创建培养健康问责制的文化。
• 进行简报和反向简报，让团队高效准确地报告其行动。
• 使用问责对话传达意图，以便所有关心你工作的人都能以高效和支持的方式提供帮助、建议或纠正。
“不是又来一个！”Danny惊呼道。“这是本周第二个被延迟的功能了。照这个速度，我们周五根本没什么可以演示的。”
作为一家快速成长的初创公司的CTO，Danny手下的团队比以往任何时候都多。在公司规模较小的时候，他能够在所有工程师之间分配时间，并准确了解每个人的进展情况。但现在，他没有时间在每个冲刺期间与每位团队成员交谈；他正在失去对日常进展的掌控。
他刚刚读到的邮件很典型：移动开发人员又落后了，他们的一个应用变更不会在冲刺结束前准备好。他们并不孤单；几乎每周至少有一个团队给他带来坏消息，通常会有两三个团队报告延期。
Danny非常清楚开发工作并不总是按计划进行。事实上，他很享受工作中开发人员向他提出问题的那部分——他喜欢讨论技术选项，与产品设计师和业务部门合作寻找创造性的解决方案。对于许多老团队来说，这种动态仍然运作良好，开发人员确实会向他提出问题；当然会有小问题和bug，但他不担心在冲刺结束时会有令人不快的意外。然而，一些新团队的可预测性要差得多，主要功能延迟数周甚至数月。
Danny双手抱头，试图想出一个计划。他应该引入每日进度报告吗？聘请一位交付经理？替换某位团队负责人？他不确定下一步该采取什么措施，但他知道必须做出改变。
Danny的反应很常见。如果我们反复遭遇令人不快的意外——错过截止日期、系统宕机、预算短缺——我们想要采取行动来结束这些意外。通常的做法是要求更详细的信息，提供更具体的指示，或者设置更详细的控制。有时三者兼而有之！不幸的是，这些本能反应往往会让事情变得更糟，因为它们错过了问题的根源：问责制(accountability)。
我们所说的负责是什么意思？我们的意思仅仅是有义务报告你做了什么以及为什么这样做。每个人持有的责任感是成功的关键之一。问责制类似于所有权、责任和能动性。如果我能控制自己如何分配时间，那么只有我能够提供关于我为什么做了我所做的事情的信息，提供我行动背后的推理和意图。
请注意，我们对问责制的定义与大多数人非常不同。当我们听到一位经理说她将”追究某人的责任”时，我们的本能可能是躲到最近的桌子下面；这个短语意味着对做错事的纠正或惩罚。(请参阅下一页的侧边栏，了解可能解释这种恐惧的历史视角。)被追究责任的人应该感到内疚，从错误中吸取教训。相比之下，我们的定义表明，你可以为成功、失败或中性结果负责。但”让我们追究某人上个月销售额翻倍的责任！“可能不是我们经常听到的一句话。
我们对问责制的版本——解释我们结果的义务——是敏捷(Agile)、精益(Lean)和DevOps团队所追求的自组织的关键。每个团队成员都有权自己决定如何分配时间和精力。然而，伴随这种授权而来的是分享这些决定是什么以及为什么做出这些决定的期望。有时问责对话采取分享意图的形式：“这是我计划做的事情以及原因。”其他时候，它是关于过去事件的汇报或正式报告。无论这种问责制采取何种形式，如果Danny抑制他的控制本能，转而在团队内部建立问责文化，他将能够更成功地扩展他的工作。
这听起来可能很简单；然而，有效地负责是一项需要学习的技能。像往常一样，它需要艰难的情感工作、文化变革和大量实践。特别是，有效的问责对话需要高度信任(“我相信你会分享我的表现故事”)、低恐惧(“我知道你不会对我所做的事情反应过度”)、一致的目标(“我们正朝着这个愿景前进，这是我们今天走了多远”)，以及明确的承诺(“这是我的报告：我承诺做A，实际发生的是B”)。如果你和你的团队在开始问责对话之前已经进行了这些对话，你更有可能成功。
为什么”accountable”（负责任的）这个词通常带有惩罚性的含义?我们认为这可能与这个词的起源有关。“Accountable”字面意思是”提供账目”,而”account”(账目)一词则来自古法语,意为”计算”或”枚举”。这个词最早在中世纪进入英语,用来描述十二世纪郡长(sheriff)的行为。这些郡长或”郡督”(shire-reeve)与后来西部荒野时代持枪的郡长后代不同,他们本质上是为幅员辽阔的安茹帝国(Angevin Empire)征收税款的人。每个郡长都被分配了一个”farm”(定额),即每年需要向国王上缴的金额,他们可以或多或少地随意从自己的辖区内征收这笔款项。许多郡长通过向敬畏的公民索取远超其指定定额的款项而获利丰厚,将多余部分据为己有。
亨利二世(英格兰国王,1154-1189年在位)的政府规定,郡长们必须在每年的米迦勒节(9月29日)被召唤到他的宫廷,届时他们要带来年度收入——当然是现金(在1100年代没有支票或信用卡!)——进行清点和上缴。算术是一项罕见的技能,所以财务大臣和他的助手们使用了一种名为”Exchequer”(财政署)的工具,类似棋盘,配合一套筹码来表示和计算郡长欠王室的款项,以及该金额的任何抵扣。这个财政署棋盘逐渐代表了整个过程,被称为特定年份的”Exchequer”。每个郡长依次上前描述当年的收入,并提醒财务大臣任何例外情况或扣减项。当达成一致的总额后,郡长会交出一袋银便士来结清债务。如果发现郡长的款项不足正确金额,他可能会当场被罚款或监禁。所以,如果你认为报告一个未完成的冲刺目标(sprint goal)令人担忧,那么想象一下在十二世纪被追责是多么令人焦虑的经历!
我是Nicole,一位产品总监,负责我们组织中的多个团队。Bobby是其中一个团队的产品经理。他似乎经常误解我要求他做的工作,这意味着我们经常不得不在一个功能或项目进行到一半时停下来,与开发人员重新设定期望,并修改一半的代码。情况已经糟糕到我正在考虑解雇Bobby,但我开始怀疑自己的管理风格和沟通方式可能也在助长这个问题。从第一个R(记录)开始,我记录了我们上次的互动,看看是否能找到改进的方法。
提醒:先阅读右侧栏,然后返回从右向左阅读。
| Nicole的想法和感受 | Nicole和Bobby实际说的话 |
|---|---|
| 我希望这对你来说有意义。 | Nicole:这是新现金流报告的模型。 |
| 好问题! | Bobby:好的。它与我们今天的报告有什么不同? |
| Nicole:嗯,首先,它需要每天更新。而且它按照我们新的全球区域进行细分,而不是汇总。 | |
| Bobby:明白了。 | |
| 这就是你需要知道的全部吗?我想模型是相当不言自明的。 | Nicole:你认为什么时候能准备好? |
| 哇,真快!财务部会非常高兴。我只希望你不会像上次那样遗漏任何东西。 | Bobby:我需要和团队确认一下,但我预计我们可以在下一个冲刺中完成它。 |
| Nicole:那太好了! |
当时我对这次对话感觉很好;然而,当团队在一周后演示新报告时,我就不那么高兴了。团队使用了逗号分隔值而不是Excel格式,没有将澳大利亚作为一个区域包括进来,还犯了一堆较小的错误。为什么Bobby不能把这些事情做对?
期望你的团队承担责任是否合理?员工是自私自利的、只有在上级指示下才会行动、无法解释自己的行为吗?还是他们对成功感兴趣、受到做好工作的愿望驱动、对自己的行为负责?管理理论家Douglas McGregor在《企业的人性面》(The Human Side of Enterprise)一书中,将这两种关于员工激励的观点称为X理论和Y理论(见表7.1)。
X理论与第1章探讨的泰勒主义观点密切相关。它认为工人懒惰且愚笨，必须由管理者监督。当他们搞砸时，需要被送到”惩罚角”从错误中吸取教训。“我的员工没有产出结果?解决方案是加强管理，”X理论的管理者说。“如果我没有获得预期的进度洞察，如果我没有及时听到问题以便修复它们，那么我会雇佣一个管理者来获取这些信息。”如果你信奉X理论，那么个人贡献者的问责制(accountability)是荒谬的。工人对自己的行动没有投入，也没有真正参与规划，所以要求他们解释这些行动或后果是愚蠢的。相反，你应该询问相关管理者——了解这些是他们的工作。
Y理论是一种根本不同的人性观。它认为人们希望参与，希望承担责任，并且他们自身就具有成功的驱动力。如果我们相信Y理论，那么X理论的管理模式不仅有害，而且浪费。通过利用每个人内在的成功驱动力，我们能以更低的成本获得更好的结果。在Y理论组织中，问责制至关重要。我们有动力、有责任心的员工需要并希望向管理者和合作者讲述他们的活动和结果；他们也渴望对这些结果获得准确的反馈，以适当调整自己的行动。
回顾第1章的敏捷(Agile)、精益(Lean)和DevOps原则，我们可以看到强烈的Y理论倾向：
• 为有动力的个人提供他们需要的环境和支持，并信任他们能完成工作。
• 赋能团队。
• 相信每个人都在为业务尽最大努力。
| X理论 | Y理论 |
|---|---|
| 态度 | |
| 人们不喜欢工作，觉得它无聊，如果可能会避免它。 | 人们需要工作并希望对它感兴趣。在适当的条件下，他们享受工作。 |
| 方向 | |
| 人们必须被强制或贿赂才能做出正确的努力。 | 人们会朝着他们接受的目标自我引导。 |
| 责任 | |
| 人们宁愿被指挥也不愿承担责任(他们会避免责任)。 | 在适当的条件下，人们会寻求并接受责任。 |
| 动机 | |
| 人们主要被金钱和对工作安全的恐惧所激励。 | 在适当的条件下，人们被实现自身潜力的渴望所激励。 |
| 大多数人几乎没有创造力——除了在规避规则时。 | 创造力和独创性广泛分布且严重未被利用。 | |
Niels Pflaeging, “为什么我们无法从丰田或 Semco 学到任何东西。”
表 7.1：X 理论和 Y 理论
这当然不足为奇；当我们审视前面四个对话中的每一个时，我们看到一个又一个软件团队通过与 Y 理论一致的行为取得成功的故事，比如建立信任、解释动机而不是强加愿景，以及提供上下文来推动承诺。事实上,我们同意 Niels Pflaeging 的观点，采用 Y 理论是成功实施敏捷(Agile)、精益(Lean)或 DevOps 方法的前提条件。
那么令我们困惑的是，为什么 X 理论在那些至少在理论上采用以人为中心的软件方法的团队中仍然如此普遍。为什么有人会保留一种积极阻碍问责(accountability)（在我们的意义上）的文化模式？
我们将把详尽的答案留给社会科学家，但我们怀疑一个促成因素可能是电视和电影中展示的例子，它们提供了我们最初的领导力模型。一些电影描绘了强硬、果断的领导者发号施令——一个坚定但公平的人。强硬。不怕指出搞砸的人。另一个老套形象是无效的管理者，《呆伯特》中的”尖头发老板”，他总是要求状态报告，对细节吹毛求疵，同时忽略大局。这两种方法都不是有效领导力的例子，部分原因是它们与真正的问责(accountability)相悖（果断的领导者不会倾听叙述，而优柔寡断的领导者无法决定如何处理信息）。这两种风格都会导致组织内部的无效冲突——但冲突恰恰是制造戏剧的东西，这正是销售电影票和 Netflix 订阅的原因，从而解释了这些方法在电影和电视中的流行。
相比之下，关于相互依存和自组织的媒体模型要有限得多。我们能想到的唯一突出的 Y 理论领导者的戏剧性描绘是帕特里克·斯图尔特在《星际迷航》系列中饰演的皮卡德舰长，他在对新观察或事件做出反应之前，定期收集船员的所有观点，然后经常将大胆、危险的干预委托给其他人。像复仇者联盟这样的超级英雄团队，或者偶尔的群像电影如《伴我同行》的主角，描绘了具有非常不同技能的相互依存的人群，他们通过使用每个人可以贡献的任何优势来克服障碍；他们也为自己的决定及其后果相互负责。但这些都是似乎远离日常生活的例外。
你能做些什么来克服这种对 X 理论的偏见？与大多数这样的变化一样，我们建议你争取有同情心的团队成员来帮助你识别和克服组织中的 X 理论信念和习惯。例如，你可以重申对心理安全的承诺（见第 4 章），像 Anna Shipman 和她的团队那样分享业务背景(context)（见第 6 章），并庆祝那些承担额外责任的人。仅仅通过举行问责对话(Accountability Conversation)，你就会发出关于自主性和内在动机的强有力的文化信息。
阻碍问责对话(Accountability Conversation)的另一个障碍是朴素实在论(naïve realism)。这是一种观点，认为我们客观地、无偏见地看待世界，而且其他人会根据相同的观察得出与我们相同的结论。当我们采用这种对世界的简单化观点时，我们认为不太需要沟通，当然也看不到叙述的必要性；毕竟，其他人观察到的事情与我们相同，那么我们为什么需要解释我们的行动或其结果呢？当然，这种方法是错误的，我们需要问责对话(Accountability Conversation)恰恰是因为其他人可能拥有我们不具备的信息；他们可能对结果得出与我们不同的结论。
有一种结构化的方法可以消除我们对朴素实在论(naïve realism)的偏见，而且来自一个令人惊讶的来源：十九世纪普鲁士军队的实践。Stephen Bungay 在他的书《行动的艺术：领导者如何缩小计划、行动和结果之间的差距》中描述了这种方法，他称之为”定向机会主义(Directed Opportunism)“。
Bungay 首先描述了”摩擦(friction)“，即墨菲定律（”任何可能出错的事情都会出错”）发挥作用的所有方式的总和。摩擦的结果是在我们试图将期望的结果转化为计划、将计划转化为行动、将这些行动转化为我们预期的结果时出现的三个差距（见第 164 页的图 7.2）：
• 知识差距(knowledge gap)是我们想知道的和我们实际知道的之间的差异。
• 认知差距（knowledge gap）是我们认为自己知道的和实际知道的之间的差异。
• 协调差距（alignment gap）是我们希望人们做的和他们实际做的之间的差异。
• 效果差距（effects gap）是我们期望行动达成的效果和实际达成的效果之间的差异。
图7.2：Bungay的三个差距
[改编自”执行战略：一些主张”，StephenBungay.com，访问于2019年10月3日，https://www.stephenbungay.com/ExecutingStrategy。]
针对上述三个差距，以管理为中心的方法是试图消除它们。为了缩小认知差距，领导者寻求更详细的信息。为了缩小协调差距，他们给出更具体的指示。为了缩小效果差距，他们实施更详细的控制。然而，完全消除这些差距是不可能的，我们越是坚定地试图这样做，就越会造成痛苦。面对这种专制的微观管理，“承诺被服从取代，活力被消耗，士气下降。”[12]
作为替代方案，Bungay提出了他的定向机会主义（Directed Opportunism）方法，这是他从19世纪普鲁士军事领导人在与法国、丹麦和奥地利的战争中的战略和战术创新中逆向推导出来的。普鲁士人发现，在指挥链的上下级之间清晰地沟通计划和意图，对于掌控19世纪战争日益增长的复杂性至关重要。因此，定向机会主义的核心是各方之间的一个协议：一方使用简报来描述我们要去哪里，另一方使用”回报”来解释我们计划如何到达那里。
在简报中，一方传达她期望的结果，提供应在其范围内寻求该结果的约束条件，并描述执行过程中可用的自由度。例如，Bungay讲述了一个指挥官的故事，他告诉他的两位将军将他们的师向北移动以包围法国人（结果），不要被与敌人的交战所拖延（约束），并通过任何对他们来说最合理的路线（自由度）。[13][*](#calibre_link-261)
通过提供期望的结果及其相关的自由度和约束条件，提供结果的人正在承担责任。他们提供的是只有他们才能提供的信息，例如优先级和他们重视的权衡取舍。这与X理论方法非常不同，后者从高层下达计划，组织想要实现的目标充其量与应该如何做事混杂在一起；而且几乎没有偏离规定路径的自由。
除了浪费人力资源外，这种自上而下的规划方法往往陷入认知差距，因为做规划的管理者缺乏那些更接近工作实际执行地点的人的知识和经验。普鲁士指挥官怎么可能在数英里之外，在没有现代战场信息来源（如无人机和无线电）的情况下，知道他的下属应该选择的正确路线？更好的做法是为他们提供清晰的意图，让他们根据只有他们才拥有的本地数据做出正确的选择。
波音公司在777客机设计阶段提供了一个清晰简报的好例子。[14]设计师们在降低飞机总重量的同时，还要将成本控制在计划预算内。他们如何在整个飞机的设计中获得减重和节约成本之间的最佳权衡？例如，他们是否应该使用更昂贵的方向舵来减轻重量，同时改用更高效但更重的起落架？数百名工程师在大量子系统上分组工作，很难看出在飞机相隔很远、不相关的部件上，甚至在哪里可以进行这样的成本和重量交换。
波音公司找到的解决方案是以简单的成本指南形式向工程师提供简报，说明他们可以和应该在本地子系统上做出什么样的权衡。工程师可以在不需要批准的情况下花费最多300美元来减轻一磅重量；每磅花费最多600美元只需要当地主管的同意；甚至可以花费更多，最多2500美元来减轻一磅，只要项目经理批准即可。这些指南明确了工程师需要在其范围内工作的约束条件，提供了一个框架，让他们能够做出决策，同时确保这些决策与最小化成本和重量的总体目标保持一致。
如果我们仅用一个清晰的简报就停止定向机会主义协议，我们已经有了很大的改进，至少有一方提供了问责。然而，即使有详细的简报，也很容易出现大大小小的误解。为了说明和检测这些不完善之处，我们还安排了对简报的回应：由执行方主导的”回报”，旨在描述其计划如何实现期望的结果，并确认该计划与原始结果、约束条件和自由度相匹配。这种对人们计划做什么以及为什么计划这样做的说明——这种推理和意图的分享——确保了各方之间的一致性。
在《行动的艺术》(The Art of Action)一书中,邦盖向我们展示了普鲁士总参谋长冯·毛奇(von Moltke)写的一封信——他就是前面提到的那位指挥官,想要让他的两支军队追击并包围法军。他的信描述了当时的形势、他的意图、每位将军的职责,以及法军越境进入比利时时的特殊指示。信的结尾要求各位将军在截止日期前向他汇报他们将向各自军队下达的指令。将军们的回复就是复述确认(back briefing),这让冯·毛奇能够协调自己军队与下属部队的行动,并纠正任何误解。
在我们的一个客户——一家儿童零售商那里,我们建立了一套复述确认系统,由首席运营官(COO)与各团队领导审查产品计划。在其中一次会议之前,我们能看到产品经理是多么兴奋地想要分享改版后的电子商务网站的计划,家长们将能够从大幅扩展的产品范围中购买商品。然而,在会议期间,随着产品经理展示新页面的截图和早期原型,首席运营官的表情越来越不满意。最终他说:“但我们在哪里解释这些好处呢?”原来团队在专注于支持新产品类型和令人兴奋的新购买方式时,忘记了网站必须将产品宣传为有趣且富有教育意义,而这正是营销团队所依赖的。修订计划虽然痛苦,但在编写大量代码之前就发现问题要好得多。显然,简报(briefing)和复述确认(back briefing)的结合是建立相互问责的有力方法。
如果一次对话涉及提出请求,你可以将其评为简报。将你的分数显示为三分之几的分数,三个要素各得一分:预期结果、寻求该结果应遵循的约束条件,以及执行过程中可用的自由度。如果你提供了部分约束或部分自由度但不是全部,给自己部分分数,例如如果你描述了一半的约束条件就得0.5分。例如,如果你分享了预期结果和所有约束条件,但没有描述任何自由度,你的分数将是2/3。
同样,如果你在回应请求,可以将对话评为复述确认。与简报一样,将分数显示为三分之几的分数,包含三个要素各得一分:你的预期行动、采取该行动的理由,以及确认你的计划与对方提供的简报相符。
假设你计划和家人开车去度假目的地。你如何决定谁需要什么信息以及何时分享?在公路旅行中协作与使用问责对话(Accountability Conversation)与团队互动非常相似。
旅程的开始很简单,但在出发前,我们需要对规划所需的信息有共同的理解——简报。这包括预期结果(“我们要经过萨克拉门托去湖边小屋,在那里接你妹妹”)以及约束条件(“避开5号高速公路;交通太拥堵”)和可用的自由度(“我们可以在你最喜欢的餐厅停留”)。一旦这些明确了,我们应该返回相当于复述确认的内容:预定路线、提出该路线的理由,以及请求确认预定路线是否令人满意。但旅程开始后会发生什么?
一辆汽车即使沿着最笔直的道路行驶,也需要许多难以察觉的微调来与白线保持对齐,而像车辆突然停车或孩子跑到路上这样的意外需要立即调整。乘客不期望司机告知这些持续的路线修正,同样也不期望司机在应对紧急情况时请求许可。然而,如果司机突然刹车,让其他乘客感到震动,乘客确实期待一个解释!如果有改变路线或约束条件的新信息(“湖边在下雨;我们去山里吧”),无论是司机还是后座的孩子有新信息,他们也期待某种沟通。参与项目的每个人都有义务为问责对话的各自部分做出贡献。
那么与不在车里的人沟通呢?
技术专家伊丽莎白·艾耶(Elizabeth Ayer)建议,就像司机在转弯前和转弯期间显示持续的方向信号一样,你应该始终”辐射意图”(radiating intent)。我们认为这是很好的建议,可以产生意想不到的好处:当我们对自己的意图保持透明时,我们允许其他人提供相关信息、调整他们的计划,甚至帮助我们实现目标。无差别地辐射意图使我们能够在可能没有预料到的时候获得这些好处;即使你(错误地!)认为没有人看到,为转弯发信号也可能对你最有帮助。
在决定你想要辐射什么信息时,请记住这些关键要素:
• 分享当前状态:我们正在尝试为我们的移动应用选择一个崩溃报告工具,成本要在我们的预算范围内。我们已经与两家公司交谈过,他们的产品都不符合我们的标准。
• 描述计划和预期结果：“我们下周将再拜访三家供应商，同时也在探索内部解决方案。月底前我们应该能找到一个可行的方案。”
• 提醒障碍：“预算重新预测可能意味着我们不得不完全放弃这个项目。周四之前我们就会知道结果。”
通过适当的Y理论(Theory Y)思维方式，并运用你在前几章练习的相互学习工具，你会发现问责对话(Accountability Conversation)对于保持项目按计划进行是有价值且富有信息量的。但要警惕——问责对话不是一次性的事情。
“他信任，但他不验证，”我们一位客户的工程主管这样描述他们的CEO。(熟悉的短语”信任但要验证”是罗纳德·里根关于与苏联谈判核条约的著名格言，源自一句俄罗斯谚语。) “他给了我们团队愿景和焦点，”她继续说道，“但没有定期互动，我们无法保持一致。我们追求的使命版本存在缺陷；当他从总部飞过来看我们时，他说我们必须放弃三个月的工作，从头开始。”
我们发现，问责对话最困难的事情之一不是进行讨论本身，而是记得持续进行讨论。就像我们客户的CEO一样，你可能认为一旦就项目方向达成一致就完成了——特别是如果你使用了简报(briefing)和回馈简报(back briefing)来反复检查对预期结果、自由度和约束条件的理解。毕竟，对方不会觉得我们在侵扰吗?Y理论不是说我们应该信任他人的良好意图，让他们自己完成任务吗?
这些都是合理的异议，因为应该尽可能避免微观管理(我们不希望有人在后座告诉我们如何掌舵);但问责对话的双方都不应该脱离接触，以免发生灾难性的不一致。简报者需要了解执行进展如何，因为他们有义务检查一致性，也有责任协调自己的行动。此外，被简报方也需要关于其进展的反馈以及外部情况如何变化的更新，特别是当这影响到要完成的工作时。检查的频率会因项目的重要性及其风险水平而异，但在问责对话方面，我们不建议采用”设定后就忘记”的理念。
幸运的是，现代软件开发方法提供了完美的仪式和流程来触发最初的问责对话，并提供定期的机会来辐射意图和进展。
计划。Scrum、XP和类似方法为我们提供了讨论问责的自然时机：冲刺计划会议(sprint planning session)。精益(Lean)或看板(Kanban)团队有更频繁的、拉动触发的计划活动，但仍然需要分解任务并就验收标准达成一致，通常在每日站会期间或之后进行。在团队的计划活动中，确保留出时间讨论问责对话的所有三个要素：当前状态、预期结果和潜在障碍。超越通常的路线图规划和估算活动，包含更多上下文，通常会激发团队其他成员的想法和帮助。在电子邮件或公司聊天中发布计划会议的结果，也能鼓励更广泛的讨论，并为那些不直接参与你工作的人提供更多问责的机会。
信息辐射器。一个常见的DevOps实践是在团队区域的大屏幕上显示系统指标——网站访客、内存使用、响应时间。敏捷和精益团队通常有燃尽图(burndown charts)和看板(kanban boards)，以电子方式显示，或在白板或画架上维护。我们的一个客户维护着一个看板，显示所有潜在客户及其在商业管道中的当前阶段，以便让技术团队了解可能到来的销售请求。在所有这些情况下，可见的指示器都是基于显示信息进行问责对话的完美提示。团队内部的人可以邀请其他人参观他们的辐射器进行讨论，或者团队外部的人可以路过并根据显示的内容开始对话。
回顾会。冲刺结束或项目结束时对最近进展的反思是好奇正在进行的项目进展情况的自然时机，特别是在寻找可以消除的障碍时。避免将回顾会变成状态报告，这不是它的目的；相反，通过确保团队集体推动对话，反思其当前状况、计划以及可以做些什么来增加成功的机会，来记住Y理论。
演示。我们最喜欢的辐射意图的方式之一是演示可工作的软件。这可以在冲刺结束时、向客户交付时，或者更好的是，在功能刚完成时进行。尽量避免”演示”用户不可见的变更，如数据库更新；相反，专注于结构化工作，使当前和未来状态对非技术观察者来说是显而易见的(第6章中的行走骨架(Walking Skeleton)可以提供很大帮助)。如果可能，录制演示视频并广泛发布，向那些远程或无法参加演示的人辐射信息。
一次成功的问责对话(Accountability Conversation)对所有参与者来说都应该是积极的，即使报告了令人惊讶的结果或重大障碍。在这样的对话结束时，你将分享项目的当前状态，明确并讨论下一步行动，并识别出障碍。这些都应该为各方提供机会来澄清和修订要完成工作的预期结果、自由度和约束条件。根据我们的经验，成功做到这一点的团队能够构建正确的软件，并对他们的目标感到满意，即使这与他们最初的想象不同。
好的，让我们尝试对这次对话进行评分，尽管当时听起来还不错；也许我会反思并找到一些需要修订的地方。我注意到我根本没有提任何问题，所以这里是零比零。在我的左栏思维中，我对Bobby的理解有一些疑虑，但我没有分享这些疑虑，希望他能弄清楚我的意思。我注意到的一个习惯是，我倾向于默认接受一个自信的”明白了”，而实际上，提出更多问题可能更明智。
对简报进行评分，我认为我没有完整包含任何一个要素。非常慷慨地说，也许我对与当前报告差异的解释传达了一半的期望结果。但我肯定没有提到自由度（例如，开发人员可以按任何方便的方式排列列）或约束条件（报告必须是原生Excel格式，而不是制表符或列分隔的）。所以充其量，这里是3分中的0.5分。
我想通过提出更多问题来改进，而不是急于得出一切都好的结论。我认为在简报和反向简报(back briefing)中采用更结构化的方法会有所帮助，因为这会促使我更好奇我在说什么和听到什么。最后，我将尝试分享更多我的反应，而不是一直试图看起来自信。我希望这能帮助我更有效地与Bobby和其他人合作，避免不愉快的意外。
上周我与Bobby核实了他所在开发团队的进展。我想根据从之前对话中学到的东西，更好地处理这次反向简报。我请一位值得信赖的朋友提前进行了角色扮演(Role Play)，这帮助我在进入对话时更加好奇。
| Nicole的想法和感受 | Nicole和Bobby说的话 |
|---|---|
| 我想知道他在优先考虑什么。 | Nicole：你有很多不同的项目在进行中。你计划本周重点关注什么？ |
| 他取得的进展比我意识到的要多得多。嗯，等等——这是我的习惯在起作用。我应该进一步核实这一点。 | Bobby：我认为我们已经准备好完成简化配置的工作了。我想我可以在周五之前完成。 |
| 我们还没有讨论他将如何呈现这次调查的发现。 | Nicole：太好了！那么你打算如何呈现结果？ |
| 什么？！听起来他已经开始实施了，而我甚至还没有看到提案。 | Bobby：上周我审查了所有当前的配置选项，团队已经删除了大部分选项。我预计我将能够演示只有五六个选项的新页面。 |
| 也许他发布了他的分析而我错过了？ | Nicole：等一下——我有点困惑。我期待你检查并解释每个选项的必要性，我不记得从你那里看到过审查文档。你已经完成了分析并转向实施了吗？ |
| 哦天哪！我以为我说得很清楚了。 | Bobby：什么？我以为你想让我去掉尽可能多的选项。我们周一决定简化配置时就这么说的。 |
| 我不想做出武断的决定。 | Nicole：不，不完全是。我想要的是得到你对每个选项的意见。客户实际需要和使用哪些选项？ |
| 这听起来更像我期待听到的。 | Bobby：哦！好的，那这改变了我本周的计划。我们可以暂停对页面的更改，我可以专注于与更多客户交谈。不过，我们这周不会准备好新页面了。 |
| 我很高兴我们进行了这次对话——我们躲过了一劫。如果我们没有核实，我们可能会过早地发布新页面。 | Nicole：没问题。对我们决定保留、删除或更改选项有更大的信心将是很好的，无论我们决定做什么。 |
Grace 说：“通过与客户交谈，我们知道最终用户参与度对他们很重要。我们想出了一个很好的解决方案，即在每周开始时向不活跃用户发送提醒邮件。我们几乎准备好推出每周提醒了,所以我们安排了与重点客户的简报电话,让他们知道即将发生的变化。大多数客户对我们的提议非常满意,但有一位客户 Lisa 的反应却大不相同。”
| Grace 的想法和感受 | Grace 和 Lisa 说的话 |
|---|---|
| 我知道 Lisa 一直很关注参与度问题。我预计她会对此感到高兴,所以我只需要解释我们正在做什么以及为什么这样做。 | Grace:嗨 Lisa,感谢你抽时间了解我们计划实施的一项变更。我们将在每周一向上周未登录的用户发送电子邮件。我们这样做是为了回应那些担心最终用户参与度不够的客户。 |
| 什么?!你已经向我抱怨过参与度问题很多次了。我以为你会感激的。 | Lisa:哦,请不要这样做! |
| 奇怪,没有其他客户反对这些邮件。我很确定参与度对你来说仍然是个问题,但我应该确认一下。 | Grace:哦,这很令人意外!我已经与其他几位客户交谈过,你是第一个有这种反应的人。查看最新的使用报告,我可以看到你 40% 的用户处于不活跃状态。你认为这是个问题吗? |
| 哇,听起来很糟糕。难怪她不希望我们直接给用户发邮件。而且我很高兴她有一个可能适合他们的替代方案。 | Lisa:参与度确实是我们想要改进的。只是我们已经收到太多来自内部系统的电子邮件,根本无法应付;我最不想要的就是收到更多邮件的投诉。你能不能每周给我发一份不活跃用户的报告?这样我们可以在内部跟进。 |
| 这可能是一个很好的实验。如果成功的话,我们可以向其他客户提供这个选项。 | Grace:当然可以。我会告诉我们的团队,你更希望收到不活跃用户的信息,而不是直接给用户发邮件。在下次季度审查中,我们可以讨论这些报告的效果,以及我们在系统中还能做些什么来提供帮助。 |
| 我也是! | Lisa:太好了。我真的很高兴你提前联系我,而不是让大量邮件涌向我们的用户! |
我们很容易相信自己理解问题和解决方案,而实际上我们缺少关键信息。Grace 有一个已被其他几位客户认可的解决方案,用于解决她知道 Lisa 关心的问题;她不可能知道在 Lisa 的组织中,电子邮件是一种不可接受的方式。负责任意味着即使我们认为自己是对的,也要向会受到影响的其他人表明我们的意图。这些机会最自然地出现在我们日常合作的团队内部。跨部门甚至跨公司寻找这样的机会也很有价值。
Andy说：“在我担任工程主管的金融服务公司，当我们进行事故复盘调查时,我们不仅试图了解发生了什么,还要了解当时涉及的人员眼中的世界是什么样的。我们的目标是重建一个画面,在这个画面中,所采取的行动是正确的;因为无论我们事后了解到什么,我们相信这些行动在当时一定看起来是正确的。无论我们做什么来使我们的系统具有韧性(resilience),都是人们在关键时刻的判断和行动帮助我们应对意外情况。就像我们最近丢失了一个生产系统的数据,我让我们的系统管理员之一Wayne解释他在恢复服务时采取的行动。”
| Andy的想法和感受 | Andy和Wayne的对话 |
|---|---|
| 我们有一个恢复数据的正常流程。他们为什么不直接使用那个流程? | Andy: 好的,那个表被删除了,服务也离线了。为什么你们没有使用正常的、有文档记录的备份程序? |
| 这是个好观点。我确信我们从未预料到这种部分故障。 | Wayne: 嗯,那个流程假设整个数据库已经丢失或损坏。在我们的情况下只是一个表,因此大多数服务仍在正常运行。如果我们执行了正常的灾难恢复流程,它会起作用;但这也意味着所有服务都将离线一天或更长时间。 |
| 意识到我们练习过的流程都不适用,一定压力很大。 | Andy: 我明白了,所以你们当时处于未知领域。 |
| 我同意——那会让问题变得更糟。 | Wayne: 没错!当然我们可以照章办事,但那会让事情变得更糟。即使那是有文档记录的流程,它似乎也不是正确的做法。 |
| Andy: 那你们是如何确定如何继续的? | |
| 我不确定我会采取他们的方法,但他们的优先级是正确的。 | Wayne: 我们的首要目标是保持所有其他服务正常运行,我们的第二个目标是恢复丢失的表并恢复依赖它的服务。我们想出了多个恢复数据的选项,由于不知道哪个最快,我们同时启动了其中几条路径,不同的人负责每一条。 |
| 我很高兴Wayne在这里有创造性思维。照章办事会意味着数小时的停机时间和更大的麻烦。 | Andy: 那是敏锐的思维!我们应该考虑在运行手册中添加”尝试多种解决方案”。 |
事情不可避免地不会总是按计划进行,那么当这种情况发生时,人们会如何应对?在Andy的组织中,传递的信息是:你应该在关键时刻运用你的专业判断;同时,你也需要在事后解释你的推理。目标不是因为意外而惩罚人们;而是从经验中尽可能多地学习。这使人们能够自由发挥并创造比照章办事的思维方式更好的结果。
“我拿到了!”Mike拿着一个巨大的活页夹冲进办公室门大喊。“我拿到了!我们又回来了!”
Marcus是伦敦初创公司Arachnys的产品经理,他怀疑地抬起头来。Mike去见了一个主要的银行潜在客户,想了解为什么他们在几周前拒绝了公司的反洗钱产品。Marcus原本期望Mike带回一份竞争对手获胜的原因清单,作为产品开发的素材,帮助他们在下次与其他人的竞标中获胜。Mike究竟搞出了什么?
Mike兴奋地摊开活页夹的内容。“这些是银行给其他人的规格说明。显然,在他们拿到交易后,另一家公司看了一眼这些,就说他们不会承诺在少于九个月的时间内完成系统的第一个版本,满足所有这些要求。那太慢了;所以当我问我们能否看一看时,他们说,’当然!’然后就把这个交给了我。”
Marcus和他的同事、同为产品经理的Annegret浏览了前几页。
“天哪，他们有遗漏什么吗？”Annegret带着明显的讽刺口吻问道。“四种身份验证类型，与十七个系统的集成端点，还有测试数据和协议占了——让我数数——六十三页。需求列表中有超过一千个条目。”
“Mike，你打算让我们拿这个庞然大物怎么办？”Marcus问道。
“嗯，正式来说，我只是说我们会给他们一个评估，”Mike回答。“但是做决策的大人物Benny送我出门时——在门口，我私下告诉他我们很快就能给他们一个原型。”
Marcus和Annegret互相看了看，然后同时露出震惊的表情问道：“多快？”
Mike笑了笑。“嗯，六周？”他有点不好意思地说。
Marcus和Annegret立刻就看出来，这份文件夹里的工作量至少够他们小型开发团队做一年。六周显然是不可能的。但因为Arachnys是那种质疑简报或任务安排理所当然的地方，他们没有放弃，而是开始仔细翻阅这些页面。
他们发现许多”需求”是相互矛盾的，这是不同部门在不顾彼此的情况下将各自的愿望清单加入文档的结果。其他一些则与系统应该解决的监管要求无关；还有一些简直不可能实现。删除这些无意义的项目大大减少了需求量，但仍然留下数百个需要处理的详细项目。
他们又过了一遍列表，但这次不是删除功能，而是旨在挑选出那些绝对必要的功能，以证明银行能够满足监管标准。就像[第6章]的行走骨架一样，这些关键功能将构成系统的骨干，使他们能够证明解决方案是可行的，同时为持续添加更多功能提供框架。他们圈出了每个符合严格测试标准的项目，然后数了数。
“六个！”Annegret说。
“我不敢相信，”Marcus说。“真的就这些吗？”
“我们已经看过每一页了，”Annegret回答。“没有别的了。”
“但他们会买账吗？”
“只有一个办法可以知道！”
几天后，周围摆满了中餐外卖盒，证明两位产品经理通宵达旦地工作，Annegret点击了”发送”，将他们精心制作的电子邮件发给了银行。他们分析了每项需求，并详细解释了为什么将列表缩减到仅六个项目。这封邮件是他们的反馈简报(back briefing)，通过分享他们的推理来回应银行的需求，并描述他们将如何为交付他们定义的小得多的范围负责，在达到六周目标的过程中进行多次交付。
Mike在邮件到达他收件箱后立即打来电话，从一个行业会议上联系他们。“这太棒了！我确信他们会想让我们构建你们提议的东西。”
“我不太确定，”Marcus用疲惫的声音回答。“我们几乎删掉了他们要求的所有东西。另一家公司对所有事情都说是。为什么不继续用他们呢？”
就在那一刻，Annegret的屏幕上出现了一条新消息。是Benny，那位”大人物”发来的。
“开始吧，”邮件说。“六周后见。”
Marcus和Annegret与开发人员密切合作交付原型，按照承诺经常与客户沟通。Benny和他的团队对结果以及计划所代表的明确问责制(accountability)非常满意，于是签约购买完整产品，并向数百名内部用户推出。
之后，Marcus有机会问Benny：“你为什么决定选择我们？”
Benny的回答很明确。“因为你们说了不。你们思考了能交付什么和不能交付什么，并与我们分享了你们的推理。然后你们交付了承诺的东西。这让我确信可以信任你们完成项目的其余部分。”
问责对话(Accountability Conversation)为Arachnys和他们的客户都带来了成功。
在本章中，你学会了通过采用Y理论来培养问责性，通过使用简报(briefing)和反馈简报(back briefing)来识别和使用计划行动的约束和自由度，以及通过广泛而清晰地表明你的意图来交代说明。对成功和失败都负责，可以让你从经验中有效学习，并促进推动你对话转型的建设性推理。你可以通过多种方式使用问责对话，包括以下方式：
执行领导者可以向组织中的人员说明她的战略行动，帮助他们与产品和公司目标保持一致。
团队负责人可以向团队成员简报测试新功能或执行渗透测试等行动，并通过反馈简报对准确执行充满信心。
个人贡献者可以通过看到同事和管理者认为他有动力且有能力，从而发现内在承诺和驱动力，比如信任他尝试新库或尝试创意性的重新设计。
* 与军队不同，在商业场景中，各方的关系可能不是领导与追随者；例如，产品经理可以向营销团队简要介绍如何协调即将到来的功能发布。
** 这些陈述对自动驾驶汽车和人工驾驶汽车同样适用；无论驾驶员是碳基还是硅基，都需要有人负责转向和进行即时调整。
*** 你可以在这里查看一个示例：https://www.leadingagile.com/2017/11/information-radiators-information-vaults/。
恭喜你！如果你已经读完了这本书（而不是只翻到结论部分），并尝试进行了部分或全部的五个对话，那么你已经克服了对困难对话的恐惧，承担了艰难的情感工作，并走上了培养高绩效团队五大关键属性的道路：高信任(Trust)、低恐惧(Fear)、清晰的目的(Why)、明确的承诺(Commitment)和扎实的问责(Accountability)。你已经掌握了一系列有助于成功对话的技能和技巧，包括面向人的测试驱动开发(Test-Driven Development for People)、一致性破解(Coherence Busting)、联合设计(Joint Design)、行走骨架(Walking Skeleton)和定向机会主义(Directed Opportunism)。这些都是了不起的成就！
但我们有一个具有挑战性的消息要告诉你。虽然你已经走了很远，但前面还有数年的实践等着你。这是因为五个对话永远不会结束。在你使用面向人的测试驱动开发建立信任之后，随着环境的变化和你对他人看法的改变，你需要不断调整你们的故事。在你通过联合设计定义了清晰的目的之后，市场或你的公司会发生变化，你将不得不重建另一个目的。在你们共同工作的整个过程中，你和你的团队将希望相互讨论问责，在履行彼此的承诺时一次又一次地提供有意义的说明。
正如我们在本书中所论述的，对话转型是摆脱困扰众多敏捷(Agile)、精益(Lean)和DevOps团队的功能工厂的出路。既然你知道了这一点，我们相信你将在你工作的团队和组织中推动许多对话转型。这意味着你将有机会在一生中不断改进你的对话技巧。与演奏乐器或练习运动等其他任何技能一样，持续练习使我们能够以更优雅和更有风格的方式表现。它还向我们展示进一步改进始终是可能的，从而对我们提出挑战。即使在研究这些方法超过十年之后，我们两人都在继续犯新的错误并发现新的错误，这也让我们能够学习新技能并发明新技巧。早上，我们可能会进行一次美妙的、建立关系的对话，但那天下午，我们可能会磕磕绊绊地进行一场激烈的讨论，让每个人都感到沮丧。我们体验到了继续练习对话分析(conversational analysis)等方法的真正价值，以及愿意与我们一起练习和角色扮演的耐心朋友的更大价值。失败的对话可能是痛苦的，但它们给了我们发展最重要技能的最大机会。
在改进你的对话方面，你拥有的最有用的资源是其他同样希望改进相同技能的人的帮助。因此，我们给你的最后建议是，找到你的组织或社区中的其他人，他们可以定期与你合作，共同提高对本书技巧的掌握——那些将与你一起遵循阿吉里斯(Argyris)策略的人，使用对话来调查和改进你组织绩效的人。
人类的天性和我们认知偏见的结果是一个怪癖，即其他人的错误比我们自己的错误更容易发现。你的学习伙伴会发现你讨论中遗漏的替代方案，你也会为他们做同样的事。学习小组还提供了一个很好的刻意练习(deliberate practice)空间，你可以在房间里尝试应用这些技巧，并立即从其他人那里获得关于他们感受的反馈。
我们对建立学习小组的建议是从简单开始，专注于建立定期练习的习惯。首先请每个人朗读一个对话分析，并与小组讨论每个人的对话。提前创建和评分你的对话将帮助你更充分地利用时间。然而，不做准备地见面——在会议上进行对话分析——也比跳过会议要好；即使是最少量的工作也会得到回报。我们在2到20人的小组中举行过成功的练习会议，与同事、朋友和陌生人一起，讨论了与老板、同事、邻居、配偶、父母、室友等人的对话。如果你在寻找机会，每次对话都提供了改进的机会。
随着你对学习小组越来越熟悉，你可能想要学习文章或视频，或进行其他刻意练习(deliberate practice)来帮助你进一步提升。我们知道有一个小组正在逐条研究敏捷宣言(Agile Manifesto)的原则；另一个小组每月聚会练习新技术，如非暴力沟通和关系日志。本书末尾的”延伸阅读与资源”部分（第189页）将为你提供许多想法和额外学习资源，包括在本书的配套网站和播客上与我们保持联系的方式。
在一次漫长的午餐会上，我们讨论了本书中的对话技巧后，我们的一位客户说：“我感觉就像刚听了一场关于风筝冲浪的讲座，但我没有下水。”你可以学习所有你想要的理论知识，但如果不下水并从冲浪板上摔几次，这些知识对你毫无用处。
我们邀请你投入实践，定期练习我们与你分享的对话技巧。回报是巨大的。
继续交流，
Jeffrey 和 Squirrel
一旦你以双栏格式记录了对话，请按照以下步骤反思(Reflect)你的好奇心、透明度、对话模式以及我们在书中描述的关键技能的使用。
圈出右栏中的所有问号。
计算真诚提问的数量。
写出一个分数：<真诚提问数>/<总提问数>。
为了实现最大的好奇心，你希望看到大量提问（较大的分母），其中大部分是真诚的（较大的分子）。
在左栏中标出未出现在右栏中的想法和感受。
如果你表达了大部分思考和情绪（即左栏中标出的句子很少），说明你非常透明。
圈出并标注导致你强烈反应的触发点、表示缺乏透明度或好奇心的信号，以及代表默认反应的抽搐。
你可能无法避免在这里识别出的自动反应，但你可以学会在它们发生时检测到它们。如果你能实时注意到你的模式，无论是在左栏还是在对话中，说明你做得很好。
面向人的测试驱动开发(TDD for People)：用推理阶梯(Ladder of Inference)的层级标注任一栏中的陈述和问题。如果你在辩论阶梯顶部的项目之前，先建立了对阶梯底部的共同理解，说明你做得很好。
连贯性破解(Coherence Busting)：计算左栏中无根据结论的数量。目标是低分数——理想情况下，没有！
联合设计(Joint Design)：对你观察到的联合设计的五个要素分别加分：包容性、提出真诚问题、邀请反对意见、时间盒(timeboxing)和使用决策规则。目标是五项全满。
达成含义共识(Agreeing on Meaning)：圈出两栏中的重要词汇，然后计算已确认、共享含义的数量。创建一个分数：<已确认含义的词汇数>/<重要词汇总数>。理想情况下，这个分数等于1（分子等于分母）。
简报与回报(Briefing and Back Briefing)：根据情况给自己打分（满分三分）：对于简报，看是否包含结果、约束和自由度；对于回报，关注行动、推理和确认。你的目标应该是3/3分。
关于沟通有许多丰富的文献；我们在下面分享一些我们最喜欢的资源。
以下文章描述了分析对话的工具，其中只有部分被收录在本书中。
• Roger Schwarz 的《更聪明团队的八种行为》(https://www.csu.edu.au/__data/assets/pdf_file/0008/917018/Eight-Behaviors-for-Smarter-Teams-2.pdf)
• Diana McLain Smith 的”将’关系’放回人际关系” (https://thesystemsthinker.com/putting-the-relational-back-in-human-relationships/)
• Roger Martin 在《斯坦福社会创新评论》上发表的”拯救行动” (https://ssir.org/articles/entry/to_the_rescue)
• Chris Argyris 在《哈佛商业评论》上发表的”熟练的无能” (https://hbr.org/1986/09/skilled-incompetence)
Bruce Patton、Douglas Stone 和 Sheila Heen 的《关键对话》(Difficult Conversations)是对我们在《敏捷对话》(Agile Conversations)中描述的技术的温和介绍。
Roger Schwarz 的《熟练的引导者》(The Skilled Facilitator)和 Bill Noonan 的《讨论不可讨论之事》(Discussing the Undiscussable)是更高级的对话分析指南，涵盖许多应用并包含真实案例。
Diana McLain Smith的《房间里的大象》和Roger Martin的《责任病毒》涵盖了对话技巧在复杂商业关系中的具体应用，比如那些背负着长期不良互动历史或角色与职责混淆的关系。
Chris Argyris、Robert Putnam和Diana McLain Smith合著的《行动科学》是关于行动科学方法的开创性著作，为本书和本列表中的其他几个资源提供了基础。它比这里引用的其他著作更学术化和理论化，还有一个额外的优点是可以在网上免费获取。
Xavier Amador博士的《我对你错，现在怎么办？：打破僵局并获得你需要的》向大众描述了他在为处于否认状态的人提供治疗时开发的模型：LEAP（倾听-共情-同意-合作）。这种方法是对话式的，我们相信它与我们在本书中描述的方法既相似又适用。
Marshall B. Rosenberg博士的《非暴力沟通：生活的语言》不仅是一种沟通方法，更是一种生活哲学。然而，即使是对这种哲学持怀疑态度的人，也能找到一些非常有用的练习来反思他们的沟通和心态。
在每周的《敏捷故障排除》播客（https://troubleshootingagile.com）上，我们讨论敏捷、精益和DevOps团队中的相关时事话题，为改善软件团队的交付和沟通提供想法和解决方案。
David Burns博士每周的《感觉良好》播客（https://feelinggood.com/list-of-feeling-good-podcasts/）定期提供改变对话如何改变关系的优秀现实案例。特别相关的是涵盖”沟通五大秘诀”和”人际关系模型”的剧集。
本书的配套网站ConversationalTransformation.com提供后续资料、视频、邮件列表订阅等更多内容。
伦敦组织学习聚会（https://www.meetup.com/London-Action-Science-Meetup）每月在伦敦举行。它由Jeffrey Fredrick运营，是与其他对改变文化感兴趣的人一起练习和改进对话的绝佳机会。
Adžić, Gojko. 《实例化需求：成功团队如何交付正确的软件》. Shelter Island, New York: Manning, 2011.
Allspaw, John, and Paul Hammond. “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” SlideShare.net. Posted by John Allspaw, June 23, 2009. https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr.
Anderson, David J. 《看板：技术业务的成功演进式变革》. Sequim, WA: Blue Hole Press, 2010.
Appleton, Brad. “The First Thing to Build Is TRUST!” Brad Appleton’s ACME Blog. February 3, 2005. http://bradapp.blogspot.com/2005/02/first-thing-to-build-is-trust.html.
Argyris, Chris. 《组织陷阱：领导力、文化、组织设计》. Oxford: Oxford University Press, 2010.
Argyris, Chris. “Skilled Incompetence.” 《哈佛商业评论》(September, 1986): hbr.org/1986/09/skilled-incompetence.
Argyris, Chris, Robert Putnam, and Diana McLain Smith. 《行动科学：研究和干预的概念、方法和技能》. San Francisco, CA: Jossey-Bass, 1985.
Argyris, Chris, and Donald Schön. 《实践中的理论：提升专业效能》. San Francisco, CA: Jossey-Bass, 1974.
Ayer, Elizabeth. “Don’t Ask Forgiveness, Radiate Intent.” Medium.com. June 27, 2019. https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-intent-d36fd22393a3.
Beck, Kent. 《极限编程解析：拥抱变化》. Reading, MA: Addison-Wesley, 2000.
Beck, Kent. 《测试驱动开发：实例教程》. Boston, MA: Addison-Wesley, 2003.
Beck, Kent, et al. “Manifesto for Agile Software Development.” AgileManifesto.org. 2001. https://agilemanifesto.org.
Beck, Kent, et al. “Principles Behind the Agile Manifesto.” AgileManifesto.org. 2001. https://agilemanifesto.org/principles.html.
Brown, Brené. 《重新崛起：重置能力如何改变我们的生活、爱、养育和领导方式》. New York: Spiegel & Grau, 2015.
Bungay, Stephen. 《行动的艺术：领导者如何缩小计划、行动和结果之间的差距》. New York: Hachette, 2011.
Burns, David. 《一起感觉良好：让困难关系奏效的秘密》. New York: Random House, 2010.
Center for Nonviolent Communication. “Feelings Inventory.” Accessed September 23, 2019. https://www.cnvc.org/training/resource/feelings-inventory.
Cockburn, Alistair. 《敏捷软件开发：协作游戏》, 2nd ed. Boston, MA: Addison-Wesley, 2007.
Cockburn, Alistair. “Characterizing People as Non-Linear, First-Order Components in Software Development.” Humans and Technology. HaT Technical Report 1999.03, October 21, 1999. http://web.archive.org/web/2014032 9203655/http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development.
Cockburn, Alastair. “Heart of Agile.” HeartofAgile.com. 2016. https://heartofagile.com.
Coleman, Mark. “A Re-Imagining of the Term; ‘Full-Stack Developer.’” Amsterdam DevOpsDays 2015 proposal. Accessed Feruary 3, 2020. https://legacy.devopsdays.org/events/2015-amsterdam/proposals/mark-robert-coleman__a-re-imagining-of-the-term-full-stack-developer/.
Cutler, John. “12 Signs You’re Working in a Feature Factory,” Hacker Noon (blog). Medium.com. November 16, 2016. https://medium.com/hacker noon/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2.
Debois, Patrick. “Agile Operations—Xpdays France 2009.” SlideShare.net. November 27, 2009. https://www.slideshare.net/jedi4ever/agile-operations-xpdays-france-2009.
Dennett, Daniel. From Bacteria to Bach and Back: The Evolution of Minds. New York: W. W. Norton, 2017.
Derby, Esther, and Diana Larsen. Agile Retrospectives: Making Good Teams Great. Raleigh, NC: Pragmatic Bookshelf, 2006.
Duff, John D., and Louis E. Dietrich. Dehydrated flour mix and process of making the same. US Patent 2,016,320, filed June 13, 1933, and issued October 8, 1935, https://pdfpiw.uspto.gov/.piw?Docid=02016320.
Edmondson, Amy. Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy. Hoboken, NJ: Jossey-Bass, 2012.
Financial Times. “FT Tops One Million Paying Readers.” Financial Times. April 1, 2019. https://aboutus.ft.com/en-gb/announcements/ft-tops-one-million-one-million-paying-readers/.
Fisher, Roger, William Ury, and Bruce Patton. Getting to Yes: Negotiating Agreement without Giving In. New York: Houghton Mifflin, 1991.
Fitz, Timothy. “Continuous Deployment at IMVU: Doing the Impossible Fifty Times a Day.” Timothy Fitz (blog). February 10, 2009. http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/.
Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Portland, OR: IT Revolution, 2018.
Fowler, Martin. “Writing the Agile Manifesto.” MartinFowler.com (blog). July 9, 2006. https://martinfowler.com/articles/agileStory.html.
Goldratt, Eliyahu M. and Jeff Cox. The Goal. Aldershot, England: Gower Publishing, 1984.
Griffin, Dale, and Lee Ross. “Subjective Construal, Social Inference, and Human Misunderstanding.” Advances in Experimental Social Psychology 24 (1991): 319–459.
Harari, Yuval Noah. Homo Deus: A Brief History of Tomorrow. London: Harvill Secker, 2015.
Harari, Yuval Noah. Sapiens: A Brief History of Humankind. New York: Harper, 2014.
Highsmith, Jim. “History: The Agile Manifesto.” AgileManifesto.org. 2001. https://agilemanifesto.org/history.html.
Hihn, Jairus, et al. “ASCoT: The Official Release; A Web-Based Flight Software Estimation Tool.” Presentation. 2017 NASA Cost Symposium, NASA Headquarters, Washington, DC. https://www.nasa.gov/sites/default/files/atoms/files/19_costsymp-ascot-hihn_tagged.pdf.
Humble, Jez, Joanne Molesky, and Barry O’Reilly. Lean Enterprise: How High Performance Organizations Innovate at Scale. Boston, MA: O’Reilly, 2015.
Humphrey, Watts S. Characterizing the Software Process: A Maturity Framework. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1987. ftp://ftp.cert.org/pub/documents/87.reports/pdf/tr11.pdf.
Kahneman, Daniel. Thinking, Fast and Slow. New York: Farrar, Straus and Giroux, 2011.
King, Martin Luther, Jr. “I Have a Dream.” Speech. Washington, DC, August 28, 1963. American Rhetoric, mp3 recording. Last updated February 14, 2019. http://www.americanrhetoric.com/speeches/mlkihaveadream.htm.
Kurtz, Cynthia F. and David J. Snowden. “The New Dynamics of Strategy: Sense-Making in a Complex and Complicated World.” IBM Systems Journal 42, no. 3 (2003): 462–483.
Latané, Bibb, and John M. Darley. The Unresponsive Bystander: Why Doesn’t He Help? Upper Saddle River, NJ: Prentice-Hall, 1970.
Lencioni, Patrick. The Five Dysfunctions of a Team: A Leadership Fable. New York: Wiley & Sons, 2010.
Martirosyan, Arthur. “Getting to ‘Yes’ in Iraq.” Mercy Corps 博客。2009年7月1日。https://www.mercycorps.org/articles/iraq/getting-yes-iraq。
McGregor, Douglas. 《企业的人性面，注释版》。纽约：McGraw-Hill出版社，2006年。
Mezak, Steve. “The Origins of DevOps: What’s in a Name?” DevOps.com。2018年1月25日。https://devops.com/the-origins-of-devops-whats-in-a-name/。
Murphy, Gregory. 《概念大全》。波士顿：MIT出版社，2004年。
NASA. 《总统航天飞机挑战者号事故调查委员会向总统的报告》。华盛顿特区：NASA，1986年。
Nelson, Daniel 主编。《精神革命：泰勒之后的科学管理》。俄亥俄州哥伦布市：俄亥俄州立大学出版社，1992年。
Park, Michael Y. “A History of the Cake Mix, the Invention that Redefined Baking.” 《Bon Appétit》博客。2013年9月26日。https://www.bonappetit.com/entertaining-style/pop-culture/article/cake-mix-history。
Pflaeging, Niels. “Why We Cannot Learn a Damn Thing from Toyota, or Semco,” LinkedIn，2015年9月13日。https://www.linkedin.com/pulse/why-we-cannot-learn-damn-thing-from-semco-toyota-niels-pflaeging/。
Poole, Reginald. 《十二世纪的财政署》。牛津：牛津大学，1911年。https://socialsciences.mcmaster.ca/econ/ugcm/3ll3/poole/exchequer12c.pdf。
Poppendieck, Mary 和 Tom Poppendieck. 《精益软件开发：敏捷工具包》。波士顿：Addison Wesley出版社，2003年。
Reinertsen, Donald. “An Introduction to Second Generation Lean Product Development.” 演讲。Lean Kanban France 2015。https://www.slideshare.net/don600/reinertsen-lk-france-2015-11-415。
Ries, Eric. 《精益创业：当今企业家如何利用持续创新创造极其成功的企业》。伦敦：Penguin出版社，2011年。
Rogers, Bruce. “Innovation Leaders: Inc.Digital’s Michael Gale On Digital Transformation.” 《福布斯》。2018年1月16日。https://www.forbes.com/sites/brucerogers/2018/01/16/innovation-leaders-inc-digitals-michael-gale-on-digital-transformation/#45d9ee157693。
Rogers, Bruce. “Why 84% of Companies Fail at Digital Transformation.” 《福布斯》。2016年1月7日。https://www.forbes.com/sites/brucerogers/2016/01/07/why-84-of-companies-fail-at-digital-transformation/#5d0b0759397b。
Roos, Daniel、James Womack 和 Daniel Jones. 《改变世界的机器：精益生产的故事》。纽约：Harper Perennial出版社，1991年。
Rosenberg, Marshall. 《非暴力沟通：生命的语言》，第3版。加州恩西尼塔斯：Puddledancer Press出版社，2015年。
Schwarz, Roger. “Eight Behaviors for Smarter Teams.” Roger Schwarz & Associates 网站。2013年。https://www.csu.edu.au/__data/assets/pdf_file/0008/917018/Eight-Behaviors-for-Smarter-Teams-2.pdf。
Schwarz, Roger. 《智慧领导者，更智慧的团队：你和你的团队如何摆脱困境以获得成果》。加州旧金山：Jossey-Bass出版社，2013年。
Senge, Peter. 《第五项修炼：学习型组织的艺术与实践》。纽约：Currency Doubleday出版社，1990年。
Sheridan, Richard. 《Joy, Inc.：我们如何建立一个人们热爱的工作场所》。纽约：Penguin Group出版社，2013年。
Shipler, David. “Reagan and Gorbachev Sign Missile Treaty and Vow to Work for Greater Reductions.” 纽约时报。1987年12月9日。https://www.nytimes.com/1987/12/09/politics/reagan-and-gorbachev-sign-missile-treaty-and-vow-to-work-for.html。
Shipman, Anna. “After the Launch: The Difficult Teenage Years.” 演讲。Continuous Lifecycle 2019。https://www.slideshare.net/annashipman/after-the-launch-the-difficult-teenage-years。
Shipman, Anna. “How Do You Delegate to a Group of People?” 《Anna Shipman》（博客）。2019年6月21日。https://www.annashipman.co.uk/jfdi/delegating-to-a-team.html。
Silvers, Emma. “A New Guest at Your House Show: The Middleman.” KQED网站。2017年4月28日。https://www.kqed.org/arts/13114272/sofar-sounds-house-shows-airbnb-middleman。
Sinek, Simon. “How Great Leaders Inspire Action.” 2009年9月摄于怀俄明州纽卡斯尔。TED视频，17:49。https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action。
Sinek, Simon. 《从为什么开始：伟大领导者如何激励每个人采取行动》。伦敦：Penguin出版社，2011年。
The Standish Group. 《CHAOS报告：1994》。马萨诸塞州波士顿：The Standish Group，1995年。https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf。
Travaglia, Simon. “Data Centre: BOFH.” The Register. 2000–19, https://www.theregister.co.uk/data_centre/bofh/.
Travaglia, Simon “The Revised, King James Prehistory of BOFH. Revision: 6f.” The Bastard Operator from Hell (blog). 访问于2019年10月23日。http://bofharchive.com/BOFH-Prehistory.html.
Vaughan, Diane. The ChallengerLaunch Decision: Risky Technology, Culture, and Deviance at NASA. Chicago, IL: University of Chicago Press, 1996.
Weinberg, Gerard M. The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully. Gerard M. Weinberg, 2011.
West, Dave. “Water-Scrum-Fall Is the Reality of Agile for Most Organizations Today.” Forrester. 2011年7月26日。https://www.verheulconsultants.nl/water-scrum-fall_Forrester.pdf.
1.Lencioni, Five Dysfunctions of a Team, “Exhibition.”
2.Lencioni, Five Dysfunctions of a Team, “Understanding and Overcoming the Five Dysfunctions.”
3.Coleman, “A Re-Imagining of the Term.”
4.Lencioni, Five Dysfunctions of a Team.
5.Sinek, Start with Why.
1.Michael Gale, 引用自 Rogers, “Why 84% of Companies Fail.”
2.Michael Gale, 引用自 Rogers, “Innovation Leaders.”
3.Cutler, “12 Signs You’re Working in a Feature Factory.”
4.Nelson, A Mental Revolution, 5–11.
5.The Standish Group,The CHAOS Report: 1994, 3.
6.Humphrey, Characterizing the Software Process, 2.
7.Cockburn, “Characterizing People as Non-Linear, First-Order Components.”
8.Cockburn, “Characterizing People as Non-Linear, First-Order Components.”
9.Cockburn, “Characterizing People as Non-Linear, First-Order Components.”
10.Roos, Womack, and Jones, The Machine That Changed the World, 52.
11.Fitz, “Continuous Deployment at IMVU.”
12.Highsmith, “History: The Agile Manifesto.”
13.Highsmith, “History: The Agile Manifesto.”
14.Fowler, “Writing the Agile Manifesto.”
15.Beck, et al., “Manifesto for Agile Software Development.”
16.Beck, et al., “Principles Behind the Agile Manifesto.”
17.Poppendieck and Poppendieck, Lean Software Development, xxv.
18.Poppendieck and Poppendieck, Lean Software Development, 101.
19.Debois, “Agile Operations.”
20.Mezak, “The Origins of DevOps.”
21.Allspaw and Hammond, “10+ Deploys per Day.”
22.Allspaw and Hammond, “10+ Deploys per Day.”
23.Travaglia, “The Revised, King James Prehistory of BOFH.”
24.Eric Minick, 与作者的私人通信，2019年7月12日。
25.West, “Water-Scrum-Fall Is the Reality.”
26.Sheridan, Joy, Inc., 19.
27.Pflaeging, “Why We Cannot Learn a Damn Thing.”
28.Kurtz and Snowden, “The New Dynamics of Strategy,” 462–483.
29.Kurtz and Snowden, “The New Dynamics of Strategy,” 469.
1.Harari, Sapiens, 20.
2.Dennett, From Bacteria to Bach and Back, Chapter 14.
3.Harari, Sapiens, Chapter 2.
4.Harari, Homo Deus, 158.
5.Forsgren, Humble, and Kim, Accelerate, 31.
6.Argyris, Putnam, and McLain Smith, Action Science, 79.
7.Argyris and Schön, Theory in Practice.
8.Argyris and Schön, Theory in Practice, 6–7.
9.Argyris, Putnam, and McLain Smith, Action Science, 81–83.
10.Argyris, Organizational Traps, 61.
11.Argyris, Organizational Traps, 17.
12.Argyris, Putnam, and McLain Smith, Action Science, 98–102.
13.Argyris, Putnam, and McLain Smith, Action Science, 90–99.
14.Argyris, “Skilled Incompetence,” 5.
15.Argyris, Putnam, and McLain Smith, Action Science, 88–98.
16.Cockburn, “Characterizing People as Non-Linear.”
17.Cockburn, “Characterizing People as Non-Linear.”
18.松散基于 Schwarz, “Eight Behaviors for Smarter Teams.”
19.Rosenberg, Nonviolent Communication, 115.
20.Center for Nonviolent Communication, “Feelings Inventory.”
21.Rosenberg, Nonviolent Communication, 93.
22.Argyris, Putnam, and McLain Smith, Action Science, 98.
1.Appleton, “The First Thing to Build Is TRUST.”
2.Brown, Rising Strong, 86.
3.Kahneman, Thinking, Fast and Slow, 85.
4.Beck, Test-Driven Development, xvi.
5.Argyris, Putnam, and McLain Smith, Action Science, 57.
6.Argyris, Putnam, and McLain Smith, Action Science, 58.
1.Edmondson, Teaming, Chapter 4.
2.Edmondson, Teaming, Chapter 4.
3.Beck, Extreme Programming Explained, 33.
4.Allspaw and Hammond, “10+ Deploys per Day.”
5.Bibb Latané and John M. Darley, Unresponsive Bystander, 46.
6.Vaughan, The ChallengerLaunch Decision.
7.NASA, Report of the Presidential Commission, Appendix F.
8.Kahneman, Thinking, Fast and Slow, Chapter 1.
9.Kahneman, Thinking, Fast and Slow, 85.
1.Sinek, “How Great Leaders Inspire Action.”
2.Sinek, Start with Why, 94.
3.King, “I Have a Dream.”
4.Martirosyan, “Getting to ‘Yes’ in Iraq”; Fisher, Ury, and Patton, Getting to Yes, 23.
5.Argyris, “Skilled Incompetence,” 5.
6.Senge, The Fifth Discipline, 185.
7.Park, “A History of the Cake Mix.”
8.Duff and Dietrich, Dehydrated flour mix.
9.Gerald M. Weinberg,The Secrets of Consulting, 177.
10.Gerald M. Weinberg, The Secrets of Consulting, 177.
11.Schwarz, “Eight Behaviors for Smarter Teams.”
1.Schwarz, Smart Leaders, Smarter Teams, 99.
2.Murphy, The Big Book of Concepts.
3.Adžić, Specification by Example.
4.Silvers, “A New Guest at Your House Show.”
5.Cockburn, Agile Software Development, 357.
6.Hihn, et al., “ASCoT: The Official Release.”
7.Shipman, “How Do You Delegate to a Group of People?”
8.Financial Times, “FT Tops One Million Paying Readers.”
9.Shipman, “How Do You Delegate to a Group of People?”
10.Shipman, “How Do You Delegate to a Group of People?”
11.Shipman, “How Do You Delegate to a Group of People?”
12.Shipman, “How Do You Delegate to a Group of People?”
13.Shipman, “After the Launch: The Difficult Teenage Years.”
14.Shipman, “How Do You Delegate to a Group of People?”
1.Merriam-Webster Dictionary, s.v. “account,” accessed July 20, 2019, https://www.merriam-webster.com/dictionary/account.
2.Poole, The Exchequer in the Twelfth Century, 128.
3.Poole, The Exchequer in the Twelfth Century, 139.
4.Poole, The Exchequer in the Twelfth Century, 100.
5.Poole, The Exchequer in the Twelfth Century, 34.
6.Poole, The Exchequer in the Twelfth Century, 127.
7.Poole, The Exchequer in the Twelfth Century, 107.
8.McGregor, The Human Side of Enterprise, 43 and 59.
9.Pflaeging, “Why We Cannot Learn a Damn Thing.”
Griffin and Ross, “Subjective Construal,” 319–359.
Bungay, The Art of Action.
Bungay, The Art of Action, 50.
Bungay, The Art of Action, 123–130.
Reinertsen, “An Introduction to Second Generation Lean Product Development.”
Bungay, The Art of Action, 123–130.
Ayer, “Don’t Ask Forgiveness, Radiate Intent.”
Shipler, “Reagan and Gorbachev Sign Missile Treaty.”
Cockburn, Agile Software Development, 98.
Rosenberg, Nonviolent Communication.
Burns, Feeling Good Together.
本书建立在许多对话形成的基础之上——有些充满欢乐，有些充满痛苦，所有对话都是学习的来源。以下是一些通过与我们的对话帮助我们成长和学习的人，我们对他们深怀感激：
Benjamin Mitchell，他向我们介绍了Chris Argyris的工作，并在我们学习对话分析(conversational analysis)等知识时耐心地与我们合作。Waseem Taj、Andy Parker、Jamie Mill和Lisa Miller，他们与我们一起学习如何分析对话，以及如何克服对困难互动的恐惧。Rich Koppel和Colin Berthoud，TIM Group的创始人，以及那里的许多员工与我们（尤其是与Jeffrey）合作，尝试建立一个基于透明度和好奇心的学习型组织(learning organization)。Steve Freeman，他鼓励我们讲述TIM Group变革的故事（本书并未讲述那个故事，但确实分享了这些变革背后的对话）。
我们的CTO导师圈(CTO Mentoring Circles)和伦敦组织学习聚会(London Organisational Learning Meetup)的参与者们，这些活动成为本书许多概念的试验场。
Chris Argyris和Donald Schön，他们的理论支撑了本书的大部分内容。还有那些发展了他们思想的人，包括Action Design的Philip McArthur、Robert Putnam和Diana McLain Smith，以及Roger Schwarz，他的八项行为(Eight Behaviors)在我们早期的对话中给予了我们极大帮助。
Patrick Lencioni，他的层级功能失调模型(hierarchical dysfunctions)为我们对话的顺序提供了依据。Amy Edmondson，她将”心理安全”(psychological safety)带入我们的词汇表。Simon Sinek，他解释了”为什么”(Why)的价值。Stephen Bungay，他展示了简报和反向简报(briefing and back briefing)的价值。Brené Brown，她帮助我们用语言表达我们对自己讲述的故事。David Burns博士，他帮助我们理解对话的分形特性——我们创造了自己的人际关系现实。
Alistair Cockburn、Kent Beck以及早期敏捷软件开发社区的其他成员，他们开创性地提出了关系很重要这一激进理念，那时我们俩还困在软件工厂中。Mary Poppendieck、Tom Poppendieck、Eric Ries等人，他们帮助将精益思维(Lean thinking)引入软件世界。Patrick Debois、John Allspaw和Paul Hammond，他们帮助打破了最后一公里的孤岛，并确保DevOps是关于文化而不仅仅是工具。
Geckoboard（包括Paul Joyce和Leo Cassarani）、Unmade Ltd.和Arachnys，他们都慷慨地允许我们在书中包含与他们合作的细节。
Anna Shipman，她富有洞察力的博客文章成为了一个案例研究。
Sofar Sounds，他们慷慨地允许我们讲述关于他们的故事。
Sergiusz Bleja，他允许我们包含与他共同创建的案例研究。
比利时联邦养老金服务机构(Belgian Federal Pensions Service)、Thierry de Pauw和Tom Jans，他们慷慨地允许我们将他们的一个项目的细节作为案例研究。
Elisabeth Hendrickson，她对这些材料的热情促使她将我们介绍给IT Revolution，此外她还建议我们在分析工具库中加入”抽搐”(twitch)。
Mark Coleman，他在关键阶段提供了非常有用的建议，并给了我们”困难的情绪工作”(difficult emotional work)这个概念。
Eric Minick，他对我们所取得进展的看法非常有帮助。
Chris Matts和Cirilo Wortel，他们在本书成形期间分享了故事和想法。
Ian Ozsvald，他在早期阶段给了我们宝贵的建议和联系方式。
Gojko Adžić，他分享了大量关于他的出版和咨询经验的信息和建议，他对测试和产品管理的愉快态度一直是观察的乐趣。
Paul Julius，他建议我们创办一个会议，促成了Squirrel和Jeffrey的相遇（以及更多）。以及那个会议——持续集成和测试会议(CITCON)的参与者们，我们多年来一直向他们承诺会出版这本书。
Alan Weiss和Gerald Weinberg，他们关于图书出版和推广的著作对我们始终具有启发性。
Laurel Ruma和Melissa Duffield，他们帮助我们巩固了最初非常松散的想法，最终形成了这本书。
Anna Noak，她在提案和写作阶段始终如一的耐心反馈对创作完成的作品至关重要，以及IT Revolution的许多其他人以多种方式为本书做出了贡献。
我们播客Troubleshooting Agile的听众们，他们提供了故事、建议，并成为我们许多想法的共鸣板；以及Michelle Choi和Laura Stack，他们确保播客引擎始终运转。
在过去二十年里允许我们指导他们并向他们学习的许多人和团队。
Jerry Shurman和Joe Buhler，他们教会Squirrel在智力追求中获得乐趣。
感谢 Pat Yanez、Ron Fredrick 和 Marilyn Fredrick，他们为 Jeffrey 提供了尝试困难任务的背景知识。
感谢 Robert Schuessler 敏锐的眼光和快速的反馈。
最后，感谢我们的家人——Andreas、Anton、Eliana、Emeline、Leanne、Lisa 和 Star——他们的耐心受到了考验，但从未停止对我们的信任，他们的支持是无价的。
Douglas Squirrel 从事编程工作已有四十年，领导软件团队二十年。他利用对话的力量，在各种规模的技术组织中创造显著的生产力提升。Squirrel 的经验包括：在初创公司担任 CTO 期间发展软件团队，涉及金融科技到电子商务等领域；在英国、美国和欧洲为六十多个组织提供产品改进咨询；以及指导各类领导者改善对话、与业务目标保持一致并创造建设性冲突。他住在英格兰 Frogholt 一座建于 1450 年的木结构小屋中。
Jeffrey Fredrick 是国际公认的软件开发专家，拥有超过二十五年的经验，涵盖业务和技术两个领域。作为 XP 和敏捷实践(Agile practices)的早期采用者，Jeffrey 曾在美国、欧洲、印度和日本的会议上发表演讲。通过在开创性开源项目 CruiseControl 上的工作，以及作为持续集成和测试会议(CITCON)的联合组织者，他对全球软件开发产生了影响。Jeffrey 在硅谷的经验包括担任产品管理副总裁、工程副总裁和首席布道师(Chief Evangelist)。他还曾担任独立顾问，涉及企业战略、产品管理、营销和交互设计等主题。Jeffrey 现居伦敦，目前担任 TIM Group(Acuris 旗下公司)的董事总经理。他还运营伦敦组织学习聚会(London Organisational Learning Meetup)，并通过 CTO Craft 担任 CTO 导师。