工具系列之邮件--浅谈工具怎样改变你的工作效率

关于提高个人工作效率有非常多方法。如计划工作、时间意识。集中精力、避免并行；简化工作、任务分解。回想反省、总结经验；劳逸结合、健康体魄等等。

本文以日常工作过程中人人都在用的邮件为出发点，从工具辅助、改善习惯的角度看待个人工作效率与工具使用方式上的关联，试图找出使用邮件的最佳实践。

通常，针对反复性或耗时过长的工作。我们利用工具来改善过程；针对自身能力或工作上存在的弱点，我们利用工具进行弥补。邮件作为最典型的一个职场工具。其在详细软件和操作上有丰富的表现形式，文中提到的邮件相关知识和使用方式主要都是面向0基础用户，但工具使用的习惯有时候一旦形成。假设使用方式不当反而比較难以融入到团队统一的方式中去。所以也推荐中高级用户能够參考一下。本文强调团队协作模式下工具的使用场景、策略和原则。不以工具的详细操作方式、步骤和不经常使用功能为重点。

一. 关于邮件

关于邮件。第一个问题是我们什么时候使用邮件？个人觉得在须要多方协作且时效性不强、须要明白细节、追踪状态、安排事情、须要历史记录备份时使用邮件是合适的。邮件是沟通模式中典型的“推模式”。受众明白但不适合版本号信息管理。那使用邮件有什么优点呢？邮件为我们提供了过程记录、冗余备份、有效的信息传递手段和丰富的内容检索方式。

本文要回答的问题是我们应该怎样使用邮件来提高自身的工作效率，下文主要从两慷慨面对这个问题进行展开：写邮件和管理邮件。

二. 写邮件

我们首先来看两个场景分析：

场景一：

以下的这两封邮件来自Scott Berkun的《Making Things Happen: Mastering ProjectManagement》，当中一封写得好，一封写的不好。这是第一封：

过去四周以来，我们之中有非常多人想知道。我们又一次设计的程序代码签入流程，什么时候能够终于完毕。我知道我们花了非常长时间在门厅和会议室里讨论，想找出正确的方法来决策，但却没有了解新流程的实质设计。挑选委员会成员对我来说也不easy，非常多人都知道，花的时间要比预期多。我为此感到道歉。但这些事还是发生了。
所以，首先。我想让你们知道新提案的一些重点，避免有人错过了我们的周会讨论。或者这两周没有和我谈过情况：
1.签入程序非常重要。
它们决定我们究竟在构建什么。
2.每一个人都有意见。我们都听过Randy和Bob各自的详细描写叙述。解释他们觉得当前系统这么糟糕的原因。
3.没有简单的答案。我们讨论过的多数改动都有缺点。所以。当我们最后达成结论时。在转换时期会有一些粗糙之处，并且可能会持续不断。
得出这些结论后，如今我想让你们知道。本周剩下的时间我会给你们发去改动过的提案。请注意我发的下一封电子邮件。应该非常快就会发了。

这是第二封：

新的签入程序流程的终于提案已完毕。放在站点上：http://intman/proc/checkin/。

由于这是一个有争议的问题，我已经和团队中的多数人一对一地讨论过这个提案。整合了每一个人的反馈意见。假设当中没包括你的，而你有强烈意见，请尽快发给我。
但要注意：关于这些即将到来的改变，这是第二次公开声明。眼下改动的机会非常小。今后会更小。请如今就採取行动。不然就保持沉默。

周五下午五点，是针对上述提案和我联络以提出反馈意见的截止时间。
在那之前。我会考虑和回应不论什么问题或意见（和适当的人共同研究）。否则，这件事就这样，并在下周開始生效。

大家对照两封邮件，不难得出结论：第二封邮件写得好。

那第一封邮件的问题出在哪里呢？个人觉得第一封邮件看起来写的非常不错。但实际上存在非常多让人分心、难以把握邮件重点的内容，并且有些描写叙述摸棱两可。反观第二封邮件全部的描写叙述都是面向行动，让接收方明白自己该做什么以及在什么时候做。这样邮件的价值就体现出来。通过该邮件起到的协调和沟通作用也在无形中提高了全部人的工作效率。

