讀書心得:學會專案管理的12堂課

前言

專案管理一詞，相信大家都不陌生，在職場上我們也常常聽到或是實際參與專案的進行，業界也有許多與專案經理(Project Manager)有關的職務。究竟有沒有哪些技能及知識，是專案管理必備的呢?在此就藉由本書(學會專案管理的12堂課，鍾文武著，博碩文化股分有限公司出版)，摘錄一些重要的書摘，以及自己的心得。

 

一、專案概論

我們首先先了解幾個名詞的定義:

1.1何謂專案:專案是一暫時性的努力行為，其目的是為了完成一項獨一無二的產品，服務或是結果。由此定義，小至決定周末的出遊行程，大到國家重大的基礎建設都可以是專案。

1.2何謂專案管理:所謂專案管理就是運用所有我們所知的知識、技術、工具與技巧透過專案活動，達成專案所預先設定的目標。

接下來介紹幾種專案進行中的角色:

1.3專案經理:負責專案成敗的人，想要勝任專案經理的工作除了所謂的硬技術(Hard Skill)，還需要有軟技術(Soft Skill)。

1.3.1硬技術:偏向科學層面的技能，如:專案計畫書的製作，風險管理技巧，工作分解結構方法...等。硬技術不須天分，只要肯花時間用心學習，任何人均可具備相當程度的知識。

 

1.3.2軟技術:偏向藝術，如:談判技巧、溝通能力、激勵、團隊建立...等。雖可後天學習，但天生個性占較大因素。

現代專案管理非常重視軟技術，其重要性占75%。

1.3.3職能金三角:根據國際專案管理學會的研究報告顯示，要成為一位有效率的專案經理需有以下三方面技能:專案管理技術、領導統御能力、策略與商業管理知識。

1.4專案贊助人:出資讓專案執行的人或單位，他們指派專案經理全權負責專案，定期審視專案進度，協助專案經理解決困難，專案不如預期時，也有權終止專案。

1.5專案利害關係人:專案的失敗或成功，對其利益會有影響的人或團體。專案利害關係人對專案各自有不同的期望，這些期望可能會彼此衝突，專案經理需釐清並解決這些衝突。

 二、專案成立

專案會成立，都有它存在的理由，每一個專案都有其既定的目標，而這個目標最好能與組織的使命與目標相結合。為了將有限資源做最大效益運用，組織中會設立專門單位，負責監看所有專案，定期審核所有專案，以決定專案是否還有繼續進行的必要。

這種統一管理組織內部所有專案，嘗試將資源發揮到最大效益的做法，稱為專案組合管理(Project Portfolio Management)。

2.1運用專案管理組合:以下是專案組合管理的幾個步驟

 

2.1.1專案分類:進行專案組合管理前，先將組織的專案分類，其目的是為了方便管理，如將專案分為:強制型、策略型、日常型。

 

2.1.2設定選擇準則:不同的專案，可有不同選擇準則，但都須圍繞組織的願景與目標。

 

2.1.3收集專案提案書:大多由管理階層提出專案候選名單，經過討論後定案。

 

2.1.4審核專案提案書:在規定的時間收齊專案提案書後，評審委員根據專案類別，將專案提案書經由不同的選擇準則評估，產生專案的優先順序。

 

2.1.5定期評估專案:專案辦公室需定期審查目前執行中的專案，看看是否有背離組織願景及目標的情形發生。若發現有此情形，則需要將專案導回正軌，或是斷然中止。

 

2.2專案起始:經過審慎的篩選後，專案終於正式被核准，有了合法的權力可以取得資源，進入正式起始階段。這個階段有以下三個工作須完成。

 

2.2.1取得專案章程:專案起始的第一份文件，由專案發起人負責撰寫，是一份正式宣布專案成立的文件。

 

2.2.2:指派專案經理:專案成立後，應盡速指派專案經理。專案贊助人可與專案經理一起選出專案團隊，協助專案經理展開專案細部規劃工作。

 

