整合管理
正式授權
正式場合
關鍵Stakeholder參與
具備權力者參與
書面記錄
專案啟動
Kickoff meeting
目的
宣告專案啟動
介紹專案成員與職責
說明專案範疇、時程、限制
說明專案里程碑
說明專案執行計畫
取得stakeholder承諾
參與人員
Sponsor
專案成員
客戶代表
需求提供者
承諾人員
技術架構師-->承諾沒有技術風險
開發團隊-->承諾需求都可以做到
委外團隊-->承諾可於規定的時限內交付產出
Sponsor-->承諾專案的成本會依計畫撥下來
關鍵人力-->承諾專案規定的時間內一定可以空出時間
承諾類型
充分承諾(確認可達成)
暫時性承諾(有議題待澄清但影響不大,可以先承諾)
下個專案再開發
無法承諾
行動方案
專案執行計畫(PEP)
參考blog
里程碑會議
里程碑為一個工作期程為0的項目
里程碑會議為一個專案的check point,確認專案是否進入下階段
PM報告專案狀況
團隊進行Lesson Learn
變更管理
變更6問
Who誰提出?
Why變更的原因?
What確切的需求是什麼?
Where評估影響的範圍有多少?
是否確認要變?
When何時進行這個核可的變更?
變更記錄
做或不做都要記錄
實獲值管理EVM
主要元素
計畫值(Planed Value, PV,又稱BCWS)
實獲值(Earned Value, EV,又稱BCWP)
實際成本(Actual Cost, AC,又稱ACWP)
主要指標
時程績效指標(Schedule Performance Index, SPI)
SPI=EV/PV
用來衡量時程進度
成本績效指標(Cost Performance Index, CPI)
CPI=EV/AC
用來衡量成本進度
正確觀念
SPI/CPI最常被用來衡量專案的績效
SPI/CPI為1代表最佳,過大或過小都代表預估不準確
SPI/CPI距離1太大時必須要思考重新規劃可能性,確保後續管理能準確
範疇管理
需求收集
需求訪談前置
定義客戶代表
定義訪談主題
方法
問卷訪談法
結構化需求誘導問卷
情境:需求人員數量多,需求過度發散
特性:可快速歸納共通需求
雛形法
情境:用在需求不明確、需求人員說不清需求狀況下
特性:更接近最終使用者想要的
腦力激盪法
情境:需求不確定下,針對特定主題做發想
特性:先發散,再收斂,主持人很重要
經驗法
情境:有過去案例可供參考
特性:由專家提出需求
工具
Axure塑模工具
UML
業務流程圖
需求分類
功能性需求
商業邏輯
資料結構
非功能性需求
效能
安全性
易用性
美觀
技術選擇
操作型定義
需求要可被定義才能被驗收
非操作型定義
很快(多少才算快)
很漂亮(每個人定義不同)
愈少愈好(那要多少呢)
客戶需求列表
範疇定義
什麼做?什麼不做?
原則:不能多也不能少
定義系統邊界
建立WBS
子項範疇相加=父項
需涵蓋日常工作
驗證範疇
交付物定義
交付物允收準則
查核表
需求追溯
需求>特性
特性>SA文件
SA文件>SD文件
SD文件>Code
控制範疇
問自己:你在做哪個工作項?
應避免
範疇蔓延(Scope Creep)
鍍金效應(Gold Plating)
時程管理
時間管理
技巧
列出工作清單
排定優先順序
一次只做一件事
減少干擾
善用零碎時間
將工作切細
決定工作優先順序
排序原則
強制相依
本質上就有優先順序
偏好相依
經驗或者最佳實務
優先順序四維度
重要且緊急(先做)
重要但不緊急(預先規劃)
不重要但緊急(避免)
不重要且不緊急(暫緩)
評估所需資源
資源種類
人力資源
內部人力
外部人力
軟/硬體資源
其他資源
人月神話
加愈多資源不見得可加快專案進度
專案時程不可用專案工作量/專案人數
評估活動時程
估算方法
類比估算
問專家
依經驗
參數估算
各個擊破
分類擊破
三點預估法(PERT)
(最短+4*最有可能+最長)/6
估算原則
單一工作項不超過2工作天,超過建議再拆
由最熟悉該工作者來估(或該項工作負責人)
反應真實(估算是要估的準,不是要考驗成員能耐)
要徑法
鬆時、浮時
正確觀念
專案上最長的路徑為要徑
要加快專案,應將資源投入到要徑上
要徑可能會改變,必須持續關注
關鍵鏈
成本管理
品質管理
人力資源管理
溝通管理
風險管理
採購管理