- 原发: 电邮靠谱指南
- 今天 gitcafe 公众号转载了此篇扫盲文, 才知道原来常识也得持续的传播.好吧... 简书 当然是个稳定的渠道 ;-)
俺常常说的:
忘记的就是不重要的
不知道就是不必要的
现实住住不是这样的
<!--more-->
准入
~ 想理解以下内容,先明确:
-
习惯
科学上网 -
习惯
用 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
- 指定这种文字编码的人,基本上没救了.
- 参考:
神奇的邮箱名
- 类似
.嘦ぐ龘ǒ
之流后现代网络KUSO文 - 或是,每天变更邮箱名,每次收到邮件都不确定是否是同一位
最容易被无视的邮箱
背景:
在中国,技术圈儿里,使用以下邮箱来发送邮件,基本上很难得到很好的第一印象:
- @qq.com
- @163.com
- @126.com
- @sina.cn
- @hotmail.com
- @msn.com
- ...
因为,这些邮箱代表着...呵呵呵...
邮件基础行为要理解
背景: ARCI分析矩阵
工作中任何一个环节的上下文总是有以下责任层级:
-
A
ccountability ~ 责任 : 对成败负责和进行协调管理 -
R
esponsibility ~ 职责 : 具体实施 -
C
onsulted ~ 咨询 : 提供意见,救助决策 -
I
nfomed ~ 了解 : 知晓进度
所以,邮件作为工作中的关键信息载体,要合理使用不同的内置行为:
- 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文 呢?
- 俺要真正完成这位同学的吩咐,目测要作:
- 运行 VirtualBox
- 进入XP
- 安装 WPS
- 在主机设置共享
- 回到虚拟系统,从共享中打开乱码文件名的 .wps
- 逐一阅读内容,明确都是给谁的邀请函
- 输出为对应的 pdf 文件
- 对应修订 pdf 文件名,为全E文的
- 另外创建一个 .txt 文件,将邀请函内容,复制进入
- 关闭虚拟机,回到主机
- 进入gmail 逐一转发邮件并 增补邀请函内容到正文,并附件上对应pdf
- 整个儿的耍下来,没有半小时搞不掂哪!
正确的作法:
- 组织好邀请函,并输出为pdf
- 向俺发送三封邮件:
- 给俺的邀请函,并说明马上有另外两封邀请函发送过来,请转发
- 另外两封邀请函,完全是向另外受邀人的口吻和内容
- 所有邮件,邀请内容都以纯文本形式在正文,并包含图文排版的 pdf 附件
这样俺收到邮件后,完成吩咐的行为就变成:
- 打开邮件,阅读,明确接下来的行为
- 收到另外两封,逐一 FW 给对应小伙伴
是也乎
简单的说,用好/用对 电邮 的原则极其简单:
- 从收件人角度设想
- 邮件的内容/形式/结构/过程,都为解决事儿,而不是掉书袋神马的
- 以尽可能的节约涉及到的所有人的时间/精力为目标
- 持续改进,自个儿的邮件习惯
这其中,个人发觉,越早习惯以下思维,越容易变得靠谱:
- Markdown
- 不用中文标点
- 每行不超过79字
修订记录
- 140508 快速形成独立文章
- 140222 GDG 活动进一步分享
- 140219 WPS 内部交流
- 140215 意动,创建 draft