2.2.3指認專案利害關係人:專案成立後，專案經理需與專案贊助人與專案管理團隊，一起找出專案所有的利害關係人，建立專案利害關係人登錄表。

 

2.3專案成功與利益實現管理:在相對穩定的商業環境中，組織藉由對市場的了解，規劃未來的方向，訂出組織策略目標，然後依據優先順序一一投入足夠資源，依序啟動專案。隨著專案完成，而替組織帶來商業利益。然而在現今詭譎多變的環境下，組織若不能迅速反應市場需要，最終將會被市場洪流吞沒，如柯達、諾基亞。因此專案成功的定義不再僅是在限定的預算內，如期如質的完成專案的主要目標，專案成功與否必須衡量專案是否能替組織帶來實質利益。

 

專案管理辦公室與專案贊助人是利益實現管理(BRM, Benefits Realization Management)的主要負責人，在專案啟始前制定專案成功準則，專案進行中追蹤專案是否偏離專案目標，並在專案結案或結束後評估專案是否帶來商業價值。

 

三、專案規劃

 

3.1專案規劃階段最重要的事就是產生一份專案管理計畫書，他提供了專案執行所需的所有資訊，從開始一直到專案結束。專案管理計畫書至少應包含以下部分:

 

3.1.1範疇管理計畫書:用來說明管理專案範疇的方法，包括如何收集專案需求、如何定義專案範疇、如何建立工作分解結構(WBS, Work Breakdown Structure)、如何確認及控制範疇。

 

3.1.2時程管理計畫書:描述專案在時程管理上運用哪些流程。定義專案時程單位，專案進行中，如何控制時程，時程差異多少內數可接受範圍，時程差異超過多少，需要向外求救。

 

3.1.3成本管理計畫書:說明使用的成本管理流程有哪些?成本的單位?(幣別/單位)如何追蹤成本執行狀況?成本差異多少內，屬可接受範圍，差異不同，是否有不同處理方式。

 

3.1.4品質管理計畫書:內容包括品質控制與品質保證兩部分。說明在專案中，將如何確保專案品質，以及如何確保專案成功。定義專案會透過哪些方法測試專案品質，測試結果如何視為通過，若沒通過，會有那些補救措施。

 

3.1.5資源管理計畫書:說明專案資源分為哪幾類，專案團隊的組織架構，各個職位的角色與職責。

 

3.1.6溝通管理計畫書:說明專案的溝通方式，有那些固定的會議?多久一次?那些人該參加?

 

3.1.7風險管理計畫書:定義專案對風險管理採取哪些流程，說明流程內容。採用何種方式收集風險項目?是否需要對風險項目做定量分析?定義風險類別有哪幾種?在風險監控上，要先規劃好多久進行一次風險指認。

 

3.1.8採購管理計畫書:針對專案採購做好原則性規劃，使用哪些流程進行採購。

 

3.1.9利害關係人參與計畫書:如何收集、紀錄、滿足利害關係人對專案的期望?多久須檢討一次利害關係人參與的策略?

3.1.10流程改善計畫書:說明提出改善建議的程序。

3.1.11變更管理計畫書:說明專案基準確定後，若有任何基準需要修改，其變更流程為何。

3.1.12建構管理計畫書:用於版本控制，專案進行中，會有許多文件產出。如何確保最新版本文件會留下來，當異動發生時，不會造成互相掩蓋的情形。以及問題的追蹤與跟催，也會記錄在此計畫書中。

 四、專案範疇

專案範疇管理最重要的一件事，就是要把專案的範疇確定下來，能明確定義專案範疇，專案可以說已成功了一半。

4.1定義範疇:任何專案目標都不應背離當初的商業需求。 專案團隊首先要根據專案章程上所記載之商業需求，拜訪專案利害關係人收集需求，發展出專案範疇說明書。此文件主要目的在對專案範疇做一初步的釐清與定義。

