一封email引发的血案

原创飞总飞总聊IT

一封email引发的血案

文丨飞总图丨源自网络

下周公司年会，美德两地同事第一次全家福，加上一个Hackthon Demo获奖，诸事繁忙。于是决定今天临时多更新一期。下周公众号更新比较慢，见谅。

下午出门有事，在SafeWay偶遇了前同事。屈指算来，自从我离开微软，这是第二次见到了。有时候我会觉得，人生命里的那些人，只有一起在一个特定场合的时候才容易见到。一期一会，过期不候。大约这也是人生的一部分。

这位同事的水平相当之高。当然仔细想起来，当年我从学校毕业就进到某个组，周围陆陆续续来的人一个比一个更牛。而我无知无畏的在那个地方混了这么多年，没有因此而饱受打击从此一蹶不振。所以到今天我一直没搞明白无知是不是好事情。

我早期的时候基本的工程经验都没有，也不知道怎么做系统设计。所以很大程度上我的那些最基础的知识都来源于这位同事。以今天的我去看过去这位同事的设计和编程能力，依然是一个比较高的水准，除了有些时候会有设计过度的问题外，我很难挑出什么来。

但是从另外一个方面看，这位同事的职业生涯非常的不好。和这位同事了解到，从上次和我偶遇之后，迄今为止，依然没有任何的升级。由此算来，这位同事已经有很多年在同样的位置上，没有升一级了。当然一个人的职业生涯到了一个阶段，其实讲究的是综合素质。而综合素质，则是一个大家需要好好想想的东西了。

我至今为止记得的，是这位同事的一封email。故事的开局，就像任何狗血的故事一样稀疏平常。我们组和我们的上游，使用我们平台的一个组，要通力合作完成一件大事。所谓大事就是VP以上级别的人盯着，做成了可能让Bing的某些方面上一个台阶，而不能按时做出来，可能会让很多的KPI变得很难看的事情。

这个东西当然是不好做的。其中的一个模块，就由我的领导和对方领导开头，进行了热烈而深刻的讨论。这个热烈的讨论，有很多责任权力义务的分配。有很多方案的选择等等。必须说我领导是我遇过的最为聪明的人之一。然而马有失蹄，这次我那个聪明的领导好像犯浑了。于是在A和B方案里面，我领导带着他最信任的成员坚持说A多好，对方领导坚持说B好。这个时候，我前同事乱入了。乱入得非常的简单。写了一封长长的email。有理有据有节的分析了B为什么比A好。这封email当然成了对方领导展示为什么B比A好的有力证据。之后的事情，有我知道的，有我不知道的。我知道的那一部分是，我被拉了进来，实现了B方案，还有我前同事被领导踢出了那个讨论的email列表。这位前同事的职业生涯受到了很大的影响。从此以后，多年未曾升过一级。

八卦完我的前同事，来说说我。在我职场的早期生涯，发生过这样一件和email有关的事情。

在我们支持的用户邮件列表里面，有一个用户对一个由我写的新的功能提出了严苛的质疑。他以非常不信任的态度，很不友好的语气写了一封信。信的大意这个新的功能bug满天飞，导致了他一个很重要的数据分析任务没有完成。造成了非常恶劣的影响。那个开发这个功能的人给人带来了那么多麻烦，是不是应该。。。应该什么就留给大家脑补了。

我读到这封信的时候就属于一下肺气炸了。于是我花费了很多的时间，仔细研究了他的那份非常复杂的任务脚本。然后找出来到底是因为什么他的东西不工作了。最后我有理有据有节的回了一封信。然后把他说的是不是应该什么什么的话，大大的红字圈出来，回敬给了对方。最重要的，这封信当然是发给了整个用户邮件列表。

信才出去，我们组的Architect首先给客户回了一封信，道歉表示我们产品没有能够很好的提供debugging的环境，感谢对方反馈。同时对开发者无礼回信的事情请对方见谅。同时在我们工作的内部邮件组里，一封信，开头大大的红字：我们不可以这样对待我们的客户！！！事情当然没有什么好结果。我也当然乖乖的在内部道歉，又跑去和客户当面道歉。

