1、手機項目管理流程目錄1 概述2 項目流程控制2.1 市場調研和項目定向2.1.1 采集用戶需求（見用戶需求采集分析部分）2.1.2 指定項目負責人2.1.3 合理組建需要的各個部門并指定負責人2.1.4 制定市場推廣計劃2.2 研究并確定技術方向，競爭對手資料收集2.2.1 確定使用的平臺，語言和工具2.2.2 整理可用的資源2.2.3 研究相應規范和標準2.2.4 比較競爭對手資料2.2.5 記錄項目資料2.3 制定開發里程碑和安排開發人員2.3.1 選擇開發模型2.3.2 安排開發人員2.3.3 組織項目進度跟蹤小組PTT2.3.4 指定易用性（用戶友好性）研究員2.4 用戶需求采集和分析

2、2.4.1 采集用戶需求2.4.2 需求變更控制2.4.3 生成規格說明書2.5 概要設計和原型設計2.6 數據結構，存儲設計2.7 功能詳細設計2.8 功能實現和功能測試2.9 集成測試和系統測試2.10 產品相關宣傳和產品交付2.11 回歸測試和項目總結2.12 技術培訓跟溝通附錄六考評規則跟獎懲制度附錄七需求變更控制附錄八進度拖延處理跟風險規避附錄九項目核心控制小組 PTT1 概述針對手機項目，其開發，流程控制和系統分析做出的相應項目管理規范。2 項目流程控制2.1 市場調研和項目定向2.1.1 采集用戶需求（見用戶需求采集分析部分）手機項目中由策劃人員取代用戶提出需求，交流相對方便但需

3、求變更量相對增加。對于軟件方面考慮用戶日常工作中相對繁瑣和需要重復操作的步驟， 對可以實現的用戶需求 和易用性的研究進行整理和記錄。2.1.2 指定項目負責人給項目指定一個總負責人來對項目開發、 經費控制、 人員管理、 進度掌握、 質量控制等負責。項目負責人需要具備能夠預先發現問題和解決問題的能力、 能夠團結和發揮項目中每個人的能力、 能夠很好的規劃和控制進度進行的能力和能夠對項目的質量進行嚴格控制和評估的能 力。2.1.3 合理組建需要的各個部門并指定負責人手機項目對于部門劃分相對要求較少，但是對于每個環節指定相應的負責人員是必要的。2.1.4 制定市場推廣計劃提前設計廣告及宣傳，做針對項目

4、特色跟潛在用戶的市場推廣計劃。可以采用大型活動， 與其他相關企業合作舉辦活動， 在網絡論壇上組織活動和媒體宣傳等多種形式。具體采用方式需要對投入，效果，活動規模等作出詳細分析后決定。根據產品特色和優勢制定相應的推廣方案，根據用戶特點制定相應推廣形式。媒體宣傳網絡宣傳與聯通移動合作與SP合作與手機開發商合作與高校合作市場成本 高 低 較高 較低 一般 較低效果 好 一般 好 一般 一般 一般面向對象 媒體用戶 網絡用戶 手機用戶 SP 用戶 手機用戶 學生附加收獲 與媒體建立聯系，知名度提升 打開網絡宣傳通道 與移動聯通建立聯系，知名度提高 寄售游戲，合作雙贏建立合作關系，提高知名度尋找，培養興

5、趣優秀畢業生待增加對于市場推廣部分， 由于曾經在中國移動經歷了移動跟Nokia 合作舉辦的手機程序大賽， 對于其運作模式跟部門有一定了解，可以根據需要選擇任何一方作為合作伙伴進行市場宣傳。另外， 大學校園是成本非常低的活動基地， 同時可以尋找培養優秀人才加盟。 舉辦適當新產品調研，游戲開發大賽和游戲大賽都是非常具有前景的。以上所有形式可以根據現有資金， 市場需要進行搭配組合， 可以同時啟動以達到更好的市場宣傳效果。另外對于開展形式和時機可以根據項目需要進行相應調整。2.2 研究并確定技術方向，競爭對手資料收集2.2.1 確定使用的平臺，語言和工具研究當前的新技術和開發語言、 項目管理工具、 版

6、本質量控制工具， 比較各種語言和工具的優缺點并整理記錄到對比表中， 根據項目特點、 人員和要求選擇適合的開發工具和管理工具。開發語言對比表Kjava Uni Java CC+ 待增加開發平臺 Moto OS CDMA 1x, 2x Nokia OS Symbian OS開發代價一般一般較低一般面向對象 Moto 聯通 Nokia Palm運行效率一般一般一般快運行穩定性穩定 穩定 很穩定 很穩定其它復雜度單項兼容 計費接口 MIDP 應用 單項兼容待增加采用的數據庫比較（穩定性主要考慮主流數據庫應用）： 手機數據庫不同于一般數據庫，其存儲量不會很大，一般使用rms。項目管理和質量控制工具比較（

