人生處處是專案,只要有問題需要解決,就可以應用專案管理之方法來處理。
專案管理PMP就是結合各種知識、技能與技術以達成利害關係者的需求(客戶並不是想買我們的物品或服務,
而是想買它背後帶來之價值。如女孩子買化妝品,買的是美麗與自信;搭高鐵,買的是準時;買賓士汽車,
買的是身份;買VOLVO,買的是安全。)及專案(工作)目的、目標。
也有人把PMP戲稱為拍馬屁,講的也沒錯。你必須找到對的馬(目標客戶),並找到它的需求,應用對的工具及流程,
才能滿足它的需求,解決它的問題(搔到癢處)。
我們平常做工作為何常會失敗,是因為沒有一套完整之管理方法。專案管理PMP就是一套你一定要學習的方法。
一個專案之形成,是我們對現況有所不滿,想要有所突破(改善或創新),但在原有官僚式之系統內很難成功,
才會獨立出來,形成一個專案。
但後來軟體開發業為了因應快速變化之環境,提出了敏捷式專案管理ACP,但個人覺得PMP與ACP應該是結合在一起使用,
而不是互斥的對立。以PMP為體,ACP為用,才能發會最大之效果。
以下表來說明其互相應用方式:
PMP專案管理
(為體,主體架構)
法為主,人為輔,強調「不別親疏,不殊貴賤,一斷於法」
|
ACP敏捷式管理
(為用,應用之方法)
道家,人為主,法為輔,主張「道法自然」。講求的是從快速從經驗中學習反應和團隊的自我管理。
|
利害關係人管理
|
分析誰是關鍵利害關係人,想辦法滿足其需求,以減少專案障礙。
|
PO必須掌握利害關係人需求,在每個週期找利害關係人驗收成果,以確認進行方向是正確的。
|
專案起始(章程)
|
要找到有價值之專案目的,並訂定專案目標,了解限制及假設,提升專案之價值。
|
使用Use Story及Story map來描繪專案之目的、目標及路徑(策略)
|
範圍管理
|
確認專案之產品範圍(特性、功能、驗收原則)及專案範圍(必須執行之工作)。
|
由PO使用產品願景盒,來說明產品範疇及能提供之價值及驗收之標準及Product Backlog(產品待辦清單)。
|
時間管理
|
估算完成專案之時間及排出進度表以管控專案進度。
|
應用TIMEBOX之1-4週訂定截止日,由團隊挑出對客戶最有價值之工作先做,並以燃盡圖(工作包之完成數量) 來追蹤進度
|
成本管理
|
估算完成專案之成本,並訂出預算書,據以控制成本。
|
-
範圍是可改變的,只要達到客戶之要求條件,可以提前結束專案以節省成本。
-
每週期與利害關係人驗收,確認方向是正確的,可以節省很多重工之成本。
|
品質管理
|
規劃專案品質標準,進行品質保證及品質控制。
|
事先由PO確實掌握利害關係人之要求,訂出工作能產生價值之優先順序及驗收原則。
|
人資管理
|
選才、育才、用才、留才。
|
-
建立能自主管理(當責)之團隊,以教練式溝通方式替代命令式管理。
-
團隊成員分為產品擁有者PO(能掌握業主需求)、MASTER(協助隊員解決問題之領導者)、專案團隊
|
溝通管理
|
建立與利害關係人溝通之理效途徑。及時、正確、有效的將資訊傳遞給需要的人。
|
-
Daily Scrum(每日站立會議):每天10-15分鐘不能超時,目的是讓團隊資訊同步。一定要站著為了讓大家長話短說。
-
Sprint Planning(衝刺規劃會議):Sprint 開始時,討論一下這個Sprint 團隊可以交付哪些Item。Item 優先順序PO 決定,要選多少Item 由Dev Team 決定。
-
Product Backlog Refinement / PBR(產品待辦清單精煉會議):PO 跟Team 一起討論近期內會開始施工的Item,主要是從商業和使用者角度切入,盡可能不觸及技術細節。
-
Sprint Review(衝刺檢視會議):Sprint 結束時針對產品的會議,PO邀請利害關係人對產出給意見,是要可用的軟體才算產出。不準備Powerpoint或其他簡報,單純就軟體操作取得回饋。
-
Sprint Retrospective / Sprint Retro(衝刺回顧會議,『自省』會議)針對這個Sprint 團隊的工作模式討論改善,并定出下個Sprint 改善事項。為了創造一個安全的環境,原則上只有團隊成員才能參加。
|
風險管理
|
建立風險管理計畫書。進行風險辨識、排序、回應及控制風險。
|
每天互相交流工作進度及障礙,每週期提出流程改善方法,可將風險降到最低。
|
採購管理
|
建立採購管理計畫書,以進行必要之採購流程。
|
軟體設計大都都是用人力,敏捷對採購方面著墨較少。
|
時間管理
|
估算完成專案之時間及排出進度表以管控專案進度。
|
應用TIMEBOX之1-4週訂定截止日,由團隊挑出對客戶最有價值之工作先做,並以燃盡圖(工作包之完成數量) 來追蹤進度
|
PMP專案管理(為體,主體架構)
|
ACP敏捷式管理(為用,應用之方法)
|
成本管理
|
估算完成專案之成本,並訂出預算書,據以控制成本。
|
-
範圍是可改變的,只要達到客戶之要求條件,可以提前結束專案以節省成本。
-
每週期與利害關係人驗收,確認方向是正確的,可以節省很多重工之成本。
|
人資管理
|
選才、育才、用才、留才。
|
-
建立能自主管理(當責)之團隊,以教練式溝通方式替代命令式管理。
-
團隊成員分為產品擁有者PO(能掌握業主需求)、MASTER(協助隊員解決問題之領導者)、專案團隊
|
溝通管理
|
建立與利害關係人溝通之理效途徑。及時、正確、有效的將資訊傳遞給需要的人。
|
-
Daily Scrum(每日站立會議):每天10-15分鐘不能超時,目的是讓團隊資訊同步。一定要站著為了讓大家長話短說。
-
Sprint Planning(衝刺規劃會議):Sprint 開始時,討論一下這個Sprint 團隊可以交付哪些Item。Item 優先順序PO 決定,要選多少Item 由Dev Team 決定。
-
Product Backlog Refinement / PBR(產品待辦清單精煉會議):PO 跟Team 一起討論近期內會開始施工的Item,主要是從商業和使用者角度切入,盡可能不觸及技術細節。
-
Sprint Review(衝刺檢視會議):Sprint 結束時針對產品的會議,PO邀請利害關係人對產出給意見,是要可用的軟體才算產出。不準備Powerpoint或其他簡報,單純就軟體操作取得回饋。
-
Sprint Retrospective / Sprint Retro(衝刺回顧會議,『自省』會議)針對這個Sprint 團隊的工作模式討論改善,并定出下個Sprint 改善事項。為了創造一個安全的環境,原則上只有團隊成員才能參加。
|
風險管理
|
建立風險管理計畫書。進行風險辨識、排序、回應及控制風險。
|
每天互相交流工作進度及障礙,每週期提出流程改善方法,可將風險降到最低。
|
採購管理
|
建立採購管理計畫書,以進行必要之採購流程。
|
軟體設計大都都是用人力,敏捷對採購方面著墨較少。
|
|