近段時間，一直在負責一個產品版本改造（C/S系統進行B/S改造）的研發項目管理，在任務緊、時間短、團隊成員又沒有相關技術（Silverlight）背景的惡劣情況下，我帶領包含我在內只有6個人員（5個研發人員，1個產品經理，產品經理在系統版本改造中主要精力投入到輔助市場部進行產品推廣去了）的超小型項目團隊，終于在公司給定的時間范圍內完成了整個產品的版本改造。這其中經歷了需求變更、技術風險、人員變動等諸多問題，項目任然取得了成功，這種使用新技術的試驗項目能夠取得成功不得不說有幾分僥幸，更多的還是團隊兄弟之間的互相幫助、團隊協作。

　　在歷時3個月的產品版本改造過程中，經歷了大大小小的諸多問題，積累了一些經驗和教訓可以和大家分享。其中主要包括：需求、設計、研發、測試、實施、進度、風險、溝通、團隊管理等。由于剛涉入研發項目管理，很多方面都做得不到位，于此記錄下本次產品版本改造中的點點滴滴，在以后的工作開展中以此為戒，希望可以將項目管理做得更好。

　　大家都知道，無論什么項目都應該以需求為核心，分析、理解清楚所有的目標需求以及潛在的需求，以研發出一套能夠得到客戶滿意的軟件產品，那么項目就可以算是成功了。不同的項目環境的需求也是不一致的，就我這邊的項目情況，其需求主要體現在：成本需求、軟件環境需求、軟件功能需求等。

　　1）、成本需求

　　　　成本需求主要是在人力、物力、財力、時間等方面，項目團隊由6個人組成，在公司內部研發，給定三個月的時間完成整個產品版本改造，這對于人力、物力、時間的需求是明確了，研發過程中需要的項目成本公司全部支出，也沒有財力需求上的不足，在成本需求上公司提供了條件，以使整個產品版本改造工作能夠正常、順利的完成。

　　2）、軟件環境需求

　　　　軟件環境需求實際上也是屬于成本需求的一部分，只不過這里主要想說明的是站在研發側的軟件環境，包括研發場地、會議室、研發計算機、配置管理以及常用硬件設備和工具軟件。在項目啟動后對于產品版本改造的技術選型，公告技術對比，專家評比等多種方式確定下了最終的軟件環境，后續項目開發完全按照確定的軟件環境方案執行。這樣可以可以團隊組織上直接避免軟件環境的變更，唯一存在的風險就是對于研發所使用的技術熟練度，這可歸根為技術風險。本次產品版本改造所采用的研發軟件環境為：VS2010 + TFS + Office 2007 + ASP.NET + Silverlight + Oracle + PL/SQL。

　　3）、軟件功能需求

　　　　業界許多專家都說，一個項目能否取得成功，對于功能需求的準確掌控應該占項目工時的60%左右。不管架構設計、團隊建設做得多成功，對于需求的把控不準確，最終或許都會化為烏有。幸運的是本項目研發是從老C/S版本的穩定產品進行B/S版本改造，且該產品已經推出多年并在多個客戶現場實施，取得客戶的認可。對于需求的精確把控上不會出太大的問題，我采取了系統功能清單的方式，針對老系統現有的功能點進行逐個的列出，最后輸出產品功能清單表，具有如下幾個主要作用：

　　A、有助于團隊成員清楚知道產品功能點，避免需求偏差。

　　B、有助于技術經理制定WBS和研發計劃。

　　C、有助于測試人員進行功能點測試，確定測試是否覆蓋了產品所有功能點。

　　D、有助于產品經理及市場銷售人員，更加清晰軟件功能點，好針對不同的客戶需求選擇性的介紹產品功能點。

　　在版本改造中除了覆蓋老系統的現有功能，同時也推出了些新的功能模塊以及對現有功能模塊的設計改進，對于新的功能模塊需求變更的控制，采用大眾評審的方式進行，會議后確定出最終方案，后續的實際研發中發現了什么問題，重復發起會議評審通過同樣的方式確定一套可性的方案。

　　本次產品版本改造我們非常重視設計，包括架構設計和UI設計兩方面。系統技術選型為ASP.NET后臺 + Silverlight前臺，這對于系統前臺只需要后臺能夠提供穩定的通信接口就行，對于系統后臺的整體架構可以不關系其如何實現。鑒于多年來這套產品的實施情況來看，不同的客戶需求不一致，以及部署麻煩等諸多問題。老系統中采用了插件式架構的方式將不同的功能模塊進行系統功能組件化，以便能夠通過靈活的配置實現系統功能點的動態組裝，并采用了智能客戶端實現系統部署和更新。

　　新版本的產品也同樣采用了插件式的架構設計，包括系統后臺業務組件的插件化，系統前端插件化功能模塊組合。研發了一套基于MEF框架的Silverlight插件式架構框架，可以靈活的更具系統配置組合系統功能模塊，動態裝載模塊程序包并托管運行等。

　　對于設計管理工作主要涉及到架構設計管理、功能模塊詳細設計管理和系統UI設計管理三方面。

