|
|
| 首頁 | 討論區 | 最新話題 | 搜尋 | XML | 登入 |
 博客來購書 |
《主管這樣帶人就對了！》
貝殼鯨魚兒童程式啟蒙（點我去報名）
|
 |
Blueimp » 列出所有討論區 » 討論區: 專案管理 |
|
|
| 此話題中所有文章數: 1 [ 話題狀態: 一般 ] | |
|
專案執行計畫書(PEP)專案計畫書 Project Execution Plan, PEP定義： 沒有專案的計畫，就如同在大海中航行卻沒有航海圖 有計畫書才能讓你和你的組員有共同的目標，知道在什麼時候該做什麼事 沒有計畫書，你永遠不知道你的專案已經 delay 很多了 有了計畫書，你還必須定期的審視目前的狀態與計畫書的計畫差多少，當差很多的時候，你必須採取補救措施 計畫書是大家一起討論並且同意的 有計畫卻沒有實現，比沒有計畫還糟糕 需要定期的去審視計畫的內容是否正確合宜，並適時的修改計畫書 當修改計畫書時，記得要做好版本的控管以確定大家拿到的計畫書是最新的 專案計畫書發展的意義 專案?因應在推動時有一執行的依據及有一評估與審查的「基準」，必須於規劃時提出一份書面的專案計畫書 ，以明確定義並敘述專案計畫、執行、控管、結案等之管理程序與作業 專案執行過程中需對專案計畫予以運用、管理及更新，並要能充分而適時顯示出專案的進度與現況 專案計畫書的作用 指導專案的執行 記載專案計畫的假設及限制事項 記載專案計畫對備選方案選擇之決策 明訂專案利害關係人間之溝通方式 定義重要里程與審查計畫表 提供專案執行與控管的基準 專題計畫書至少必須包含以下內容： 專題題目 動機、目的、特色、功能、做此專案預計的學習成效 所需用到的技術 預計的工作項目、工作分配、規劃的時程 預計採用的工法（系統發展的生命週期，例如瀑布式系統開發) 專題的成員、聯絡方式、指導老師 可能會遭遇到的困難、解決方法 資料的參考 專案計畫書格式 1.計畫緣起 2.限制及假設事項 3.執行策略及專案目標／任務 4.範疇說明(SOW, 產品範疇, 產品說明等) 5.專案編組及職掌 6.工作分解結構 7.時程管理規劃 --主要里程碑及目標日期 --主計畫時程圖 --甘特圖(可列入附件II) --網路圖(可列入附件II) 8.專案成本分析 9.成本基準分析圖(表) 10預算分配(表) 11專案人力需求分析 12風險分析，回應及管理 13專案控管程序及方法(含審查會議及報告等) 14附件(可視專案性質增減) --範疇管理計畫 --時程管理計畫 --成本管理計畫 --品質管理計畫 --人力運用管理計畫 --溝通管理計畫 --風險回應計畫 --採購管理計畫 IEEE 1058 專案計畫書建議（中文版） () 內項目表示學生應視專題的特性作適當的修改或移除。 1. 概述 1.1 計畫概述 1.2 計畫動機、範圍與目標 1.3 (假設與限制) 1.4 計畫成果與交付物 1.5 計畫時程(與經費概述) 1.6 本計畫書修改歷程 2. 參考 3. 名詞定義 4. 計畫組織 4.1 外部組織架構與介面 4.2 內部組織架構 4.3 角色與職責 5. 管理計畫 5.1 專案起始計畫 5.1.1 計畫預估 5.1.2 (人員招募計畫) 5.1.3 資源取得計畫 5.1.4 (教育訓練計畫) 5.2 工作計畫 5.2.1 工作列表與說明 5.2.2 時程規劃 5.2.3 (資源分配計畫) 5.2.4 (經費分配計畫) 5.3 (控制計畫) 5.3.1 需求控制計畫 5.3.2 時程控制計畫 5.3.3 品質控制計畫 5.3.4 報告計畫 5.3.5 度量資料收集計畫 5.4 (風險管理計畫) 5.5 (結案計畫) 6 技術規劃 6.1 開發流程模式 6.2 開發方法、工具與技巧 6.3 (基礎建設計畫) 6.4 (產品接受計畫) 7 (支援計畫) 7.1 構型管理計畫 7.2 驗證計畫 7.3 文件計畫 7.4 品保計畫 7.5 審查與稽核計畫 7.6 問題解決計畫 7.7 外包商管理計畫 7.8 流程改善計畫 8 (其他計畫) 9 (附錄) 專案計畫書查核表 構型管理 是否有版本編號？ 是否有修改歷程？ 是否有出版日期？ 內容是否完整 是否 follow IEEE 1058 的標準？ 是否清楚的描述計畫，目的，範圍，方法？ 是否描述專案大小估計的方法？ 是否考慮到成本的預估？ 是否包含明確的時程計畫，包含里程碑審查日期？ 是否包含溝通計畫 -- 學生與助教，老師的溝通方法，包含email, telphone, meeting 等。 是否交代工作分配？ 內容是否合適 計畫是否可行？ 工作計畫是否可以達成目的？ 計畫時程是否合合適？時程會不會太緊或太鬆？ 是否有規劃教育訓練或尋找具有相關知識能力的人參與？ 工作分配是否合適？ 承諾 是否所有的專案成員都看過且簽名確認 是否助教已看過並簽名？ 是否老師已看過並簽名？ (ps) 在v1.0 (baseline) 以前可以電子型態代替 - 即在末頁做一個虛擬的簽名欄，成員自己打上姓名表示簽名。在老師確認後請印一份加上個別的給老師助教存底。 http://www.dotblogs.com.tw/jimmyyu/archive/2010/09/05/project-execution-plan.aspx 上個月為了起一個案子，請部門內的PM擬了一份專案執行計畫(Project Execution Plan, PEP)，這份執行計劃裡頭會載明了專案的基本資訊、如何執行專案、如何管理專案等相關細節，大致上會包含以下的內容： 專案基本資訊 紀錄專案目標、範疇、專案經理、專案發起人(委製單位)、專案期間、專案預期成本、假設與限制等，大致上就是Project Charter中所記載內容的80%。 主要工作項目 專案執行過程中，會包含專案管理類工作(主要是PM的工作)、專案支援類工作(包含建構管理、QA、QC、教育訓練、重工等)、需求發展(取得需求列表、獲取內部承諾、外部承諾等)、系統分析與設計(SA、SD相關工作)、撰寫程式等主要工作項目的計畫，這部分可以參考專案的WBS。 專案里程碑 專案主要的里程碑，一般來說最少會有兩個里程碑，及啟動會議(Kick-off meeting)與驗收結案，這部分加上專案基本資訊，大致上就是Charter的內容了。 需求訪談規劃 紀錄專案中主系統、各模組的需求訪談對象、時程、負責人員、進行方式(面談、問卷等)、訪談要點(要獲得的結果)，這部分的重點在找誰談，以及要獲得什麼結論，通常需求的來源者很多，這份資料應該是要持續被維護的，因為需求提供人員可能會隨著專案的進行逐漸增加。 變更管理 記錄專案如何進行Change Manangement，針對專案管理需求(變更時程、成本、範疇)、客戶需求、內部需求(讓設計更靈活、更美觀等)我們如何處理這些變更，必須要記載由誰發起，由誰核可等相關程序。 專案組織與組織圖 記載專案的組織，記載了利害關係人、專案經理、專案成員扮演的角色與主要工作範圍，對PM來說，專案團隊最好是專案型團隊，PM可以管理到所有的人，大家只有一個共同的頭頭，那就是PM；如果是矩陣型的團隊，那Kick-off時的團隊成員承諾就變得異常重要，絕對要成員承諾在專案進行的時候必須要全力配合，否則將形成風險。 人力資源 從專案組之中做衍生，記錄每個人的稱呼、聯絡方式、因專案所需欠缺的技能以及補強方式，例如今天我缺乏了OOAD的技能，那就必須要註明如何補強OOAD的技能，是由老手帶領、開教育訓練課程還是到外頭上課等。 人員責任矩陣(ARCI) 記錄專案中每項主要工作的A(Accountable)、R(Response)、C(Consult)、I(Informed)人員名稱，這邊要注意的是R、C、I可能都有多個，但A一般來說只有一個。 專案監控與品質活動 記錄如何做專案監控？何時、何人來進行？要監控的項目？例如在第二個里程碑之前，為了讓專案走的更順，可能會定每週一次進度審查，有問題的話就進行矯正；進入專案中期，可能會改成每兩週進行一次；末期在改成每週進行一次，也就是說讓專案的監控更具有規範性，不會漫無章法的亂開會，而品質活動也相同，必須要定義何時、何人來進行品質活動，以確保專案的品質符合一開始定義的範圍。 驗證與確認(V&V) 註記每一項工作流程(可能會對應到工作產品)的驗證方式、負責人，例如軟體架構設計由系統架構師來進行驗證。 建構管理 定義專案各項基準中應該包含哪些內容，例如開發基準可能需要包含系統設計規格、原始碼；產品基準可能包還原始碼、產品文件等，除此之外還要註明建構管理員如何進行建構管理以及建構管理區的R/W權限表。 資料管理 記載專案開發過程中文件、原始碼、規格等資料的放置位置，作為專案開發時的依歸，也避免大家將資料擺放在不同的位置或者隨意放置，到時候要找尋相關文件時會變得非常麻煩。 資源需求 包含專案管理、需求管理、議題追蹤、開發管理、原始碼管制、建構管理等相關工作衍生出來的資源需求，包含軟硬體。 專案工作環境 成員的工作環境，例如使用Windows 2008/SQL Server 2008/Office 2007/VS 2008等，一般來說專案成員必須要使用相同的開發環境才不會出現大家執行出來的結果不相同。 部署計畫 說明專案部署方式、部署負責人等，例如部署時應該使用特定工具、經由特定步驟來執行，且Production環境應只有部署負責人有權限進行操作，不應交由每個人來進行，會上到Production環境的通常是經過測試環境驗證過的程式，而非部署負責人本機或者開發人員提供的程式。 風險管理計畫 定義風險來源、說明風險參數定義(包含影響性、機率與可偵測性，而什麼叫『高』影響性、『低』機率，這些定義應該被記載)、風險回應人員、風險回應計畫與策略、專案風險清單、風險監控方式與頻率等等。 一份專案計畫應該包含以上內容，而因專案特性不同，每個專案都會再增加或者修改一些內容，以我們手上這個專案來說，大約有28個不同項目要規劃，對專案團隊來說，一份清楚的專案執行計畫非常有助於專案團隊溝通。 以上提供給大家參考參考。 ---------------------------------------- 支持小惡魔 BTC : 19tn3RnCuwZVukXAwyhDWZD4uBgUZoGJPx LTC : LTFa17pSvvoe3aU5jbmfcmEpo1xuGa9XeA 知識跟八卦一樣，越多人知道越有價值；知識最好的備份方法，散播！ 藍色小惡魔(林永傑)： 臉書 |
||||
|