專案範疇指的是，為了要完成專案最後產出，所需要做的所有工作，就是我們的專案範疇。

專案範疇說明書至少包含以下各項:專案源起、專案目標、專案產出、產品概述、專案里程碑、專案時程、專案成本、專案組織、專案風險、技術需求、專案利害關係人、假設、限制、完成標準、專案贊助人確認。

 4.2商業分析師:專案團隊中負責蒐集需求，釐清問題，定義出專案範疇的人，稱為商業分析師(Business Analyst)

以下幾種工具可以協助我們釐清專案的範疇

4.3工作分解結構(WBS Work Breakdown Structure):它是以專案開始，類似家族族譜的方式，往下展開專案的各個產出項目，直到夠清楚為止。展開到最底層的項目，稱作工作包(Work Package)

4.4流程分解結構(PBS Process Breakdown Structure):根據專案進行的過程，依時間前後進行拆解。

4.5責任指派矩陣(RM Responsibility Matrix):利用二為矩陣，將工作細目與專案成員的責任種類清楚呈現。每一項工作都要指定負責人，且只能有一位負責人。 

五、成本預估

 

5.1估算成本:專案成本包括人力資源、原物料、機器設備、資訊系統、通貨膨脹、利息、及任何完成專案所需的一切費用。

成本預估一般有以下幾個方法:

 

5.1.1巨視法：用過去類似專案，或業界一般標準估算，準確度不高，適合專案初期或需求範圍不明確時採行

5.1.2微視法:先利用工作分解結構，將專案展開至工作包後，請對該工作包熟悉的人，針對每一個工作包詳細預估成本，再將工作包累加，便可算出專案總成本。準確度高，估算時間及人力成本較高。

5.1.3階段預估法：不確定因素較高的專案適合用階段預估法，對即將到來的階段，採微視法；對後期階段，採巨視法。

5.1.4專案準備金:專案成本預估，除了考量專案本身已知工作外，還需考量"意外"狀況，即專案不確定性(已知不確定/未知不確定)，為管理專案的不確定性，專案採用預留準備金的方式，以處理不預期會發生的事件。

5.2決定預算:成本是將工作包隨著專案執行順序予以加總所得。專案成本每天都會發生，預算是一段區間的總額。預算決定後，財務單位在資金運作上，就會配合專案的支出撥款，專案的成本管理才算告一段落。

六、時程發展

6.1專案時程估算:有以下幾種方式

6.1.1由上而下估算：類似專案的歷史資料，業界共同認可的標準。粗略的估算，快速又節省估算成本。

6.1.2由下而上估算：準確，估算時間成本增加。

6.2定義活動:定義活動由工作包開始，最好請對該工作包熟悉的專案成員分析，要完成該工作包需要進行那些活動。

6.3排序活動:活動與活動間可能有些互有關聯，排時程之前，要先一一找出，定義好各自的關係，以作為排程的基礎。

6.3.1活動邏輯關係:最常使用的關係，"前後關係"(Finsh to Start)，活動A做完後，才進行活動B。

6.3.2提前與延後:為了更貼近現實面， 活動間關係還可以加上提前或延後。

6.4估算活動資源:活動資源包括所有人力、原料、設備與資金。預估活動資源前，我們需要有兩份資料:

 

6.4.1專案資源限制:專案經理首先須了解，專案當中有沒有哪些資源的限制。

 

6.4.2專案資源行事曆:記載資源有空可茲利用的時間。

6.4.3資源安排：由底層開始，底層活動安排完資源，再逐層累加上來。一次只考慮單一活動，在正常狀況下所需工期。

同時考量各種解決方案，決定最適合方式。

6.4.4資源分解結構:專案活動安排好資源後，逐一累加上去，專案所需的所有資源也就決定了。可利用資源分解結構(RBS Resource Breakdown Structure)呈現。 