7、可以組合使用）Project ClearCase Bugzilla CVS ClearQuest 待增加項目規劃 有 有 沒有 沒有 沒有項目進度把握有 有 沒有 有 沒有錯誤及修正記錄 沒有 有 有 有 有及時反饋交流沒有 沒有 有 有 有人員工作統計有 有 有 有 有其它優點 整體規劃 流程控制 錯誤處理 版本控制 錯誤處理待增加代 碼和版本控制工具：目前使用CVS者ClearCase ,需要以較低成本構建詳細項目體系時推薦使用CVS作為版本控制，加入 Bugzilla 作為測試控制工具。在資金允許的情況下， 比較推薦使用 IBM 的 ClearCase 和 ClearQuest 建立整個

8、項目控制管理體系。項目規劃和進度劃分推薦使用 Project 做前期進度設計。對于已經進行的項目或者發展中公司， 針對現有資源， 代碼進行整合的時候應盡可能的減少改動， 因地制宜的設定規范跟質量管理體系， 使已經適應當前開發模式的人員可以盡快適應新的健全開發體系并盡可能的減少由于變更帶來的問題。根據手機游戲開發的特點， 需要確定該項目是支持網絡功能還是單機游戲。 對于網絡又分為支持藍牙功能還是WA助能。對于單機游戲，需要在圖像，操作和存儲方面分層進行處理并整理可用資源。2.2.2 整理可用的資源利用所有可用的資源以提高開發的進度， 整理現有可用的資源和代碼， 并且查找相關的共享源碼和資源。 將

9、所有現有資源整理并找出可用的部分加以利用， 這樣不但能夠有效提高開發效率還能得到一些有益的經驗。例如增加模塊數據庫管理現有引擎， 復雜算法， 封裝好的模塊以便隨時去用， 開發過程中盡可能使用現有模塊降低成本減少錯誤的產生。2.2.3 研究相應規范和標準 研究當前領域內的國際和國內可能使用到的規范和標準， 整理并翻譯相應規范。 盡量使產品符合更多通用的規范，這樣也有利于以后的產品宣傳和產品升級。2.2.4 比較競爭對手資料收集領域內其它競爭對手的產品， 總結出其優越性和特點。 結合自身情況考慮實現代價取舍其中的功能點并增加自己的特色。 需要專人負責整理所有比較數據記錄進項目文檔中， 對于 市場宣

10、傳，功能點設計和市場推廣都將起到參考作用。2.2.5 記錄項目資料將根據上述資料討論確定項目使用的主要技術、 平臺、 開發工具和項目管理工具等整理記錄，記錄與競爭對手的比較資料和相關規范。2.3 制定開發里程碑和安排開發人員2.3.1 選擇開發模型根據項目工期、經費和其它需要合理選擇搭配開發模型。制定開發模塊，功能點，實現周期。2.3.2 安排開發人員根據需要安排開發人員， 記錄項目需要的總人員、 各個部門指定的針對項目的人員， 估算每個人的工作量和時間安排。 給每個人員進行相應的項目培訓使所有參與項目的人員對項目有一定認識，并收集各個部門的員工對項目的建議和意見。2.3.3 組織項目進度跟蹤

11、小組PTT項 目核心控制小組由項目管理人員從開發部門，設計部門，測試部門，美術部門中指定技術過硬的人員擔任。其中至少包括30的參與人員，項目管理人員還需要指定一名易用性研究員做項目各個階段的用戶友好性評估跟修訂。參與核心小組的是項目中的核心程序員，核心設計人員跟核心測試，美術人員。項目核心控制小組的主要作用是隨時監控項目進度， 增強各個部門對于項目進度的把握， 風險預測跟規避， 項目拖延處理機制， 項目里程碑控制， 技術討論培訓管理跟項目中所有問題的協商處理。2.3.4 指定易用性（用戶友好性）研究員指 定一個易用性研究員，負責研究市場上同類產品的易用性優缺點，控制每個步驟的易用性檢查工作并對

12、產品提出相應的改進意見和建議，確保產品的易用性。需要有一定積極性和創造性并熟悉用戶需要從用戶角度考慮問題的人員擔任， 可以是售前、 產品設計或者開發部門的人員，該員工需要參加PTT小組。2.4 用戶需求采集和分析2.4.1 采集用戶需求采用SRS模板、指明需求的來源、為每項需求注上標號、記錄業務規范、創建需求跟蹤能力矩陣、審查需求文檔、以需求為依據編寫測試用例、編寫用戶手冊、確定合格的標準。1. 繪制系統關聯圖，這種關聯圖是用于定義系統與系統外部實體間的界限和接口的簡單模型。同時也明確了通過接口的信息流。2. 創建用戶接口原型，當開發人員或用戶不能確定需求時，開發一個用戶接口原型。用戶通過評價

