1、 項目管理計劃模板版本歷史版本號日期作者修訂原因0.1.02012-01-17Jerry Sun初始版本0.2.02012-02-14Jerry Sun增加了4.1、4.4、4.7章節的容，同時重新排版，使結構更加清晰0.3.02013-06-24Cherry Shen結構調整，添加發布，上線與附件0.4.02013-06-26Cherry Shen根據Review結果，文檔更新目 錄1目的42項目摘要42.1項目目標和圍42.2主要干系人42.3里程碑和可交付成果42.4約束62.5假設62.6項目組織結構73項目計劃73.1項目生命周期73.1.1生命周期確認73.1.2制定項目過程與產物

2、裁剪73.2工作分解結構73.3項目評估83.4開發計劃93.5資源計劃113.5.1知識和所需的技能113.5.2人員安排與分配113.5.3角色和職責113.5.4培訓計劃123.5.5軟硬件資源計劃133.6相關干系人員計劃管理133.7溝通計劃143.7.1每日溝通143.7.2每周溝通143.7.3每月溝通143.7.4隨時溝通153.8流程質量控制計劃153.8.1PPQA評審機制153.8.2PPQA檢查計劃153.9風險計劃153.10發布計劃163.11上線計劃163.12驗收計劃173.12.1項目驗收標準:173.12.2驗收項清單173.12.3驗收時間和進度173.1

3、3監督和控制計劃173.14需求管理184附件181 目的該項目計劃確定適用的政策，需求和軟件開發的數據交換的標準，文檔為完成開發工作定義了日程安排，組織，資源和必要的軟件活動進程。2 項目摘要2.1 項目目標和圍示例：Movitech 負責Eleven技術所需的所有資源.相關資源部門會和美國團隊和全隊職工協作來實現Eleven Pepperidge Farm 技術產品的成功交付。國的資源將會按照Eleven技術而在一個可接受的生產力水平和效率。該項目涵蓋Eleven Pepperidge Farm技術產品的所有新的功能、 bug 修復和修改現有功能和代碼的十一項技術產品有關的所有事項。2.2

4、 主要干系人示例:序號職位職責1Eleven Technology董事長兼首席執行官Tim Curran2Eleven Technology技術副總裁Vanessa Hang3Eleven Technology項目經理Vanessa Hang4Movitech首席執行官Tina Ji5Movitech首席運營官Charlie Chang6Movitech 項目經理Brad Cao2.3 約束與假設示例:序號約束條件1.管理上的約束。對Manager和pm來講，預算是最大的限制條件。2運行環境要求。例如：系統必須安置在一個已經加載了其他 EDX的平臺上。3資源方面的約束。如時間，人員方面；軟硬件

5、方面的要求。4質量保證方面的約束。如要求unit test。5.其他約束。6.所有工程師都可以在項目開始前到崗7.項目不會因為顧客反饋的意見而取消8.支持多語言，開發團隊現場開發。2.4 項目組織結構示例：3 項目計劃3.1 項目生命周期3.1.1 生命周期確認主要按照項目特征、項目類型或客戶的需求來確定項目的生命周期（如：迭代，瀑布，Scrum)。去認定我們需要根據項目的生命周期來做項目計劃。3.1.2 制定項目過程與產物裁剪詳細參考附件1：項目裁剪模板3.2 里程碑和可交付成果示例（瀑布式）:序號里程碑可交付成果交付日期負責人1.Story Board完成Story Board2005-4

6、-25Jacky Hu2.SRS 完成SRS2005-4-30Jacky Hu3.設計完成SDS測試用例測試計劃2005-5-18Kyle LeeCharles Di4.代碼完成BuildRelease Notes2005-6-30Kyle Lee5.Alpha 版本BuildRelease Notes2005-7-29Jacky Hu6.Beta 版本BuildRelease Notes2005-9-9Jacky Hu7.最終版本BuildRelease Notes2005-9-30Jacky Hu8.UAT完成BuildRelease Notes測試報告用戶手冊2005-10-10Jack

7、y Hu9.系統上線Build培訓資料2005-10-30Jacky Hu示例（敏捷式）:序號里程碑可交付成果交付日期負責人1.Story Board完成Story Board2.Backlog完成Backlog3.Sprint1完成BuildRelease Notes4.Sprint2完成BuildRelease Notes5.BuildRelease Notes6.UATBuildRelease Notes測試報告用戶手冊7.系統上線Build培訓資料3.3 工作分解結構通過WBS把模糊的工作逐層分解和簡化，為后續工作打下基礎，很好的解決現階段項目開發中存在的問題。在信息系統開發項目中創建

