程序员代码需要死记硬背吗（这项技能跟写代码一样重要）

一次真实的冲突

要成为一名程序员，会写代码这是共同的认知。但还有一项同等重要的技能，那就是要会说话。

看到这个，恐怕大家都会觉得奇怪 ，只要不是哑巴，都会开口说话，这算哪门子重要技能，居然还能和写代码相提并论了。

在回答这个问题之前，先看下我公司之前发生的一次冲突吧。

那是客服接到用户投诉，反映订单提交过程中出现问题。后端通过日志进行排查发现，是因为输入数据有误导致。

原因找到了，接下来项目经理召集前后端开发人员，讨论解决方案。偏偏就是在这个会议上，出现了谁也没有预料到的状况。

项目经理先提出问题后，后端开发负责人先发言，要求前端开发先做数据校验，立即上线解决投诉，后端这边在下一个版本迭代时进行修复。

前端开发立即表示反对，提出在设计时，为什么后端没有考虑到这个情况。再加上前端这边工作繁重，不能总是停下来替后端擦屁股，要求后端先修复上线。

于是技术讨论变成了意气之争，双方都把多年的陈芝麻烂谷子晒了出来。眼看争执不断升级，项目经理只好叫停，为了这事去请示 CTO 决断。

在那之后，我一直在想，有没有更好的办法解决问题，而不产生冲突呢？

会说话为何如此重要

我一直从各方面去找原因，管理上的、技术上的，甚至是性格上的。但最近读了一本书，却让我发觉，可能问题是出在说话这件事上。

这本书就是《改善对话：突破团队协作障碍》。此书的两位作者杰弗里与斯奎勒尔，都是敏捷开发的倡导者，认为泰勒主义的“科学管理”并不适合软件开发这项事业。

他们认为，在软件开发工作中，“非线性的，最重要的组件”是人。对此我深表赞同，一家科技公司最宝贵的财产就是协作无间的优秀团队。

著名的《敏捷软件开发宣言》第一条原则，就是“个体和互动，高于流程和工具”。而最有效的互动方式，就是直接对话。

如果大家沟通顺畅，能很快抓住重点，达成一致解决问题，那这就是建设性的对话。但由于个体之间总是存在差异，或者因为信息的不对称，对话就会变成防御性的——摆脱困境，而不是解决问题。

很显然，我公司的那次冲突，就是典型的防御性对话，大家都试图把责任推给对方。

《改善对话》就提出了实用方法，就像规格说明书一样好用：4R 法。

4R 方法怎么用

4R，是四个英语单词的首字母缩写，分别是：记录、反思、修订、角色扮演。这是一个顺序执行的步骤，在某些情况下，还可以增加两个 R ，就是重复与角色转换。

话说好记性不如烂笔头，在实践 4R 法时千万不能仅依赖于记忆来复盘。第一件事，就是准备好纸和笔吧。

记录，就是将发生过的对话写在纸上，不必精确到所有细节，能抓住关键点即可。

反思，剖析对话，检查其中的透明度和好奇心，标识出诱因、掩饰与本能反应的行为模式。这一步需要相当的勇气，因为要诚实地面对自己的内心，直击问题的痛点。

修订，以反思的结果为基准，在对话中增加更多信息，提高透明度。识别自己的行为模式，避免临阵脱逃，明确要达到的目标，坚定信念。

角色扮演，不要急着立即去进行下一次对话，找一个模拟对手先演练一下。要求是将修订以后的版本大声地念出来，在这个过程中根据自己的感受调整内容。

执行完以上四个步骤，如果还没有十足的把握，那么可以进行角色转换 ，将自己放在对手的身份上去体验。从对方的视角看问题，此时要是发现真正的分歧点，那么就进行重复步骤，回到反思去迭代执行。

4R 法看起来并不深奥，但执行时难免产生偏差。为了帮助程序员更好地做好对话，《改善对话》还提供了一件超实用的工具——双栏对话分析法。

力挽狂澜的秘技

大家把对话写在纸上后，有没有觉得还少了些什么？眼里看到的是对话，那么心里是怎么想的呢，把心里话也写下来是不是会更好？

双栏对话分析法，就是做一张两列多行的表格，在右栏写下真实对话内容，左栏则描述自己的内心真实想法。再与 4R 法结合，对这张表格进行反思、修订，直至让自己可以进行下一场对话。

要注意的是，左栏要忠实记录自己的想法，而不是臆测对方的任何想法。

我想以我公司曾经发生的那场冲突为例，探究一下双栏对话分析法的使用方法。从后端开发的身份记录冲突对话的场景，如下表：