13、原型將使項目參與者能更好地相互理解所要解決的問題。 注意要找出需求文檔與原型之間所有的沖突之處。3. 分析需求可行性，在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。4. 確定需求的優先級別，應用分析方法來確定使用實例、產品特性或單項需求實現的優先級別。 以優先級為基礎確定產品版本將包括哪些特性或哪類需求。 當允許需求變更時， 在特 定的版本中加入每一項變更，參看需求變更。5. 為需求建立模型，需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、 不一致的、 遺

14、漏的和冗余的需求。 這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。6. 創建數據字典，數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。 在需求階段， 數據字典至少應定義客戶數據項以確保客戶與開發小組是使用一致的定義和術語。分析和設計工具通常包括數據字典組件。7. 使用質量功能調配，（QFD是一種高級系統技術，它將產品特性、屬性與對客戶的重要性聯系起來。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。QFD各需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現了會給客戶帶去驚喜

15、，但若未實現也不會受到責備1.1.2 需求變更控制由于需求變更是所有項目中最為常見也是代價最高的部分，所有CMM皺以上對需求變更做了詳細規定。我 們在處理需求變更時，對于必須變更的需求，經過項目核心小組討論決定后與用戶就詳細變更要求，所需要付出的時間或者資金代價進行協商，達成一致后在詳細規格說明書中由設計部門進行整體設計并考察其可能影響的模塊變更。開發部門根據設計做相應的更改，對于任何變更需要進行從功能測試，集成測試到系統測試的全 面測試。對于每一次需求變更在項目中需要有詳細記錄跟跟蹤，最后項目總結部分需要進行變更統計。需求變更詳細規格詳見：需求變更控制規范。1.1.3 生成規格說明書 最后生

16、成一份項目中最完整的規格說明書， 為設計、 開發、 測試提供參考并最終從中抽取出用戶使用說明書和其它終端文檔。PTT 小組評審、確定設計方案，文檔記錄。之后如果對設計文檔進行任何修改都需要經過PTT 小組的討論確定并詳細記錄修改原因、 修改日期、 修改人員等信息。詳細規格說明書應該包括所有確定需要實現的用戶需求功能點， 其分配人員， 預定完成時間，工作量，風險評估， 里程碑設定。針對每一個功能點需要有負責人，每周查看進度是否符合預定目標。功能需求是否有相應更改，詳細見需求變更控制部分。2.5 概要設計和原型設計設計圖標和用戶界面。進行概要設計、制作產品原型（美工和設計部門參與，開發部門協助），

17、提供給用戶并收集用戶反饋意見循環改進。2.6 數據結構，存儲設計利用現有企業對數據結構的詳細規范要求進行設計。 盡量精簡數據結構， 做到合理邏輯關聯，減少復雜度。數據存儲結構需要根據實際情況響應制定。2.7 功能詳細設計由開發部門完成的詳細設計包括了對功能點的詳細理解， 算法設計， 數據結構設計跟功能詳細流程圖。 所有部分應嚴格符合開發規范跟文檔規范的要求。 按照統一的文檔規范編寫詳細設計文檔，包含算法設計、流程設計和數據結構設計。質量控制部門對詳細設計進行考核和修改， PTT 小組對詳細設計進行評審。確定之后詳細設計文檔記錄，如果有任何改動需要經過PTT小組討論決定。詳細設計文檔作為測試和質

18、量控制考核程序質量的依據。2.8 功能實現和功能測試根據詳細設計和代碼編寫規范完成代碼編寫工作，實現各個需求中描述的功能點。對每個功能點進行測試。對所有代碼做易用性、算法復雜度和規范檢查。完成代碼文檔的編寫。編寫用戶使用說明。項目改進小組對開發流程進行監督和不斷改進。2.9 集成測試和系統測試由測試部門完成的集成跟系統測試需要在測試環境中進行。 將相關功能點聯調， 測試并修改。將系統集成，對系統進行硬件、軟件、壓力測試，對客戶端進行不同使用平臺，不同軟件版本的測試。利用錯誤控制工具記錄和修改錯誤。模擬用戶環境進行完整流程測試，邀請部分用戶或者潛在用戶參與beta 版本的測試。對于所產生的錯誤進