8、WBS的基本原則 任務原則：一個單位工作任務只能在WBS中出現一次；每一項任務只能有一個人負責；WBS中任意一項任務的容是其對應下級各項工作之和； 實際原則：WBS必須與實際工作任務的執行過程一致，分解后的工作應該是可管理的、可檢查的和獨立的，要符合項目團隊工作的需要； 時間原則：在任務的分解過程中，最小級別的任務最好控制在40工時，可以保證項目問題在兩周或更短的時間解決； 文檔原則：在任務的分解中，每個WBS項都必須文檔化，以確保準確理解已包括和未包括的工作圍； 靈活原則：WBS必須在根據圍說明書正常地維護項目工作容的同時，也能適應無法避免的

9、變更。3.4 項目評估（現階段暫時還是按項目經理本身的估算方法實現，后期跟進。評估人天大于100人天的需要組織部分有經驗員工集體review）項目評估流程參考附件2:項目評估流程項目評估方法與模板參考附件3-6：Project Estimate Template-Normal項目估算模板- Delphi項目估算模板-Analogy-Pert項目估算模板-Pert四種評估方法和模板任選一種進行評估。3.5 開發計劃Ø 開發計劃的每個任務需要小于等于5人天；Ø 任務明確，并可驗證；Ø 開發驗證的過程需要包括在計劃中。關鍵里程碑計劃可采用圖形方式。將項目的所有里程碑和關

10、鍵活動標注在下面的時間軸上。注意：如果存在早期功能子集Beta和/或ESP交付件，PDT 需要對交付件進行TR4A/TR5評審，以與對GA層產品交付件進行TR4A和TR5評審。PDT不需要對每一個構件標注TR4，只需要標示第一個TR4的日期。如果需要將所有里程碑和關鍵活動標注出來，可將時間軸劃分成階段：階段估計結束日期交付件驗收準則（可去掉）TR1（需求評審）和概念DR市場調研報告（立項階段輸出）市場需求清單（立項階段輸出）初始業務計劃（立項階段輸出）產品需求規格書TR2（總體方案評審）和計劃DR產品可行性分析報告/產品業務計劃產品開發計劃總體設計方案書/產品設計說明書產品測試與驗證計劃工藝總

11、體方案裝備總體方案初始物料清單供應商和物料選擇計劃物料認證計劃提前采購決策TR3（模塊級概要設計評審）模塊級概要設計/總體設計各模塊級測試報告目標成本跟蹤表市場教育和培訓計劃測試方案TR4（原型機評審）原型機原型機測試報告TR5（設計定型評審）中試樣機驗證報告制造系統驗證報告BETA測試結束BETA測試報告外部認證結束系統認證和標桿測試報告TR6（轉產評審）和發布DR產品可行性分析報告/產品業務計劃（優化后）市場發布材料清單受控銷售階段評估報告試產驗證測試報告制造系統驗證報告量產點GA量產檢查點確認通知3.6 資源計劃3.6.1 知識和所需的技能  必備的知識和技能所需人員數量滿意度

12、 (%)C+6100%Java270%VB2100%Oracle7100%PLM12100%Donet23Perl/Python223.6.2 人員安排與分配工作人員名稱角色開始時間結束時間投入比列%Dana DaiPM07-06-0512-31-0730%Michael ZhouDev Leader04-20-0512-31-07100%Jennifer WongDev05-16-0512-31-0760%Luke ZhongDev04-20-0512-31-07100%Johnny YangDev04-20-0512-31-07100%Moon ZhangDev05-19-0512-31-

13、07100%Morris LiQA07-04-0512-31-07100%Leopold WuQA07-04-0512-31-07100%3.6.3 角色和職責角色責任備注項目經理（PM）制定項目計劃定義項目過程管理項目日程項目資源管理器開發經理（Dev Leader）管理開發日程安排管理開發資源定義開發方法設計系統體系結構檢討 SDS技術培訓人員測試經理/負責人（QA Leader）管理質量保證計劃QA 資源管理定義 QA 和發布過程查看測試計劃和測試用例QA 技術培訓人員驗收軟件工程師（Dev）設計和編寫功能代碼測試工程師（QA）制定測試計劃與案例測試產品生成測試報告PC/PPQA協助項目

14、負責人完成項目注冊表的填寫并根據表上的信息在ProjectForge、JIRA和Confluence上立項CM根據流程中附件的容為相應資源配置ProjectForge、JIRA和Confluence的權限3.6.4 培訓計劃主題說明目標目標人員培訓時間時長備注Agile 產品高層次的介紹初步認識Agile產品所有新員工加入Agile85的第三周用1.5小時Michael trainsVSS/CQ 用法詳細介紹工作原理所有新員工新人加入Agile85的第二周用0.5小時Michael trains developers, Arnold trains QAs項目進程介紹所有員工07-10-0507

