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

时间：2014-10-13 18:01:31 阅读：269 评论：0 收藏：0 [点我收藏+]

关于提高个人工作效率有很多方法，如计划工作、时间意识；集中精力、避免并行；简化工作、任务分解；回顾反省、总结经验；劳逸结合、健康体魄等等。本文以日常工作过程中人人都在用的邮件为出发点，从工具辅助、改善习惯的角度看待个人工作效率与工具使用方式上的关联，试图找出使用邮件的最佳实践。

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

一. 关于邮件

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

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

二. 写邮件

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

场景一：

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

过去四周以来，我们之中有很多人想知道，我们重新设计的程序代码签入流程，什么时候可以最终完成。我知道我们花了很长时间在门厅和会议室里讨论，想找出正确的方法来决策，但却没有了解新流程的实质设计。挑选委员会成员对我来说也不容易，很多人都知道，花的时间要比预期多。我为此感到道歉，但这些事还是发生了。
所以，首先，我想让你们知道新提案的一些重点，避免有人错过了我们的周会讨论，或者这两周没有和我谈过情况：
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，邮件接收方可以从标题中掌握整件事情的要点，后续邮件管理时也可根据多个关键字进行检索。多段式标题是个人使用最多的标题风格，效果也是最好的。

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

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.