本文，是我對過去某個項目進行團隊建設的實踐總結，旨在為讀者分享我的經驗教訓。接手項目組時，項目組的軟件開發能力處於無序狀態，沒有任何管控措施，甚至連最基本的團隊規則和編碼規范都沒有制定。團隊沒有形成有效的合作，沒有明確分工，代碼質量低下。
一 經過半年的嘗試
| 事件 | 描述 | 好的方面 | 未解決的問題 | 經驗教訓 |
| 嘗試讓領導了解軟件研發的復雜與軟件構建的那些事情。 | 通過文檔，會議上的發言，電話的溝通希望能影響領導對軟件開發是認識。在領導的決策中，大膽提出自己的建議，並分享自己的項目經驗， | 領導對軟件項目與一般工程項目間的差距有所了解。能夠逐漸接受項目組提出的進度要求。 領導對軟件項目風險有了新的認識，不在盲目立項。 領導了解了項目團隊的基本組成和崗位分工，能夠傾聽PM的意見進行人員招聘。 |
領導對程序員職業定位和程序員的價值觀並不理解，對開發人員不夠尊重。 領導不理解軟件項目的管理原則，對項目插手過多，並時常作出破壞團隊建設的活動。 領導對質量不夠重視。 |
不要對“培訓”領導有太高的希望。工作之中的合理建議是必須的，但當領導不在傾聽你的聲音時，你們間的任何溝通都是無效的，那時即使你有滿腔抱負也無濟於事。 |
| 擬定編碼規范。 | 我的第一步就是擬定編碼規范，強調命名規則的重要性，命名的隱喻，並力求得到項目組的認同。 | 理解了命名規則的隱喻，並能更好地解讀代碼。 通過討論達成了一致的命名規則，並開始執行。 |
沒有績效考核機制，沒有代碼審查，程序員任然會踐踏規范。 | 在沒有代碼審查、團隊規范和績效考核的情況下，難以讓編碼規范得到強制實施。如果管理者被賦予的權力過低，連讓開發人員返工的權力都沒有的話，編碼規范形同廢紙。 |
| 制定進度計划並進行進度控制。 | 使用Project做進度計划，並進行跟進。 | 由於采用自底向上的方式安排進度，參考開發人員的主張調整，開發人員的責任感明顯上升，進度滯后現象有所收斂。 |
開發人員會為應付進度而縮減功能。 | 進度固然重要，但是質量不能忽視。必須結合質量來考慮進度情況，而非單方面地認為任務已經完成。 |
| 文檔標准化。 | 強調文檔的重要性，在項目實施中，有意識地申請編寫文檔的時間，並身先士卒撰寫的大量的技術文檔，幫助團隊理解需求、技術架構，提高開發效率。 | 開發人員已經形成文檔意識，並能撰寫部分文檔。 |
文檔內容風格無法統一，文檔規范難以在項目中推行。撰寫文檔的優劣程度不一。 | 必須有團隊規則和績效考核保證，自上而下的貫徹執行才能推行標准化。 |
| 推行SCM。 | 搭建SVN環境，培訓SVN使用，大力倡導版本控制的好處。 | 團隊成員基本掌握SVN的使用方法。 |
沒有按照指導規范使用SVN，版本控制雜亂無章。 | 沒有考核的培訓，效果不佳。 |
| 明確分工和職責。 | 通過內部討論明確成員分工，力求責任到人。 | 分工基本明確。 |
互相推卸責任。 | 在沒有追溯和績效考核的情況下，難以做到責任到人。 |
| 倡導技術學習。 | 向公司申請資料費購買技術圖書，提倡團隊成員在工作之外進行技術學習和實踐。 | 初期，團隊成員熱情高漲，看書並撰寫博客， |
后期，大多數成員不再看書或撰寫博客。 | 雖然本意是實現公司與團隊成員的雙贏，但多數成員更看中的是工資待遇，而不是技術知識。 |
| 明確技術方向。 | 嘗試建立願景並明確技術方向。 | 經過漫長的討論，明確了技術路線。 |
技術方向，無法被貫徹實施。 | 沒有一定的執行力，個人做再多的努力也無濟於事。 |
二 “演化”還是“革命”
一般，我更傾向於通過“演化”來緩慢地，進行變革。雖然，“演化”的周期更長，效果不那么容易凸顯，但是其能夠減輕團隊的震盪，並能夠得到高層的支持。我也在思考“革命”的做法是否會有更好的效果。當團隊成員已經形成一個個工作模式和習慣時，就很難讓接受不同的東西。我想，如果之前進行的是徹底的“革命”，從公司制度角度來強勢推行某些措施是否會得到不同的效果。
三 “人”還是“過程”
敏捷與CMM之爭已經持續很久，在我看來就如同魔獸世界沒有最出色的職業，只有最優秀的玩家一樣，這種爭論永無意義。
我一直在觀察，現實與理想。我發現，很多錯誤的東西正在成為主流，但錯誤的價值觀不應該影響到我們。
應付進度 不如 保證質量
溜須拍馬 不如 求真務實
推卸責任 不如 承認錯誤
加班趕工 不如 按時完工
雖然左側的人很多，但我認為右側的才是正確的。