15、-10-05Michael train代碼樣式培訓全部開發人員加入Agile85的第二周用2小時Oracle & Agile DB針對全部人員全部項目組人員10-08-0510-08-05Moon trainsQA技術培訓所有QA05-23-0505-23-05Arnold trains3.6.5 軟硬件資源計劃資源名稱優先詳細配置購入方法和日期備注Agile Advantage SDK (6) 正常2005 SP2從中小企業獲得2005/04/26SftTree Control正常從IT獲得2005/05/26SolidWorks 2005 (6)高從IT獲得2005/04/22Se

16、rver (1)正常P42.4/2.4G/HD 160 GWin 2003 ServerOracle 8.1.7Agile Advantage 2005從IT獲得2005/04/27Desktop (8)高P42.4G/1G/HD 80GWin2K Pro SP4 (5)Win XP SP2 (2)VS6, MS Office 2000Rational Rose (2)從IT獲得2005/04/223.7 相關干系人員計劃管理 干系人 活動項目經理開發經理測試經理開發工程師測試工程師客戶IT客戶業務部圍定義項目計劃確認需求收集Story Board確認SRS確認項目進度監控UAT環境準備UAT

17、驗收報告簽字項目結項會議備注：u R：誰負責（R = Responsible）， 即負責執行任務的角色，他/她具體負責操控項目、解決問題。 u A: 誰批準（A = Accountable）， 即對任務負全責的角色，只有經他/她同意或簽署之后，項目才能得以進行。 u S:誰支持（S = Supportive）， 即提供信息資源，輔助執行任務的人員。 u C:咨詢誰（C = Consulted）， 擁有完成項目所需的信息或能力的人員。 u I:通知誰 (I =Informed), 即擁有特權、應與時被通知結果的人員，卻不必向他/她咨詢、征求意見。該活動主要針對需要客戶方參與的活動，可根據項目需要

18、自行添加。3.8 溝通計劃3.8.1 每日溝通序號方式工作容目標參加人備注3.8.2 每周溝通序號方式工作容目標參加人備注3.8.3 每月溝通序號方式工作容目標參加人備注3.8.4 隨時溝通序號方式工作容目標參加人備注根據項目自身需求，可調整各個溝通頻率。3.9 流程質量控制計劃3.9.1 PPQA評審機制Ø 實施審計PPQA根據PPQA檢查計劃，檢查項目實際執行過程和相關工作產品是否符合既定的規。Ø 記錄結果PPQA將不符合項記錄在PPQA檢查計劃-偏差明細列表中。Ø 協商糾正措施PPQA工程師與項目經理（或EPG Leader）分析不符合項原因并協商改進措施。

19、對于項目經理（EPG Leader）不認同的不符合項，PPQA工程師將該不符合項匯報給PMO，由PMO協商解決。3.9.2 PPQA檢查計劃詳細參見附件7:PPQA檢查計劃3.10 風險計劃序號風險管理圍風險管理方法/工具風險跟蹤頻率(每周/每月)1.技能方面的風險組織相關培訓2.設備（軟硬件）環境與IT溝通去落實3.需求通過訪談、原型、組織會議等多種方式去獲取需求并得到需求的確認。4.假期協調，延長休假的時間圍5.干系人風險加強溝通詳細參見附件8：項目風險跟蹤管理模板13.11 發布計劃該計劃特質外部發布計劃，部發布計劃見測試計劃。序號發布包時間標準環境功能&文檔對象責任人備注3.1

20、2 上線計劃序號步驟開始時間結束時間負責人備注1設備安裝2配置3數據遷移4數據初始化5培訓6上線支持3.13 驗收計劃3.13.1 項目驗收標準:1) P1 缺陷 = 02) P2 缺陷 <23) 所有新提出的問題解決.4) QA 結束了所有測試.5) Agile接受sp的質量.3.13.2 驗收項清單序號驗收項列表狀態備注3.13.3 驗收時間和進度序號驗收物計劃驗收結束時間實際驗收結束時間驗收狀態備注3.14 監督和控制計劃監督和控制策略控制機制頻率負責人員風險風險管理計劃PM問題PM管理issues，項目人員在周會上匯報issues情況，如果有困難的問題，應與時提出。PM進度管理主

21、持周會，項目人員匯報工作狀態，PM對照項目計劃，如有需要則調整項目計劃PM產品質量單元測試，代碼審查，測試用例審查，測試所有項目人員項目圍管理缺陷少于100， HFs 少于5發布項目組相關人員管理相關人員管理計劃PM協作項目計劃開會PM3.15 需求變更管理每個客戶認可的需求變更都需要通過需求申請單填寫需求變更申請，保存在項目部的SVN中。需求申請單 如附件9。4 附件序號附件名地址附件1項目裁剪 s:/svn.movit-tech.:3690/svn/Organization_Standard_library/branches/項目模板庫/2. 項目管理/2.2 項目管理附件2項目評估 s:/svn.movit-tech.:3690/svn/Organization_Standard_library/branches/項目模板庫/2. 項目管理/2.1 項目評估附件3Project Estimate -Normal s:/svn.