Home | 簡體中文 | 繁體中文 | 雜文 | 打賞(Donations) | ITEYE 博客 | OSChina 博客 | Facebook | Linkedin | 知乎專欄 | Search | About

3.4. 溝通管理(Communication Management)

為了確保項目的信息的合理收集和傳輸所需要實施的一系列措施,它包括溝通規劃,信息傳輸和進度報告等。

我的要求就是單向精準,消息漏斗化。單向是有別于廣播的。

很多企業喜歡使用廣播試溝通,典型的例子是將電子郵件CC抄送給所有人,有關無關均抄送。這帶來一個問題,員工每日面對一屏幕的電子郵件,找出與自己有關的郵件,既浪費時間也容易出錯。所以電郵需要精準投遞,不要發給無關的人。

消息漏斗化是指消息到達最終接收者,中間經過的環節不斷過濾,消息量越來越少。舉例,10個需求,5個評審通過,3個實現不了,1個開發實現不了,最終只有1個需求安排給開發者。

3.4.1. 表達方式

職場生存就不免不了與人打交道,高大上的說法叫“溝通”。不像生活中的溝通有天人的信任和默契,哪怕是不那麼注意談話方式,也不會產生誤解。

職場上則不同,我們經常需要面對陌生人,需要更多技巧和規則。

3.4.1.1. 拒絶反問句

職場溝通應該儘量使用陳述句和祈使句,措辭需非常謹慎,以免產生歧義,甚至傷害對方的情緒而誘發矛盾。

當今的職場90、95後為主力,這一代獨生子女內心比較脆弱,管理層稍有措辭不當,就會傷害到他們的情緒,後果是撂挑子就走。

無論是誰被反問的時候,都難免產生被冒犯的情緒。



XXXX 難道你們之前沒有人對 XXX 進行測試驗證嗎?
我已經跟你們說我無數次,為什麼還犯這種低級錯誤?

換一種說法



XXX看來是測試不足,您看我們採用 XXX 方看是否可行?
目前的問題是 XXX,我們應該討論一下怎麼徹底解決,不再發生同樣的事情。

職場中,善用反問的同事是令人生厭的。換做官場,對上級或者平級採用反問的方式,仕途就此終結。

3.4.1.2. 任務分配

一旦時間點確定,接下來就是分配任務倒指定開發人,任務的分配十分講究,分配任務要精確描述,不能使用模糊語言,那樣會造成誤解。我的分配原則是5W2H方法:



- What:做什麼事?
- Why:為什麼做這件事?有什麼意義?目的是什麼?有必要嗎?
- When:什麼時候做,完成的時間是否適當?
- Where:在什麼地方做,在什麼範圍內完成?
- Who:由誰負責做?由誰負責執行?誰更合適?熟練程度低的人能做嗎?
- How:怎樣做
- How much: 成本 (不是所有崗位都會涉及成本)

舉例,運維任務



- What:為api伺服器做負載均衡,多增加一個節點,負載均衡算法採用最小連接數。
- Why:目前api伺服器只有一台,如果出現故障將影響倒所有業務運行,顧該伺服器存在單點故障,需要增加節點。
- When:本週內完成,周末上線。(此處可以寫日期)
- Where:在A機櫃,低2機位處,連接倒交換機第三個連接埠。
- Who:XXX負責網絡配置,XXX負責上架,XXX 負責驗收測試
- How:增加/etc/hosts設置如下
  - api.example.com   127.0.0.1
  - api1.example.com  192.168.2.5
  - api2.example.com  192.168.2.6

舉例,開發任務



- What:增加圖片驗證碼。
- Why:目前用戶註冊登陸以及發帖無驗證嗎,某些用戶通過機器人軟件批量開戶/發廣告帖,給我門管理帶來很大困擾。
- When:2014-06-15 開始開發,2014-06-20 12:00 上線。
- Where:用戶註冊,登陸與發帖處增加該功能,。
- Who:張三負責驗證碼生成類的開發,李四負責用戶註冊,登陸UI修改,王五負責發帖UI的修改。
- How:具體怎麼操作的細節,此處省略200字...

舉例,測試任務



- What:測出XXX軟件並發性能。
- Why:目前XXX軟件在綫任務達到200後,用戶反映速度慢,經常掉綫。
- When:故障時間點10:00AM,需要周二完成測試,周五完成優化,月底上線。(此處可以寫日期)
- Where:在AAA分支檢出代碼,編譯後部署到BBB環境。
- Who:XXX負責網絡配置,XXX負責軟件部署,XXX 負責測試
- How:具體怎麼操作的細節,此處省略200字...

舉例,促銷任務



