由“每週例會”說起

每天專案例會的話，頻率太高了，可能會浪費時間，如果每月一次，似乎時間太長了，於是我們往往會“每週例會”。
有一次我參加了某專案的每週例會，開會的時間是週五，會上其中一位專案成員反應了一個問題。
我問：該問題什麼時候發現的。
答曰：週一。
我問：週一為什麼不說這個問題？
……
這是真實個案，有問題為什麼不立刻反饋，要等到例會才說？擔心例會上沒有東西可以說嗎？

如果你們公司實施年度績效考核，12月你的領導找你談話，進行績效考核，你的領導說：小X啊，你1月份做得那個事情不對啊，然後2月份到11月份你每個月都重複犯類似的錯誤啊！你的領導之前一直沒有跟你說過此事，直到績效考核才跟你說，你會有什麼反應？如果因為這樣，你的績效成績很差，導致你得不到年終獎，你會不會有衝動去掐死你的領導？

績效考核這個案例是虛構的（儘管是虛構，其實有很多類似的真實個案），但道理和“每週例會”其實差不多，開會到底是為了啥？其實我很反感“例會”的這個“例”字，一旦帶上這個字，就很容易認為這是例行要做的事情，這樣就很容易導致我們走形式，而忘記了為什麼要開會？
不過話說回來，前面提到的“每週例會”個案已經不算很差的了，一些專案的每週例會說的事情是：本週幹了啥，下週準備幹啥。變成了工作彙報會議！如果遇到這樣的會議，我會直接開罵：你這專案經理幹什麼吃的？大家幹了啥你平時不知道嗎？下週要幹啥，你事先沒有規劃嗎？

為了避免走形式，下面開始我不會用“例會”這個詞，為了讓你們的會議效率更好，建議不要用“例會”這個詞，你甚至可以考慮將會議室改名為“War Room”！每一次會議都是一場戰鬥，是需要解決問題的！一位同事曾經形容過會議給她的感覺，只有四個字：刀光劍影！會上所有與會者都會投入進來，為了專案的成功各抒己見、據理力爭。沒錯，咱們要的就是這個效果！

每日會議是這樣開的嗎？

極限程式設計有每日站立會議，SCRUM有每日晨會，那是不是每天開一次會就是敏捷呢？
有朋友提到他們也實踐每日會議，但沒啥效果。
我問：你們每天開會是不是說一下最近一天干了啥，接下來了一天打算幹啥呢？
答曰：是滴……
那自然沒啥效果了，這樣就變成工作彙報會了，而且更嚴重的問題是：敏捷開發是今天計劃今天的事情，見一步走一步的嗎？
極限程式設計中的小版本釋出，以及SCRUM中的Sprint（衝刺），其實就是一次迭代。在某一次迭代中的工作應該是事先規劃好的，絕對不是見一步走一步的。每日會議完全沒有必要說那些大家都知道的事情，說廢話可不是敏捷的初衷。

每日會議應該怎樣開？

每日會議應該重點說以下有價值的內容：
1.有什麼問題、困難、風險影響你當前的工作，以致不能按照既定計劃進行。
2.有什麼問題、困難、風險會影響當前迭代的成功？
3.有什麼問題、困難、風險會影響專案的成功？
4.當前計劃是不是已經或者可能不合時宜了，需要立刻更新或改進？
5.有什麼做法或建議可以讓專案更加成功？
簡單說，每日會議主要是用來讓你提出問題、困難和風險的。

每日會議可以讓問題隱藏不會超過24小時，並且可以讓你的工作及時獲得其他成員的支援！這是“白痴”也懂的道理：問題早一點暴露和解決，將會節省莫大的成本。可惜我們往往是為了節省開會成本，日會變成周會甚至是月會，看上去節省了不少開會時間，但專案的問題就在你的姑息下滋生和蔓延，最後可能會要了專案的命！任何專案都會存在大量的問題，如果說你的專案沒有問題，那麼你要警惕了，沒有問題是最大的問題！不是你的專案真的沒有問題，而是你們連發現問題的能力都沒有了！質量是需要投資的，每天會議就是一種投資。

敏捷開發絕對不是今天計劃明天的工作的，要保證每一次迭代都能成功，那麼工作就必須落實到每一天。每日會議是保證計劃有力執行的重要手段，將專案的情況每天都視覺化地展現在所有專案成員面前，讓我們一天一個腳印、踏踏實實地將專案做好。

讓專案組全體成員明白為什麼要每日會議和如何每日會議，這樣每日會議其實很容易做到很有效的。每日會議無論是站著開還是坐著開？是早上開還是下班前開？要用白板還是用投影？等等這些都是形式而已。開門見山，抓住要害，必要時要做書面記錄。

每日會議進階

在我的專案中經常會每日會議，而且更變態時我會每半天會議！
我為什麼要這麼變態半天開一次會議呢？
1.每日會議雖然可以讓問題存在不會超過1天便暴露，但我仍然覺得1天的時間太長了，我受不了，最多半天我就要發現它！
2.中國教育制度出來的技術性人才，大多是悶頭苦幹型，有問題喜歡自己解決，有想法不主動提出來。中國教育制度我無法改變，但我必須改變團隊成員的這種工作習慣，那麼半天會議會比每日會議更加有效。
3.專案的工作是爭分奪秒的，我的專案中的工作時間是精確到小時甚至是半小時的。問題如果可以存在一天，那麼一天中就很可能至少會有2-3小時的工作時間是浪費的，將來要返工的，如果半天例會一次，這種返工的時間就會縮短到1小時內。

