自述

        2016年6月進入公司以來，經歷了團隊從無到有，從三個研發，發展到目前13個，團隊分成後端、前端、android、IOS、運維。剛開始接手團隊，簡直一團亂麻，沒有規範，沒有技術儲備，沒有後備資源儲備，連HR都沒有，公司內部各種奇葩亂象都有。最大的感受就是公司戰略在不停的改變，對應的團隊建設也隨之改變。我在公司負責技術部，我在管理上只能算是新手，我們的流程也不規範，問題也是多多。到目前為止還沒寫過詳細設計，發版後代碼備份總是有問題，開發時間總被壓縮，外部事務所佔大於內部工作時間，這也是個教訓，下面我來總結一下經驗。

團隊配置

        每個技術都希望跟一幫牛人一起工作，然而一個全是牛人的團隊，對大多數人來說都只是夢想，我從業這麼多年想過無數次，卻一次都沒幸遇到。後來我放棄了，團隊固然要牛人，但是牛人也不是滿大街跑，對一個10多人的團隊來說，有4、5個精英就夠了，其他的用有點經驗的、經驗少的、甚至實習的都沒關係，這樣就能組成團隊梯隊。團隊梯隊很重要，核心功能必須要精英來完成，放手給沒經驗的也不安心啊。最重要的一點建設團隊的時候要考慮好對團隊有什麼樣的期望，產品不是一版就做完美的，初期只需要能推就行，所以有一兩個骨幹做核心，兩三個做做普通業務，至於更低的可以當半個人用，做些邊邊角角工作。

團隊培養

        團隊培養不一定就是技術能力提升，個人技術能力固然重要，但是一幫牛人在一起，也不一定能做出牛逼的產品，一個團隊最重要的是對所做產品的認識，只有認識到產品才不會做無用功。一個牛人對高併發有很深的認識，但是對產品意圖卻認識不到，讓他來做專案絕對會失敗，不是技術不行，是對產品認識不夠，專案初期能上線才重要，就算明知有高併發問題，對專案初期又有什麼影響呢，高併發和效能問題讓負載均衡去解決吧。能確定產品方向，就可以確定技術方向，技術培養方向決定跟產品方向一致，而且進度大致差不多，不要好高騖遠。團隊培養是要公司支援的，首先要有人，其次要花時間，在其次要制定制度，有獎有罰，但是大多數公司只有罰沒有獎，慢慢的培養就變成了形式，毫無價值。團隊培養可以提高效率，但是不是馬上見效，產品認識只能提高團隊穩定，對效率提高真心不行，其他硬條件上不來，沒幾天這種認同感就下去了，這需要花太多的精力去畫餅。

團隊分工

        每個人都是獨特的。一個產品技術面很廣，每個人熟悉的可能都不一樣，如何合理的分配是非常重要的，我們公司還好，因為所有人都是我面試的，我對每個人側重點都有一些瞭解。有一種人非常適合中小團隊，他們什麼都懂點，什麼都不太精或者只有一個點稍微熟一點，這樣的人非常適合專案初期，有一半這樣的人，至少專案初期幾乎零風險了，在初期要儘快補充精英進來，中期解決效能問題必須要精英。產品理解快的可以負責更多的業務，給他們更多的資源，專案理解慢的只能慢慢淘汰，很現實很殘酷。產品認識達到的情況下，在看技術水平，這樣產品出來質量才高，BUG才能更少。

團隊憂患

        管理團隊一定要有憂患意識，在什麼樣的公司做管理最輕鬆？規章制度明確，福利待遇不低於平均水，對待員工寬容的公司比較好做，也是我想象中的公司。如果這些都沒有，那麼要注意了，尤其在決策改變，或精英離職的時候。他們可能造成人員流失，甚至連鎖反應，對於中小團隊或沒有儲備資源的團隊來說是致命的。所以團建就很重要了，當然這需要公司支援，怎麼選擇仁者見仁了。

團隊規範

先說說這裡面我吃過的幾個虧。
        第一次，因為程式碼一個地方管理，服務掛了，怎麼也啟動不了，重灌都不起用，後來只能拿一個人的本地版本當最新版本，光技術內部就改了兩天，然後各種迴歸測試。後來聰明瞭，GIT伺服器上的程式碼有兩個地方備份。
        第二次，因為發完線上版本後沒有做程式碼備份，開發任務還在繼續，然後線上各種臨時改需求，都沒辦法馬上修改，只能放到下個版本中修改。後來每次上線都備份程式碼，線上修改用備份程式碼，提交後繼續備份，同時更新當前開發版本中的程式碼。

        第三次，BUG修改過程中，有幾次因為開發人員都不熟（開發的人離職了或已經沒法追究了），然後就開始踢皮球。這種問題，每個團隊可能都有，在士氣地下的時候，沒人願意改自己不熟的BUG，其實認真讀讀別人的程式碼都是可以解決的。後來制定規則，類似問題以獎勵方式，全部解決了。（需要公司支援）