老翅寒暑

項目管理沙龍第二次聚會紀要

本次話題依然集中在敏捷方法和傳統項目管理的問題上，在兩次聚會之后，一些概念正在漸漸地清晰。

有人提出，如果傳統項目管理方法將敏捷的一些做法接受過來，是不是也會變得敏捷起來呢？在討論中大家發現敏捷的一些做法原本就是早已存在的一些通用的做法，例如頭腦風暴、集體評估story的點數、定期的回顧總結、團隊工作等，這些做法傳統項目管理方法也在做，但是為什么效果不如敏捷呢？關鍵還是在于敏捷和傳統方法的本質區別：后者認為人是需要監管的，需要一個項目經理去監督他們，不讓他們偷懶，并需要別人指導項目組成員如何去工作；敏捷的理念正好相反，它認為人是可以激勵的，項目組成員天然就有一種保質保量完成任務的愿望，管理者只需要引導他們。從實踐來看，用傳統方法管理項目，始終無法做好項目規模的評估和進度預測，但是在使用敏捷方法的兩個迭代內就可以輕松得到，這個也是我們敏捷實踐中得到的最讓人驚訝的成果。

傳統的項目經理需要很高的能力，他們首先需要能夠準確評估每個任務的規模，其次需要及時跟蹤項目的進度，還需要收集項目過程中的數據，以便進行評估和預測。另外，他還需要和客戶溝通，確保需求的穩定或及時提出需求變更請求，然后定期填寫一大堆的報告和表格，向不同的人報告 ... 。有人認為敏捷方法對項目經理的需求比傳統的方法還要高，而且這么“高”的項目經理幾乎是不存在的。可是只要去回顧實際的敏捷實踐過程之后，我們就會發現情況恰恰相反，敏捷方法對項目經理的要求是降低了。實踐中我們一個之前沒有項目管理經驗的人，在敏捷團隊的項目經理位置上做得很好。如果我們深入地思考敏捷管理方法，就會發現敏捷團隊的管理任務其實是分散到了每一個成員的身上，敏捷和傳統管理方法相比，就像是拿“分布式計算”和傳統的“單機運算”相比，結果也當然是一樣了。敏捷的項目管理力度其實比傳統的指令式項目管理方法要高，但是平均到每個人身上的管理任務卻比傳統的項目經理一個人要低很多。這不正是我們經常談論的“負載均衡”嗎？

與會的嘉賓們一致同意敏捷的一個缺點，就是容易“只見樹木不見森林”，認為敏捷團隊中依然需要有設計師這樣的角色去關注整體架構的實現和演進。

在談到人員能力問題的時候，我們提到了“檢查表”。大部分人都沒有關注檢查表這個東西，而事實上，檢查表是一個公司管理能力的直接體現。一個管理穩定的公司，必定有很多“檢查表”在支撐整個公司的運作。簡單地通過“檢查表”的形成過程，我們就可以了解到這個“檢查表”的價值所在。首先公司在實踐中得到的經驗，會以檢查表的形式沉淀下來，并且在實際使用過程中，會逐漸地改進，所以一個公司的檢查表肯定是最貼合這個公司實際運作的（因此檢查表拿到其他公司去也用處不大，這個也是檢查表不為人所知的原因之一了），隨后，檢查表的使用者只需要直接對照表格內容進行實施和檢查，最終就可以把事情做完，或者得到一個評估結果。而且，我們可以看到，檢查表的使用者其實并不需要是專家，只要不是文盲就可以了。專家在設計完檢查表之后，可以去做別的事情。

最后，我來談一點沙龍本身的問題。

本次沙龍的缺席率比較高，沒有通知就缺席的人數有兩位，也許是國慶長假即將到來的緣故吧。但是還是引出兩個問題，一個是共同話題如何提煉，第二個是如何讓這個聚會對大家產生實際的作用。但是歸根到底有一個問題需要首先解決，那就是需要激情和耐心。沙龍不會承諾給大家什么東西，“師傅領進門”，“修行”都要靠“自身”，何況一個小小的沙龍呢，它只是一個交流場所而已。

對于共同話題的提煉問題，我認為還是需要沙龍參與者之間的頻繁交流，要么是BBS，要么是即時通訊會議，或者干脆碰頭幾分鐘也可以，實踐中使用郵件討論的方式證明效率太差，達不到雙向溝通的效果。其次對于沙龍產生實際作用的問題，目前來看有如下幾種：集體閱讀，實際案例分析，提問。目前候選的圖書有《項目百態：深入理解軟件項目行為模式》，如果可以找到電子版，我們可以從中選擇幾個典型案例來討論一下實際的應對方式。