场景二：

场景二由三封邮件组成，这是第一封，由发信方发给客户：

According to the schedule of shipping, the boards should have been received. Do you get them?

As agreed before, boards will be tested and paid within 20 days after received.
Well, after ready, nearly 30 days, they are only picked up and shipped.
Therefore, please kindly arrange test and the balance payment ASAP.

这是第二封。客户回复给发信方：

wehave not yet received the shipment. Please be aware that yesterday, Monday wasbank holiday in Hugary. I will check with UPS today, and will let you know.

发信方收到客户回复之后，对回复作出反馈：

Many thanks for your letter.
I just asked forwarder and learnt that boards are still in importing customs clearance.
Hope you receive them early.
After reception, please kindly help arrange test as early. :-))
Many thanks!

通过上面三封邮件的loop，大家看到问题出在哪里吗？个人觉得最大的问题在于发信方没有站在对方的角度看问题。说出去的话全然仅仅顾自身的利益而无论对方的难处。邮件是一种相对照较正式的沟通方式。代表着利益关系，假设态度和措辞上让对方感到不舒服。碰到不同的人可能会有不同的反应，极端情况下会给自己和团队带来不必要的麻烦。影响沟通的效果。

通过上面的分析我们体会到好的邮件和差的邮件之间有时候会导致截然的沟通结果，这些结果非常大程度上影响甚至决定着个人以及周围团队的工作效率。以下让我们环绕怎样写一封邮件的各个组成部分进行展开，探讨邮件的写法和对应的实践方式：

1. 标题

关于邮件标题，业界存在一个“CURVE原则”，当中CURVE是Curiosity（好奇心）、Urgency （紧迫性）、Relevancy（相关性）、Value（价值性）和Emotion（感染力）五个英文单词的首字母组合。

CURVE原则觉得一个好的邮件标题应该至少满足上述五点中的两点。尽管提出该条原则的是一个营销大师，但个人觉得这条原则在平时写邮件是还是有一定指导意义的。通常相关性、价值型和紧迫性是能够用来做主要參考。

标题的还有一个要素就是“风格”。相同的内容通过不同的标题风格表现出来效果往往不一样。个人总结经常使用的标题风格有：

多段式标题。通过标题中分段描写叙述的方式展示邮件所要表达的主题。例：

XX管理移动版系统 - XX医院产品公布更新 - UAT, No.01, 2014/02/28

上述标题用于对外服务公布，表示在2014/02/28这一天，XX医院的XX管理移动版系统公布更新，公布目标环境和公布序号各自是UAT和No.01，邮件接收方能够从标题中掌握整件事情的要点。兴许邮件管理时也可依据多个keyword进行检索。多段式标题是个人使用最多的标题风格，效果也是最好的。

正文主题式标题。标题直接展示邮件主题。例：

XX医院售前支持

事件驱动式标题。通过事件和活动等确定邮件的标题。带有非常强的上下文信息。例：

请与下周一(2014/06/23)之前提交培训PPT

事件驱动型标题一般对事件内容、时间和责任人有明白体现，经常使用于团队内部使用，对外部沟通而言慎用。

流程式标题，该邮件标题用于流程运转和过程记录，通常为兴许回想提供数据基础。例：

MCS-PKU update(1)@2014-03-14

上述标题用于研发团队内部提測，表示在2014-03-14这一天，MCS-PKU有了第一次服务更新须要測试跟进。

2. 收件人

关于收件人。强调三点：

收件人有时候比邮件本身更重要：有时候邮件本身并没有可发挥的内容，但不同的收件人会让重要的事情变成不重要。也能把不重要的事情变得重要，在写收件人时。确保找到合适的收件人。
相同当你接受邮件时。也请第一时间关注一下收件人列表。
干系人的概念：请确保邮件的收件人满足关系人的定义。仅仅有满足是我的事情并且与这间事相关的人才是我的干系人。
区分接口人还是邮件组：邮件组是常见的邮件接收方组织形式，但邮件组是“不必要接收人”的典型邮件误用现象，有些职位的人会增加到非常多邮件组中，假设他每天都收到几十封和自己完毕没有关系的邮件。那真正须要他採取行动的邮件非常可能会被遗漏，导致沟通出现故障。