我的專案加班的時間一般不多，很大程度是得益於每日會議甚至是半日會議。其實每半天會議不算什麼創舉了，只要清楚明白你想要達到怎樣的效果，你就可以實踐出更多的最佳實踐！美劇《24小時反恐》，劇中處理某些突發事件時，那個反恐部甚至是每1小時一次會議！

開發人員需要長時間的獨立思考，你可能會質疑：半日會議會打斷開發人員的思路，反而降低效率？你也可能會質疑：專案的整個過程都需要半天會議或每天會議嗎？
這個問題很好！每日會議或者是每半日會議，並不會在我的整個專案週期中出現，我一般在以下情況才實施每日會議甚至是半日會議：
1.專案初期頭緒很多、隱藏問題很多的時候。
2.專案組成員提不出問題，無法迅速進入戰鬥狀態的時候。
3.軟體釋出階段，不斷地發現bug和解決bug的時候。

除了半日會議這個變態做法外，我還有其他“另類”的做法：

1.突然會議
當我意識到有危機或隱患需要立刻處理時，我會立刻召集專案會議。

2.任何人都可以召集會議
任何專案組成員遇到問題需要其他人支援，或者他預感到有隱患或危機時，不需要得到我同意，可立刻召集專案組全體或部分成員召集會議，他成為這次會議的領導！

其實道理很簡單，就是：發揮團隊的力量，儘早發現和消滅問題！在萌芽狀態就消滅它，而不是等待問題發芽並壯大到不可收拾的地步。更加不是做鴕鳥，將頭埋在沙裡，對問題視而不見！

回到原點——為什麼要開會？

有朋友在群中提到，他們專案基本不需要開會，因為平時就把問題給解決了！
我覺得這實在是太牛了！說到底開會只是一種形式，問題是我們開會的目的是什麼？如果不用開會能用更簡單有效的辦法達到開會的目的，那麼開會幹嘛？回到這個原點，我們自然就會處理很多專案中的問題，讓會議更加有效甚至不需要會議！

當然有些溝通是必須通過會議來進行的，目前可能我們暫時沒有辦法完全不需要會議，那麼必要的會議是必須的！譯作會議的英文單詞有“meeting”和“conference”，你知道這兩個英文單詞有什麼不同意思嗎？
meeting：參與人數不多，參與者聚在一起討論問題，每個人的發言權力是平等的。
conference：參與人數比較多，說話的人佔少數，大部分人是聽眾。例如你參加什麼過程改進年會，我在上面演講，你在下面聽，那種就叫conference。

兩個詞的意義不同主要在於三點：
1.目的不同：meeting尋求各人的意見來達成共識；conference主要是宣講某些人的觀點。
2.參與人數不同：meeting參與人數不多（我建議不要超過7人，5人以內最有效）；conference參與人數可以很多。
3.參與方式不同：meeting人人有均等發言權力；conference中演講者佔主導，其他人是聽眾。

按照上述的定義，你可以看看你們專案中的會議是meeting還是conference？
如果你要打造自組織的團隊，那麼就必須賦予小組成員權力，讓你的會議是meeting而不是conference！而且在meeting中做到每個人都是主角！

後話：每日會議不會助長懶人歪風？

有朋友提到：他們解決不了的問題都會拋給我，自己也不思考，搞得我頻繁救火，感覺很疲憊。
再進一步深挖此問題，發現：這些專案成員是來自不同部門的，專案經理基本上沒啥權力了管理他們，不能影響專案組成員的薪金、獎金和職位升降等。
也就是說：這個專案小組全體成員並不在一條船上！專案的成敗只與PM有關，與專案組成員基本沒有關係，專案組成員當然是能少幹就少幹，能不幹就不幹了！

會議中提問題的目的是集合全體智慧來應對這些問題，如果提問題的目的是為了偷懶，那根本就不是這個味了！這個團隊建設或者說團隊文化就超級有問題，在這樣的基礎上，其實無法實施任何敏捷實踐。曾經在2011廣東過程改進年會上，有朋友問到什麼東西是最需要首先改進的？我提出的觀點是：首先要做好團隊建設，否則其他都是虛的；如果團隊建設能做好，那麼團隊就能自覺解決很多問題，也很容易實施各種敏捷實踐，甚至打造屬於自己自己的最佳實踐。

本文關於每日會議及半日會議的實踐體會，是基於專案組全體是在一條船上的基礎上的。如果目前你的專案組還不能坐在一條船上，那麼請參考一下我在CSDN上已經或即將發表的關於團隊建設的文章。

但要提到的一點是，專案組必須是相對獨立和有一定的權力，專案經理應該有一定的權力。至於SCRUM中提到的ScrumMaster有點專案經理的意思，但他是沒有行政權力的，僅是充當教練的角色。問題是：這樣的角色在國外可能適用，但在國內如果你沒有任何權力，僅靠人格魅力來帶動團隊，那要看你的RP了，看看你帶領的團隊成員是不是都是人格高尚的了。

作者：張傳波

創新工場創業課堂講師

華為某團隊高階顧問

《火球——UML大戰需求分析》作者