- What:XXX產品促銷。
- Why:目前XXX產品在 XXX 市場佔有率 XXX 用戶反映 XXX。
- When:促銷起始時間 XXX 結束時間 XXX
- Where:AAA 細分市場,BBB區域。
- Who:XXX負責 XX,XXX負責 XX,XXX 負責 XX
- How:具體怎麼操作的細節,此處省略200字...
- How much: 成本XXX

3.4.1.3. 任務確認

當接受分配的任務後,最好能夠在溝通完畢後確認一下對方的意思,例如:

“XXX 總, 我沒理解錯誤的話,您的意思是要求我:第一,......; 第二,......; 第三, ......; 是這樣嗎? 沒有問題的話我就按這個去執行了。”

3.4.2. 越級和跨部門溝通

謹慎處理越級和跨部門溝通,無論是對上還是對下的越級,都是職場中的忌諱。

對上越級溝通,會讓自己的上次暗生不滿。

對下的越級溝通,會損害直接下屬的權威。

兩者都會打亂其部門內部的權利結構和工作部署,形象整個組織架構管理。

3.4.3. 會議管理

3.4.3.1. 會議的時間成本

會議不僅占用管理層的時間,更占用員工的時間,所以要嚴控會議用時。

開會就要有解決方案,成熟的方案,否則不要開會,開了沒有意義,浪費時間。

3.4.3.2. 三個臭皮匠,還是臭皮匠

三個臭皮匠,還是臭皮匠,永遠不會成為諸葛亮,如果三個臭皮匠能成為諸葛亮,就不會出現三足鼎立的情況,集思廣益純屬扯淡。

大部分的會議就浪費在聽取廣大群眾的發言。

通常我們看到的會議就是針對XXXXX問題你們看看怎麼做,你們大家商量一下,然後你一言,我一嘴,各個提建議,到頭什麼都沒有解決,一份會議記錄發給所有人,几乎沒有人看。

提意見都很踴躍,具體到誰負責都開始低頭,會議內容落實5%不到。

3.4.3.3. 下一個飯局

會議出現交叉,追尾,就是如同趕飯局。

多任務處理和預約衝突使會議效率變低,公司不得不安排更多會議完成工作。

3.4.3.4. 會議必須有結論

會開了,問題仍然沒有解決,這種議而不決非常普遍。

會議不能議而不決,會議的目的是針對方案細節依次敲定,然後進入到Ticket對應具體負責人。

3.4.3.5. 會議記錄

我從來不看,沒有必要寫。

3.4.3.6. 會議地點

會議地點可以隨時隨地,桌面討論也是會議,不一定非要定會議室。

3.4.3.7. 與會人員

與會議議題無關的的人員不應該參加會議。

3.4.3.8. 怎樣管理會議的時間呢?

取消一定數量的會議或者刻意壓縮會議時間並不現實,因為促進合作和作出重大決定都需要開會研究。

我認為可以這樣管理,首先規定一個部門或者管理層,一周或者一個月的會議時長。每組織一次會議,便扣除會議時長,並告知剩餘時長。

同時制定下面六條規定,可以讓許多公司大幅提高會議質量。

  1. 會議審批,議題論證,組織會議人員資格,會議時間、與會人員都要嚴格審查

  2. 議程目標明確。比如通知A事項,討論B事項和決定C事項。會議過程也和會議目標一樣簡明扼要,與會者專注于完成具體目標。

  3. 提前準備。所有周商業計劃回顧都必須提前發出,讓與會者能在會議前查閲。這一舉措大大減少會上分享信息時間。

  4. 按時開始。時長一小時會議如果晚5分鐘開始,就會浪費8%的會議時間,但很多管理團隊在任何其他職責領域都不會允許8%的浪費發生。

  5. 敲定事項,會議的目的是針對方案細節依次敲定,什麼是應具體負責人,什麼時間完成。

  6. 儘早結束,尤其是在會議無法得出明確結果的情況下。當公司內部會議效率下降,或與會者準備不充分時,喬布斯會馬上“緊急叫停”。有人覺得這樣做唐突無禮,但當會議不太可能得出理想結果時,該做法有效制止了時間和金錢浪費。

3.4.4. 工作報告

不要讓員工為了寫工作報告而寫工作報告。

我從不要求團隊寫工作報告,因為項目管理中Ticket/Issue一幕瞭然,任務出口是由經我這裡確認後發出,對整個項目了如執掌,所以不需要工作報告。

工作報告並不能判斷員工的工作量以及是否工作飽和,所以工作報告是不准確的,可以虛構,不實的,而員工為了寫報告而寫報告,造成時間成本浪費。

3.4.5. 負面信息處理

任何公司內部都會時不時傳出一些負面信息,例如,公司投資項目失敗,高層政治鬥爭,銷售業績受挫,緋聞謡言。

怎樣處理這些負面信息呢?答:欺上瞞下。

對下屬,聽而不說。

對平級,不聽不說。

對上級,過濾後說。