近段時間，一直在負責乙個產品版本改造（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）、出現溝通解決不了的問題，及時上報給領導，讓上層人員出面調解。
產品版本改造中的專案管理
近段時間，一直在負責乙個產品版本改造 c s系統進行b s改造 的研發專案管理，在任務緊 時間短 團隊成員又沒有相關技術 silverlight 背景的惡劣情況下，我帶領包含我在內只有6個人員 5個研發人員，1個產品經理，產品經理在系統版本改造中主要精力投入到輔助市場部進行產品推廣去了 的超小型專案...
專案管理和產品管理
本文翻譯至 專案 是為了執行新工作的交付手段。所有的組織裡都有專案。專案可以利用通用的專案管理流程來進行管理。專案管理 是指為了創造，擴充套件產品而使用的流程。另一方面 產品 是由專案創造的具體的東西。你從 商購買產品的話，該 商就是利用專案來構建這個產品。如果產品是臨時的東西，或者壽命很短，那麼那...
git專案版本管理
今天閒來無事 其實是不想動 就打算將最近學習的東西以基本專案案例的形式記錄實踐下來，但是，又不想簡簡單單寫個工程，所以打算自己還是像正規專案那樣，能有個版本控制工具，由於以前的專案都是用的svn，所以，這次我打算換一換，嘗試用現在主流的git作為專案版本管理工具。在想要放專案的資料夾 當前的整個路徑...