　　1）、架構設計管理

　　　　架構設計以安全、穩定、高效、 易維護、擴展等為導向，基于微軟MEF設計的插件式開發框架。通過不斷的優化更新，最后確定下最終的框架設計方案，輸出架構設計文檔并提交到配置管理，然后啟動框架的開發，測試。在具體的研發過程中出現了相關的變更通過會議評審確定變更后的解決方案，然后更新架構設計文檔并修改框架實現完善框架功能，整個過程中都有指派專人負責。

　　2）、功能模塊詳細設計管理

　　　　需求明確的前提下開展功能模塊的詳細設計是非常順利的，基本上和架構設計的管理差不多，首先確定下模塊的實現方案，然后編寫詳細設計文檔，文檔通過審核后提交到配置管理，然后啟動模塊開發。如有變更需要從走評審，重復前面的步驟，每個功能模塊都有指定直接負責人。

　　3）、UI設計管理

　　　　UI設計管理這塊的工作相對比較簡單點，基本流程也相差不大，首先確定下設計方案，然后再開展設計工作，如果設計出的UI效果圖沒有達到預期的效果或者對于前端開發人員來說比較難以實現，就將需求提交給美工進行修改。在設計過程中的步驟大致如下：

　　A：設計出主體界面框架效果圖，確定后由研發人員實現系統主體框架界面。

　　B：設計出通用的界面元素，確定后由研發人員將通用界面元素統一開發為通用用戶控件或者定義為系統樣式資源。

　　C：細化到功能模塊的局部，根據不同的模塊功能實現設計出大方、直觀、簡潔的界面，確定后由研發人員實現界面效果。

　　研發管理主要是在研發進度、風險、成本、質量、溝通以及團隊管理方面。首先根據系統功能清單劃分出WBS工作分解結構，隨后制定了研發計劃，在研發計劃執行過程中根據實際進度情況不斷細化WBS工作分解以及更新研發計劃。使用了微軟TFS做項目配置管理，并基于TFS展開項目管理工作，包括進度計劃，進度跟蹤，任務分配等，并讓團隊成員通過配置管理直接將分配給自己的任務同步到本地Project項目計劃文件中，一旦項目計劃發生變動便立即通知團隊成員更新項目計劃表。盯緊項目計劃，按照計劃有效的執行，從而在項目風險和成本上可以得到一定的控制。

　　由于團隊成員對于Silverlight技術的掌握程度不夠深入，同樣也存在著很大的風險和成本投入，技術層面上我采用的是培訓的方式來提高團隊成員的技術水平，集中培訓技術大體范圍，私下根據其負責的功能模塊對技術的需求情況單獨指導，以此來保證不同的人重點學習自己負責的功能模塊需要的技術點及某一方面的技術，不用團隊成員都將所有的技術點都學習一遍，從而縮短了學習時間，為整個產品研發直接降低了成本的投入。

　　對于研發過程中的產品質量管理也是非常重要的，項目啟動后我們項目團隊一起制定了一系列標準規范，包括數據庫設計規范、編碼注釋規范以及性能等其他規范。通過這些規范來約束項目團隊成員的研發習慣，避免出現個性化的特色模塊。其主要體現在數據庫表命名、字段命名、注釋模板、變量命名、界面元素命名、類，接口命名、代碼組織結構、穩定性、程序包大小等多方面。通過每周的代碼走查（Code Review）來檢查團隊人員是否按照規范在執行，沒有按照規范執行的要求立馬修改，在編程風格上形成一個統一的風格，對于他人接受項目模塊或者是后期的維護，都具有非常重要的作用。

　　團隊人員流動造成項目進度拖延，同時也會增加項目風險和成本，期間有一個員工離職，幸運的是從別的項目組及時的調配了一個人員補上，避免了因為人力的缺乏對項目的進度帶來影響。在整個研發過程中團隊成員之間討論問題也發生口頭上的爭吵，沒能達成一個統一的共識的情況，納悶的是組里面就有個一位老員工，時常因為討論問題因為意見不合而和新員工發生爭執，明明知道自己的東西存在問題也不承認的陳咬金。雖然作為項目的負責人，也是團隊的技術經理，某些時候也很難說話，為了解決問題不得不得罪人，針對不同的情況我主要采用了以下幾種方法：

　　1）、綜合評估團隊成員的方案，分析各自的優缺點，最終讓團隊成員一起總結出最佳方案。

　　2）、綜合評估團隊成員的方案，根據自己的經驗和對業務的熟練度，給團隊成員提出備選方案，最后讓大家評估選擇確定方案。

　　3）、團隊成員的方案都不可行，根據自己的經驗給出一套方案，強制項目團隊執行。

　　4）、出現溝通解決不了的問題，及時上報給領導，讓上層人員出面調解。

　　本篇內容為本人在項目管理工作中的真實記錄，以便在項目管理過程中遇到同樣的問題的朋友參考。同時歡迎廣大從事項目管理的朋友前來指點、交流，大家共同學習，進步。