6.5估算活動工期：活動資源決定後，就要預估在此條件下，需要多少時間可以完成。如果專案成員已經決定，單然應請該活動負責成員估算所需時間。如果該活動外包給廠商，就該請廠商提出時程表。活動若還沒負責人，專案經理可請對該活動較熟悉的專案成員或其他利害關係人協助，預估出合理工期。

6.6發展時程:每一個活動工期預估完後，依據活動與活動間的先後排序，專案時程可以透過專案時程網絡圖(Project Schedule Network Duagram)完整呈現。

6.6.1專案時程網絡圖:以圖形方式，將專案所有活動，依照安排好的順序，有系統的呈現。我們以節點表示活動，箭頭表示關係，這種網絡圖又稱為節點圖示法(AON Activity on Node)

 

 

 6.6.2專案時程計算:網絡圖完成後，將每一個活動預估工期記載在活動節點上，依照活動順序累加下去，由左而右向前推進，就可以得到專案最終時程，這種方式稱為前推法(Forward Pass)

 

ES:Early Start活動最早可以開始時間

ID:活動編號

EF:Early Finsh活動最早可以完成時間

DU:Duration活動的預估工期

專案總時程經計算後，其結果為35天。專案時程網絡圖除了可以知道活動的關係，與專案的時程外，還可以表示出專案的關鍵路徑(Critical Path)。

6.6.3關鍵路徑:指的是專案中最長的路徑，它決定專案的總時程。關鍵路徑上的活動，稱為關鍵活動(Critical Activity)，任何一個關鍵活動延遲一天，專案總時程就會延遲一天。因此，專案管理上，關鍵路徑上的活動，絕對要優先照顧妥當。

6.6.4資源衝突:當資源分派到每一個活動後，需查核資源有無衝突，或是超過正常工作量。當有這種情形發生時，就要進行資源撫平(Resource Leveling or Resource Smoothing)。經資源撫平調整後，專案時程往往會再度往後延伸。

6.6.5時程縮短:專案規劃時，有時會因上級或客戶要求時程壓縮，或是在專案進行中，因下列原因，被要求加速完成專案。

專案進度已明顯延誤、專案資源有更重要任務須提前離開、爭取提前完工獎金、需早日進入市場搶先機。

時程壓縮有以下兩種方法:快速跟進(Fast Tracking)把後面的工作盡可能往前，提早開始。縮程法(Crashing)將專案活動重新檢視，看是否可藉由其他方式縮短工期。如:增加人力、縮小範圍、降低品質、更換更有經驗成員、增加設備...等。

6.6.6關鍵鏈(Critical Chain):是另一種專案排程方法，源自於高德拉博士所創的限制理論(TOC Theory of Constraints)。基本觀念是找出瓶頸點所在，然後全力維持瓶頸點的順暢，如有可能，投注資源改善瓶頸點的效率。就專案時程而言，瓶頸點就是關鍵路徑，唯有縮短關鍵路徑，專案時程才有可能縮短。關鍵鏈要全力保障關鍵路徑的暢通。它在每一條非關鍵路徑要進入關鍵路徑前，都加上緩衝時間，以免非關鍵路徑的時程延誤，會耽誤到關鍵路徑的順暢，這叫匯入緩衝(Feeding Buffer)。

但在實務中，常因人性弱點將預留的緩衝被耗盡。關鍵鏈採用全新、革命性的思考，它不在工期中加緩衝，它採用更大膽的方式估算工期，只估算50%可能完成的時間長度。如此積極的專案時程，延遲的風險當然很高。解決之道是在專案最後增加一個專案緩衝(Project Buffer)，以吸收活動當中的延誤。由於每個活動的工期都以50%的機會可以完成的態度預估，因此可以激起團隊的鬥志。萬一沒達成，專案緩衝可以保護專案時程不致延誤。

七、風險控管

7.1專案風險：有可能發生，也有可能不會發生的事件。然而，一旦發生就會對專案目標有正面或負面的影響。專案風險包含以下三個要件:不確定性、對專案目標有影響、有正面負面的影響。