后端开发的想法	前端开发与后端开发的对话
你们改完了上线快，而且错误请求不会传导到后端，我们可以集中精力完成新版本开发	后端：前端兄弟们可以先把数据校验加上，赶紧解决客户投诉，我们就放在下个版本里升级吧。
怎么扯到设计上去了，我要能想到不早就写进去了	前端：不对啊，这个问题在你们的设计里并没有提到。再说我们这边任务也很重，你们更了解情况，还是你们先改吧。
多大点事儿，有这开会的功夫，你们都改完了	后端：老板催着我们新版本服务上线不是，再说这修改也不复杂，你们辛苦辛苦吧，怎样？
呀，还来劲了是吧，那咱们就练练	前端：谁不是一堆事儿呢？不复杂你怎么不来，你说这是第几回了，我们合着啥也干不了，尽给你们擦屁股呢。
我就是对人不对事了，来互相伤害吧	后端：我这个人说话对事不对人，你别介意啊，你们上上回这个那个……

经过反思，发现后端开发过于急切地想要解决客户投诉带来的困扰，就提出了自己认为最好的办法，却忽略了前端开发的感受。修订的过程中，发现可以分享更多信息，并且注意到项目经理在场，应该让他也成为对话的一方。

修订对话如下：

后端开发的想法	前端、后端、项目经理之间的对话
先评估一下紧急程度	后端：项目经理，这个问题现在有多严重？
看来优先级还挺高的	项目经理：老板已经知道这个事了，正要过问。各位大哥们麻烦一下，看拿出个办法来。
先说我们这边的方案，尽量多同步信息，大家最好把注意力放在问题上啊	后端：我这边连改带测需要半天，服务程序替换更新那就要看运维兄弟了。但我们这边过两天就要发布新版本，到时又得升级一次。前端兄弟们这边修改大概要多久？
好事儿，前端兄弟起码没有明显抵触情绪	前端：这个也差不多是半天。
好问题！其实项目经理大哥您心中早就有数了吧	项目经理：哪个办法可以最快解决客户的投诉？
兄弟你还是明白事理的啊，给你点个赞	前端：应该是我们这边调整会比较快，把代码更新上去，客户那边刷新一下页面就可以了。但这半天时间，项目经理你得计入我们的加班。
这是一次富有成效的建设性会议，很开心	项目经理：这个没问题！辛苦各位兄弟了，我这就给老板汇报去。

我一边在做修订时一边感叹，要是早知道这个好方法，当初也许就能力挽狂澜了。顺便说一下，当时这事闹到 CTO 那里，除了双方被痛骂一顿，解决办法也还和修订中的一样。谁都没有得到真实的利益，却失去了最宝贵的信任。

团队要想亲密协作无间，还要做好包括信任对话在内的五种对话，我们接着学习起来。

做好五种对话，助团队协作无间

我们的最终目的，是想拥有一支有着超强执行力，所有成员都能团结协作的团队。要想形成凝聚力，就需要彼此间充分信任，消除恐惧，让每个人都主动担负起责任。

《改善对话》将团队管理中有关于人的问题，分为五种典型的场景，并对每种场景详细阐述了如何实践 4R 法与双栏对话分析法。我们一一进行说明。

信任对话，要想建立信任关系，开诚布公地分享信息与感受都是必须的。借助于“推断之梯”工具，实践以下几个步骤：观察、获得数据、赋予意义、推断结论、采取行动。循环迭代，消除猜疑，彼此信任。

恐惧对话，软件开发工作要承受巨大的压力，这是团队成员心中恐惧的来源。消除恐惧的最好办法，就是所有人都勇敢地直面它，把隐藏的任何担忧和害怕都说出来，会发现其实并没有那么可怕。

动机对话，有的老板喜欢用画大饼的方式激励团队，可能短期有效，但长期却无用。要想让团队成员有自主性，就要让他们参与到决策中。使用“联合设计”工具，可以让所有人都畅所欲言，推动形成决策。

承诺对话，程序员在对工作作出承诺时，往往会给出一个太乐观的预估，最终完成却要付出成倍的工作量。要做到合理承诺，对话就需要三个步骤：就承诺的含义达成一致；就承诺的下一个结果达成一致；就承诺进行重申。

当责对话，不少程序员喜欢闷头干活，难得主动反馈。为自己的工作负责，就一定要有主动反馈，可以包括三个方面：分享当前状态、描述计划和预期成果、对障碍的预警。

继续说，不要停

几乎所有的程序员招聘 JD 里都会有一条“具备良好的团队协作意识和能力”。不少人对此的理解，就是听话、肯加班、不争功。

《改善对话》对什么是团队协作，以及为实现良好的协作要做好哪些事情，给出了答案。这也是一本写给程序员的书，让我们明白，原来会说话是跟写代码一样重要的技能。

在我的职业生涯里，就曾受困于艰难谈话中，吃过不少亏，也学会了一些应对之法。在看过《改善对话》之后，恍然发现人性其实都是相通的。但人家总结成工具和框架，超脱无数程序员出苦海，功德无量。

程序员想学会一门编程语言，都知道必须写代码-编译-排错-运行。学习对话也是一样，尽管知道了 4R法、双栏对话分析法这些个，也一定要不断地实践应用。

继续说，不要停。

,