隨著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，還須要非常多非常多的東西去總結去學習。先講到這裏。未完待續……

【項目總結】：怎樣做一個牛逼的Team leader？