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

导读一次真实的冲突要成为一名程序员，会写代码这是共同的认知。但还有一项同等重要的技能，那就是要会说话。看到这个，恐怕大家都会觉得奇怪，只要不是哑巴，都会开口说话....一次真实的冲突

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

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

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

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

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

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

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

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

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

会说话为何如此重要

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

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

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

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

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

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

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

4R 方法怎么用

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

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

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

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

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

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

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

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

力挽狂澜的秘技

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

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

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

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