文章41沟通之痛如何改变.pdfVIP

2018/11/5 极客时间 | 程序员进阶攻略 木讷与沉默，这两个名词似乎已变成了程序员的标签，它们形象地体现了程序员在沟通中的表 现。 在程序员的世界里，沟通的主要场景可能包括：与产品经理沟通需求，与测试同学推敲 Bug， 与同行交流技术，给外行介绍系统，还有和同事分享工作与生活的趣闻，等等。然而，有些程序 员在分享趣闻时，与谈需求或技术时的表现大相径庭，刚才明明还是一个开朗幽默的小伙，突然 就变得沉默不语了。 沉默有时是因为不想说。特别在沟通需求时，有些程序员默默不言，但心里想着：“与其扯那么 多，倒不如给我省些时间写代码！”然而，程序员写出的代码本应该是公司的资产，但现实中代 码这东西是同时带有资产和负债双属性的。 需求没沟通清楚，写出来的代码，即使没 Bug 将来也可能是负债。因为基于沟通不充分的需求 写出来的代码，大部分都是负债大于资产属性的，这最后造成的后果往往是：出来混都是要还 的，不是自己还就是别人来还。 有些程序员可能会争辩道，“与人沟通本来就不是我们所擅长的，再说了我们也并不是因为热爱 跟别人聊天才做软件开发这一行的。”这个言论很有迷惑性，我早年一度也是这么认为的。 我毕业去找工作那年，外企如日中天，所以我也去了当时心中很牛的 IBM 面试。面试过程中的 大部分交谈过程和内容现在我都记不清了，但就有一个问题至今我还记忆犹新。面试经理问 我：“你是喜欢多些跟人打交道呢，还是跟电脑打交道？”当时的我毫不犹豫地回答：“喜欢跟 电脑打交道，喜欢编程写代码，而且我自觉也不擅长和人打交道。” 然后，我就被淘汰了。后来我才明白了，其实当时的这类外企挂着招工程师的名义，实际需要的 更多是具有技术背景和理解的售前技术支持，因而就需要所招之人能更多地和人沟通去解决问 题，而不只是写代码解决问题。 结合我自己多年的工作经历和经验来看，即便你仅仅只喜欢写代码，那么和人的沟通能力也依然 是你必须跨过去的门槛。《计算机程序的结构与解释》有云：“程序写出来是给人看的，附带能 在机器上运行。” 其实，写代码本身也是一种沟通，一种书面沟通。沟通从来都是个问题，书面沟通也同样困难。 二、争论与无奈 程序员最容易产生沟通争论的地方：沟通需求和沟通技术方案。 在程序员的职业生涯路上，我们不可避免地会碰到和同事关于技术方案的争论。我从中得到的教 训是：千万不要让两个都自我感觉很牛的程序员去同时设计一个技术方案。 /column/article/64938 2/6 2018/11/5 极客时间 | 程序员进阶攻略 假如不巧，你已经这么干了并得到了两个不同的方案，那么记住，就别再犯下一个错：让他们拿 各自的方案去 PK。因为这样通常是得不到你想要的“一个更好的方案”，但却很可能会得 到“两个更恼怒的程序员”。 既然分歧已经产生了，为了避免无谓的争论，该怎么解决呢？ 1. 以理服人 首先，把握一个度，对事不对人 ，切勿意气用事。 有些程序员之间的分歧点是非常诡异的，这可能和程序员自身的洁癖、口味和偏好有关。比如： 大小写啦、命名规则啦、大括号要不要独立一行啦、驼峰还是下划线啦、Tab 还是空格啦，这些 都能产生分歧。 如果你是因为 “该怎么做某事或做某事的一些形式问题” 与他人产生分歧，那么在很多情况 下，你最好先确定分歧点是否值得你去拼命维护。这时，你需要判断一下：技术的 “理” 在什 么地方？这个 “理” 是你值得拼命坚守的底线不？用这个 “理” 能否说服对方吗？ 我所理解的技术的 “理” 包括：先进性、可验证性、和团队的匹配性、时效性、成本与收益。 另外还有一些不合适的“理”，包括：风格、口味、统一、政治等。 不过有时候，有“理”也不代表就能搞定分歧，达成一致。毕竟林子大了，不讲“理”的人也是 有的，那么，就需要换一种方式了。 2. 以德服人 分歧进入用 “理” 都无法搞定时，那就是应了那句古词：“剪不断，理还乱”。 这时继续“理”下去，不过都是互相耍混罢了。“理” 是一个需要双方去客观认可的存在，而 越“理”越乱则说明双方至少没有这种客观一致性的基础，那就找一个主观的人来做裁决吧。