# PMP專案管理證照考試重點整理 **Author:陳詰昌 Email: power.shell@gmail.com** 如有錯誤請告知~ ## 考試占比 | 項次 | 項目 | 占比 | | ----- | ------ | ------- | | 1 |人員 | 42% | | 2 |流程 | 50% | | 3 |商業環境 | 8% | | |總計 | 100% | ## 資格 * PMP訓練課程35小時以上 * 專案管理經驗 * 大學學歷以上:4500小時以上 * 專科或高中學歷:7500小時以上 ## 參考書籍 * 專案管理輕鬆學:PMP國際專案管理師教戰寶典 * 長宏PMP講義 * PMBOK Guide v7 ## 報名長宏 [長宏報名優惠](http://www.pm-abc.com.tw/list_course.asp?couponid=C2FFF749B0612937470D196805B1FE2CF49C2DCA0D499E6) # <font color="GreenRed">一、商業環境</font>  ## <font color="GreenBlue">1A.基礎</font> ### 專案 * 專案手法參照 2D #### 專案4特徵 * 專案是一種暫時性的努力,以創造獨特的產品、服務或成果。 <font color="yellow"> 1. 創造獨特產品、服務或結果(獨特且未曾發生過,即不重複的) 2. 時間限制(暫時性) 3. 驅動變更/變革(逐步完善的) 4. 創造價值 </font> * 專案與營運差異 * 專案:暫時性、獨特性工作,為達成組織特殊目標 * 營運:持續性、 重複性工作,為執行日常營運工作 #### 專案管理 * 定義:將知識knowledge、技能skill、工具tool和技術techniques,應用到專案活動上,以符合專案需求 1. technical project management 2. leadership 3. strategic and business management * 管理專案 * 識別需求 * 建立清楚可達成的目標 * 妥善處理利害關係人 * 平衡競爭性限制 * 六大限制 * 範疇、時程、成本 * 品質、資源、風險 #### 專案分類 * 內部專案 * 外部專案:協議或買賣契約 ### 擬定專案章程前投入的商業文件 #### 商業企劃書Business case * 在專案發起前,商業企劃是一項**經濟可行性研究**,用於了解專案的業務需求並確認效益 * 商業需求分析:證明了專案的必要性,並包含專案描述、範圍的高階描述、問題分析、財務分析和成功因素等資訊。 * 成本效益分析:從業務活動中獲得的可量化的淨收益,可能是無形的、有形的或兩者兼而有之。 #### 效益管理計畫書 * 專案實現效益的方式how和時間when * 制訂效益衡量(Metrics)機制 * 關鍵要素包括 * 目標收益(Target Benefits) * 策略校準(Stratgeic alignment) * 實現收益的期限 * 效益負責人、指標、假設、限制和風險 ### 專案評選方法 1. 現值法 2. 淨現值法NPV:總預期未來產生的現金流量折現值-投資成本 3. 還本期間法 4. 效益成本比較法 5. 內部報酬率法IRR:年化報酬率 ### 專案發起 #### 制訂專案章程ITTO * 輸入:協議或買賣契約 * 工具與技術: * 專家判斷 * 數據收集:頭腦風暴、焦點小組、訪談 * 人際關係與團隊技能:衝突管理、引導、會議管理 * 會議:要有共識、要有行動方案 * 輸出: * 專案章程 * 假設日誌:專案生命週期中的所有假設條件和限制因素 #### 專案章程 Project Charter * 專案發起的正式授權文件(高階、概略) * 正式啟動專案 * 授權PM規劃、執行、監視/管制及結束專案權力 ``` 1. 專案目的Purpose 2. 專案目標Objectives 3. 高階需求 4. 高階專案描述、邊界及關鍵交付標的 5. 里程碑時程 6. 預先核准財務資源 7. 整體風險 8. 利害關係人清單 9. 專案經理 10. 專案經理的責任與授權 11. 發起人 ``` #### 專案生命週期與開發手法(參照2D) * 生命週期:專案由開始到完成,所經歷一系列階段 * 階段:一群有邏輯關係的專案**活動**的集合,可完成一個或多個交付標的 * 交付標的 * 為完成某個階段或專案,產出任何獨特、可驗證、可驗收的專案中間產出的*工作包*及*最終產品* * 專案管理計劃書的組件 * 依照專案管理計畫書所完成的各項中間產出 * 依照專案管理計畫書所完成的最終產品、結果或提供的服務 * 工作包及產品須經內驗(驗證,正確性)與外確(驗收,可接收性) * <font color="yellow">三種開發手法</font> 1. <font color="yellow">預測式:瀑布式,以計畫為基礎手法</font> * 需求明確固定 * 按計畫進行過程嚴密控管 * 價值單一或多次交付、最終可見 * 專案經理帶領團隊 * 交付標的完成後轉移給客戶 2. <font color="yellow">調適式:迭代式、增量式,以變更為基礎的手法</font> * 需求技術不確定 * 每個迭代有相同時間盒限制 * 價值週期性交付、過程可見 * 角色 * 產品負責人管制價值主張 * 專案團隊交付工作 * 向客戶迭代或增量交付 3. <font color="yellow">混合式</font> * 前後關係 * 服裝設計敏捷式、服裝生產預測式 * 平行關係 * 敏捷式:迭代、站立會、回顧會 * 預測式:工作指派與進度追蹤 * 你儂我儂 * 預測式:橋梁硬體 * 敏捷式:橋梁軟體 ### 專案管理辦公室PMO #### 專案經理與專案辦公室關係 * 將數個專案<font color="yellow">集中與協調管理的單位</font>,主要工作在 * 管理專案間之分享資源 * 識別及發展專案管理方法論、最佳實務及標準 * 發展、管理及監控專案管理政策、程序及範本 * 協調專案間之溝通 #### 專案組織類型 1. <font color="yellow">支援型supportive</font>:制定最佳實務、方法論、標準和範本 2. <font color="yellow">管制型controlling</font>:使用規定的範本、表格、工具,透過稽核,監視專案管理標準、政策、程序和範本合規情形 3. <font color="yellow">指揮型directive</font>:直接管理專案或共享資源 * 敏捷卓越中心ACoE(Agile Centers of Excellence),又稱價值交付辦公室(Value Delivey Office):扮演推手角色,而非管理與監督專案 ### 組織專案管理(OPM):價值交付系統 * 透過單獨或共同運用<font color="yellow">專案組合、專案集、專案和營運管理</font>的策略執行框架,使組織能夠實現策略 * 為一個框架,其中組合、計劃和專案管理與組織推動因素整合以實現策略目標 * 專案組合管理就是將範圍相似的專案、計劃、專案組合和其他工作分組,並根據業務的策略目標權衡每個專案的價值。 * 專案組合管理還監控項目,以確保它們遵循目標並有效利用資源。 * 專案組合管理通常由具有多年專案和專案群管理經驗的高階經理負責。 * 專案組合(Portfolio)管理:實現策略目標,將<font color="yellow">專案(Project)、專案集(Program)、子專案組合(Subsidiary Portfolios)及營運(Operations)</font>視為一個整體以進行管理,與商業策略一致 * 專案集管理:以協調方式管理相關的專案、子專案集和專案集各項活動,以實現效益 * 專案管理:專案活動上應用知識、技能、工具和技術,以符合專案要求 * 價值交付系統創造出交付標的,交付標的帶來成果,成果實現效益,效益為利害關係人創造價值 * 內部環境影響:內部政策、程序、方法論 * 外部環境影響:外部法律、經濟、競爭環境 ### 專案組織結構 <font color="yellow">1. 功能性</font> * 專案經理權限最小 * 每個人都有明確上司 * 預算與資源都在功能經理 * 跨部門溝通須透過功能經理 <font color="yellow">2. 專案導向</font> * 依專案或產品別區別組織 * 專案經理權限最大 * 所有資源以專案為主 * 預算或資源都集中在專案經理 <font color="yellow">3. 矩陣式</font> * 弱矩陣 * 功能經理權限較大 * 平衡矩陣 * 兼有功能式與專案式的特徵 * 強矩陣 * 專案經理權限較大 * Colocation將專案成員集合在同一實體位置 <font color="yellow">4. 組合式</font>  ### 敏捷宣言Manifesto(4價值) <font color="yellow">1. 可用的軟體:有價值可運作</font> 勝於 完整文件 <font color="yellow">2. 客戶協作:互信</font> 勝於 契約協商 <font color="yellow">3. 人員與互動:個人、團體及溝通與協作</font> 勝於 過程和工具 <font color="yellow">4. 應對變更:變更是常態</font> 勝於 遵循計畫書 #### 12項原則(補充宣言) 1. 我們的首要任務是通過早期和持續交付<font color="yellow">有價值的軟件</font>來滿足客戶。 2. 歡迎不斷變化的要求,甚至是開發後期。敏捷流程利用變化來實現客戶的競爭優勢。 3. 經常提供工作軟件,從幾周到幾個月,優先考慮更短的時間尺度。 4. 業務人員和開發人員必須在整個項目中每天一起工作。 5. 圍繞有動力的個人建立項目。為他們提供所需的環境和支持,並相信他們能夠完成工作。 6. 向開發團隊內部和內部傳達信息的最有效和最有效的方法是面對面交談。 7. 可用軟件是主要衡量專案進度標準。 8. 敏捷過程促進可持續發展。贊助商,開發者和用戶應該能夠長時間地保持穩定的步伐。 9. 持續關注技術卓越和良好的設計可提高靈活性。 10. 簡單性 – 最大化未完成工作量的藝術 – 至關重要。 11. 最好的架構,要求和設計來自<font color="yellow">自組織團隊。</font> 12. 團隊定期反思如何變得更有效,然後相應地調整和調整其行為。 ## <font color="GreenBlue">1B.策略調整</font> ### 人才金三角 1. 工作方法:熟悉多樣化和創造性的方法來完成任何工作 2. 影響力/權力技能:影響力意味著利用權力和政治來完成事情的能力。 * 權力是讓人們做他們通常不會做的事情的能力,也是改變想法和影響結果的能力。 * 政治涉及讓具有不同利益的群體在衝突和混亂中仍能進行創造性合作。 3. 商業敏銳度:有效的決策制定,並理解專案如何與更廣泛的組織策略和全球趨勢大局保持一致 ### 組織的影響 1. 企業環境因素 EEFs * 企業外部環境 * 提示清單:PESTLE、VUCA * 法規環境、產業標準、市場狀況 * 企業內部環境 * 組織文化、組織結構、<font color="yellow">資訊科技軟體或系統</font> * 識別利害關係人流程中使用的企業環境因素的範例,包括公司文化、組織結構、政府或行業標準、全球趨勢以及資源和設施的地理位置。 2. 組織過程資產 OPAs:工作過程與程序及知識庫 * 第一類:專案政策、過程、程序和範本 * 組織圖、招聘與任職程序 * 組織用於進行工作(包括專案工作)的政策、指南、流程、程序、計劃、方法和標準 * 第二類:歷史專案資訊、組織知識庫 * 歷史專案資訊 * 組態管理知識庫 * 組織的標準、策略、流程和專案文件的版本和基準 ## <font color="GreenBlue">1C.專案效益與價值</font> ### 商業價值 1. 市場需求經濟利益 2. 業務需求 3. 客戶需要:新客戶 4. 社會效益 5. 環境考量 6. 改善:科技技術或過程等 7. 合規化:符合或遵守標準和法規 ### 商業文件 #### 企劃案 1. 商業企劃案:證明專案的合理性,並建立界限 * 成本效益分析 CBA * 效益成本比ratio可以稱為成本效益分析。 * 它是一種常見的效益衡量方法,它將生產產品、服務或專案結果的成本與組織在執行專案後將獲得的效益進行比較。 * 評分模型Scoring * 效益貢獻方法 Benefit Contribution 2. 效益管理計畫書:創造、最大化和維持專案效益的過程 * 說明專案效益被交付的方法與時間的文件,向贊助人或投資人解釋專案如何獲利或是投報率等,可視為專案的說帖 #### 專案選擇 * 專案選擇方法包括 1. 效益衡量方法 * 成本效益分析 * 現金流量分析 2. 數學模型(也稱為約束最佳化方法) ### 成本效益分析的5指標 * 企業衡量指標 1. 機會成本低 2. 回收期短(最不精確評估方法) * 財務衡量指標 1. ROI高 * ROI= 淨利/最初成本 2. 淨現值(NPV,Net Present Value)高 * NPV= PV-最初成本 4. 內部報酬率(IRR):投資報酬率 ## <font color="GreenBlue">1D.組織文化與變革管理</font> ### 變革管理 * 一種全面、循環、架構化的方法,用於將個人、團體或組織從目前狀態過渡到實現預期效益的未來狀態,通常被組織視為一項策略。如組織文化、組織導入敏捷手法等 * 與專案變更控制不同 * 變更控制是一個過程,用於辨識並紀錄與專案相關文件、交付標的或基準的修訂,然後進行核准或否決 ### 組織變革對專案的影響 * 評估組織文化 * 評估組織變革對專案影響,決定行動方案 * 評估組織變革對專案影響,提供建議方案 * 持續監視外部商業環境,對專案範疇影響 ### 組織變革需要個人改變 ADKAR * 察覺何處需要改變Awareness * 有意願支持改變Desire * 擁有如何改變的知識knowledge * 具有展示新技能和新行為的能力Ability * 強化並堅持改變Reinforcement ## <font color="GreenBlue">1E.專案治理</font> ### 專案治理 * 為了創造獨特的產品,用來指導專案管理活動的框架、功能、過程 * 專案治理委員會又稱專案指導委員會,負責指導與監督專案,並審查關鍵交付標的 #### 預測式專案治理階段的兩種關係 * 連續(前後) * 重疊(同時進行) #### 專案治理的審查點 * 預測式專案治理的審查點:階段閘門 * 調適式專案治理的審查點:迭代結束時 ## <font color="GreenBlue">1F.專案合規性</font> * 專案面對法規、政策、限制或標準(如品質與風險)有遵循與符合的需要 ### 合規性五個最佳實務 * 文件化:更新的合規性需求和風險 * 風險規劃:風險規劃中優先考慮合規性 * 合規性委員會 * 執行合規性稽核:正式的的過程 * 將合規性視為己任 ### 合規性委員會 * 由品質、稽核、法律、技術等專家組成,來審查與確保專案需求及成果有符合合規性的組織 # <font color="GreenRed">二、啟動專案</font>  ## <font color="GreenBlue">2A.識別並讓利害關係人參與</font> * 產出 1. 利害關係人參與計畫書 2. 利害關係人登錄表 3. 利害關係人參與評量矩陣 4. 溝通管理計畫書 ### 1.辨識利害關係人 #### 利害關係人 * <font color="yellow">(潛在)影響專案目標與(潛在)被專案影響的人</font> * 專案團隊外: * 公司組織內:治理機構、專案辦公室 * 公司組織外 * 專案團隊內 * 專案經理 * 專案成員 * 專案管理人員 #### 規劃利害關係人參與流程 1. 識別:先識別高階,隨著專案調整 2. 瞭解與分析:清單與資訊,組織職務、角色、權力、期望等 3. 排序:依據上述對行動方案排序 4. 參與:溝通方式 5. 監督:在專案生命週期確保利害關係人滿意 #### 利害關係人流程的產出 1. 利害關係人登錄表  * 內容(身分及評量) 1. 利害關係人 2. 身分背景資訊 3. 評估資訊:需求、期望與潛在影響 4. 分類資訊 * 內/外部、權力/關切/衝擊/影響、向上/向下/向外 * 利害關係人呈現分類4工具 1. 2D網格 * 權力power/關切interest * 權力/影響 * 衝擊impact/影響influence 2. 3D網格 * 利害關係人立方體(權力/關切/態度) *  3. 三環顯著模式(議題導向) * 權力power * 急迫性urgency * 合法性 legitimacy *  4. 4種影響力來自方向 * 由上方來:高層管理階層 * 由下方來:團隊或專家 * 由外部來:客戶、終端用戶、組織外部 * 由側向來:同行、組織其他部門 2. 利害關係人評估網格  * 識別:大量蒐集資訊 * 分類並產生策略:行動方案(參與管理策略) * 參與管理策略 * 讓利害關係人參與 * 啟用適當管理策略 * 建立和維護關係 * 影響:提昇利害關係人的支持及降低阻礙 3. 利害關係人參與評量矩陣(SEAM)  * 參與程度分為帶領、支持、中立、阻礙與不明等五級 1. 完全不覺 2. 抵制 3. 中立 4. 支持 5. 領導 * C代表現在參與等級,D代表期望參與等級(管理策略) * 有差距要強化溝通,無差距則繼續監控(溝通需求) #### 規劃利害關係人參與 * 利害關係人參與計畫書(主要) * 溝通需求 * 參與評量矩陣 * 參與管理策略 * 促進利害關係人有效參與專案決策制訂與執行,定義所需的策略與行動 * 基本規則用於管理利害關係人的參與 #### 監控利害關係人參與 * 工具和技術 * 包括數據分析、決策、數據表示、溝通技巧、人際和團隊技能以及會議 ### 2.規劃溝通 * 規劃溝通管理->管理溝通->監督溝通 #### 規劃溝通管理 ##### A.溝通需求分析 * 溝通管道數,一對一,一對多,多對多及相互依存關係 * 溝通主題、頻率、模型與技術 * 產出表格,記錄每個利害關係人溝通方式與溝通技術等需求 ##### B.溝通技術 * 急迫性 * 可用性 * 容易使用 * 專業環境 * 資訊敏感性和機密性 ##### C.溝通模式中術語 * 編碼、訊息、傳遞形式、解碼等 *  ##### D. <font color="yellow">溝通方法</font> ##### 方法 * 推式:對特定對象發送 * 發電子郵件 * 打電話 * 拉式:大量資訊放於特定位置接收者自行存取 * 布告欄 * 參考文件資料庫 * 互動溝通式:有資訊交換溝通,一來一往 * 研討會 ##### 形式 * 會議口頭 * 實體 * 虛擬 * 電話 * 數位媒體 * 電子郵件 * 電話或即時通訊軟體 * 網站或社交媒體 * 實體 * 肢體語言與手勢 * 白板 ##### E.人際與團隊技巧 * 溝通風格 * 主動傾聽3步驟 1. 參與:身體往前 2. 跟隨:反問問題 3. 反映:確認無誤解 * 政治認知:組織政策與專案環境 * 文化認知:個人、團隊、組織對專案溝通策略的不同 #### 溝通管理計畫 * 產出:溝通管理計畫書(輔助利害關係人參與計畫書) * 專案資訊發布與交流 * 確保專案團隊與利害關係人的資訊流是有效果及有效率。 * 溝通5R 1. Right Time 2. Right Person 3. Right information 4. Right Channel管道 5. Right Content ##### 溝通技巧 * 溝通職能:促進團隊關係、資訊分享與提昇領導力 * 回饋:Coaching、Mentoring及協商等技巧 * 非語言 * 簡報 ##### 專案績效報告 * 收集與發布專案工作績效報告(WPR,Work Performance Report)、交付物狀態及時程進度給適當的利害關係人,也可運用實獲值的專案績效資訊 * 工作績效報告範例:現況報告與進度報告 * 實獲值圖表、趨勢線、預測值、燃盡圖、缺陷直方圖等 #### 專案溝通 * 本流程產出: * 績效報告、時程進度、簡報等一頁紙專案管理報告 ### 3.監督溝通 * 依據溝通管理計畫書,監控是否確實傳遞資訊給相關利害關係人,並是需要修正溝通管理計畫書,確保正確時間、將正確資訊傳遞給正確對象。 ## <font color="GreenBlue">2B.組建團隊</font> * 規劃團隊管理->獲得團隊->建立團隊->管理團隊 * 產出文件: * 資源管理計畫書 * 團隊章程 * 基本規則 ### 1.規劃資源管理 * 規劃資源(人、機、料)管理 * 資源(人)管理計畫書 1. 專案組織圖 * 科層式 * 矩陣式 * 文字導向 2. 角色與職責 * 預測式:有R&R * 調適式:無R&R 3. 用人管理計畫(獲得、解散、發展、表彰、訓練) ### 2.獲得(團隊)資源 1. 通過協商與功能經理要(內調) 2. 請Sponsor先行指派(固定班底) 3. 多準則決策分析:依照多面向考慮來篩選適合人才(外聘) 4. 虛擬團隊:不在一起工作,但目標一致 #### 專案團隊4特性 1. 自組織團隊 * 團隊為達成目標,自我決定要做什麼?何時做?怎麼做? 2. 跨職能團隊 * 成員各擁有不同技能 3. 通用型專才 * 成員不僅擁有特定技能,也擁有一般技能 4. 虛擬團隊 vs 同地團隊 * 集中型實體團隊:在同一地點辦公,溝通協作效率高 * 分散型虛擬團隊:在不同地點工作,善用科技工具促進溝通協作 * 混合型 #### 專案團隊組建類型 1. 預測式 * 專業職能分工 * 領導管理 * 科層式組織,有位階之分,也有明確角色與責任 2. 調適式特性 * 跨職能團隊 * 自組織團隊(願意試錯、價值導向) * 開發人員沒有位階之分,沒也明確角色與責任 * 通用型專才 3. 混合式 * 專案經理與團隊領導者進行集中式協調並負完成工作之責 * 同時有部分工作由自組織團隊當責 * 專案經理權責包含大於Scrum Master * 產品負責人為團隊成員,表達利害關係人需求,為產品負責與專案經理同時存在 #### 專案團隊形成五階段(Tuckman階梯理論) 1. <font color="yellow">形成階段forming * 初次見面、試探 2. 風暴階段Storming * 意見衝突 3. 規範階段Norming * 角色分工、開始依賴 4. 表現階段(自組織)Performing * 共同目標、協同合作 5. 結束階段Adjourning * 解散</font> ### 3.建立團隊(章程) * 發揮1+1>2 * 提高團隊合作、向心力、溝通技能、領導力等 #### 方法 1. 集中辦公colocation * 專案辦公室 * 利用儀表板或資訊散熱器 2. 溝通技術:衝突管理 * 制訂團隊行為守則 3. 團隊成長 * 審查會議 * off-site meeting 4. 表揚與獎勵 * 金錢:有形獎勵 * 表揚:無形獎勵 5. 個人及團隊評估 #### 團隊章程 * 團隊溝通細節文件 * 價值觀 * 績效 * 溝通和工具使用原則 * 決策原則 * 衝突解決 * 實務上於啟始會議來建立 * PMI價值觀 * 責任responsibility * 尊重respect:依專業進行回應與行事 * 誠實honesty * 公正fairness ### 4.管理(虛擬)團隊 * 管理成員績效、提供回饋、解決議題及管理團隊變更,使團隊最佳化 #### 方法與產出 1. 決策制訂 * 以目標為焦點、遵循決策制訂程序、分析可用資訊,達成共識,做出正確決定 2. 情緒智能EI * 識別、評估、管理、控制個人或他人情緒降低衝突與壓力,增進彼此合作 3. 領導 * 請跟我來 #### 權力種類 1. 正式權力:影響者的地位 2. 獎勵權力 3. 懲罰權力 4. 專家權力:高度專業知識,讓人信服 5. 參照權力:對管理者崇拜,如老闆的親戚,所以尊重其領導 #### 衝突解決方法 1. 退出/迴避 2. 調和/和解 3. 強制/指示 4. 協同/面對  #### 僕人式領導 * 透過專注於培養團隊成員並理解和滿足他們的需求,以產生最大可能的績效來為團隊提供服務的領導實踐。 * 促進而非管理 * 提供指導與訓練 * 移除工作阻礙 * 著重於團隊成就 #### <font color="Yellow">帶領虛擬團隊挑戰</font> * 難以追蹤個人績效 * 多元化:語言與技能 * 單獨工作影響凝聚力 #### 虛擬團隊基本需要 * 明確的目的 * 共同的目標 * 明確的角色和期望:當則與透明度 * 團結凝聚:團隊規範 ### 5.團隊訓練 ## <font color="GreenBlue">2C.建立專案共識</font> * 產出文件 * 團隊願景聲明 * 專案章程 ### 1.建立共識方法與文件 * <font color="GreenBlue">建立團隊共識與理解專案願景的4文件 1. 專案願景聲明 2. 專案章程(預測式) 3. 時間盒練習(調適式) 4. 極限程式設計隱喻(混合式) </font> #### 專案願景聲明 * 專案發起人或領導階層建立 * 對預期的專案目標所呈現的一種清晰願景,並校準組織的策略目的 #### 專案章程 * 每個專案都需要一個專案章程 * 作用與重要性 * 授權專案 * 將資源用在專案工作上 * 定義組織進行該專案的理由和商業需要 * 校準策略目的 * 讓每個人都有清晰專案願景 #### 時間盒練習(調適式) * 從客戶的角度內化願景,並著重產品或專案的價值 #### 極限程式設計隱喻 * 使用一般的語言或詞彙,以簡單、熟悉的術語說明複雜的概念 ### 2.啟動會議 * 目的 * 建立專案背景 * 協助團隊組建 * 使團隊和利害關係人與專案願景保持一致 ## <font color="GreenBlue">2D.確定專案方法</font> * 專案的開發方式、進行的節奏、生命週期的階段等相關活動與功能 ### 1.專案開發手法 * 專案方法或稱專案生命週期,在專案過程中用於建立及發展產品、服務或成果的手法 #### 3種開發手法 1. 預測式: * 計畫驅動、**階段閘門控制** * 專案分為多個階段,每個階段產出一部分成果 * 單一或多次交付 * 需求確定性高 * 可以變更但要管制 2. 調適式(迭代與增量):以Scrum及Kanban為主流 * 變更驅動、發布(Release)控制 * 產品可分多次發布,每次發布產出一個版本產品,每個發布劃分為多次迭代 * 每個迭代產出增量,逐漸累積為產品 * 週期性交付 * 需求不確定 * 高度變動 3. 混合式(考題最多) * 經裁適後的開發手法  #### 迭代與迭代式 * Iterative迭代式:最終一次交付的開發手法,不一定是調適式開發手法 * Iteration迭代:以Scrum為基礎的調適性開發手法的固定時間週期,兼具迭代式與增量式的特性 * 迭代式:每個迭代規劃或代辦清單精鍊會調整與細化產品代辦清單 * 增量式:每個迭代會交付已完成且驗收的增量 #### 專案選擇考量 1. 產品、服務或成果:需求確定、範疇穩定性 2. 專案:利害關係人、時程限制、資金等 3. 組織:組織結構、文化、組織能力及專業團隊規模 ### 2.專案角色 #### 預測式 * 專案經理:當責專案規劃整個專案生命週期工作 * 蒐集需求 * 記錄需求在 * 範疇說明書 * WBS * 建立時程、預算、資源、品質計劃書以交付需求 #### 調適式 * 產品經理人:當責一個迭代或發布中建立、排序與維護產品/發布待辦清單(Backlog) * 建立和精煉發布待辦清單 * 向團隊說明每個已排序的使用者故事 * 開發團隊:當責估算產品/發布代辦清單、建立與維護迭代/短衝代辦清單 * 估算所需投入effort並建立迭代基準,挑選符合預期之迭代速度的使用者故事 * 將產品待辦清單中使用者故事放入發布待辦清單 * 利用使用故事圖排序使用者故事,決定發布待辦清單中優先順序 #### 增量與迭代 | 項次| 需求 | 規劃 | 交付 | 著重 |劃分固定週期 | |---- |---- |---- |---- |---- |---- | | 預測式 |明確固定 | 一次 |最終一次 | |否 | | 迭代式 |動態 | 多次 |最終一次 | |否 | | 增量式 |動態 | 多次 |多次交付 | 速度 |否 | | 敏捷式 |動態 | 多次 |多迭代的小增量多次交付 |客戶價值排序 |是 |  ### 3.產品與專案 * 產品是專案的一部分 * 產品負責人負責最大化產品的價值 #### 產品生命週期4階段 1. 導入 2. 成長 3. 成熟 4. 衰退退場 #### MVP(Minimum Viable Product) vs MBI(Minimum Business Increment) * 最小可行產品:用最少的努力所能夠產出功能特性的集合,成為最基礎而可使用的產品,進而從客戶獲得最大的回饋,提供對未來產品方向有價值明確的資訊,不一定具有可銷售性。 * Idea、Prototype * 目的在試驗,需求不明確時可以發現客戶需求 * 最小商業增量:在產品或服務上所增加可以產生商業價值的最小增量。 * 已取得客戶實際需求,有清楚產品構想,用MBI得到價值 ### 4.Scrum * 常用的敏捷框架 #### Scrum的3角色 1. Product Owner 2. Scrum Master 3. Developers #### Scrum的4儀式 1. 短衝規劃Sprint Planning * DT與PO規劃短衝工作 * Scrum Master主持 * 產出迭代計畫與迭代代辦清單 2. 每日站立會議Daily Scrum * DT每日簡短會議 * 報告團隊進度、規劃與障礙 3. 衝刺審查Sprint Review/Interation demonstration * 短衝結束前舉辦 * DT、PO和利害關係人參加,或客戶審查進度,提供回饋並調整產品 4. 衝刺回顧Sprint Retrospective * 整個團隊針對迭代中人員、互動、流程、工具、產出及DoD等討論,提出需要改善事項 #### Scrum工件 * 發布計畫包含發布待辦清單、迭代計畫包含迭代待辦清單 1. 產品代辦清單:一份經過排列優先等級的利害關係人需求清單,表達產品所有可能屬性與功能 2. 發布待辦清單:團隊所規劃在某個發布期間所要進行與完成且經過排列優先等級的需求項目清單 3. 迭代待辦清單:團隊所規劃在某格迭代期間所要進行與完成的需求及任務 # <font color="GreenRed">三、規劃專案</font>    * 知識領域掌握 * 定義What * 作用Why * How: ITTO(Input、Tool&Technology、Output) * 輸入、工具和技術、輸出 ## <font color="GreenBlue">3A.規劃專案</font> * 專案管理計畫書(組件:子管理計畫書、基準、附加組件) * 為了交付專案交付物或成果,所需要的啟始、持續及演進的組織與協調相關的活動與功能 * 考量以下變數 1. 開發方式 2. 交付物 3. 組織需求 4. 市場狀況 5. 法規限制 ### 1.制訂專案管理計畫書 * 定義、準備與協調專案計畫所有組成部分,並整合為一份綜合專案管理計畫的過程 * ITTO * 輸入: * 專案章程 * 規劃過程產生子計畫與基準 * 工具與技術: * 頭腦風暴、核對清單、焦點小組、訪談 * 人際關係與管理:衝突管理、引導 * 會議:kick-off meeting(規劃結束前開)獲得相關方一致認可 * 輸出:專案管理計畫 #### 10知識領域+2管理計畫+3基準+4組件 * 10大知識領域組成:整範時、成品人、溝風採、尚厲害(指南型計畫 how) 1. 專案整合管理計畫 2. 專案範疇管理 3. 專案時程管理 4. 專案成本管理 5. 專案品質管理 6. 專案人力資源管理 7. 專案溝通管理 8. 專案風險管理 9. 專案採購管理 10. 專案利害關係人管理 * 2子管理計畫 * 變更管理計畫 * 配置/構型管理計畫 * 3大基準(實體型計畫) * 範疇基準 * 時程/進度基準 * 成本基準 * 其他組件 * 專案生命週期描述 * 績效測量基準 * 開發方法 * 管理審查 ### 2.指導與管理專案工作 #### 為實現專案目標而領導和執行專案管理計畫中確定的工作,並實施以批准變更的過程 * ITTO * 輸入: * 專案管理計畫書 * 批准的變更請求 * 工作與技術: * 專案管理系統 * 會議 * 輸出 * 可交付成果 * 工作績效數據 * 問題日誌:問題描述、責任人、解決期限 * 變更請求:糾正措施(維護基準)、預防措施(維護基準)、缺陷補救(品質) 、更新(修改基準) ### 3.調適式規劃方式 * 規劃是從不確定到確定的過程(湧浪規劃、逐步精進) #### 湧浪規劃法 vs 逐步精進 * 運用於工作包、規劃包和發布規劃的逐步精進 * 湧浪規劃法:對於近期要完成的工作進行詳細(detail)規劃,對未來工作進行叫高層級(high level)規劃的一種反覆規劃方法 * 應用於專案工作包、規劃包和發布規畫的逐步精進 * 適用於調適式或預測式手法 * 逐步精進:隨著掌握更多的資訊與更精準的估算,提高專案管理計畫書細節程度的反覆過程,資訊少high level,資訊多detail ### 4. 產品路線圖 vs 里程碑 * 是從高層規畫到細部規畫的過程(產品路線圖、里程碑) #### 產品路線圖 * 設想與規畫大局 * 產品策略與方向及要交付的價值 * 以總體產品願景為主導,並使用逐步精進方式來精煉願景 * 使用主題或目標提供結構和關聯 * 使短期與長期均變得可視化 #### 里程碑 * 定義:大事件、審查、付款或決策的標記(特定事件開始或結束的時間點,duration為0) * 建立者:由專案經理、客戶或兩者共同建立 * 里程碑清單 * 強制性:契約要求 * 選擇性:根據歷史資訊估算 ## <font color="GreenBlue">3B.範疇</font> 1. 範疇管理計畫書 * 如何定義、發展、監視、管制及確認範疇 2. 需求管理計畫書 3. 需求追溯矩陣 4. 專案範疇說明書 5. WBS & WBS說明表 6. 範疇基準  #### 產品範疇 vs 專案範疇 * 產品範疇:說明產品或服務的**功能特性與功能** * 決定專案範疇 * 產品需求文件 * 專案範疇:為了交付具某特定功能特性及功能的產品、服務或成果而**需要進行的全部工作** * 服務於產品範疇 * 專案管理計畫 * 範疇是固定還是變動? 看專案性質,建築專案是固定,行銷專案是變動 ### 1.規劃範疇管理 * 如何定義、確認和控制專案範圍及產品範圍,而創建範疇管理計畫的過程 #### 規劃範疇管理輸出 1. 範疇管理計畫書(Scope Management Plan):專案管理計劃書的組件,描述如何定義、發展、監視、管制和驗證範疇 * 無範疇,範疇在範疇基準 2. 需求管理計畫書(Requirement Management Plan):專案管理計劃書的組件,描述如何分析、記錄和管理需求 * 無需求,需求在需求文件 * 內容包含 * 需求活動如何被計畫、追蹤及報告 * 構型(Configuration)管理活動(變更啟動、衝擊分析、追蹤及核准) * 排定優先順序準則與過程 * 產品度量指標與該指標採用理由 * 可追溯內容的結構,包括需求屬性 ### 2.蒐集與排序需求 * 需求是一種產品、服務或結果的<font color="Yellow">條件或能力</font>,以滿足企業的需求 * 收集需求:判別、記錄並管理利害關係人的需要與需求,以達成專案目標的過程 * 需求?根據特定協議或強制規範,產品、服務或成果必備的 * <font color="Yellow">條件或能力</font> * 條件或能力的單一可衡量陳述 * 明確的(可衡量、可測試)、可追溯、完整的、一致的,且為利害關係人所接受 * 說明產品、服務或成果如何滿足商業需要 * 需求的類型 * 商業需求:專案緣由 * 利害關係人需求:又名報告需求(Reporting Requirement) * 專案需求:必須符合的行動、過程與條件 * 產品需求:功能特性(功能性)與特點(非功能性) * 品質需求:驗證交付標的 * 移轉/就緒需求:成功移轉到期望未來的狀態所需暫時性的能力  * ITTO * 輸入: * 專案文件 * 商業文件 * 協議 * 工具與技術: * 文件分析:從現有文件得到新專案需求 * 替代方案分析:執行專案工作可能潛在方案或手法 * 產品分析:詢問產品問題並形成答案,以描繪產品用途、特性與其他面向 * 專家判斷:分析所需資訊,以發展專案範疇說明書與技術細節 *  *  *  * 輸出: * 需求管理計畫書 * 需求相關文件:說明利害關係人與解決方案等個別的需求以及其優先等級 * 需求追溯矩陣: 一份從需求來源連接到交付標的,並在整個專案生命週期中,用以追溯需求變化的表格(記錄需求) * 把每個需求與業務目標或專案目標聯繫起來,確保每個需求都有商業價值 * 整個專案生命週期中跟蹤需求的方法  #### 蒐集需求常見方法 * 腦力激盪 * 訪談:請教有經驗前輩 * 焦點團體:專家進行話題鎖定討論 * 問卷方法 * 標竿比對:使用標竿比對產生產品需求 * 別人怎麼做? 別人做了什麼? 別人為何成功?  #### 資料分析 * 文件分析,包括協議、營運計畫、企業流程、市場文獻、議題記錄單、政策與程序等 #### 決策制訂 1. 投票表決 * 一致同意 * 獨裁 * 多數決(超過半數) * 複數決(相對多數) 2. 多準則決策分析 * 超過兩個以上參數需要考量,需要用矩陣來進行系統分析,找出最佳解 #### 資料呈現方式 * 心智圖(Mind Mapping):腦力激盪產生意見,整合至一圖形上 * 親和圖(Affinity Diagrams):大量想法的分類,以供審查與分析 #### 排列需求順序 1. MoSCoW * Must have * Should have * Could have * Won't have 2. 狩野模型 * 魅力需求:沒有沒關係,有了是加分 * 期望需求:客戶在意做越好越滿意 * 反向需求:做得好應該,做不好萬萬不該 * 無差異需求:無所謂 3. 配對比較分析 * 所有選項在一特定準則的基礎上互相對比,然後產生一份排序過的名單 4. 100點方法 * 每個利害關係人100點,透過點數投票選擇 ### 3. 定義範疇 * 從需求文件中選取最終專案需求,制訂專案和其產品、服務或成果詳細描述 * 描述產品、服務或成果的<font color="Red">邊界和驗收標準</font> #### ITTO * ITTO * 輸入: * 專案章程 * 專案文件:需求文件 * 工具與技術: * 數據分析 * 決策:多標準決策分析 * 人際關係與團隊技能:使用引導技能協調與對邊界達成跨職能共識 * 產品分析:把高層及產品描述轉變為有形可交付成果 * 輸出:<font color="Yellow">專案範圍說明書</font> * 專案範圍和產品範圍、必要的可交付成果、驗收標準、除外責任 * 明確說明哪些不屬於本專案範圍 #### 專案範疇說明書 * 對專案範圍、可交付成果、假設與限制等因素進行描述 * 專案範疇說明書 * 專案和產品的範疇描述(篩選) * 驗收準則(可交付成果) * 必要的可交付成果 * (除外責任)不包含在本專案範疇的項目,管理相關方的期望,減少範圍蔓延 * 一旦被核准成為基準,必須要依照變更管理計畫書審核同意,才能進行變更 ### 4. 建立工作分解結構 * 把專案可交付成果和專案工作分解為較小、更易於管理的組件 * WBS與範疇說明書差異 * WBS組織並定義專案總範圍,專案範疇說明書指定義專案範圍沒有組織 #### 建立工作分解結構 * 未完成專案最終的產品與服務,由專案團隊對整體工作範疇進行的階層式分析 * 遵守100%原則 * 包含所有層面,沒有多餘也沒有遺漏 * 包括專案與產品組成部分 * 使用階層結構 * 最上層:專案 * 下一層:交付標的 * 最底層:工作包(再細分為活動)  * WBS分解方法 * 把專案生命週期作為分解第二層,把主要可交付成果作為分解第三層 * 把主要可交付成果作為分解第二層,逐層分解 #### 範疇基準 1. 專案範疇說明書:規格書 2. WBS * 工作包 * 規劃包 * 管制帳戶CA:一個控制點,在該控制點上把範圍、預算、成本和進度加以整合,並與規劃值(績效量測基準PMB)比較以量測績效 3. WBS說明書(詞典) * 說明與描述工作包 * 提供有關WBS中每個組件(工作包)的詳細交付標的、活動和進度資訊、負責人、品質需求、驗收準則等 * <font color="Yellow">考點:可交付成果和驗收標準:優先選範疇說明書、次選WBS說明書、再次選範疇基準</font> ### 5. 確認範疇(客戶驗收) * 客戶或發起人正式驗收已完成專案可交付成果的過程 #### ITTO * 輸入:通過品質驗證(QC)的可交付成果 * 工具與技術:檢查(Review、Audit)可交付成果是否符合驗收標準 * 輸出: * 驗收的可交付成果(Accepted Deliverables) * 客戶或發起人簽字確認 * 變更請求 * 記錄原因 * 提交變更申請 * 進行缺失補救 #### 可交付成果 1. 驗收準則(AC) 2. 技術績效量測:KPI 3. 完成的定義DoD ### 6. 控制範疇 * 監督專案產品的範疇狀態,管理範疇基準變更(監控現況,管理變更) * 控制範疇的工具與技術 * 偏差分析(Variance Analysis):基準與實際結果比較,確定<font color="Yellow">偏差是否處於臨界值區間內</font>或是否有必要採取糾正與預防措施(現在) * 趨勢分析(Trend Analysis):審查專案<font color="Yellow">績效隨時間的變化情形</font>(未來) ### 7. 補充 * 範圍蔓延:未經控制的範圍擴大 * 團隊內叫鍍金 * 團隊外叫潛變 * 鍍金:討好客戶而做 * 範圍潛變:客戶不斷提出不易察覺的範圍變更,導致專案嚴重偏離範圍基準 * 出現範圍蔓延需要補變更流程 ## <font color="GreenBlue">3C.時程</font> * 時程管理計畫書 * 活動清單與活動屬性 * 時程基準 ### 1.規劃時程管理 * 時程管理:建立、執行、監視和管制專案時程而制定政策、程序和文檔的過程 #### 時程管理計畫書 * 專案管理計畫書的組件,建立、監視和管制時程的準則和活動 * 時程管理計畫無時程進度,內容包含 * 時程計畫的發布和迭代長度 * 準確度:持續時間估算可接受區間及允許應急儲備數量 * 計量單位:人天 * 控制臨界值:允許出現最大時程偏差 * 績效量測規則:EVM實獲值 ### 2.定義活動 * 識別及記錄產生專案可交付成果所需採取的具體行動 * 作用: * 建立工作分解結構流程,先將交付物分解至WBS最底層的工作包,再將工作包分解至活動 * 分解至活動作為對專案工作進行估算、進度規劃、執行和控制的基礎 * 活動是專案的任務,是時程(工作包以上是範疇)、成本估計與監控的基礎  #### ITTO * 輸入:專案管理計畫 * 範圍基準:需要考慮範圍基準中的WBS、可交付成果、約制因素和假設條件 * 工具和技術: * 分解 * 將工作包分解為活動,透過活動完成可交付成果 * 讓團隊成員參與分解過程 * 滾動式規劃(湧浪規劃) * 迭代式 * 漸進明細方式用於工作包,敏捷或瀑布式用於規劃包 * 輸出: * <font color="GreenBlue">活動清單</font> * 專案所需全部時程活動的綜和清單 * 活動清單需要定期更新 * 活動屬性 * 活動清單的補充資料 * 更詳細活動的內容與特性,用來協助規劃、分類與排序 * 里程碑清單 * 重要時點或事件 * 可能是強制性或選擇性 * 不是活動,持續時間為零,代表一個時點 #### 2-1 估算活動期程 * 活動期程(Duration):對完成一項活動所需可能期間的量化評估,常以週、日、時為單位 * 經過時間(Elapsed time):活動從開始到結束所需的實際日歷時間 ##### <font color="Yellow">4種估算期程技術</font> 1. 類比法:由上而下估計法。過去類似專案歷史資分的耗用時間為基礎,以估算現在專案可能需要工期。 * 成本低較省時 * 不準確 2. 參數法:運用歷史資料和其他專案參數間之統計關係 * 模型精準程度可提高準確度 * 統一工作單元並非常見典型 3. 由下而上法:由WBS最低工作組件估算向上聚合加總 * 準確度高 * 非常耗時 4. 三點估算法:最樂觀、最悲觀與最有可能加總除以三 * 納入風險與不確定因素,提高單點準確度 * 需要詳細資訊與專業知識估算  #### 2-2 發展時程 * 專案時程:專案的進度表,分析活動排序、工期、資源需求及時程限制,以建立專案時程模型 * 時成績準:作為專案績效的基準 ##### 要徑法、浮時(float time) * 專案中最長路徑的活動順序,它決定了可能的專案最短期程 * 要徑活動的浮時為0,要徑上有延誤就會影響到整個專案 * 浮時=最晚開始日期 - 最早開始日期 = 最晚完成日期 - 最早完成日期 * 總浮時:專案的緩衝時間,就是專案活動可以延遲的時間,此延誤並不影響專案完成日期 * 自由浮時:在不延誤後續活動的最早開始日期下,活動可以被延遲的時間  ##### 2種資源衝突優化技術 1. 資源平滑(限浮時內調整): * 要徑不變,限浮時內調整,也不會延長專案時間 * 無法優化資源 3. 資源撫平(要徑優先):資源優化技術 * 資源受限,重新調整設定資源上限,要徑可能會改變,可能會比原時程長 * 資源需求與可用量之間取得平衡 ##### 2種時程壓縮技術 1. 快速跟進法fast tracking: * 原有順序活動以**同時並行**方式執行 * 可能導致重工,風險增加和成本增加 3. 趕工縮程法crashing: * **增加資源縮短時程** * 超時工作 * 增加費用 * 僅適用於要徑上活動 * 可能導致成本和風險提高 ##### 4種時程模型呈現方式 1. 產品路線圖 2. 甘特圖 3. 里程碑圖 4. 專案時程網路圖 * 視覺化活動的相依關係 #### 時程基準 * 本流程產出 * 時程模型的批准版本,僅能使用正式的變更管制程序進行變更,並用作與實際進度比較的基礎 #### 2-3 控制時程 * 監控專案現況與管理專案時程基準之變更 * 比較績效與計畫 * 績效審查就是監控現況,進行KPI Review * 產出是工作績效資訊、請求變更及相關專案臉計畫與文件更新 ### 3.排序活動 * 辨識及記錄專案各活動清單及活動屬性(關聯性與優先順序) #### <font color="Yellow">相依關係</font> * 強制與刻意 * 強制(硬邏輯)相依:先天或實體限制所需要強迫限制,先蓋三樓才能蓋四樓 * 刻意(軟邏輯)相依:基於專業或時程考量,而對工作所做之限制,先鋪地板再刷油漆 * 內部與外部 * 外部相依:環評通過才能蓋公路 * 內部相依:組裝完成才能測試 #### <font color="Yellow">前後關係</font> * FS:結束A到B開始,最常用。 * SS:前項活動開始,後項活動才可以開始。校慶開始,園遊會才能開始。 * FF:前項活動結束,後項活動才可以結束。馬拉松結束,交管才能結束。 * SF:前項活動開始,後項活動才可以結束。新系統上線,舊系統才可以下線。  #### <font color="Yellow">提前lead/延後lag</font> * 提前:提前是彈性,後續活動可以提前開始時間,FS-2W * 延後:延後是保險,後續活動開始前等待時間,FS+2W ### 4.調適式時程規劃 #### 2種主要時程規劃手法 * 代辦清單搭配時間盒排程(迭代為基礎) * 時間盒:一個固定時間區間 * 按需排程(看板/精實為基礎) * 排序:時間固定且有限,排定交付項目和工作優先順序是重要 #### 發布規劃、迭代規劃與代辦清單精煉 * 發布規劃:產品路線圖 + 專案時程(發布日期) * 估算使用者故事:由開發人員估算完成某個使用者故事所需人力投入,主要考量工作複雜度,常以故事點為單位 * 使用者故事在發布規劃進行估算,在迭代規劃或代辦清單精煉可稜進行調整 * 迭代規劃: * 迭待的時間長度,在發布規劃決定,在整個發布期間就不可以更改 * 迭代速度,在一個迭代可以完成的工作量,即預估完成使用者故事的點數總和,通常在發布規劃進行估算,在迭代規劃進行調整 * 代辦清單精煉 #### 估算技術(工作量大小,投入的心力) * 相對估算法:相對大小/故事點數(Story Point) * 範例:T恤;水果大小;規劃僕克牌 #### 排序技術 * 優先排序 * 高價值 * 高風險 * 高ROI * 重大技術債 * 工具與技術 * MoSCoW * 狩野模型 * 相對排名 * 100點方法 * 大富翁鈔票 #### 備妥的定義(DoR)和完成的定義(DoD) * DoR(Definition of Ready):代辦清單工作項目在進入迭代開發前,應該要滿足一定的就緒條件 * 待辦清單工作項目在進入迭代開發前,應該要滿足一定的條件,以避免過於模糊的需求會導致迭代的失敗 * 待辦清單精練就是為了滿足DoR * DoD(Definition of Done):開發團隊與產品負責人針對產品完成程度或品質要求的共識,完成的定義是以檢核表的形式呈現 * 開發團隊與產品負責人一起訂(規劃會議上訂出) * 以檢核表的形式呈現 * 每個迭代產出增量或產品,除要滿足驗收準則AC(Acceptance of Criteria)外,還必須符合DoD,才算滿足驗收的所有條件,並在迭代審查會議上展示。 ## <font color="GreenBlue">3D.資源(人員、設備、材料)</font> 1. 人力資源 2. 設備、材料、設施或基礎設施 ### 1.規劃資源管理 #### 資源管理計畫書 * 專案管理計劃書的組件,描述將如何獲得、分配、監視和管制專案資源 * 內容: * 識別資源:識別和量化專案所需資源 * 獲取資源:獲取專案所需資源 * 角色和職責: * 角色:職務 * 職權:權力 * 職責:職責和工作 * 能力:技能和才幹 * 專案組織圖:報告關係 * 專案團隊資源管理 * 培訓 * 團隊建設 * 資源控制 * 認可計畫 #### ITTO * 輸入:專案文件 * 工具與技術:責任分配矩陣(避免權責不清) * 輸出: * 資源管理計畫 * 如何分類、分配、管理和釋放專案資源的指南 * 團隊管理與實物資源管理計畫 * 團隊章程:價值觀、共識和工作指南 #### 資源分配矩陣(RAM)或RACI矩陣圖 * 分派給資源關係人或利害關係人的責任類型 * 保持資訊可見  #### 自製或外購分析與決策的考量 * 成本/效益、時間、品質、技能、專業、風險等 ### 2.估算活動資源 * 估算執行專案所需團隊資源(資源種類、數量、特性) #### ITTO * 輸入: * 專案文件 * 活動屬性、清單 * 成本估算 * 資源日曆 * 風險登錄表 * 輸出: * 資源需求 * 估算依據 * 資源分解結構RBS * 資源分解結構 * 資源種類:人、材料或用品 * 資源類型:能力水平、要求證書、 ### 3.獲得資源 * 內部資源從職能經理或資源經理處獲得 * 外部資源從採購或租賃等途徑獲得 * 專案經理應進行有效談判,影響哪些能為專案提供所需資源的人員 * 資源或人員能力不足會降低專案成功概率,甚至導致專案取消 * 限制因素無法獲得資源,專案經理可能不得不使用替代資源(能力較低) #### ITTO * 獲取資源工具或方法 * 談判協商 * 職能經理:最佳資源 * 組織中其他專案管理團隊:希缺或特殊資源 * 外部組織:希缺特殊 * 預分派 * 競標過程中承諾分派 * 專案取決於特定人員專有技能 * 專案章程中指定 * 虛擬團隊 * 有共同目標 * 沒有時間或機會面對面 * 多標準決策分析 * 制訂出標準 * 加權 * 評級打分 * 匯總  * 輸出 * 實物資源分配單 * 專案團隊派工單 * 團隊角色職責與專案團隊名單 * 資源日曆 * 每種資源可用時間(何時及期間) ### 4.規劃採購管理 #### 4-1 規劃採購管理 ##### A.採購管理(合約管理)計畫書 * 描述將專案團隊採購的決策與識別潛在賣方 * 契約類型 * 獲得和評估投標的過程(Metrics) * 核准標準化採購文件 * 如何管理供應商 ##### B.<font color="Yellow">3大類契約類型</font> * 契約:使工作協議合法化 * 契約可以依合作夥伴關係進行調整 * 契約類型依照買方風險由高至低為 1. 成本補償契約(CR/CP):買方缺乏相關專業、需求不明確或變動性高,難以事先定義SOW,須仰賴賣方專業和技術 * 成本加固定費用CPFF(Cost Plus Fixed Fee):固定利潤 * 成本加獎金CPAF(Cost Plus Award Fee):績效滿足,依照買方對賣方績效評估決定獎勵費用,係主觀績效準則,不受理賣方上訴 * 成本加激勵費用CPIF(Cost Plus Incentive Fee):低於原本期望成本,達成目標給激勵費用,買賣雙方比事先議定比例分攤,分享額外之利潤 2. 工料計價契約(T&M,Time and Means):買方想要快速取得資源(人力、顧問服務、材料、設備等),決標時單價以議定,用多少付多少 * 無法獲得精確範疇或工作說明書時使用 * 同時具有成本補償(最終價格合約簽訂時未知)和固定價款(單位費率)的特性 * 常用於擴編人力、聘請專家及尋求外援使用 3. 固定價款契約(Fixed Price):買方對需求很清楚且預期範疇不會有重大變更,故買方自己可以訂定明確SOW * 固定價款加經濟價格調整FPEPA(Fixed Price with Economic Price Adjustment):契約中包含特殊條款,如通貨膨脹或成本上升下降,能以事先定義好的方式對契約價格進行調整 * 固定價款加激勵費用FPIF(Fixed Price Incentive Fee):賣方能否達到議定的指標,達標加付固定激勵費用 * 絕對固定價款FFP  ##### C.商源評選準則 * 買方評選合作賣方的標準與規則 * 價值觀、技術、屬性等與專案一致的外部資源合作 * 成本、專業、技術、解決方案、實績、口碑、財務狀況、智財權等 * 市場研究可用於檢查行業和賣家的能力 #### 4-2 執行採購 ##### A.招標流程 * 採購招標文件 * 工作說明書SOW + 招標文件(報價徵求書RFQ、資訊徵求書RFI、提案徵求書RFP、邀標書IFB、意向書EOI) * SOW(Statement of Work)工作說明書:由外包工作的範疇,由範疇基準發展而來,說明採購項目 * RFQ(Request for Quotation)報價徵求書:T&M合約 * RFI(Request for Information)資訊徵求書:買方要求供應商提供更多資訊 * RFP(Request for Proposal)提案徵求書:向供應商發書的工作要求說明書 * IFB(Invitation for Bid)邀標書:詢問供應商是否有意願投標 * EOI意向書:賣方發出的工作意願表達 * 尋商訪價 * 廣告:公告 * 投標人會議 * 釐清廠商疑問 * 建立共同的理解 * 評選商源 * 參選商源評選準則 * 建議書評估 ##### B.合約簽署 * 談判模型 * 談判技巧:談判(negotiation)是與他人合作達成協議。 * 仲裁Arbitration和調解mediation是談判的兩種形式。 * 授予合約 ##### C.控制採購 * 履約 * 廠商交付後檢驗與採購稽核 * 若有疑慮進行求償管理 * 協議 * 仲裁 * 訴訟 ## <font color="GreenBlue">3E.預算</font> * 對專案成本與預算進行規劃、估計、籌措資金、財務管理及控制,以利專案在預算內完成 ### 1.規劃成本管理 * 如何估算、預算、管理、監督和控制專案成本 * 輸出:成本管理計畫書 * 專案管理計劃書的組件,描述將如何計劃、建立和管制成本 * 成本管理計畫無成本 * 內容 * 計量單位 * 準確度:活動成本估算規定一定可接受範圍,如10%,包括一定之應急儲備 * 精確度: * 控制臨界值: * 組織程序鏈結:控制帳戶 * 績效量測規劃 ### 2.估算成本及預算 * 對完成專案工作所需資源成本進行預估 * 在特定時間點,根據已知訊息所做成本預測,包括通貨膨脹、應變準備金 #### 預測式估算 * 輸入:專案進度計畫 * 估算成本單位 * 貨幣單位:美金、台幣 * 其他計量單位:人天 * <font color="Yellow">成本估算技術(同時程估算)</font> 1. 類比估算法(成本低、粗略、耗時少):一種專家判斷、整體估算、由上而下 2. 參數估算法(產出更高準確度):歷史數據之間統計關係和其他變量,回歸分析就是典型案例 3. 由下而上估算法(非常準確、耗時):估算個體、逐層匯總 4. 三點估算法(透過風險及不確定因素提高單點估算的準確度) :從未執行過的專案 * 應考慮專案收費的全部資源(通膨、融資、應急成本) * 輸出: * 成本估算 * 完成專案工作所需成本與應對已識別風險的應急儲備 * 估算依據 * 支持性文件 * 假設與限制 * 估算信心水準 #### 調適式的預算規劃 * 預測預算 = 完成一個故事點所需的薪資 * 待完成項目的總故事點 + 其他費用 ### 3.制訂預算 #### 成本基準 * 匯總所有單個活動或工作包的估算成本,建立一個經批准的*成本基準* * 成本基準 * 經批准之按時間段劃分的專案預算,不包括任何管理儲備,只能透過正式的變更管制程序進行更改,並作為基礎來與實際結果進行比較 #### <font color="Yellow">應變儲備 vs 管理儲備</font> * 應變儲備:因應已知未知風險之儲備金(包含在成本基準中) * 管理儲備:因應未知未知風險之儲備金(需經變更流程,並於動用後加入到基準中) #### ITTO * 輸入:商業企劃案、效益管理計畫、協議 * 工具與技術: * 成本匯總 * 歷史訊息:參數估算、類比估算 * 資金限制平衡:資金限制下,可能導致進度變更 * 輸出: * 成本基準(包含應急儲備,但不包括管理儲備) *  * 專案資金需求=成本基準+管理儲備 *  ### 4.控制成本 * 監督專案狀態,以更新專案成本,管理成本基準變更的過程 * 成本基準的維護 * 分析專案經費支出和相應完成工作間之關係 * 重點在管理經批准的成本基準 * 控制成本工具(績效監控) * BAC:Budget At Completion總預算 * AC:Actual Cost * PV:Planned Value * EV:Earned Value *  * SV:Schedule Variance * CV:Cost Variance * SPI:Schedule * CPI:Cost *  ## <font color="GreenBlue">3F.風險</font> * 風險 risk:未來對專案目標達成的不確定因素 * 議題 issue:當下對專案產生影響的條件或狀況 ### 1. 規劃風險管理 #### 風險管理計畫書 * 用於說明如何建構與進行風險管理活動 * 依照風險管理計畫書制定風險應對策略 #### 風險與議題 * 風險:一種不確定性的事件或情況,一旦發生會對一個或多個專案目標產生正面或負面影響 * 議題:可能對專案目標產生影響的當前條件或情況 #### 風險策略:建立風險偏好、風險門檻 * 風險胃納(Risk appetite)亦稱風險偏好,代表企業面對風險願意損失的 最大數量或金額 * 風險容忍度(Risk tolerance)亦稱風險門檻,企業設定風險胃納之後,進而決定可以承受與管理多少風險 ### 2.識別風險 * 識別風險與風險來源,並記錄其特性 * 識別風險是一個迭代過程 #### 典型風險分類 1. 技術風險 2. 管理風險 3. 商業風險 4. 外部風險 #### ITTO * 輸入 * 工具與技術 * 提示清單 * PESTLE * VUCA * 風險分解結構RBS * 腦力激盪 * 集體發想表決法 * SWOT分析 * 親和圖 * 假設分析 * 文件分析 * 德爾菲技術 * 蒙地卡羅模擬 * 產出:風險登錄表 * 風險清單是簡化版的風險登錄表 * 內容 * 風險項目 * 負責人 * 潛在回應策略 ### 3.分析評估風險 * 先定性再定量 #### 定性風險 * 機率與衝擊矩陣PIM * risk exposure = 機率 X 衝擊 #### 定量風險 * 蒙地卡羅分析:電腦模型與模擬決定風險因子 * 敏感性分析:決定最大風險,常用龍捲風圖 * 決策樹分析:最佳選擇,根據一系列條件與問題來分類資料,最終做出決策。幫助決策者在複雜狀況下,做出明智決定。 * 專案時程延遲,應變方案會大幅增加成本,可招集利害關係人討論,進行決策樹分析 * 影響圖:決策樹太複雜時使用 * 期望貨幣值EMV:成果貨幣價值乘以機率,計算每個分支EMV #### 風險參數評量 1. 急迫性:對風險進行回應已產生預期結果的一段時間,越短越急迫 2. 接近性:風險可能對一或多個專案目標產生衝擊前的一段期間,期間越短表示接近性越高 3. 蟄伏性:風險發生後直到發現其造成衝擊之間所留是的一段時間 4. 關聯性:風險與其他專案個別風險的相關程度。 ### 4.風險應對 #### 風險應對策略(response strategies):發生前 * 威脅:陳報(長官定奪escalate)、迴避(機率為零)、移轉(保險、外包或採購)、減輕(控制措施)、接受 * 機會:陳報、開拓(exploit)、分享(share)、增強(enhance)、接受(accept) | | 採取前機率 | 採取後機率 | | --- | -------- | -------- | | 規避 | 0<p<1 | p=0 | | 開拓 | 0<p<1 | p=1 | | 減輕 | 0<p<1(大)| 0<p<1(小)| | 增強 | 0<p<1(小)| 0<p<1(大)| #### 衍生風險 * 由於採取某種風險應對策略而產生的新的或改變的風險 * 車子在高速公路爆胎,為了換胎下車而又產生被車子 #### 殘留風險(監控) * 實施某種風險應對策略後,仍然存在的風險 * 軟體開發經過測試驗證後仍有bug存在 #### 應變回應計畫、備援計畫、權變計畫:發生時 * 應變(Contingency)計畫:事先規劃好的風險應對策略,風險發生時實施 * 備援計畫:事先規劃好的風險應對備案,應變計畫無效時實施 * 權變計畫:事先未規劃的風險應對,突然發生黑天鵝事件的變通行動 #### 規劃風險回應 #### 執行風險回應 #### 監督風險 ## <font color="GreenBlue">3G.品質</font> * 品質:一組與生俱來的特性能符合實現需求(符合需求)的程度 ### 1.規劃品質管理 #### 過程 1. 審視合規性需求:如業界標準(PCI DSS)或法規等 2. 建立品質政策 3. 建立品質指標:對專案或產品屬性及其衡量方法的描述 4. 設定品質目標:品質指標所設定欲達到的水準 5. 發展品質管理計畫書 #### 品質管理計畫書 * 專案管理計劃書的組件,描述如何實施適用的政策、程序及指導方針,以實現品質目標 * 品質管理是計畫書可包含以下組件: * 產品與專案的品質標準 * 品質目標(品質指標所設定欲達到的水準) * 品質的角色與責任 * 使用的品質工具 * 不合格處理程序 #### ITTO * 輸入: * 工具與技術: * 成本效益分析:減少重工、提高生產力、減低成本及增進利害關係人滿意度 * 輸出:品質成本 * 合規成本:避免失敗而花費的成本 1. 預防(Prevention)成本:建立具品質的產品 * 訓練 * 品質需求、規劃、品質保證 * 防呆 2. 評價鑒定(Appraisal)成本:品質評估 * 可靠度測試 * 產品檢驗 * 品質稽核 * 非合規成本:由於失敗而在專案期間或之後花費的錢 1. 內部失效成本 * 重工 * 調查失效原因 * 報廢品 2. 外部失效成本 * 負擔責任 * 保固工作 * 失去生意 ### 2.管理品質 * 將品質管理計畫納入組織品質政策,轉化為可執行的品質活動,增加滿足品目標的機率,識別無效益的流程及品質不良的原因 #### ITTO * 輸入 * 檢核表 * 工具與技術 * 流程分析 * 根因分析 * 因果關係圖:魚骨圖、石川圖,找出問題可能發生的原因 * 直方圖:垂直長條圖 * 散佈圖:兩個變數間關係,正相關、負相關 * 柏拉圖:找出改善重點(矯正)順序,就是重點管理 * 產出 * 問題解決 * 品質報告 * 品質改善方法 #### 交付標的品質 vs 專案過程品質 * 管理品質QA * 預防瑕疵發生 * 事前 * 透過自主管理與稽核 * 注重過程 * 管制品質QC * 防止瑕疵流出 * 事中或事後 * 透過檢驗與測試 * 注重結果 #### 合規性需求 * 內部與外部標準(what) 1. 政府法規 2. 組織政策 3. 產品及專案品質需求 4. 專案風險 #### 合規性行動(how) * 辨識及分類合規性類別 * 決定對合規性的潛在威脅 * 分析不合規的的後果 * 決定因應合規性需求的必要方法和行動 ### 3.控制品質(Quality Control) * 監控及記錄執行品質管理活動的結果,以評估績效及確保專案的產出是完整、正確及符合顧客期待的 * 驗證交付物及工作符合關鍵利害關係人的需求,以達到最終驗收的目的 #### ITTO * 輸入: * 工作績效資料 * 交付物 * 專案管理計畫 * 工具與技術 * 查檢表 * 統計抽樣:隨機抽取、進行檢驗。 * 檢驗:檢查工作產品是否符合文件化的標準。 * 測試/產品評估: * 結構化的調查,提供產品或服務是否符合專案需求的客觀資訊。 * 目的就是在找出錯誤、缺點或其他不符和事項。 * 管制圖:判定製程是否穩定,亦即是否受到控制。 * 產出 * 品質管制量測:檢驗結果回饋給QA,讓品保人員持續改善品質活動有效性 * 驗證的交付物:判定交付物正確性,以利顧客驗收 ## <font color="GreenBlue">3H.整合計劃書</font> * 整合範疇、時程、資源、預算、風險、品質等計劃書 ### 1.專案整合管理 * 整合兼具統一、合併、溝通和建立聯繫的性質,這些行動應該貫穿整個專案。 * 專案整合管理應該由PM負責,承擔最終責任,且責任不能被授權或轉移。 ### 2.整合專案管理計畫 * 用於建立變更管理委員會,記錄其職權範圍,並說明變更管制系統的實施方式 * 誰可以提變更?所有人 * 變更對專案目標有何影響? 衝擊六重限制 1. 預測式:在專案規劃尾聲,將各領域規劃結果整合起來,建立專案管理計畫書及基準 2. 調適式:加入調適式過程和敏捷儀式,持續整合計畫並保持靈活性 3. 混合式:邊做邊調整,找出讓各項規劃要素保持整合性的工作方法 ### 3.變更管制 vs 構型管理 #### 構型管理 * 版本控制 * 管理專案工件的規格與版本 * 構型管理計畫書 #### 變更管理 * 專案流程合規 * 管理變更的程序、角色與權責 * 變更管理計畫書 #### 變更管制七步驟 1. 提出變更 2. 確認變更申請及記錄 3. 評估變更造成影響 4. 審核變更 5. 更新變更紀錄 6. 通知利害關係人 7. 執行與追蹤變更 #### 專案變更的原因 * 基準績效不一致 * 規格變更 * 新法規 * 為滿足的需求 * 利害關係人未說明清楚 * 基準失效 * 初始估算不正確 #### 績效vs變更 * 可交付成果 * 產品 * 工作包 * 工作績效資料 * 範疇 * 時程 * 成本 # <font color="GreenRed">四、領導專案團隊</font>  ## <font color="GreenBlue">4A.打造領導技能</font> * 專案經理同時運用領導技巧與管理風格 * 領導:透過討論與想法引導,專注於人際關係 * 管理:使用一組的規定行為來指導行動,專注於組織架構 ### 1.領導風格 * 直接型:照我說的做 hands‐off approach * 階層式,PM決策 * 諮詢型:你怎麼看 Management by exception * 考慮大家意見後決策 * <font color="Yellow">僕人式領導</font>:試試這個(參考2)Puts other people first * 塑造期望行為,提昇團隊生產力 * 共識協作:以人為本 Seeks to inspire and encourage innovation * 凝聚共識,自主運作 * <font color="Yellow">情境型</font>:跟我來 High‐energy and enthusiastic * 變化風格以適應環境與團隊成熟度 ### 2. Tuckman團隊發展五階段 1. 形成期:各做各的,單打獨鬥 2. 風暴期:開始衝突與磨合 3. 規範期:信任共識與合作 4. 表現期:產生績效表現良好 5. 結束期:原地解散 ### 3.虛擬團隊 * 地域分散 * 選才彈性 #### 管理虛擬團隊最佳方法 1. 管理**孤立感**的風險 2. 關注**團隊目標** 3. 建立**共同承諾** #### 資料搜集工具 * 溝通類 * 腦力激盪 * 訪談 * 焦點團體 * 促進 * 文字圖像類 * 文件分析 * 問卷調查 * 親和圖 * 心智圖 * 系統關聯圖 * 互動類 * 觀察交談 * 標竿比對 * 雛形prototype ## <font color="GreenBlue">4B.建立協作團隊環境</font> 空間與資訊集中 工件管理 ### 1.協作環境4要素 1. 集中作業 2. 開放性對話 3. 有意義的互動溝通 4. 建立基本規則 ### 2.標準化工件4要素 1. 標準格式與範本 2. 審查核准流程 3. 版本控制 4. 即時分配文件 ### 3.工作資訊管理系統 1. 專案管理資訊系統:收集整合和共享專案資料 2. 工件管理系統 #### 工件的重要性 * 其他專案受益 * 在專案團隊在專案生命週期中建立和維護的文件 #### 資訊儲存和分配最佳實務 * 資訊散熱器information radiators * 主動傾聽 * 有效回饋 #### 維護工件 * 構型管理計畫書 * 促進產品、服務或專案結果和可操作性一致性 * 構型管理系統 * 如何追蹤專案工件和監視,並管制其變更 ## <font color="GreenBlue">4C.賦權給團隊</font> * 推動團隊當責 ### 1.激勵理論 #### Maslow 馬斯洛需求層次理論 1. 生理需求:食物、水、睡眠(生理) 2. 安全需求:秩序、安全、穩定(生理) 3. 歸屬與社交需求:友情、歸屬(心理) 4. 尊重需求(別人給):成就、尊重、欣賞(心理) 5. 自我實現(自己給):學習、發展、自覺(心理)  #### 赫茲伯格Hertzberg 雙因素理論 * 保健因素:導致不滿足感的因素,做的好不會提高激勵,做不好會損害激勵 * 薪水、工作條件 * 激勵因素:導致滿足感的因素,能夠起激勵作用(尊重及自我實現) * 進步、表彰、參與  #### 麥格雷戈McGregor:x理論與y理論 * x理論:人性本惡 * 缺乏進取心,逃避責任(低層次需求) * y理論:人性本善 * 願意進步與承擔責任(高層次需求) #### McClelland成就動機理論(3需要) 1. 成就需要:被肯定,超越別人,追求名譽 2. 權力需要:領導團度或影響組織或他人行為 3. 歸屬/親和需要:關係導向,尋求認同,甚於被肯定 ### 2.獎勵與表彰 #### 獎勵與表彰 * 獎勵:錢,有形的消耗品 * 表彰:拍手,無形的體驗活動 * 不建議只給少數員工 ### 3.決策 * 賦予團隊採取行動的權力 * 團隊章程確定決策和衝突處理準則 #### 決策方法3技術 1. 表決(定性): * 集體決策與評估 * 一致同意 * 過半數 * 多數決 2. 多準則決策分析(定量) * 資料驅動 * 使用系統的分析方法 3. 獨裁(一人當家) * 領導力驅動 ## <font color="GreenBlue">4D.支援團隊成員績效</font> ### 1.僕人式領導3步驟 1. 定義願景 2. 使成員與願景保持一致 3. 激勵追求願景 ### 2.情緒商數EI 5要數 1. 自我意識:對自身情緒了解程度 2. 自我調節:定義自己能管理這些情緒程度 3. 激勵:自己追求成就的根本原因 4. 同理心:讀懂並理解他人情緒的能力 5. 社交技能:與他人建立關係和相處融洽的程度 ### 3.激勵4要素 1. 成就/動力:設定艱難的目標,抓住機會,探索如何提昇你的能力 3. 承諾:努力實現超出基本或預期的目標 4. 倡議:將逆轉是為由可控因素而非個人缺陷造成 5. 樂觀:熱情尋找機會來幫助實現團隊使命 ## <font color="GreenBlue">4E.與利害關係人溝通與協作</font> * 溝通:發布資訊與報告績效 * 依據溝通管理計畫書 * 使用資訊散熱器 * 主動傾聽與有效回饋 * 在里程碑時進行正式報告 * 協作:執行參與管理策略,促進利害關係人參與 * 依據利害關係人參與計畫書 * 利用權力/關切網格監視利害關係人參與 * 更新利害關係人參與評量矩陣 * 進行協作活動:站立會議、輔導或一般會議 ### 1.有效溝通2要素(資訊散熱器) * 有效(主動)傾聽 * 參與:傾聽與保持眼神接觸 * 跟隨:回應 * 反映: * 有效回饋 ### 2.有效會議的關鍵 1. 有條理:訂定明確的會議議程 2. 時間盒討論:設定時間限制,提昇討論效率 3. 練習主動傾聽與回饋:尊重參與會議的每一位成員 4. 促進協作:有效的會議控制與引導 ## <font color="GreenBlue">4F.培訓、輔導和指導</font> * 訓練規劃、訓練進行 ### 1.培訓、輔導與指導 1. 培訓training:傳授知識與技能 2. 輔導coaching:應用新技能或改進現有技能,由學習付諸實踐,由PM或Scrum Master負責 3. 指導mentoring:透過長期專業關係發展個人或專業成長,將技能與知識從經豐富一方轉移到經驗少的一方,老手帶新手 ### 2.規劃 * 進行差距分析已確定所需知識、技能與屬性 * 多樣化的培訓與輔導 * 適當進行培訓 * 鼓勵有價值利害關係人成為mentor * 衡量培訓成果  ## <font color="GreenBlue">4G.管理衝突</font> * 所有團隊成員及利害關係人都有責任管理衝突,專案經理是促成解決的角色 * 團隊章程和基本規則會規範管理衝突的偏好方式 * 衝突管理應關注議題而非個人 ### 1.衝突來源 * 資源不足引發競爭關係 * 目標與價值觀差異 * 個人工作經驗或方法的意見分歧 * 溝通失敗 * 臨時性團隊無共事經驗 ### 2.衝突管理 1. 擱置Withdraw/迴避Avoid:先放著之後再說(休會30分鐘) * 退出衝突,將問題推遲或推給他人解決 2. 強迫Force/命令Direct(輸贏):強迫別人用我的方法 * 利用全力來強行解決問題 3. 妥協調解(雙輸):各退一步找方案 * 部分解決問題,一定程度滿意 4. 緩和Smooth/包容Accommodate:有共識,無方案 * 強調一致,求同存異 5. 合作Collaborate解決Problem solve(雙贏):共同合作解決問題 * 考量不同觀點,開放對話,引導達成共識和承諾 *  ### 3.衝突管理五策略 1. 協作/問題解決:雙贏 2. 強迫/命令:輸贏模式 3. 妥協/和解:雙輸模式 4. 撤離/規避:休會30分鐘 5. 緩和/包容:放下小爭端,面向大目標 # <font color="GreenRed">五、支持專案團隊績效</font>  ## <font color="GreenBlue">5A.實施持續改善</font> ### PDCA * 持續改善:PDCA --> PDSA * 持續改善運動基礎: * 持續改善產品設計以改善服務 * 追求一致的產品品質 * 改善工作場所與研究中心的產品測試 * 透過全球市場追求更高銷售量服務 * 許多微小的改善為基礎,比起重大的變更,小幅改善不用花太多資金, * 實施持續改善過程 1. 辨識問題 2. 潛在改善方案 3. 試行改善方案 4. 評估有效性 5. 知識移轉 ### 持續改善方法 * 經驗學習登錄表 * 回顧會議 * 順利進行 * 需要改進 * 實驗 * AB測試 * 柏拉圖 * 80/20法則,把人力投入引導到可以產生最大影響的地方 ### 持續改善產出 * 工件:更新過程和標準 ## <font color="GreenBlue">5B.支援團隊績效 </font> ### 1.對標目標 * 專案經理領導專案團隊依目標管理(傳達目標),團隊專注於交付價值,促成有效團隊 * 目標明確的團隊 * 專案經理與團隊應共同設定目標 * 目標應具有挑戰性且能實現 * 產出交付標的、留下紀錄 * 管理團隊/評估團隊績效KPI #### 角色與職責 * 專案經理:監督專案管理計畫書的整合,建構跨職能團隊,協作決策並確保團隊能回應變更 將詳細產品規劃和交付管制權委託給PO * 敏捷教練:幫助團隊理解敏捷思維和使用Scrum過程 * 團隊成員:規劃和執行專案工作 * 產品負責人:負責詳細產品規劃和交付的管制,負責創造價值 ### 2.過程:支援績效 * 過程:支援團隊績效 * 方法: * 處理專案目標 * 最佳化溝通、使用回饋來支援高績效,支援團隊任務責任制 * 將知識當作資產策劃,整合知識移轉機會 * 學習激勵團隊的正確方法,經由不斷調整,讓團隊人力投入與價值交付保持一致 ### 3.產出:團隊績效評量 * 評量目的 * 改善團隊成員之間互動 * 解決議題 * 處理衝突 * 改善團隊成員的技能和職能 * 提高團隊凝聚力 * 評量績效技術 * 向團隊成員提出關鍵問題 * 一對一會議和定期專案會議與團隊成員對話 * 向團隊成員提出建設性批評和讚賞肯定 * 評估個人績效 * 撤除表現不佳團隊成員 ### 4. 知識為團隊與組織資產 #### 顯性Explicit與隱性Tacit知識 * 顯性知識:記錄、存檔與共享 * 隱性知識:見解、經驗、信念、專業等,鼓勵個人共享與合作 #### 等級 1. 個人:成員需要知道什麼來執行專案工作? * 透過研究以及與其他團隊成員協作獲得所需知識 2. 專案:實現專案目標需要什麼? * 從其他專案移轉知識並諮詢專案管理辦公室 3. 組織:管理專案及或專案 * 來自其他專案集專案組合的知識並加以裁適 #### 整合知識移轉機會 * 人脈建立 * 特殊興趣小組 * 會議、研討會或其面對面和虛擬活動 * 彼此可互動之培訓 * 工作見習/工作影子(反向觀摩)可交換特定知識提供更個人化方法 ## <font color="GreenBlue">5C.評估專案進度</font> * 監控專案工作 * 績效報告 * 依六大限制(範、時、成、品、人、風)評估專案工作進度 * 工作績效資訊 ### 1. 範疇績效衡量 | | 預測式/混合式 | 調適式/混合式 | | -------- | -------- | -------- | | 衡量方法 | 監視與確認範疇 | 迭代展示/審查會議 | | 完成進度 | 範疇基準 | 產品待辦清單 | | 工作包驗收 | 工作分解結構說明表 | 完成的定義 | | 驗收 | 範疇說明書 | 使用者故事驗收準則 | ### 2. 時程與成本績效衡量 * 實獲值管理:將實際時程與成本對比規劃的基準來衡量績效 * BAC:所有工作預算的總和 * 計畫值PV:預計時程下的預算,預計完工率 X BAC * 實獲值EV:實際的時程下的原本預算,實際完工率 X BAC * 實際成本AC:實際時程下所實際花飛得成本 | | 預計成本 | 實際成本 | | -------- | -------- | -------- | | 預計時程 | PV | X | | 實際時程 | EV | AC | * 預算內 * CV(成本變異)=EV - AC > 0 * CPI(成本績效指標)=EV/AC > 1 * 時程超前 * SV(時程變異)=EV - PV > 0 * SPI(時程績效指標)=EV/PV > 1 #### 調適式績效衡量 * 時程 1. 任務版 2. Scrum看板:將使用者故事的狀態視覺化呈現,通常使用*故事點*為估算單位 3. 速度:在迭代結束將所有使用者故事的故事點加總計算出速度 4. 燃盡圖:迭代期間以工作剩餘量顯示進度的圖 5. 燃起圖:迭代期間以工作完成量顯示進度的圖 ### 3.資源的衡量績效 * 實體資源管理 * 分配的資源及時可用並在不再需要時釋放 * 確保分配的實體資源按規劃可供使用 * 監視規劃的資源與實際資源利用率 * 更新資源分配 * 採購與契約管理 * 履約管理:監視與確保廠商有依照契約執行和交付,最後要進行採購稽核與結束契約 * 契約進行檢查:採購合規(稽核)、定期進度或活動報告、正式驗收契約交付標的 * 契約糾紛與求償管理 ### 4.品質績效衡量 * 評估和管制品質 * 驗證交付標的是否達到品質目標或滿足品質標準和需求 * 識別並提出改進建議 * 識別解決缺陷或其他不合規問題的潛在方法 * 持續監視品質報告和建議 * 已驗證的交付標的提交給客戶並被客戶驗收或驗證,從而產生已接受的交付標的 #### 調適式績效衡量 * 完成的定義:團隊對交付成果品質的承諾 * 完成迭代待辦清單項目後,必須驗證符合 * 迭代展示或衝刺審查會議中,開發人員對產品負責人和利害關係人展示所完成的工作成果,利害關係人提出回饋,產品負責人進行審查並決定是否接受或驗收增量 ### 5.風險績效衡量 * 監視風險:更新風險登錄表 * 持續監控風險的狀態、機率和影響 * 定期執行 * 識別新風險 * 重新評估目前風險 * 關閉過時的風險 * 根據整體風險暴露程度和個別風險目前的資訊做出決策 * 儲備分析:用起評估專案風險程度及時程與預算儲備的數量,以確定該儲備足以應對風險的一種方法 ## <font color="GreenBlue">5D.管理議題和障礙</font> ### 1.風險與議題 * 風險:尚未且不確定未來是否會發生的事件,可以是正面的也可以是負面的。 * 風險在發生前不一定被辨識 * 議題:專案進行中已發生且影響專案目標或專案績效的問題、落差、不一致或衝突,必然是負面的。 * 可能是已發生的風險或可能未辨識的而發生的風險 ### 2.風險管理或議題管理 * 發生與否: * 發生前:風險管理 * 已發生:議題管理 * 管理議題、管理障礙專案不一定能夠順利進行,一旦出現各種非預期的情況,就可以稱為議題 * 議題的處理要及時,不然也會提昇專案的風險 * 過程 * 管理議題,將問題的原因與症狀分開 * 管理障礙,並移除障礙,決策涉及到解決問題的其他方案 * 決策作的過早或過晚都不好 * 工件:議題紀錄 * 每一個議題都要指派處理負責人 * 確保有效的進行追蹤 ## <font color="GreenBlue">5E.管理專案變更</font> * 專案變更的原因:績效有差異、估算不正確、合規性要求、規格有變更、需求未滿足 * 變更處理 * 預測式及混合式手法:整合變更管制過程 * 調適式手法:待辦清單精鍊會議進行,不影響目前的迭代  ### 1.變更申請類型與整合變更管制過程 #### 變更申請 * 變更申請:如專案進行的過程有要更新已批准的工件,就要提出變更申請。 * 變更申請的類型包括: * 預防措施:應對風險的規避、移轉、減輕策略。 * 矯正措施:處理議題的權變(workaround)措施。 * 缺陷修正:修正不符合的成果或產品。 * 可交付成果不符合品質標準,需要找出未達標準原因,提出缺陷修復的變更申請。 #### 整合變更管制過程 * 包含確認變更、評估影響與審查變更,決定核准或否決。 ### 2.變更管理的階段 | 順序 | 階段 | 主要角色 | 說明 | | -------- | -------- | -------- | -------- | | 1 | 提出變更 | 利害關係人 | 辨識所需變更,記錄於變更紀錄表,說明變更提出者、變更項目、變更理由與效益、期望完成日期等 | | 2 | 確認變更 | 專業團隊 | 確認變更申請,將變更申請紀錄輸入變更管制系統 | | 3 | 評估影響 | 專業團隊 | 評估該變更對專案限制的影響,製作影響聲明,將結果告知變更提出者 | | 4 | 審查變更 | 專案經理、利害關係人、贊助人 | 由變更管理計畫書針對該變更內容與性質所規範的審查層級來決定核准或否決該變更申請 | | 5 | 後續處理 | 專案團隊 | <font color="Yellow">更新變更紀錄與變更管制系統並通知利害關係人; 更新專案管理計畫書和專案文件,執行並追蹤變更</font> |  ### 3.變更審查層級的基本原則 | Column 1 | 專案經理| 變更管制委員會 | 贊助者 | | -------- | -------- | -------- | -------- | | 輕度影響 | V | X | X | | 中度影響 | V | V | X | | 重度影響 | V | V | V | 1. 提出變更 2. 確認變更 3. 評估影響 4. 審查變更 5. 後續處理 # <font color="GreenRed">六、結束專案</font> * 取得客戶驗收文件 * 行政結案活動 ## <font color="GreenBlue">6A.專案/階段結束</font> ### 1.專案或階段結束 * 預測式開發手法:進入階段或專案的結束 * 利害關係人根據所建立範疇基準中的驗收準則決定接受交付標的 * 專案團隊則使用需求追溯矩陣確保所有需求的完成和批准 * 調適式開發手法:進入迭代或發布的結束 * 在迭代將近結束時,專案團隊根據他們共同商定的完成的定義(DoD)來評估成果 * 產品負責人則根據驗收準則決定接受成果產出增量,在產品發布之前進行最終驗收 ### 2.專案或階段結束的活動 * 驗收後的行政活動 * <font color="Yellow">移轉交付標的或產品</font> * 通知企業和組織職能部門 * 更新組織過程資產(OPA) * 準備專案的最終報告 * 完成外部義務,包括法律、監管、契約 * 整理與歸納專案資訊 * 釋放資源(人力、財務和實物資產) ## <font color="GreenBlue">6B.效益實現</font> ### 1.效益管理 * 審查效益管理計畫書,確保專案效益移轉和維持 * 預測式開發手法:專案已結束並交付效益,任何改進或修改都是一個新專案 * 調適式開發手法:迭代已結束並交付效益,任何改進或修改都作為未來迭代的工作,並放置在待辦清單中或重新排列優先等級 ### 2.效益負責人 * 專案期間,由效益負責人確保效益已被移轉以及妥善監控效益正在實現,並向管理階層報告 * 預測式開發手法:商業分析師、專案經理、贊助者 * 調適式開發手法:產品負責人 * 在預測式專案的產品和服務被交付後,移轉和維持計畫會指明持續衡量效益是否實現的度量指標與負責人 ## <font color="GreenBlue">6C.知識移轉</font> ### 1.結束時知識管理 * 討論從專業中級取的經驗學習 * 預測式手法:進行最終的經驗學習會議(lesson learned meeting)或全體會議(All-hands meeting) * 調適式手法:每次迭代或整個專案最後進行回顧會議(Retrospectives) * 完成經驗學習登錄表 * 將經驗學習添加到知識管理/經驗學習庫 * 將知識從專案團隊移轉到客戶 * 最終報告是專案或階段績效結果摘要,並含經驗學習 知識紀錄、總結、移轉 # <font color="GreenRed">補充:敏捷</font> ## 敏捷實用時機:目的不明確、要求不明確、技術債和高缺陷。 * 高度的不確定性: * 變化 * 複雜性 #### 發布規劃 VS 迭代規劃 * 將發布視為一項專案,故調適式專案的範疇規劃從發布規劃開始 * #### 使用者故事 * 使用者故事用卡片表達使用者需求的功能特性與價值,促進團隊成員彼此間的溝通與共識 * 使用者故事應具備的特性為INVEST * Independent獨立的:避免相互依存 * Negotiable可協調的:可以修改與調整 * Valuable有價值的:應表達使用者價值 * Estimatable可估算的:應能估算完成所需的投入或時間 * Small小型的:在一個迭代或衝刺內完成 * Testable可測試的:具體的測試方法或條件,可確認是否完成 * 史詩Epic或功能特色Feature等大型故事,應進一步分割為使用者故事 * 驗收準則應經使用者或客戶確認,最終由PO決定  #### 待辦清單 * 產品待辦清單 * 依優先等級排序後的需求清單,其項目通常由使用者故事所組成 * 由產品負責人負責產品代辦清單項目的定義與排序並具有最終決定權 * 排序是根據使用者故事價值並參考估算與風險等因素(柏拉圖法則或80/20法則) * 常用MoSCoW(Must、Should、Could、Won't have) * 發布待辦清單 * 迭代/短衝待辦清單 #### 產品路線圖/故事圖 #### 需求大小 * 史詩 * 功能特性 * 使用者故事 #### 精煉待辦清單 * 代辦清單精煉又稱為代辦清單修整(Backlog grooming),是開發人員與PO在迭代進行中進行調整產品待辦清單的一次或多次會議,目的是為下一個迭待規畫做準備 * 代辦清單精煉可能會對使用者故事新增、移除、分割、重新排序、進行或調整估算等 * 代辦清單精煉部會改變進行中迭代的目標與待辦清單 * 建議代辦清單精煉的時間每周不要超過一小時 * ### 蒐集需求 ### DOR與DOD ### MVP與MBI * 最小可行產品MVP * 最小商業增量MBI *  ### 敏捷契約  ### 預算  
×
Sign in
Email
Password
Forgot password
or
Sign in via Google
Sign in via Facebook
Sign in via X(Twitter)
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
Continue with a different method
New to HackMD?
Sign up
By signing in, you agree to our
terms of service
.