風險管理是有系統的指認、分析、與回應風險。風險在專案初期最高，因為資訊最缺乏。隨著專案的進行，對專案越來越清楚，風險就越來越低。相反的，為了修補風險發生後的錯誤，花費成本在初期越低，但越到後期，成本越高。風險管理還有以下好處:再次確認專案目標、事先防範、專案可能提前中止。

沒有做好風險管理的可能原因：不清楚風險管理的好處、不願意承認風險的存在、風險管理需要成本。

風險管理有以下流程:風險識別—》風險評估—〉風險回應規劃—》風險監控

7.2風險識別:在風險事件發生前，找出專案潛在所有風險。參與風險識別人員應廣泛邀請專案利害關係人，透過腦力激盪方式找出專案風險，並製作風險登錄表(Risk Register)。

指認風險有以下幾個方法:腦力激盪(Brainstorming)、工作分解結構(WBS)、檢核清單(Check List)、假設與分析限制(Assumptions and Constrains Analysis)、因果圖/魚骨圖(Cause and Effect Diagram/Fishbone Diagram)、SWOT 分析。

7.3風險評估：找出潛在風險後，針對這些已知風險，要逐一分析，排列出風險優先順序。風險評估方式粗略可分定性法、定量法兩類。

7.3.1定性法:常用PI矩陣(Probability Impact Matrix)計算PI值，判定風險高低。

7.3.2定量法：期望值貨幣分析(EMV Expected Monetary Value Analysis)利用統計資料計算已知風險可能產生的結果。蒙地卡羅分析，利用預設的統計模型，輸入各種已知不確定因素，利用電腦產生亂數，經過多次模擬，計算出不同結果，再利用統計分佈圖預測最後可能結果與機率。此方法成本很高，需較長時間分析，適用大型專案。 

7.4風險回應規劃：風險發生後，所應採取的措施。

面對風險，首先要先決定採取的策略，針對負面風險與正面風險各有不同策略。

 

7.4.1負面風險策略:避免:直接跳開風險可能發生的機會。轉移:將風險的衝擊，全部或部份轉移給第三方。緩和:設法降低發生的機率，或影響程度。接受:有些風險的影響可能很輕微，採取因應措施成本反而較高，此時可以直接接受它，不做因應。

7.4.2正面風險策略:開拓:發覺或創造可能的正面風險，並促使它實現。分享:有些正面的風險，可能自己力有未逮，此時可與第三方合作，共享風險發生後的利益。強化:加強正面風險發生的機率，或影響程度。接受:不採取任何行動，等它發生或是未發生。

7.4.3應變因應計畫(Contingent Response Plan)：指特定風險事件發生後，所採取的措施，也是風險發生後的因應方案。

 

7.5風險監控:隨著專案的進行，有些風險消失，有些新風險產生。因此，再專案執行過程中，還有一項重要的工作，就是定期審視專案風險登錄表與風險因應計畫，看看有哪些風險該刪除，哪些風險該新增。再次由風險識別、風險評估、一路到風險因應規劃。

八、專案執行

 

8.1依照計畫進行各項工作 ：專案執行階段，專案經理只需根據專案時程，要求專案成員按表操課即可。若任何人要更改專案原先計畫時，都要經過一定的程序才可以更改。這個程序，稱為變更控制流程(Change Control Process)。

 

8.2收集與發佈專案狀況：如何將適當的資訊內容，在適當的時機，傳遞給適當的人，這是一件非常重要的事情。專案規劃階段，對於專案資訊的收集與發佈，應先有通盤考量，並將決定記載於專案溝通管理計畫書(Communication Management Plan)中。

 

8.3召開專案定期會議：專案定期會議的主要目的是在收集與分享專案資訊，通常有:專案團隊內部進度會議、專案高階指導委員會、專案客戶會議、其他各式特定會議。專案定期會議的種類，在專案規劃階段就應決定，同時記錄於專案溝通管理計畫書中。專案執行階段，依照專案計畫召開各式會議。透過專案團隊內部進度會議，收集專案詳細資訊，然後加以過濾整理，分享給其他各類專案利害關係人。

