無論是對接甲方需求、設(shè)計(jì)細(xì)節(jié)修改還是和同事的工作分配,郵件都是職場最靠譜的溝通方式。一封得體的郵件是職場的必修課,可能很多同學(xué)落下了,沒關(guān)系,點(diǎn)開這篇文章,會(huì)發(fā)現(xiàn)作者聊的并非簡單的書面格式,職場的溝通思維才是全文的精華。
編者按:無論是對接甲方需求、設(shè)計(jì)細(xì)節(jié)修改還是和同事的工作分配,郵件都是職場最靠譜的溝通方式。一封得體的郵件是職場的必修課,可能很多同學(xué)落下了,沒關(guān)系,點(diǎn)開這篇文章,會(huì)發(fā)現(xiàn)作者聊的并非簡單的書面格式,職場的溝通思維才是全文的精華。
以下內(nèi)容不是規(guī)范,只是寫郵件時(shí)的總結(jié),請務(wù)必根據(jù)自己公司、團(tuán)隊(duì)的實(shí)際情況帶入思考。
內(nèi)容過長,手工碼字不易,為避免沒耐心的人誤以為我在寫申論,先提煉一下觀點(diǎn)
1.保證把事情說明白
2.在1的前提下,盡可能短
3.必要時(shí)可以羅嗦,不要為了短而短
4.HTML格式與txt格式的選擇,跟團(tuán)隊(duì)保持一致即可
5.寫完后考慮一下受眾的閱讀體驗(yàn)
6.讓自己的郵件易于檢索
7.由簡入繁,后而化簡
純工作性質(zhì)電郵的書寫可以粗略分兩個(gè)部分,思路和修辭。
?。ㄟ@里先做一個(gè)區(qū)分,有一部分電郵是用來搞關(guān)系、扯皮、劃分責(zé)任的,這些電郵的編寫可以按照傳統(tǒng)信的手法寫)
思路部分
有一些通用的原則可以作為書寫的指導(dǎo)。
1、“戰(zhàn)地記者”原則
設(shè)想自己是一名戰(zhàn)地記者,在彈雨紛飛的時(shí)候要報(bào)道當(dāng)前的戰(zhàn)況,在每說一句話都有可能有槍子兒找上腦門的時(shí)候,廢話、套話、官話、空話一概省略,直切主題是最合適的。比如說作為一個(gè)系統(tǒng)部署人員,要向一個(gè)主管技術(shù)的大領(lǐng)導(dǎo)匯報(bào)客戶現(xiàn)場的一個(gè)重大問題,可以用這樣的思路寫:
A系統(tǒng)B模塊目前無法運(yùn)行,部署日志見附件1,報(bào)錯(cuò)信息見附件2,客戶端環(huán)境見附件3.客戶要求24h內(nèi)解決,否則將延遲上線。
一句話將所有的重點(diǎn)信息濃縮起來,相關(guān)但冗長的技術(shù)信息用附件傳遞,可以保證對方在看到郵件后馬上理解事情的起因經(jīng)過以及可能的結(jié)果,這種情況下如果顧慮太多,仍然用“尊敬的領(lǐng)導(dǎo)”一類的套話起頭和修辭的話,可能會(huì)導(dǎo)致對方遺漏重要信息。保證對方第一眼就能看到電郵的目的。
2、“金字塔”原理
想象一下金字塔的典型構(gòu)造。我認(rèn)為所有電郵(甚至可以包括其他實(shí)用文章)都應(yīng)該遵循這種結(jié)構(gòu):中心明確,分層敘事,逐層鋪開。
關(guān)于金字塔原理的書籍,有一本同名的《金字塔原理》可以深入學(xué)習(xí),這里只講述一下我理解的具體概括法。
a. 先用戰(zhàn)地記者原理過濾一下自己所想表達(dá)的內(nèi)容。
找到少數(shù)的幾個(gè)重點(diǎn),然后再逐一篩減直到找到有且只有一個(gè)的中心,先將這個(gè)“點(diǎn)”暫時(shí)列為自己所有表述的最終目的。
還是拿剛才的例子來解釋,客戶現(xiàn)場的重大問題,我需要告訴很多事情幫助對方判斷,比如日志、報(bào)錯(cuò)信息、環(huán)境等等,但實(shí)際上仔細(xì)分析,這些東西都只是為了解決“系統(tǒng)部署失敗”這個(gè)問題,而再仔細(xì)分析,解決“系統(tǒng)部署失敗”后可以避免“系統(tǒng)延遲上線”,并且可以避免項(xiàng)目的失敗、客戶的不信任,最終將所有蛛絲馬跡的問題都匯聚到一點(diǎn)“維持客戶的信任”。
b. 分析郵件接受者對于這個(gè)中心點(diǎn)的理解程度。
如果不言而喻,則降級到下一中心點(diǎn),如果可能不甚理解,則保持這個(gè)中心點(diǎn),圍繞著它展開描述。
對方是主管技術(shù)的大領(lǐng)導(dǎo),對于“維持客戶的信任”這一點(diǎn)自然能有足夠的認(rèn)識(shí),因此降級,選擇“項(xiàng)目失敗”,同樣有足夠的共識(shí),再降級“項(xiàng)目延遲上線”,在這一點(diǎn)上,大領(lǐng)導(dǎo)可能不會(huì)比現(xiàn)場人員有更清醒的認(rèn)識(shí),因?yàn)樯礁呋实圻h(yuǎn),他能看到的實(shí)況有限,而自己的任務(wù)就是將這一實(shí)況以足夠明顯而肯定的方式匯報(bào)給對方,讓他有足夠的資源進(jìn)行判斷、協(xié)調(diào)資源,所以選定“項(xiàng)目延遲上線”這一點(diǎn)作為中心。
c. 描述中心點(diǎn)最直接相關(guān)的一層信息。
項(xiàng)目延遲上線最直接相關(guān)的是“部署失敗”,但部署失敗只是個(gè)結(jié)果而不是過程,所以還需要繼續(xù)描述為什么部署失敗。通常做一件事有這么幾方面信息,“我有什么資源做、怎么做的、出現(xiàn)了什么結(jié)果”,這三個(gè)方面就是部署失敗的直接相關(guān)的信息。
d. 繼續(xù)描述“直接信息”的“直接信息”。
這里將進(jìn)入一個(gè)循環(huán),將自己認(rèn)為需要說明的情況用逐層鋪開的方式附加到中心信息上,豐富中心信息的支撐體系。在電郵里需要根據(jù)實(shí)際情況采用不同的方式進(jìn)行附加,例如圖片、圖表、附件文檔等。
日志、操作記錄等信息雖然有價(jià)值,但因?yàn)樾畔⑦^長、對中心點(diǎn)沒有直接幫助,而必須以一種不干擾閱讀的方式出現(xiàn),掛附件是比較好的選擇,這可以保證對方在需要獲取的時(shí)候不難獲取、在不需要獲取的時(shí)候直接避開。
通常參考這兩項(xiàng)原則、經(jīng)過不斷的書寫聯(lián)系和概括,就能保證自己的電郵產(chǎn)出是思路得體的。
修辭部分
每個(gè)人都有自己的文字風(fēng)格,但在工作性質(zhì)的電郵中,需要適當(dāng)約束自己的碼字習(xí)慣。
1. 標(biāo)點(diǎn)
這部分是最容易忽視的,不少工作N年的老同事在書寫電郵時(shí)要么不加符號(hào),要么亂加符號(hào)。比如每句話都用問號(hào)結(jié)尾、到處亂跑的感嘆號(hào)、翻譯腔的破折號(hào)等等。我自己有一個(gè)電郵標(biāo)點(diǎn)的心理底線,就是“可以不規(guī)范,但一定要規(guī)律”。
比如有時(shí)因?yàn)檩斎敕ǖ葐栴}沒辦法使用標(biāo)準(zhǔn)的中文句號(hào),我索性就直接用英文句號(hào)、甚至減號(hào),但一定會(huì)有規(guī)律地用,比如所有減號(hào)都是句號(hào)的意思,避免對方看不明白符號(hào)的意義,另外日常聊天時(shí)我習(xí)慣以三個(gè)句號(hào)結(jié)尾,但在電郵中盡量避免這些個(gè)人習(xí)慣,就算不能規(guī)范地使用標(biāo)點(diǎn),但也至少不要成為潛在的閱讀障礙。
2. 字體
默認(rèn)字體
如果公司有規(guī)范,嚴(yán)格執(zhí)行,如果沒有規(guī)范,就保持默認(rèn)字體,因?yàn)樵诓恢缹Ψ揭暳?、閱讀場合、閱讀儀器的時(shí)候,默認(rèn)字體是最安全的選擇。
粗體
僅限于刻意強(qiáng)調(diào)的文字,一般情況下在一段話內(nèi)只出現(xiàn)一個(gè)粗體詞組時(shí),強(qiáng)調(diào)效果是最好的,而出現(xiàn)了三四個(gè)甚至更多的粗體時(shí),效果反而降低,“都強(qiáng)調(diào)等于沒強(qiáng)調(diào)”,所以,找到自己最需要的那個(gè)點(diǎn),然后再考慮是否值得加粗。
斜體
另外,無論如何都要謹(jǐn)慎對待“斜體”,盡量避免使用,目前win平臺(tái)的斜體是粗暴的。
3. 顏色
安全色:紅色、綠色
除了紅色(代表強(qiáng)調(diào)或者危險(xiǎn))和綠色(代表通過和安全)可以適度使用外,其他顏色盡量避免使用。
多種顏色時(shí),給出標(biāo)注
如果一定要用多種顏色,必須在顯眼的地方給出顏色的標(biāo)注,否則郵件幾經(jīng)轉(zhuǎn)手后,閱讀者會(huì)不理解顏色的意義而錯(cuò)失、誤解信息。
4. 對齊
段首對齊
我見過不少同事在寫一個(gè)新段落的時(shí)候前面加了兩個(gè)空格,甚至一些程序員會(huì)加四個(gè)空格(因?yàn)橐粋€(gè)英文空格是1/4個(gè)漢字長度),但是在電郵中,段落開始時(shí)應(yīng)該避免加空格,這屬于“web時(shí)代新文字排版問題”,不在這里鋪開討論。
段末對齊
不要用回車控制換行,因?yàn)樵谧约旱目蛻舳嗽O(shè)置下看起來美觀的回車換行,到了別人的設(shè)備上將可能是一種視覺災(zāi)難,參考這個(gè)圖片(左為原始屏幕,右為較小屏幕下的顯示效果)。
5. 換行與行間距
手工空行
在表述完一個(gè)完整段落后,盡量手工空一行,因?yàn)樵诓煌拈喿x設(shè)備中,沒有這個(gè)空行的話會(huì)導(dǎo)致密密麻麻的文字墻,這種視覺壓力會(huì)直接影響閱讀者的理解能力,留白能讓人在閱讀的時(shí)候有喘息的機(jī)會(huì)和理解的間隙。
適當(dāng)?shù)拈g距
行間距可以用默認(rèn)間距或1.5倍以內(nèi)的間距,取決于篇幅多長,更高的間距會(huì)讓閱讀者的視線跳躍過多引發(fā)視覺疲勞。
6. 文字描述手法
概括一下我所推薦的電郵寫作手法,“選擇樸實(shí)準(zhǔn)確的形容詞和副詞,多用具備一定意義的短句,避免復(fù)雜術(shù)語的堆砌”。
選擇樸實(shí)準(zhǔn)確的形容詞和副詞
這里主要針對偏愛小說式電郵的寫作方式,比如需要用“美觀”代替“美輪美奐”等等,工作電郵不是散文,需要確保務(wù)實(shí)。
多用具備一定意義的短句
將長句拆解為短句,可以讓閱讀者更容易理解,比如
本次項(xiàng)目延期上線是因?yàn)樵诳蛻衄F(xiàn)場出現(xiàn)了一個(gè)由于安裝A程序失敗導(dǎo)致了冗余的tmp文件丟失所引發(fā)的故障。
可以拆解為
項(xiàng)目延期上線,因?yàn)樵诂F(xiàn)場出現(xiàn)了安裝故障,該故障由A程序安裝失敗所引發(fā),具體原因?yàn)槿哂鄑mp文件丟失。
避免復(fù)雜術(shù)語的堆砌
這一條在技術(shù)同事來看,可能有不同意見,因?yàn)樵诖蟛糠諶D相互溝通的時(shí)候,術(shù)語是相當(dāng)于世界語的。
不過大部分RD線以外的同事并不理解RD之間說的“我打算繼承你寫的A方法”或者“給我個(gè)接口”,所以在同事間互相電郵的時(shí)候,需要確保自己寫的東西是對方能看懂的,例如下面這種替換(閱讀者是財(cái)務(wù)同事)。
你打開瀏覽器,輸入1234,然后看系統(tǒng)控制臺(tái),把里面的systemp參數(shù)copy給我。
可以替換成
你打開IE,或者360瀏覽器,在地址欄(上面那個(gè)有http:\\字樣的)里輸入1234,然后看打開的頁面,左邊有一個(gè)菜單,靠中間的位置有一個(gè)功能叫“系統(tǒng)控制臺(tái)”,點(diǎn)開它,再看彈出來的窗口,最上面有一排英文,把名字是systemp的后面的框內(nèi)的東西復(fù)制下來發(fā)給我。
粗看起來廢話不少,但這種方式的電郵卻是最能保證效果的,因?yàn)橥麻g對于信息的理解不同,而信息不對等是造成溝通不暢的最主要障礙,說白了就是“你說的我不理解,我說的你不理解,雙方都要往復(fù)幾次才能理解對方”。
7. 標(biāo)題
電郵標(biāo)題也是經(jīng)常被忽視的一點(diǎn),但這一點(diǎn)至關(guān)重要,可以說保證了自己和對方在今后查找相關(guān)信息時(shí)的準(zhǔn)確性。
恰當(dāng)?shù)臉?biāo)題一般是最全面的概括、最開始的引子、最點(diǎn)睛的描述。
最全面的概括
《有關(guān)XX項(xiàng)目在XX客戶現(xiàn)場的部署故障及現(xiàn)場情況說明》
最開始的引子
《XX市XX客戶現(xiàn)場部署故障》
最點(diǎn)睛的描述
《XX客戶現(xiàn)場部署故障將可能導(dǎo)致延期上線》
這些都是可行的例子,根據(jù)實(shí)際情況作權(quán)衡。
8. 其他
其他電郵的寫作內(nèi)容還包括簽名檔、郵件重要度、郵件格式、閱讀者的環(huán)境預(yù)估等。
簽名檔
簽名檔主要用于讓對方獲取自己的其他聯(lián)系方式,公司有統(tǒng)一要求的,需要嚴(yán)格執(zhí)行,如果沒有統(tǒng)一要求的,需要設(shè)置一個(gè)固定的格式,包括個(gè)人姓名\英文名、公司正式注冊名稱、部門\項(xiàng)目組、手機(jī)、座機(jī)、MSN等必要信息。
重要度
除非是火燒屁股的事,千萬不要使用重要度這個(gè)設(shè)置,以免重寫狼來了的故事,《狼來了之現(xiàn)代電郵版》。
郵件格式
通常設(shè)置為html格式,如果有特殊要求也可以考慮txt純文本,但后者將沒有視覺格式可言,一般不推薦。
閱讀者的環(huán)境預(yù)估
這部分其實(shí)有一點(diǎn)投機(jī),也可以看做是“電郵溝通中的用戶體驗(yàn)”,例如對方經(jīng)常使用12寸小本,就盡量把表格設(shè)置得緊湊一些,對方如果是出差在酒店里,發(fā)郵件時(shí)就盡量避免發(fā)送大附件,而使用其他方式傳遞等等。
以上為個(gè)人觀點(diǎn),供參考,歡迎討論指正。