上面三点非常大程度上与沟通管理的模式和策略有关。详细可參考我的还有一篇关于沟通的博客：《沟通管理--关于信息的有效传递和维护》。

有了上述原则，我们就能够把邮件发给你期望有所动作的人并Cc给你希望对事情有所了解或偶尔提个建议的人。

3. 附件

关于附件个人把它分成对内和对外两种场景。对外交流使用附件时须要注意：

起草邮件时第一时间拖附件
打包exe、dll、msi等文件
尽量不要传送大的附件（>10MB）
使用通用文件格式，不要使用相似rar格式
给附件起合适的名字
附件的使用方法在邮件正文中要明白表明出来
区分适合做邮件正文和适合做附件的内容

对内交流不建议使用附件，使用SVN、OneNote等进行拉模式下信息传递一般是优先的选择。

4. 正文

写正文包括几个要点。首先是表达邮件的主题：

开门见山。表明目的。“你是谁？想干啥？”
把最重要的事情放在第一段，尤其前三句
假设有多个地方期望对方有所动作。则高亮出来
补充性的、说明性的文字放在后面慢慢阐述

表达主题的基本原则：

站在自己的立场上思考、站在对方的立场上讲话
立场要坚定、态度要温柔

以下是正文表达主题上的比較好的一个演示样例：

1、XXX医院要试执行XXX系统，有一部分数据须要从移动护理系统读取，须要你安排人员配合，要求5月14号之前完毕接口程序提供，如无法及时提供，也请你发邮件时抄送一份给XXX。他是这个系统的销售。

2、移动医生查房系统开发对接人：XXX 联系方式：XXX
3、附件是“XXX标准版接口方案”，请查收。

邮件正文中避免语义误解，尽量少使用代词。比如以下都是反面演示样例：

“这个事情让他去处理“
”把这个dll放在那个文件夹里”

邮件表述上须要给对方一种积极的反馈的感觉，假设约定的时间不能给出答复。第一时间先回复一下邮件表明正在处理，可是会拖后一些时间，比如：

今天白天事情较多，晚些时候我会提供XXX版本号的部署说明及软件等，请现场人员明天及时进行预部署工作。

组织正文逻辑时，须要注意：

言简意赅，不要太发散
尽量使用自己主动编号
重要的内容放前面，辅助性的内容放后面
使用短章节、短句。断开长句、长段落
段落之间空行

同一时候，个人觉得使用inline回复在某些场景下是最佳实践。

inline回复即对用户信息的逐条回复。通常使用在大量问答式的回复场景：

在原邮件逐条回复
使用不同的字体、颜色
前缀最好加上自己的名字
句首表明态度。比方：接受、无法实现、待定、能够、不能够等
邮件正文要表明使用inline模式进行答复

以下是我工作中使用过的一个inline回复的片段演示样例：

1. How is the structure for the MDS?
Please update the System Design for discussion.
1.1. Auto update is needed for the MDS.
[Tianmin] Yes, it will be included.
1.2. MCS_SYS_LOG is needed for recording the AH_ERROR, SYSTEM ERROR, such as Wi-Fi failure
[Tianmin] Yes, it will be included.
1.3. Separated Server log between MDS/ MCS/ Any New Clients. If it cannot be separated, please make you can diagnostic the problem be system.
[Tianmin] Yes, we will separate them by using different prefix, for example, all the logs like MDS_XXX can be used for checking the issues raised by MDS.
1.4. Please propose, shell we use the MCS DB or create the new database.
[Tianmin] From your system design, we think using the MCS DB is OK
1.5. Please propose if any new system is needed, we should create individual EAR or using the same EAR with MDS?

[Tianmin] If we will have other small systems like MDS deployed in the future shown in your system design , we also suggest to create individual EAR, although it will cost extra time for development and maintenance.