有效率會議有以下原則：開會前先發議程、不論是否到齊準時開會、開會之前先申明會議時間安排、首先追蹤上次決議事項、依重要次序討論議題、分配決議事項負責人、彙整會議結論、做好會議紀錄，會後分發給與會者。

8.4取得並發展專案團隊:專案不是流程在做，是人在做。流程再好，計畫再周詳，沒有一隊有效率的團隊在執行，專案沒有成功的機會。取得足夠且適當的專案團隊，是專案成功與否的關鍵因素之一。

8.5管理專案利害關係人:早期專案管理只注重在管理專案本身的各項活動。近期，逐漸發現這樣還不夠，還要能管理好專案所有利害關係人，包括以下:專案經理、專案贊助人、計畫經理、專案組合管理經理、客戶/最終使用人或單位、專案團隊、功能部門經理、其他利益被專案影響的個人或團體。

專案開始時，即須指認出專案利害關係人，建立一份專案利害關係人登錄表(Stakeholder Register)。同時針對這些利害關係人逐一分析其重要性，將其優先順序排列出來。

管理利害關係人的原則，雖然是盡可能滿足每一位的期望，然而也不是漫無止境的接受，底線就是不超出專案的範疇。

管理利害關係人的策略，可依照重要性不同而有不同，可用權力與利益矩陣將策略分為以下:

 

 

8.6執行品質保證活動:品質保證(Quality Assurance)主要目的是確保專案擁有一定的品質水準，它的重點在稽核專案執行的流程。產出結果是否合乎專案設定的規格則是品質控制(Quality Control)的責任。品質保證:確保專案有一定的水準，重點在稽核專案執行的流程，不在專案產出的成果。稽核人員應具備以下特質:與專案無利益關系、對專案流程非常熟悉、從事多年專案，了解實務面、對組織產業有深厚認識、獨立自主，不畏各利益團體壓力，客觀評估、尊重專案團隊、從協助專案團隊與組織的角度出發。品質控制:檢驗產出結果是否合乎專案設定的規格。

九、專案監控

專案監控的目的在於，確認專案依照計畫進行。專案監控先收集專案進度與現況，比對專案計畫書中的各項基準，看看是否有差異，發現差異後，再查看各項計畫書，看看差異是否在可容忍範圍。如果不是，則要找出產生差異的根本原因(Root Cause)。有了根本原因，才會有相對應的解決方案，排除問題，將專案導回正軌。

9.1變更控制流程:專案執行過程當中，如果有任何異動之處，都需要提出變更需求(CR Change Request)。變更需求包括:提出改善措施、提出預防措施、修改瑕疵、變更計畫。

9.2實獲值管理:(EVM Earned Value Management)是美國政府在1960年代，為了追蹤專案，所發展出來的管理系統。

9.2.1基本元素:計畫值(PV Planed Value)、實際成本(AC Actual Cost)、實獲值(EV Earned Value)。

如果專案如進化進行無差異，EV=PV=AC。

9.2.2變異值與績效指標:時程變異值(SV Schedule Variance)=EV-PV。若等於0則符合進度，大於0進度超前，小於0進度落後。

時程績效指標(SPI Schedule Performance Index)=EV/PV。若等於1則符合進度，大於1進度超前，小於1進度落後。

成本變異值(CV Cost Variance)=EV-AC。等於0符合預算，大於0低於預算，小於0超出預算。

成本績效指標(CPI Cost Performance Index)=EV/AC。等於1符合預算，大於1低於預算，小於1超出預算。

9.2.3預測專案:實獲值管理除了可以用來報告專案現況外，還可以用來表達對專案未來的預估狀況。

十、團隊管理

無論哪一種專案，都離不開專案團隊，專案需要人來執行，團隊管理(Team Management)就成為專案成功很重要的因素之一。

