敏捷開發(fā)中比每日會議更瘋狂的半日會議！
每天項目例會的話，頻率太高了，可能會浪費時間，如果每月一次，似乎時間太長了，于是我們往往會“每周例會”。
有一次我參加了某項目的每周例會，開會的時間是周五，會上其中一位項目成員反應(yīng)了一個問題。
我問：該問題什么時候發(fā)現(xiàn)的。
答曰：周一。
我問：周一為什么不說這個問題？
……
這是真實個案，有問題為什么不立刻反饋，要等到例會才說？擔(dān)心例會上沒有東西可以說嗎？
如果你們公司實施年度績效考核，12月你的領(lǐng)導(dǎo)找你談話，進(jìn)行績效考核，你的領(lǐng)導(dǎo)說：小X啊，你1月份做得那個事情不對啊，然后2月份到11月份你每個月都重復(fù)犯類似的錯誤??！你的領(lǐng)導(dǎo)之前一直沒有跟你說過此事，直到績效考核才跟你說，你會有什么反應(yīng)？如果因為這樣，你的績效成績很差，導(dǎo)致你得不到年終獎，你會不會有沖動去掐死你的領(lǐng)導(dǎo)？
績效考核這個案例是虛構(gòu)的（盡管是虛構(gòu)，其實有很多類似的真實個案），但道理和“每周例會”其實差不多，開會到底是為了啥？其實我很反感“例會”的這個“例”字，一旦帶上這個字，就很容易認(rèn)為這是例行要做的事情，這樣就很容易導(dǎo)致我們走形式，而忘記了為什么要開會？
不過話說回來，前面提到的“每周例會”個案已經(jīng)不算很差的了，一些項目的每周例會說的事情是：本周干了啥，下周準(zhǔn)備干啥。變成了工作匯報會議！如果遇到這樣的會議，我會直接開罵：你這項目經(jīng)理干什么吃的？大家干了啥你平時不知道嗎？下周要干啥，你事先沒有規(guī)劃嗎？
為了避免走形式，下面開始我不會用“例會”這個詞，為了讓你們的會議效率更好，建議不要用“例會”這個詞，你甚至可以考慮將會議室改名為“War Room”！每一次會議都是一場戰(zhàn)斗，是需要解決問題的！一位同事曾經(jīng)形容過會議給她的感覺，只有四個字：刀光劍影！會上所有與會者都會投入進(jìn)來，為了項目的成功各抒己見、據(jù)理力爭。沒錯，咱們要的就是這個效果！
作者：
張傳波
轉(zhuǎn)載請注明上述內(nèi)容，否則請不要轉(zhuǎn)載。
每日會議是這樣開的嗎？
極限編程有每日站立會議，SCRUM有每日晨會，那是不是每天開一次會就是敏捷呢？
有朋友提到他們也實踐每日會議，但沒啥效果。
我問：你們每天開會是不是說一下最近一天干了啥，接下來了一天打算干啥呢？
答曰：是滴……
那自然沒啥效果了，這樣就變成工作匯報會了，而且更嚴(yán)重的問題是：敏捷開發(fā)是今天計劃明天的事情，見一步走一步的嗎？
極限編程中的小版本發(fā)布，以及SCRUM中的Sprint（沖刺），其實就是一次迭代。在某一次迭代中的工作應(yīng)該是事先規(guī)劃好的，絕對不是見一步走一步的。每日會議完全沒有必要說那些大家都知道的事情，說廢話可不是敏捷的初衷。
每日會議應(yīng)該怎樣開？
每日會議應(yīng)該重點說以下有價值的內(nèi)容：
1.有什么問題、困難、風(fēng)險影響你當(dāng)前的工作，以致不能按照既定計劃進(jìn)行。
2.有什么問題、困難、風(fēng)險會影響當(dāng)前迭代的成功？
3.有什么問題、困難、風(fēng)險會影響項目的成功？
4.當(dāng)前計劃是不是已經(jīng)或者可能不合時宜了，需要立刻更新或改進(jìn)？
5.有什么做法或建議可以讓項目更加成功？
簡單說，每日會議主要是用來讓你提出問題、困難和風(fēng)險的。
每日會議可以讓問題隱藏不會超過24小時，并且可以讓你的工作及時獲得其他成員的支援！這是“白癡”也懂的道理：問題早一點暴露和解決，將會節(jié)省莫大的成本?？上覀兺菫榱斯?jié)省開會成本，日會變成周會甚至是月會，看上去節(jié)省了不少開會時間，但項目的問題就在你的姑息下滋生和蔓延，***可能會要了項目的命！任何項目都會存在大量的問題，如果說你的項目沒有問題，那么你要警惕了，沒有問題是***的問題！不是你的項目真的沒有問題，而是你們連發(fā)現(xiàn)問題的能力都沒有了！質(zhì)量是需要投資的，每天會議就是一種投資。
敏捷開發(fā)絕對不是今天計劃明天的工作的，要保證每一次迭代都能成功，那么工作就必須落實到每一天。每日會議是保證計劃有力執(zhí)行的重要手段，將項目的情況每天都可視化地展現(xiàn)在所有項目成員面前，讓我們一天一個腳印、踏踏實實地將項目做好。
讓項目組全體成員明白為什么要每日會議和如何每日會議，這樣每日會議其實很容易做到很有效的。每日會議無論是站著開還是坐著開？是早上開還是下班前開？要用白板還是用投影？等等這些都是形式而已。開門見山，抓住要害，必要時要做書面記錄。
每日會議進(jìn)階
在我的項目中經(jīng)常會每日會議，而且更變態(tài)時我會每半天會議！
我為什么要這么變態(tài)半天開一次會議呢？
1.每日會議雖然可以讓問題存在不會超過1天便暴露，但我仍然覺得1天的時間太長了，我受不了，最多半天我就要發(fā)現(xiàn)它！
2.中國教育制度出來的技術(shù)性人才，大多是悶頭苦干型，有問題喜歡自己解決，有想法不主動提出來。中國教育制度我無法改變，但我必須改變團(tuán)隊成員的這種工作習(xí)慣，那么半天會議會比每日會議更加有效。
3.項目的工作是爭分奪秒的，我的項目中的工作時間是精確到小時甚至是半小時的。問題如果可以存在一天，那么一天中就很可能至少會有2-3小時的工作時間是浪費的，將來要返工的，如果半天例會一次，這種返工的時間就會縮短到1小時內(nèi)。
我的項目加班的時間一般不多，很大程度是得益于每日會議甚至是半日會議。其實每半天會議不算什么創(chuàng)舉了，只要清楚明白你想要達(dá)到怎樣的效果，你就可以實踐出更多的***實踐！美劇《24小時反恐》，劇中處理某些突發(fā)事件時，那個反恐部甚至是每1小時一次會議！
開發(fā)人員需要長時間的獨立思考，你可能會質(zhì)疑：半日會議會打斷開發(fā)人員的思路，反而降低效率？你也可能會質(zhì)疑：項目的整個過程都需要半天會議或每天會議嗎？
這個問題很好！每日會議或者是每半日會議，并不會在我的整個項目周期中出現(xiàn)，我一般在以下情況才實施每日會議甚至是半日會議：
1.項目初期頭緒很多、隱藏問題很多的時候。
2.項目組成員提不出問題，無法迅速進(jìn)入戰(zhàn)斗狀態(tài)的時候。
3.軟件發(fā)布階段，不斷地發(fā)現(xiàn)bug和解決bug的時候。
除了半日會議這個變態(tài)做法外，我還有其他“另類”的做法：
1.突然會議
當(dāng)我意識到有危機或隱患需要立刻處理時，我會立刻召集項目會議。
2.任何人都可以召集會議
任何項目組成員遇到問題需要其他人支援，或者他預(yù)感到有隱患或危機時，不需要得到我同意，可立刻召集項目組全體或部分成員召集會議，他成為這次會議的領(lǐng)導(dǎo)！
其實道理很簡單，就是：發(fā)揮團(tuán)隊的力量，盡早發(fā)現(xiàn)和消滅問題！在萌芽狀態(tài)就消滅它，而不是等待問題發(fā)芽并壯大到不可收拾的地步。更加不是做鴕鳥，將頭埋在沙里，對問題視而不見！
回到原點——為什么要開會？
有朋友在群中提到，他們項目基本不需要開會，因為平時就把問題給解決了！
我覺得這實在是太牛了！說到底開會只是一種形式，問題是我們開會的目的是什么？如果不用開會能用更簡單有效的辦法達(dá)到開會的目的，那么開會干嘛？回到這個原點，我們自然就會處理很多項目中的問題，讓會議更加有效甚至不需要會議！
當(dāng)然有些溝通是必須通過會議來進(jìn)行的，目前可能我們暫時沒有辦法完全不需要會議，那么必要的會議是必須的！譯作會議的英文單詞有“meeting”和“conference”，你知道這兩個英文單詞有什么不同意思嗎？
meeting：參與人數(shù)不多，參與者聚在一起討論問題，每個人的發(fā)言權(quán)力是平等的。
conference：參與人數(shù)比較多，說話的人占少數(shù)，大部分人是聽眾。例如你參加什么過程改進(jìn)年會，我在上面演講，你在下面聽，那種就叫conference。
兩個詞的意義不同主要在于三點：
1.目的不同：meeting尋求各人的意見來達(dá)成共識；conference主要是宣講某些人的觀點。
2.參與人數(shù)不同：meeting參與人數(shù)不多（我建議不要超過7人，5人以內(nèi)最有效）；conference參與人數(shù)可以很多。
3.參與方式不同：meeting人人有均等發(fā)言權(quán)力；conference中演講者占主導(dǎo)，其他人是聽眾。
按照上述的定義，你可以看看你們項目中的會議是meeting還是conference？
如果你要打造自組織的團(tuán)隊，那么就必須賦予小組成員權(quán)力，讓你的會議是meeting而不是conference！而且在meeting中做到每個人都是主角！
后話：每日會議不會助長懶人歪風(fēng)？
有朋友提到：他們解決不了的問題都會拋給我，自己也不思考，搞得我頻繁救火，感覺很疲憊。
再進(jìn)一步深挖此問題，發(fā)現(xiàn)：這些項目成員是來自不同部門的，項目經(jīng)理基本上沒啥權(quán)力了管理他們，不能影響項目組成員的薪金、獎金和職位升降等。
也就是說：這個項目小組全體成員并不在一條船上！項目的成敗只與PM有關(guān)，與項目組成員基本沒有關(guān)系，項目組成員當(dāng)然是能少干就少干，能不干就不干了！
會議中提問題的目的是集合全體智慧來應(yīng)對這些問題，如果提問題的目的是為了偷懶，那根本就不是這個味了！這個團(tuán)隊建設(shè)或者說團(tuán)隊文化就超級有問題，在這樣的基礎(chǔ)上，其實無法實施任何敏捷實踐。曾經(jīng)在2011廣東過程改進(jìn)年會上，有朋友問到什么東西是最需要首先改進(jìn)的？我提出的觀點是：首先要做好團(tuán)隊建設(shè)，否則其他都是虛的；如果團(tuán)隊建設(shè)能做好，那么團(tuán)隊就能自覺解決很多問題，也很容易實施各種敏捷實踐，甚至打造屬于自己自己的***實踐。
本文關(guān)于每日會議及半日會議的實踐體會，是基于項目組全體是在一條船上的基礎(chǔ)上的。如果目前你的項目組還不能坐在一條船上，請參考umlonline網(wǎng)站關(guān)于團(tuán)隊建設(shè)的文章。
但要提到的一點是，項目組必須是相對獨立和有一定的權(quán)力，項目經(jīng)理應(yīng)該有一定的權(quán)力。至于SCRUM中提到的ScrumMaster有點項目經(jīng)理的意思，但他是沒有行政權(quán)力的，僅是充當(dāng)教練的角色。問題是：這樣的角色在國外可能適用，但在國內(nèi)如果你沒有任何權(quán)力，僅靠人格魅力來帶動團(tuán)隊，那要看你的RP了，看看你帶領(lǐng)的團(tuán)隊成員是不是都是人格高尚的了。
原文鏈接：http://www.cnblogs.com/umlonline/archive/2011/12/30/2307375.html
【編輯推薦】
