原发: 电邮靠谱指南
今天 gitcafe 公众号转载了此篇扫盲文, 才知道原来常识也得持续的传播.好吧... sf.gg 当然是个稳定的渠道 ;-)

俺常常说的:

忘记的就是不重要的
不知道就是不必要的
现实住住不是这样的

准入

~ 想理解以下内容,先明确:

习惯 科学上网
习惯 用 Chrome/Safari/Firefox ,万不得以也可以安装 Opera, 死也不能用 IE !
习惯 每天处理 42+ 电子邮件
承认并接受 e-mail 暂时无可替代

参考

理解:
演讲:

私人经验

主要针对工作邮件的经验,但是,私人邮件其实 80% 的情况是一致的.

只探讨:

在涉及人员都具备基本的职业素养,
同事之间无冤无仇也没有人来大姨妈的情况下,
如何写出让对方看过之后觉得专业并乐于回应的邮件

书面胜于口头

如果不承认这点,就别往下看了:

written is always better than oral

想不清楚的事儿,一般写不下来
写不清的事儿,一般也说不清楚
必须当面说才能清楚的事儿,一般没谱

而且,邮件在所有事儿的过程中比其它所有网络交流方式有天然的优势在:

电子证据,无法伪造
推进事件链,能客观/完整记述具体过程
永久保存,不会丢失 (特别是使用 Gmail 类似配合云存储的服务时)

最招人反感的邮件形式

RT

正文就两个字母: RT
这种邮件,目测 99.9999% 的正常人,是不会回复的.

正文不剪裁

只回复半行
但是,带了上千行过往数十封邮件的全文
来自: AceFantasy的微博|微博-随时随地分享身边的新鲜事儿

用回复: 撕裂 coversations 的

明显使用类似 foxmail 之类未流客户端或是免费中文邮件服务的
使用各种可定制的中文前缀文,以及无视 e-mail 协议头信息有关规约
肆意撕裂邮件线索
导致一件事儿,从一组邮件变成离散的一堆邮件

用 top-post 而且有大堆标准PR缀文的

类似 gmail 中不推荐的选项打开了:

Insert this signature
before quoted text in replies
and
remove the "--" line that precedes it.
这样将造成一个讨论线索引文中包含海量难以删除的缀文

HTML

这种格式的邮件,千万别轻易使用,
太多几率对方根本就看不到,或是只能看到错乱的排版!

GB2312

指定这种文字编码的人,基本上没救了.
参考:
- 有关GB18030编码来由的传说

神奇的邮箱名

类似 .嘦ぐ龘ǒ 之流后现代网络KUSO文
或是,每天变更邮箱名,每次收到邮件都不确定是否是同一位

最容易被无视的邮箱

背景:

在中国,技术圈儿里,使用以下邮箱来发送邮件,基本上很难得到很好的第一印象:

@qq.com
@163.com
@126.com
@sina.cn
@hotmail.com
@msn.com
...

因为,这些邮箱代表着...呵呵呵...

邮件基础行为要理解

背景: ARCI分析矩阵

工作中任何一个环节的上下文总是有以下责任层级:

Accountability ~ 责任 : 对成败负责和进行协调管理
Responsibility ~ 职责 : 具体实施
Consulted ~ 咨询 : 提供意见,救助决策
Infomed ~ 了解 : 知晓进度

所以,邮件作为工作中的关键信息载体,要合理使用不同的内置行为:

TO(发送给)
- 收件人是职责人
- 是这事儿的直接参与/处置/接手人
CC(抄送)
- 抄送给责任/咨询者
- 是这事儿的直接/相关领导/组织/机构,可以发表意见
BCC(密送)
- 密送的应是有权知情人
- 是这事儿需要知道进展的领导/资源/甲方,但是,不必反馈意见
- 一般礼节,应该在正文中说明 BCC 给了谁
FW(转发)
- 收件人是职责人
- 是这事儿的应该执行/处置/接手人
- 代表,这事儿不应该归俺作的

所以,回复时,要小心,

不是随便回复就可以的,
或是,永远只是单纯的回复发件人,完全无视CC 名单

如果邮件发送方,包含了复杂的CC 名单,

一般情况是要尽力保持,
除非我们回复时包含敏感内容,必须单线联系,才能只回复发信人,清除所有CC 邮箱.

