當然，很多人可能覺得不以為然，認為csdn**首頁仍然很亂，頻道仍然很雜，我沒能改變什麼，還認為我應該為密碼門負責。我想說的是，csdn的確還有流量僅佔全站不到8%的部分(包括首頁)仍然很亂，但這個不是我短期之內能夠改變得了。至於密碼門，被掛馬拖庫是我入職csdn之前發生的，而我入職以後，即在當年8月果斷的清理了明文，並立即啟動passport產品重寫計畫，隨後在元旦上線新版passport，徹底解決了這個問題，若非如此公司會面臨更大的損失。如果非說我巧言令色，非要我背這個前任留下的黑鍋，我也認了。不過我從不覺得這些成績有什麼可以炫耀的，擦屁股的事情從來都不耀眼，更不容易邀功。擦屁股的最高境界是讓使用者不知不覺當中就把屁股給擦乾淨了，我沒能做到這一點，深感遺憾。不過說到改造團隊的經驗，自認為可以炫耀一下。
在之前自己創業的經歷當中，我的團隊管理能力就是一大弱點，經常無法調動團隊積極性而陷入個人孤軍奮戰當中。被csdn併購之前，收購方對我能力最擔心的也是團隊管理能力。兩年前我接手的團隊是公司公認最差的部門，人員也殘缺到只有15人；兩年後，我的團隊是公司公認最好的部門，人員擴充到了60人，而且部門員工離職率極低，團隊氣氛很融洽。團隊管理能力這兩年得到了質的提公升，回想起來，團隊管理中所有能遇上的問題都遇到過了，其中的磕磕絆絆之處數不勝數，完全是在實踐當中吸取教訓，所以《robbin談管理》的專欄，第一篇就是談改造團隊的經驗。去年寫過一篇部落格[url=我來csdn的這一年》[/url]，已經詳細的談了很多這方面的經驗和教訓了，這篇主要想補充一些當時的想法，也給自己做做總結。
一般來說新官上任三把火，新的高管空降之後往往會大肆招人，快速推進改革。但我在入職csdn之前就考慮過這個問題，以為宜緩不宜急，理由如下：
1、做為空降高管，在公司沒有任何根基，亦沒有做出任何成績來證明自己，這個時候領導的信任和授權是有限度的。一旦初戰不利，領導的信任度被透支，在公司恐怕難有立足之地，更遑論改造團隊，發揮自己的才能了。
2、我早年做過很多軟體諮詢專案，給很多公司講過敏捷開發、領域模型、物件導向建模和orm。但我能夠得到這些公司的信任，卻並非因為講這些時髦的內容，而是因為擅長解決各類技術上的疑難雜症，可以扮演乙個救火隊長的角色，對客戶公司的問題基本做到手到病除。當乙個公司出了**煩請你過去的時候，無論未來願景有多好，其實真正需要你的只有一點，就是讓你去滅火的。你不能快速滅火就沒有實用價值，無論你社群名望多高都扯淡。
因此剛到csdn的前半年，我相當沉得住氣，沒有招過乙個新員工，而是立足於穩定現有的團隊，止住繼續下滑的趨勢，給團隊到處滅火。之所以半年都不招人有3個考慮：
1、不想讓現有的團隊感覺一朝天子一朝臣，擔心自己在公司沒有發展前途，成為棄兒，而希望給每個人平等的發展機會。不招新人可以讓現有團隊心理比較安全，可以安心的好好工作，不至於發生更多的動盪。
2、我認為只有好的制度才能造就好的團隊，在沒有解決現有團隊的痼疾之前招聘新人，不但不會帶來新的生產力，反而會造成團隊更加混亂，應該先打下乙個好的根基，再招人才能事半功倍。
3、對現有團隊缺乏深入了解，對公司現有業務了解也不夠透徹，也不清楚現有團隊真正缺的是什麼樣的人才，在這種情況下招聘會顯得非常盲目，不如對團隊有了深入了解之後再有針對性的招人更有的放矢。因此儘管人事部門一再催促，我硬是壓著簡歷不看，拖了好幾個月，給當時負責招聘的人事mm帶來了很大的壓力。
其實我為自己當時沒有一上來就盲目招人而感到慶幸。因為後來我看到過類似的案例，空降的高管在沒有對業務深入了解，對團隊能力沒有深刻認識的情況下就從外面急吼吼招來了新的主管，結果新主管的業務能力和現有團隊匹配不上、配合不好，造成了新主管和老團隊的尖銳對立，團隊搞得一團糟。
解決團隊問題首先在於找到問題根本之所在，因此我入職後第乙個月就做了一件事情：對團隊進行深入的調研。從人事部門調集了每個員工的資料仔細研讀；對其他部門高管做訪談，問他們對本部門員工的印象和評價；給部門員工發自己寫好的調查問卷，要求每個人認真填寫；和每個員工進行面談，問他們認為公司問題在**；寫出來我對每個員工的印象和評價。
經過乙個月調研，我發現團隊混亂根源在於三點：
1、業務配合沒有建立合理的工作流程，工作目標既不清晰亦不明確，員工往往無所適從。
2、部門內部管理一塌糊塗，沒有清晰明確的管理制度，沒有合理的績效考核，沒有賞罰分明的獎懲制度，員工之間沒有交流和溝通，積怨很深。
3、跨部門之間的工作配合毫無規範可言，部門之間相互推諉，隨便什麼業務人員都會隨時給研發人員下命令，長此以往，傷害了研發團隊的積極性。
簡單的說就是：無業務流程，無部門管理，無規範協作。針對這三點我分別採取了相應的措施：
1、針對無業務流程的問題，我設立了產品團隊，親自兼任產品經理把所有產品都抓過來統一管理。無論部門內部還是跨部門產品研發，統一走產品設計流程，制定了規範的產品流程，強調以網際網路產品設計驅動整個產品設計，ui，研發和運營流程，將目前公司所有平台級產品開發統統規範起來了。關於這一點，在[url=我來csdn的這一年》[/url]有很詳細的介紹，不再多說。
2、針對無部門管理的問題，進行了部門組織架構調整，減少了部門管理層級，強化了自己對團隊的管理權。此外逐步建立和完善部門規範的管理制度，如：使用jira進行整個部門的工作任務量化管理；建立定期週會，週報和月報制度；我親自制定了部門績效考評內容、評分標準和獎勵等級；要求團隊間工作配合必須郵件書面確認抄送給我等等。關於部門管理制度的制訂，以後準備另外撰文來介紹。
3、針對跨部門無規範協作的問題，反覆在部門內部強調一條紀律：跨部門合作必須通過郵件得到兩個部門高管確認，口頭說的統統無效，拒絕合作；凡未通過我，未得到我郵件批准擅自去做的員工一律嚴懲。同時親自接管所有跨部門工作配合，事無鉅細都會親自來做。這半年我很少花時間和自己的團隊待在一起，反而花了大量時間和精力用來和其他各個部門的高管溝通和搞好關係。
其中特別想說說這第3點，在我看來如果跨部門協作的問題不解決，即便解決前2個問題也沒用。因為產品、研發和運營部門在公司的體系中不是直接創造收入的業務部門，而是承擔業務部門的服務者角色。作為乙個服務者，往往站在乙個被動和弱勢的位置上，很容易被業務人員舉著收入的大棒指揮你無條件的服從。這樣一來，部門內部無論怎樣合理的計畫都會被外部的力量輕易打破，讓員工無所適從。
我之所以親自接管所有跨部門協作，之所以花那麼多時間和其他部門溝通，目的只有乙個：充當團隊的保護傘，給自己的團隊創造乙個相對寬鬆和自由的工作空間，保護團隊不被外部的原因傷害到。
當時員工的工作積極性之所以不高，喜歡互相推卸責任，究其原因在於：員工的工作很被動，業務部門人員隨便指派任務，隨意變更需求，員工無所適從。好不容易按照業務人員的需求做好乙個東西以後，業務人員又隨意的否定做出來的成果，亂指揮且無計畫性，挫傷了我們部門員工的積極性。再者一旦這項工作最終沒有取得乙個預期的結果，責任又往往被推卸到我們研發人員身上。久而久之，員工就產生了自我保護意識，凡工作盡量往後退，凡責任盡量往別處推，不求有功但求無過。
為打破員工養成的這種自我保護意識，鼓勵員工更加積極主動做事情，我能夠做的就是把這些責任都扛在自己身上，親自去協調每項工作，讓員工沒有後顧之憂，讓員工相信我可以搞定他們擔心的事情，而一旦工作有成績，我會在員工月度績效考評當中體現出來。這也是為什麼我花了那麼多時間去處理和其他部門協調的原因。
通過半年的努力，漸漸贏得員工對自己的信任，這種信任是替員工解決乙個又乙個實際工作問題，並且堅持公平公正的給員工的工作成績考評帶來的；團隊也開始變得積極主動起來了，我的團隊管理制度也基本上定型了，後來只是不斷的強化而已。這半年儘管我已經徹底摸清團隊，對團隊改造已經拿出了有針對性的措施，形成了管理制度，但團隊畢竟還在起步階段，沒有什麼可以拿得出手的工作業績，所以當時連公司大老闆也覺得我動作太緩慢了，要求我動作快點。
這幾年，我根據自己的經驗，以及親眼看過的諸多案例，總結了乙個規律：[color=red]乙個新的高管接手團隊以後，問題將在半年之後集中爆發出來，而成績將在一年之後得以體現。[/color]
接手乙個團隊的前半年，往往還處在逐漸消除前任痕跡，打上自己烙印的過程中，在這半年無論高管多能幹，業績也不可能立竿見影。如果這半年能迅速出業績，往往不是因為你能幹，而是因為你的前任給你留下了乙個很厚的家底。
真正的挑戰來自於半年之後，前任的餘熱已經全部發揮完了，你的烙印開始打在團隊身上，而前任的痕跡還沒有消除乾淨，各種矛盾就會集中爆發出來，這才是真正考驗你的時刻。你能不能消化掉這個團隊，和這個團隊發生美妙的化學反應，全看這半年。
而到一年任期的時候，你合格不合適可以蓋棺定論了。要麼你已經改造了整個團隊，業績開始快速上公升；要麼你的團隊還是一團遭，業績沒有任何起色。
我前半年以穩為主，並沒有遇到什麼挑戰，業績也確實乏善可陳，真正的考驗都發生在半年以後，而產品改造的成績差不多都是在一年左右的時間開始井噴的。我也見過這樣的案例：高管空降過來的前半年恰逢不錯的外部環境，前任留下的家底也不錯，業績開門紅，上下皆喜。但是半年過後形勢大變，各種矛盾集中爆發，團隊動盪，骨幹員工紛紛離職，業績一落千丈。
所以我以為，前半年就出業績對空降高管來說不是什麼好事，這個業績本來和你無關，但是這麼快出業績非常具有迷惑性，讓你以為自己輕鬆的搞定團隊了，混不知下面矛盾重重，暗流洶湧。而且就算你當時能夠意識到問題，但由於有良好的業績，任何人都會猶豫要不要動手調整。而等問題在半年以後集中爆發出來，你再想著手調整團隊，已經錯過了最佳時機了，就算最終能夠解決問題，也需要付出巨大的代價。
在前半年已經打下了乙個良好基礎上，就可以大規模招聘新員工了。這個就留到下篇部落格再說。總結一下到這個階段的經驗如下：
1、剛接手乙個有問題的團隊，不著急上來燒三把火，要先對整個團隊做深入的調研，搞清楚整個團隊的核心問題在**，團隊的組成架構和運作方式，團隊每個成員的特點和能力，他們之間的關係，要徹底的摸清楚這個團隊過去成功的地方和失敗的地方，具有的優點和存在的問題。即首先做充分的調研工作，調研工作可以從公司上至ceo，下至每個員工方面進行一對一的談話。
2、找到核心問題以後，針對核心問題進行團隊微調和解決問題，但不能做大的手術，以安撫現有的員工，調動員工積極性為主，幫助他們解決實際問題，樹立他們對我的信任和依賴。這個階段基本上在到處滅火，解決團隊各種問題，目的在於取得員工的信賴，樹立團隊威信。
[url=談管理:改造團隊的經驗(2)[/url]
團隊管理小談
關於開發團隊管理的經驗與方法，網上確實很多，很多時候我看了之後都發覺很有道理，可惜在我的團隊中實施總是會碰到這樣那樣的問題，總結了這段時間辛苦的實施情況，發現有幾點需要自己做些記錄與累積的，以便以後可以重溫複習。1 溝通與執行 提高團隊的執行力，便於團隊更加容易獲得榮譽感與成就感，因此高效 便利 簡...
企業管理 深圳歸來談軟體企業團隊建設
剛剛從深圳回到北京，這次在深圳停留了13天，6年後再次回到深圳。13天裡，我用了7天和這家公司的四十多個技術人員逐一做了對話，短的也接近乙個小時，長的達到了3個小時以上。該公司的老闆人很不錯，目前公司內部情況較差，主要在於管理和工程過程上，很多東西沒有資料和制度可以依據，因此造成了較大的偏差，產品一...
產品版本改造中的專案管理
近段時間，一直在負責乙個產品版本改造 c s系統進行b s改造 的研發專案管理，在任務緊 時間短 團隊成員又沒有相關技術 silverlight 背景的惡劣情況下，我帶領包含我在內只有6個人員 5個研發人員，1個產品經理，產品經理在系統版本改造中主要精力投入到輔助市場部進行產品推廣去了 的超小型專案...