艱難的抉擇

今年三月份，我帶領開發的績效團隊終不免要到交付去，雖然是乙個妥協的結果--團隊中除了我之外所有的成員都過去了。過去的半年裡，銀行績效系統傾注了我所有的心血，此時雖有不捨之情，但卻為無奈的選擇，當然同時我希望並相信一塊去的團隊能夠很好地從我手中接替過去，願績效「專案」一路走好！

我總結了一下，績效團隊會有今天的結果，我自己會有這樣的選擇，有以下原因：

1、績效產品是跨部門合作的產品，進入開發之前沒有理順部門之間的功與累的關係，雖然訂單是交付做的，但需求分析和功能實現都是研發部做的，那麼到實施的時候該由誰來主導，專案的分紅研發部能夠佔到多少？這些根本利益一開始沒有落實，到後來就很難落實。

2、團隊中時有不和諧的聲音，這使我看不到團隊建設的希望，也是我萌生退意的根本原因。績效三線作戰，在上海的同事不了解專案現場的燃眉之急，現場的同事抱怨中心的同事不配合，所以，這種狀況，越到後來，合作的摩擦就會越大，而團隊自上而下，沒有人會圓滑的處理這種狀況。

3、績效的**決定權不在code teamleader，而且幾易人選漂浮不定，這是原因之一。

4、到後來，包括到上游的需求，也不甚嚴謹，這使我覺得績效的質量以後難以保證。

5、個人感情有時候會決定乙個人的選擇。

教訓：1、加強團隊建設，必須建立良好的合作氛圍，leader要在成員當中有一定的威信，這樣才能指揮動、協調好工作。

2、工作安排要合理，一定要鬆弛有度、知人善任，有表揚也要有批評，但不主張用罰錢的方式。

3、準備工作要充足，配置管理、**規範、資料庫設計都要盡早完善。

4、leader不能過多的參與編碼，而要更多地參與到需求的理解和管理當中，codereview要貫穿編碼的始終。

5、管理要自上而下，執行要自下而上，工作上不可能完全平等，專案經理要維護teamleader的權威。

6、多加強思想交流、技術交流。