中??！與其要求團隊成員加班加點，還不如提高會議效率。我很認同Scrum對于會議時間的明確規(guī)定。例如Sprint的計劃會議保持在4個小時，而評審會議和回顧會議則保持在2個小時左右。至于Scrum的每日例會，更是短小精悍，只有15分鐘。是誰發(fā)明了“站立會議”這個名詞呢？發(fā)明者完全就是一位天才！改傳統(tǒng)的枯坐會議為站立會議，就可以收住那些夸夸其談、口若懸河的家伙了。在我的一個團隊里，就有這樣一個家伙，總是啰里啰唆，講了半天也說不到重點。我每次看到他要發(fā)言，我就有頭暈的感覺，甚至有一種沖動，想用膠布封住他的嘴。不過，在我主持會議的時候，我常常發(fā)現(xiàn)會議成員看我的眼神，有幾分熟悉。會議之后仔細思考，發(fā)現(xiàn)他們看我的眼神，和我看那個家伙的眼神竟然驚人的一致！Larry L. Constantine在《人件集》的“因地制宜”篇中寫道：“如果想要團隊工作獲得最大成功，會議的主持人和記錄者都應(yīng)該以局外人的身份參加討論會?！鳛檎麄€團隊的最高負責人，項目領(lǐng)導(dǎo)者應(yīng)該積極參與團隊中的討論和工作，而不是對工作指手畫腳?！瓡h應(yīng)該是在一種中立的氣氛下進行?！硪环矫妫萑霟o休止的爭論中，這時候，最好由項目領(lǐng)導(dǎo)出面中止爭論，暫時地放開當前的話題，或者很偶爾的，如果話題已經(jīng)進入了死鎖狀態(tài)，那么就由領(lǐng)導(dǎo)做出一個仲裁?！?/SPAN>

4、合理安排人手。

通常在我們面臨最后期限的壓力時，第一想到的是加班，然后閃入腦海中的念頭則是增加人手。加班策略素來為我所唾棄。以每人每日的生產(chǎn)效率來看，雖然加班可以延長工作時間，但長期的過度疲勞必然會降低生產(chǎn)效率，如此以時間換來低下的效率與團隊成員的抱怨，完全得不償失。在長期積怨的情況之下，開發(fā)人員會產(chǎn)生一種破罐子破摔的思想，心里認為反正都要加班，那么在正常上班情況下，反而會“磨洋工”，敷衍搪塞項目經(jīng)理安排的工作。那么增加人手呢？且不說這會增加項目成本，我們還要考慮團隊的新兵需要多長時間才能上戰(zhàn)場？業(yè)務(wù)培訓(xùn)、團隊磨合是新增成員必然存在的兩大痼疾。如果沒有處理好這兩個問題，不僅不能提高開發(fā)進度，反而會有拖慢或者打亂原有開發(fā)節(jié)奏的危險。另外，如果添加的新手不幸是一個刺頭或者“害群之馬” 呢？需要明確的是，往往在項目經(jīng)理提出增加人手的情況下，項目經(jīng)理并沒有親自挑選新成員的權(quán)利。這些新成員要么是閑置的，要么是其他團隊轉(zhuǎn)過來的，要么是新招聘的。考慮前面兩種情況，你覺得這樣的成員能夠達到及格乃至于優(yōu)秀的幾率會有多大呢？如果是新招聘的，那么拜托，趕快在心里多念幾遍“菩薩保佑”吧?？傮w而言，如果項目經(jīng)理沒有挑選新成員的權(quán)利，最佳的選擇是非到萬不得已不要添加成員。所謂“萬不得已”，即是無論如何改進，如何協(xié)商，如何提高效率，都無法達成既定目標的情況。

兵貴在精而不在于多。關(guān)鍵在于知人善用，以及合理調(diào)度。一個項目經(jīng)理在組建自己的團隊時，必須要了解自己成員的人格特點與技術(shù)特點。在理想狀態(tài)下，如果項目經(jīng)理具有挑選成員的權(quán)利，會具有更大的成功率。如果項目過大，那么必須建立層級式的組織架構(gòu)，而在劃分出的各個小組中，卻應(yīng)該以扁平的平等架構(gòu)為最佳。這樣就能夠自由而不失于集中，平等而又不至于缺乏效力。當然，具體的組織架構(gòu)應(yīng)依據(jù)企業(yè)文化、產(chǎn)品性質(zhì)、開發(fā)規(guī)模、團隊成員特點等各個因素綜合考慮，不能死搬硬套。在安排人手時，要注意對技能型人才和管理型人才的使用，注意對領(lǐng)域?qū)＜液拖到y(tǒng)架構(gòu)師的使用，注意對開發(fā)人員和測試人員的使用，注意對編檔人員、QA、配置管理員的使用。此外，還需要養(yǎng)成從容不迫的心理，即使最終期限火燒眉毛，迫在眉睫，仍然要保證對架構(gòu)的設(shè)計、對編碼的測試以及合理考慮產(chǎn)品性