10.1專案經理:專案經理像一個航海經驗的老船長，指揮全船弟兄，合作無間的朝目的地前進。他需要具備多方面知識，但不必精通，因都有專職人員負責。他負責聯絡船東，決定行程，鼓舞士氣，處理意外狀況，防範風險，船長不必擔任某一特定工作。因為整艘安全的，在預定的時間內抵達目的地，就是他的工作。

專案經理需肩負許多角色:管理者、領導者、溝通者、談判者、思考者、決策者。

10.2團隊建立:團隊建立的目的，是要將一群互不熟悉的成員，組成一個團隊，使他們可以有效率的發揮功能。一般說來會經過五個階段:

 

常見的衝突管理方式:擱置或迴避(Withdrawing/Avoiding)、緩和或接納(Smoothing/Accommodating)、妥協(Compromising)、強迫(Forcing)、合作(Collaborating)、面對或解決問題(Confronting/Problem Solving)。

風暴階段是團隊建立必經的過程，並有利於團隊建立，越早進入越好，但此階段不宜持續太久，宜盡速進入下一階段。

風采階段是團隊最有效率的時候，團隊越快進入風采階段越好。要能鼓勵團隊有正向表現，獎勵是最好方法，獎勵有以下原則須掌握:盡量獎勵團體，避免獎勵個人。獎勵不必貴重，但須頻繁。獎勵的方式與禮品要洽當。獎勵要能擴及配偶家屬。

解散階段要著重於讓專案成員順利返回原屬單位。

 

十一、專案終止

11.1專案為什麼會終止:

專案完成；專案如計畫完成，產出專案定義的產品、服務或結果。

專案未完成，提前終止:專案若發生以下狀況，以致未能完成專案預設的目標。

專案最初的商業需求消失、遭遇無法克服的問題、優先權次序異動、經稽核提出終止。

11.2專案終止:專案終止活動包括有:正式公開宣布專案結束、 取得專案贊助人同意專案產出的文件、解除廠商合約付清帳款、關閉專案帳戶並結清專案費用、召開專案檢討會議，整理經驗傳承、評估專案團隊、專案成員歸建、專案資源歸還、整理文件歸檔。

 

十二、敏捷式專案管理

此處僅摘錄敏捷式開發模式如下:

瀑布式開發模式:

 

 

心得

 

本書依專案階段編排，從起始、規劃、執行、監控、結束階段均做了鉅細靡遺的介紹。無論你是身處在專案的什麼角色，讀完此書均會有所獲得，也讓我們知道專案的靈魂人物"專案經理"，責任非常重大，在專案中，需要肩負起各種角色:需要與客戶談判、需要領導專案團為、需要與各利害關係人溝通、也許要對困難問題做出決策。能擔任大型專案的專案經理，都有著超乎常人的能力。

 

讓人最有感觸的是，無論執行各種專案，"人"的問題往往是最難處理的，而人的問題處理不好，往往專案為後都會以失敗收場。而專案經理，正是需要能帶領團隊向目標邁進的人。所以書中一開頭，在談到專案經理的關鍵能力，軟技術占比75%，真是讓人覺得非常正確。而這些軟實力的培養，又非常困難，甚至很大一部分跟自身個性有很大關係，所以好的專案經理，真是非常難尋。

 

拿NBA做比方，最近五個球季的強隊金洲勇士隊，五年內三次總冠軍，球員陣容一攤開，五個全明星球員，2個年度MVP，要取得總冠軍就如同探囊取物一般容易。但實際上，若球員間爭奪個人數據，各自為政，不能成為一個"團隊"，往總冠軍目標邁進，此一成就也絕對無法達成，所以我覺得總教練居功厥偉，他就是專案經理的角色，將個人"捏"成了團隊，讓大家往總冠軍目標邁進。

 

最後，此書也是很好的考試用書，若有意取得PMP證照，本書也是相當好的參考用書。