關於「團隊建設」的反思

　　本文，是我對過去某個項目進行團隊建設的實踐總結，旨在爲讀者分享個人經驗教訓。接手項目組時，項目組的軟件開發能力處於無序狀態，沒有任何管控措施，甚至連最基本的團隊規則和編碼規範都沒有制定。團隊沒有造成有效的合做，沒有明確分工，代碼質量低下。

一 通過半年的嘗試

事件	描述	好的方面	未解決的問題	經驗教訓
嘗試讓領導瞭解軟件研發的複雜與軟件構建的那些事情。	經過文檔，會議上的發言，電話的溝通但願能影響領導對軟件開發是認識。在領導的決策中，大膽提出本身的建議，並分享本身的項目經驗，	領導對軟件項目與通常工程項目間的差距有所瞭解。可以逐漸接受項目組提出的進度要求。 領導對軟件項目風險有了新的認識，不在盲目立項。 領導瞭解了項目團隊的基本組成和崗位分工，可以傾聽PM的意見進行人員招聘。	領導對程序員職業定位和程序員的價值觀並不理解，對開發人員不夠尊重。 領導不理解軟件項目的管理原則，對項目插手過多，並時常做出破壞團隊建設的活動。 領導對質量不夠重視。	不要對「培訓」領導有過高的但願。工做之中的合理建議是必須的，但當領導不在傾聽你的聲音時，大家間的任何溝通都是無效的，那時即便你有滿腔抱負也無濟於事。
擬定編碼規範。	個人第一步就是擬定編碼規範，強調命名規則的重要性，命名的隱喻，併力求獲得項目組的認同。	理解了命名規則的隱喻，並能更好地解讀代碼。 經過討論達成了一致的命名規則，並開始執行。	沒有績效考覈機制，沒有代碼審查，程序員任然會踐踏規範。	在沒有代碼審查、團隊規範和績效考覈的狀況下，難以讓編碼規範獲得強制實施。若是管理者被賦予的權力太低，連讓開發人員返工的權力都沒有的話，編碼規範形同廢紙。
制定進度計劃並進行進度控制。	使用Project作進度計劃，並進行跟進。	因爲採用自底向上的方式安排進度，參考開發人員的主張調整，開發人員的責任感明顯上升，進度滯後現象有所收斂。	開發人員會爲應付進度而縮減功能。	進度當然重要，可是質量不能忽視。必須結合質量來考慮進度狀況，而非單方面地認爲任務已經完成。
文檔標準化。	強調文檔的重要性，在項目實施中，有意識地申請編寫文檔的時間，並一馬當先撰寫的大量的技術文檔，幫助團隊理解需求、技術架構，提升開發效率。	開發人員已經造成文檔意識，並能撰寫部分文檔。	文檔內容風格沒法統一，文檔規範難以在項目中推行。撰寫文檔的優劣程度不一。	必須有團隊規則和績效考覈保證，自上而下的貫徹執行才能推行標準化。
推行SCM。	搭建SVN環境，培訓SVN使用，大力倡導版本控制的好處。	團隊成員基本掌握SVN的使用方法。	沒有按照指導規範使用SVN，版本控制雜亂無章。	沒有考覈的培訓，效果不佳。
明確分工和職責。	經過內部討論明確成員分工，力求責任到人。	分工基本明確。	互相推卸責任。	在沒有追溯和績效考覈的狀況下，難以作到責任到人。
倡導技術學習。	向公司申請資料費購買技術圖書，提倡團隊成員在工做以外進行技術學習和實踐。	初期，團隊成員熱情高漲，看書並撰寫博客，	後期，大多數成員再也不看書或撰寫博客。	雖然本意是實現公司與團隊成員的共贏，但多數成員更看中的是工資待遇，而不是技術知識。
明確技術方向。	嘗試創建願景並明確技術方向。	通過漫長的討論，明確了技術路線。	技術方向，沒法被貫徹實施。	沒有必定的執行力，我的作再多的努力也無濟於事。

二 「演化」仍是「革命」

　　通常，我更傾向於經過「演化」來緩慢地，進行變革。雖然，「演化」的週期更長，效果不那麼容易凸顯，可是其可以減輕團隊的震盪，並可以獲得高層的支持。我也在思考「革命」的作法是否會有更好的效果。當團隊成員已經造成一個個工做模式和習慣時，就很難讓接受不一樣的東西。我想，若是以前進行的是完全的「革命」，從公司制度角度來強勢推行某些措施是否會獲得不一樣的效果。

三 「人」仍是「過程」

　　敏捷與CMM之爭已經持續好久，在我看來就如同魔獸世界沒有最出色的職業，只有最優秀的玩家同樣，這種爭論永無心義。

　　我一直在觀察，現實與理想。我發現，不少錯誤的東西正在成爲主流，但錯誤的價值觀不該該影響到咱們。

　　　　應付進度 不如 保證質量

　　　　溜鬚拍馬 不如 求真務實

　　　　推卸責任 不如 認可錯誤

　　　　加班趕工 不如 按時完工

　　雖然左側的人不少，但我認爲右側的纔是正確的。