我想如果需要举例子的话，那我一路过来因为写email不恰当而经历的，我看到其他人因为写email不恰当而经受的，其实我可以举更多的例子来。

我必须非常遗憾的说一句。也许我们的学校教育了我们CS的基本知识，教给了我们编程的能力，系统设计的能力，算法数据结构的能力。但是在这个email是沟通最主要的方式的IT行业里。我们有谁认真学过email沟通的能力吗？

很抱歉的说，其实我们写email的能力，哪怕是自我感觉非常良好的，可能都和我们写程序的能力匹配不上。所以，这应该也就是很多人在职业上升通道里，不好逾越的一堵墙。

那么email应该怎么写？这个问题其实不好回答。但是我们可以问一个问题，email的存在是干什么的？

为了界定这个问题的范围，我们把email定位在工作场合的email。至于私底下的，那就不在本文讨论范围之内了。

本质上来说，职场的email最重要的两个作用，其一是用于消息的传递，其二是沟通的工具。

那么我们解释一下，消息的传递和沟通的工具的差异在哪里。我们经常会收到领导的email，部门重组啊，公司有活动啊等等。这类的email，主要的目的是消息的传递。这类email有一个重要的特点，就是通常来说消息会有比较明显的单向的特点。

另外一类email涉及到沟通。其实沟通来说细分有很多，但是如果不细分的话，就是一堆人需要通过这个email去交流一些信息，达成某些一致。这就意味着email里面会有互动。

如何提高写email的能力是一个大话题。码农这种生物又有其特殊的理解世界的方式。所以我只能捡最重要的，以广大程序猿喜闻乐见的方式讲一讲。

Email的第一条，就是你需要判断一下到底是哪类的email。通常来说，沟通的email，谁来写，其实没那么讲究。而消息传达的email，谁来写是一个问题。一个不应该是你写的email，一直没有发出来，有可能是那个应该写这个email的人有自己的考虑。对方在选择合适的点发。你写了，可能就有问题了。写了自己不应该写的email，这个东西听起来好像离我们很遥远，但是我相信也许每个人都犯过几次错误。

Email的第二条，要确定写给谁。我知道很多人做这个决定的时候很草率。然而写给谁其实很重要。把无关的人放进来，浪费了别人的时间。没有放进来相关的人，问题无法解决。有时候email需要一小圈人先讨论讨论，然后再发到更大的圈子里面去。有时候是一封消息传递的email过来，但是作为接收者的你却需要进行沟通和交流，那么这种情况下回给谁，更需要想想。还有一些时候，是你作为回信的人加入到这个谈话里面的。但是有可能你还需要增加你认为要增加的人进来。那么在你增加这个人进来的时候，考虑一下，有没有必要先和被加的人，以及已经加进来的人私下有个沟通，得到对方的点头。是与不是，没有绝对，有些时候不需要，有些时候很需要。总而言之，To谁，CC谁，Bcc谁，写email的时候，如果从来都没有想过，那么我想你肯定是错了。

Email第三条，怎么写。这个说来话长。消息传递的email和交流的email也各有不同。我想对于大部分读者来说，一般是不会写到消息传递的email。如果真写到了，自己应该也是老江湖了所以不需要我来唧唧歪歪了。所以我的重点还是放在交流的email上。

有句话说得好，一行通，行行通。作为码农，码代码应该是家常便饭。好代码和坏代码应该有能力区分。当然我不排除混迹于码农队伍又不求上进的，基本的辨别美丑的能力也没有。

以代码的价值观来看，一封好的email有那么几个特点：第一做了应该做的事情，并且只做了应该做的事情。第二，代码简洁高效，不像懒婆娘的裹脚布，又臭又长。第二，有良好的模块化，模块和模块之间通过接口松耦合。第四，对于代码的功能有良好的测试。翻译一下，就是主题要明确，层次要清晰，表达了应该表达的，并且只表达了应该表达的。表达的方式高效简洁。如果表达的东西多，需要分模块分层次来阐述。有足够的校验来确保自己要表达的东西都表达了。