【專案總結】：如何做一個牛逼的Team leader？

        

        隨著ITOO高校雲平臺3.1專案的結束，我們各種各樣的總結也被提上了日程。Java版本的所有開發人員和Donet版本的所有開發人員坐在一起進行了關於專案開發管理的頭腦風暴，雖然我只是Donet開發組的一個子系統——考評系統的模組開發人員，但是對於專案開發管理也有自己的一些思考和看法。

        眾所周知，作為一個Teamleader，是要考慮很多很多事情的，如何調動團隊成員的積極性，如何統籌安排團隊成員分工合作，使工作效率達到最佳，如何根據開發人員的技術水平、經驗以及個人性格等諸多因素為他們分配任務，以使總體的專案開發效率達到最優等等，都是我們要去認真思考，從而給出可行的解決方案。

        但是，我今天要談的不是這些，而是我作為一個開發人員在做專案的過程中所遇到的種種問題和切身體會去考慮如何做一個更好的Team leader。

        首先第一個問題是：如何讓新人快速的上手專案，順利的進行開發工作？

        這是一個我個人體會比較深的問題，因為我就是所謂的新人。在專案的初期，需要我們去了解專案開發所使用的系統框架，還有更為重要的是待開發系統的業務需求，這個是我認為比較難搞的。你可能會覺得奇怪，不懂需求，看2.0的需求文件啊。

        這又牽扯出另一個管理上的問題，那就是專案文件管理問題，說實話比較亂，因此很多人都選擇不看文件，直接看原型圖然後諮詢2.0版本的開發人員業務邏輯，再加上自己的琢磨，一點一點的去理解和實現。如果我們的需求文件和各種開發文件寫的比較規範，整理的條理清晰，那麼我們的開發人員就可以按部就班的去做自己的那塊的開發。

        其次，在開發過程中，我遇到了很多的問題，這些問題讓我對開發管理進行了思考，如何才能讓水平參差不齊的一線開發人員高效率的進行程式碼開發？首先我們要明確一個觀點：真正的專案開發目的不是學習，而是產品。我們沒有那麼多的時間去研究我們的專案中使用了哪些技術，為什麼用反射？WCF的好處是什麼等等。如果你心存疑惑，去找資料進行了解和學習，那麼我們的專案工期肯定要被耽誤。

        因此我的想法是，將專案開發所用的各種工具，比如VS，DBMS以及各種工具類軟體和外掛等都放在一起，並附上一份開發環境搭建手冊，然後將專案所使用的框架純淨版做好，並將在開發中所要用到的各種類庫版本統一，也隨框架放在一起，並附上一份系統框架使用說明，把這些東西放在一起，共享給所有開發人員，這樣一來，我們能夠很順利的開始做開發，而且可以規避在專案中引用不同版本類庫造成的錯誤，比如我在專案開發中不小心把EF版本更新到了6.0，導致我的服務端程式碼徹底混亂，最後不得不將SVN上的解決方案刪除重新上傳備份。

        另一個比較讓人頭痛的問題是——程式碼除錯，這個我個人認為是我們開發過程中最耗時的事情。由於每個人的水平不一樣，遇到bug到解決bug的時間也不同，這樣會造成一種現象，那就是除錯高手會不停的在各個位置上輪轉，給這個調完了又被那個叫去了，如此一來，光忙著到處除錯了，自己的開發也會被耽擱。對於開發過程中遇到的各種Bug，我的想法是建立Bug和解決辦法對映管理機制，就是我們把錯誤管理起來，當我們的開發人員遇到自己無法搞定的bug時，先去bug庫中尋找是否有對應的解決辦法，若沒有則請人幫忙除錯，解決之後將錯誤原因和對應的解決辦法寫入Bug庫，這樣我們的錯誤管理庫會越來越完善，到開發的後期，幾乎就沒有什麼問題能夠讓我們耗上半天甚至一兩天的時間去解決了。

        同時，我們也可以組建所謂的“平臺組”，由各種技術人員組成，比如框架的設計者，UI設計和除錯高手，以及各種技術的研究者，比如熟悉WCF、EF、WF等各種技術的人員還有Jenkins整合的高手等等，由他們組成機動組，負責所有開發人員在開發過程中遇到的各種問題，這樣集思廣益式的解決方案比較適合我們現在的情況。因為我們不是分層開發的，是按照業務邏輯線進行開發的。當然我們也可以嘗試一下分層開發模式。

        可能我寫的有些太細節化了，並沒有在網上看到的很多文章那樣，說一些高大上的什麼原則啦，規範啦等等，這是我作為一個一線開發人員，從我自身看到的問題和現象去思考如何做一個牛逼的Team leader。當然要真正的做一個牛逼的Team leader，還需要很多很多的東西去總結去學習。先說到這裡，未完待續……