19、行等級劃分跟記錄， 每周對于所有錯誤進行項目跟蹤， 如果優先級較高可以臨時組織會議討論處理。 所有錯誤由項目管理或者開發負責人制定專人負責并隨時跟蹤沒有關閉的錯誤，保證代碼出錯率低于一定比率。對于出產產品出錯率嚴格限制。2.10 產品相關宣傳和產品交付根據產品特點和項目啟動時所制定的計劃進行產品宣傳和產品說明。發布相關產品專利和印刷產品。將產品交付用戶。2.11 回歸測試和項目總結進行回歸測試、迭代測試和相關產品升級。對項目進行總結， 記錄項目中所有可以重復利用的資源和經驗， 對一些對項目進度造成影響的事件和原因PTT小組進行分析和統計，記錄并為以后項目提供經驗。2.12 技術培訓跟溝通 項目

20、進行過程中要做到各個部門各個模塊的充分交流和溝通， 最忌諱的就是消息封閉和閉門造車，缺乏交流對于一個健全項目而言無疑是一種潛在的風險。項 目負責人需要根據實際情況安排技術比較過硬的人員針對各個部門技術算法難點，流程設計，接口設計等進行技術培訓，其他部門的人員根據實際情況參加培訓提出 疑問。項目剛開始進行的時候以總體流程為主要培訓主題， 隨著項目的進行， 逐漸引入美術設計， 模塊劃分，數據結構設計，算法實現，質量控制等方面的主題，確 保一個項目中每個部門都有人對于整個項目的進程和技術實現比較了解。對于培訓起到重要作用的人對于培訓人員進行業績記錄跟考評關聯以提高大家的參與熱情。員給予表揚。項目管理

21、人員在項目進行中要起到橋梁的作用， 隨時跟各個部門的人員進行溝通， 不但要掌 握項目每天的進度，而且根據情況要預知風險并進行規避。附錄六 考評規則跟獎懲制度一、程序人員考評規則程序員根據其代碼數量，質量，錯誤率，效率，業績，特別算法，溝通等進行每月考評，年度考評根據技術水平跟業績表現做整體考評。詳情參見開發人員考評指標。二、測試人員考評規則測試人員根據其發現的錯誤數量，級別， 業績， 溝通交流跟業務水平進行每月考評， 年度考評那個根據技術水平跟業績表現做整體考評。詳情參見測試人員考評指標。三、其他相關人員考評規則銷售人員有銷售部門制定詳細業績考核標準進行考評， 美術部門根據其工作量跟質量， 工

22、作反應及時度進行考評。項目整體考評根據項目進度，階段進度， 完成質量， 用戶反映等做出綜合評價，詳細考評指標參看項目文檔規范。附錄七 需求變更控制由于需求變更是所有項目中最為常見也是代價最高的部分，所有CMM皺以上對需求變更做了詳細規定。我 們在處理需求變更時，對于必須變更的需求，經過項目核心小組討論決定后與用戶就詳細變更要求，所需要付出的時間或者資金代價進行協商，達成一致后在詳細規格說明書中由設計部門進行整體設計并考察其可能影響的模塊變更。開發部門根據設計做相應的更改，對于任何變更需要進行從功能測試，集成測試到系統測試的全 面測試。對于每一次需求變更在項目中需要有詳細記錄跟跟蹤，最后項目總結

23、部分需要進行變更統計。需求變更詳細規格見需求變更控制文檔。附錄八 進度拖延處理跟風險規避由于需求變更， 技術實現， 個人原因導致項目進度拖延的情況存在于每個項目之中。 作為項目負責人， 需要能夠提前預知可能產生拖延的原因進行風險規避。 在已經產生拖延的情況下，需要預先設立解決方案及時啟動后備方案來解決當前的拖延問題。1 項目設計過程中對于時間安排要根據實際情況 （開發人員，測試人員，設計人員根據經驗對功能實現預期的實現時間）增加30的富余時間量作為緊急處理時間。對于無法按照規定實現的項目應該減少可能的功能，決不能削減測試時間來達到完成期限。2 對于需求變更詳見需求變更控制部分。 盡可能不改動需

24、求， 對于任何改動所需要增加的代價必須有完備的評估。3 技術實現拖延， 由于技術問題所產生的拖延可以考慮用其他技術取代比較難實現的技術細節或者根據實際情況用其他手段代替技術實現， 實在無法代替的情況寧可削減功能， 不能在一個技術難題上使用太多的時間跟精力。4 個人原因導致的進度拖延盡可能由項目管理人員協調解決， 幫助和鼓勵其按時完成， 趕上進度。 盡量避免在項目進行中更換或者安排接替人員， 交接培訓上手的時間會大大增加拖延導致項目不能按時完成。人員的增加會導致項目復雜度以幾何級數增長。附錄九 項目核心控制小組 PTT 項 目核心控制小組由項目管理人員從開發部門，設計部門，測試部門，美術部門中指定技