写新邮件的最佳顺序

附件->正文->标题->收件人

为毛?!

这个自个儿体验就知道了.

邮件标题的最佳结构

30字以内,尽可能的包含5W1H

用标签明确类别,是要求/通知/汇报/指令还是其它
有日期要求的一定要写
有明确专有名词指代项目/工程/产品的一定要用
一般是对部门进行叙述
有明确的期待收件方作什么的行为描述

邮件正文的最佳结构

倒金字塔叙事

在邮件的开头,用三行,言简意赅地概括大意,讲清楚5W1H
再慢慢展开邮件,旁征博引,罗列数据,推演流程吧

最忌讳将邮件写成小说/散文,一看过去乌泱泱几个大段.没人有耐心逐行去看的.

另外, 多说事实,少说道理

附件

正如 附件 的名称所指含义: 附加文件

既然是附加文件,就不应该是邮件的唯一内容!
一般附件都是相关特殊格式的数据/报告/设计稿,都是给收件人使用的工作元件
而不应该是邮件本身的主要内容!
即使是请求他人来审核附件文件的内容,也应该将全文/或是概要直接写在邮件正文中

因为, 习惯性的使用 D版 Word 来起草一切文档,然后附件邮件中发送;
这其实就是经典的学生式思维:

认定全球所有人都工作在 M$ 系统中
认定全球所有人都会安装 Word
认定全球所有人都习惯附件内容

而从来不从对方角度着想,
想看到真正的内容的操作:

点击附件下载
打开资源管理类似工具
定位到默许下载目录
点击下载的附件
等待对应专用软件打开附件

整个儿流程下来,没有半分钟完不了,但是,如果别人一天要处理几百封邮件的话,
基本什么事儿也不用想了.

实例故事

事儿:

某活动的邀请函,需要俺转发另外两人

行为:

邮件正文曰:

我将正式邀请函三份打包在附件中了,请查收并转发给另外两位评委,
辛苦您了!

然后,俺下载到 muCommander( : a cross-platform file manager) 中是这样的:

尝试用伟大的 7 - Zip 解开是这样的:

郁闷ing:

俺 MAC 10.9 Mavericks 系统,想用 WPS 得:
- 使用另外测试用 Win7 系统机器
- 或是,启动虚拟在XP 中打开
压缩包险险中文正当, Gmail 立功了
但是,内容,文件名杯具的使用了 cp936(gb2312) 编码
- 导致在本地的文件名全部乱码
- 为什么不用 E文呢?
俺要真正完成这位同学的吩咐,目测要作:
1. 运行 VirtualBox
2. 进入XP
3. 安装 WPS
4. 在主机设置共享
5. 回到虚拟系统,从共享中打开乱码文件名的 .wps
6. 逐一阅读内容,明确都是给谁的邀请函
7. 输出为对应的 pdf 文件
8. 对应修订 pdf 文件名,为全E文的
9. 另外创建一个 .txt 文件,将邀请函内容,复制进入
10. 关闭虚拟机,回到主机
11. 进入gmail 逐一转发邮件并增补邀请函内容到正文,并附件上对应pdf
整个儿的耍下来,没有半小时搞不掂哪!

正确的作法:

组织好邀请函,并输出为pdf
向俺发送三封邮件:
1. 给俺的邀请函,并说明马上有另外两封邀请函发送过来,请转发
2. 另外两封邀请函,完全是向另外受邀人的口吻和内容
3. 所有邮件,邀请内容都以纯文本形式在正文,并包含图文排版的 pdf 附件

这样俺收到邮件后,完成吩咐的行为就变成:

打开邮件,阅读,明确接下来的行为
收到另外两封,逐一 FW 给对应小伙伴

是也乎

简单的说,用好/用对电邮的原则极其简单:

从收件人角度设想
邮件的内容/形式/结构/过程,都为解决事儿,而不是掉书袋神马的
以尽可能的节约涉及到的所有人的时间/精力为目标
持续改进,自个儿的邮件习惯

这其中,个人发觉,越早习惯以下思维,越容易变得靠谱:

Markdown
不用中文标点
每行不超过79字

修订记录

140508 快速形成独立文章
140222 GDG 活动进一步分享
140219 WPS 内部交流
140215 意动,创建 draft

电邮靠谱指南

准入

参考