隨著PM解決的案子越多，交辦到手上的專案也就越來越棘手，因為主管們發現你是專案管理的箇中高手，於是那些陳年無法結束的、犧牲無數同仁的，或者負責人突然消失不見的專案，第一時間就會想到找你來處理。在我的經驗中，多數延宕多年的專案都有一個共通點，那就是範疇過大或難以界定，造成後續經常性變更、專案成員缺乏共識等衍生問題，當問題一個接一個串起來的時候，想要找出根因對症下藥就變得更加困難，因為每一個環節每一項任務看起來都像是壞掉的零件一樣，卡住整個專案的運作。
範疇邊界/Roadmap
面對範疇交代不清楚的情況，越需要花更多時間去釐清關聯及劃定邊界。哪些是現階段該做的事? 哪些必須與外單位協作? 有了明確的定義之後，接著展開的任務才能與目標對焦。當然，界定範疇並不是一件容易的事，通常必須從「需求」開始著手，需求的來源可能是產品使用者，也可能是公司內部的期望(例如建立阻擋追隨者的技術門檻)。
前幾年有部名為「一屍到底」的日本電影，使用「一鏡到底」及「戲中戲」的拍攝手法，由於成功營造前後劇情的反差效果，加上演出逗趣，因此瞬間爆紅，在全球創下3000萬美元票房佳績，成為小成本電影的成功典範，甚至被譽為「神片」。最近拜讀該部電影相關的書籍，發現它的成功並非偶然，雖然投入的資源、成本極少，拍攝時間亦不長(僅有八天)，但不論事前的企劃準備、臨場應變等，都極需要良好的管理與團隊合作，絕對可以做為專案管理的學習教材。
低成本管理
一部電影的產生，約略可分為前置準備期、拍攝期，以及後製與宣傳期。在剛開始階段，可能僅有導演、製片或編劇參與討論，隨著構想漸漸成形，劇本也要考量拍攝方式、長度等因素加以調整，例如像「一屍到底」這種低成本電影，故事的場景就不能設定太多，因為不論場地、交通都會影響預算。其他節省開銷的方法還包括「以實際的外景點取代大型布幕」、「不照劇本畫面、鏡頭順序拍攝，而以移動時間最少、器材設置最有效率的順序拍攝」……等。
實務上多數專案的處境和低成本電影相似，專案資源、經費不斷被降低，要求的產出卻不會減少，此時就必須適度調整做法，在時間、成本和範疇(專案三要素)之間找到平衡點。「以外景取代大型布幕」是最直接壓低成本的方法，但為了符合場景設定，劇本可能也要跟著調整，便與範疇管理有關。「以器材效率決定拍攝順序」可以爭取更多時間，卻也可能因為改變流程而衍生新的風險。由此可見，成本控制並非單純壓低預算就能解決，如果沒有釐清專案任務之間的相依關係，則只會將問題從A任務轉嫁到B任務上而已。
如期如質是專案的唯一目標，但多數都達不到這樣的境界，那麼，執行專案管理對我們有什麼幫助? 或許從以下的角度切入，能讓被專案dead line追著跑的你釋懷一點...
1.減少過程中的慌亂感，讓自己多一點時間做事，而不是到處救火或時時刻刻開會。同時也可以塑造臨危不亂、先知的專業形象。
2.降低老闆的不安，避免魔手入侵。
3.給自己有更多能準時下班的理由。
一個專案要失敗，有來自四面八方太多的可能性，也因此，PMP專案管理框架應用層面非常廣，甚至生活中許多時候都能引用參考。
專案執行過程最為人詬病的問題，就是用戶或sponsor持續追加需求，導致範疇不斷變更、膨脹。變更的原因有很多，最常見的情況是專案初期PM就無法明確定義範疇，也沒有讓團隊成員、用戶及sponsor都充分理解專案執行的邊界在哪裡，當邊界模糊，對於新增的需求自然也缺乏約束力，無法排除在專案之外。
在《專案管理知識體系指南》(PMBOK® Guide, A Guide to the Project Management Body of Knowledge)中，雖然有定義專案初始階段的任務，包含確認專案範疇、展開WBS...等，但如何有效界定範疇、用何種圖表來呈現，就需要靠PM自己想辦法。為了讓團隊成員及相關利害關係人都能理解專案範疇，我自己習慣使用UML中的Use Case Diagram加上流程圖的形式來輔助說明。UML是一種軟體開發的統一塑模語言(Unified Modeling Language)，用來為即將開發的系統進行塑模分析，簡單來說，就是在開發前建立一個模型概念，以統一的圖文規則來表述系統架構、功能等。而Use Case Diagram是其中一種圖形工具，從高層次的角度辨識系統所應提供的功能，在圖形的繪製上，通常會有Actor(通常為某個角色，例如系統的使用者)、Use Case(使用案例，或可想像為操作行為、或者執行的功能)，以及兩者之間的關聯，其中Actor和Use Case之間常為一對多關係。
舉一個簡單的例子來說明，假設專案要開發一套進出貨管理系統，那麼我們必須先釐清使用者有哪些，以及他們個別會如何進行操作。簡單的關係圖如下，業務建立訂單後，分別由撿貨員進行備料，再由送貨員遞送給客戶，其中訂單必須經過主管簽核才能正式成立，亦即一份完整的訂單包含了主管核准的動作，因此在圖形上使用虛線箭頭加上《include》標示，代表他們的關聯。每個專案、系統的情況不同，在拆解關係時務必以使用者為出發點，列出他們與系統、產品之間的互動關係即可，不須太過著墨細節，畢竟這個階段還未進入流程的分析。
當主要的關係釐清之後，接著便可從圖中找出隸屬專案範疇的部分，有時候專案必須仰賴其他系統的功能作為輔助，例如案例中的簽核流程可與公司原有的機制串接，此時便可將其排除在範疇之外，繪製出如下的關係圖。
當然，大部分的專案絕不會像範例一樣有如此簡單的關聯，且定義太過模糊也無法有效匡列範疇，因此PM必須與團隊成員一同檢視Use Case，從不同面向進行拆解，歸納出完整的關係圖。例如訂單成立後，是否需與銷用管理系統有資料的往來? 財務或經管單位是否需針對銷售金額或成果進行檢視? 這些都必須透過提問、訪談，逐步彙整而成。在匡列範疇的同時，也等於是對專案做整體評估，對後續展開WBS有極大的幫助。
在過去，領導者多半擁有強烈的性格，以及類似東方傳統父權的權威感，但隨著資訊發達、社會氛圍轉變，新世代的領導者也逐漸發展出不同的風格，其中一種類型會謙虛地廣納意見，不以自我為中心，偶而甚至會暴露自己的缺點，尋求部屬協助，我們稱之為懂得「示弱」的領導者。
兩手一攤，把難題丟給別人，只會惹人厭惡；不懂裝懂，則會被嘲笑外行領導內行，因此所謂「示弱」並不是單純的認輸或擺爛，而是在遭遇難題時，了解自己的能力範圍所在，謙虛地尋求各類建議 – 不論對象是否為同儕或下屬。當被諮詢的對象感受到足夠的尊重，認知自己有能力解決主管或老闆的問題時，自尊心獲得滿足，便可能投入更多的心力協助，此時領導者不僅可以分散肩上的壓力，也能吸引更多優秀(尤其是比自己更強)的人才加入團隊。
如同要一位父親向求學中的孩子示弱，並不是一件容易的事，不過近年來廣受推崇的觀點是從心理學的層面出發，當父母越能站在孩子的角度思考，放下權威與孩子溝通，就越能獲得正向的回報，同樣的道理也能套用在人際關係間，所以「示弱」其實也是建立信任關係的方式之一。
產屋敷的示弱領導
在日常工作中，尤其跨團隊協作時，難免會遇到已經談定的事情破局，或者本該對方處理的任務卻被甩鍋(註1)，這時候內心鐵定很想用力問候對方。不過，最近看到一些有趣的論點，原來經常性的「甩鍋」其實是一種認知失調，之後只要遇到被甩鍋的鳥事，內心想著「這個人勢必失調得十分嚴重」，心裡就著實舒坦了許多，還不由得替他感到辛酸呢。
根據腦成像的相關研究顯示， 人類在意識到自己做錯事情的時候，腦袋內的某個區塊就會啟用，而且這個區塊和生理疼痛的腦區是相同的，當這種類似疼痛的感覺過度強烈時，大腦就會啟動保護機制。身體碰到疼痛和恐懼時的反制行為是逃避，因此當大腦過度刺激時，將眼前所遭遇的責任推卸掉，就是大腦認為最簡單有效的方法。
心理學上所說的「認知失調」，是人們發現自己的行為和自我想像不相符的時候，無意間產生幻覺來合理化自身行為的一種保護措施。因此，當一個人經常性自以為合理化推卸責任時，某種程度而言已經患有「認知失調」。
近年來最知名的代表人物莫過於川普了，由於川普不只一次在公開場合公然甩鍋、批判，雖然某種程度展現了他的強人手腕，但也多次被專家點名他可能患有某種程度的認知失調。不過事實上是如何呢? 想必這個問題連川普自己也沒有答案(誰會承認自己失調?)，我們只要抱持著樂觀的態度，不要被那些所謂的失調行為給影響，就是對自己最大的鼓舞了。
製作時程表對於專案管理而言，可以說是一項基本但又容易犯錯的工作。何以說容易犯錯? 因為和風險管理一樣，隨著時間推移，工作時程、任務之間的關聯也會有所變化，如果沒有經常檢視、校正，就無法有效掌控潛在的問題。
今天就以前陣子才剛結束的奧運會為主題，將「舉辦羽球競賽」作為專案任務來簡單說明。製作時程表的方式很多，例如專業的Microsoft Project、免費的GanttProject軟體，或者使用Excel自己建立，只要能充分表達專案任務的時程規劃即可。我個人使用的簡易時程表如下圖，最左方欄位為負責人，橫向以時間軸表示，可以依據專案的規模、預計掌控的程度來決定每一格時間單位(天、周、月)，不同的色塊則是表示不同的工作任務，並且在最右側欄位顯示目前進度(也可以在任務色塊下方用其他顏色依完成比例標示進度)
在製作時程表的過程中，有幾個大原則如下 :
1.任務分類
嚴謹一點的作法，在製作時程表前，可先進行WBS的拆解(Work Breakdown Structure，工作分解結構)，目的是將專案工作分解成以交付標的為導向的數個任務，WBS通常是以樹狀階層形式展開，在此階段還不會考量執行、完成時間，但會盡量將任務拆解到可管理的大小(一般來說會盡量落在約80個小時可完成的工作量)。
2021年5月，台灣新冠肺炎確診數激增並進入3級警戒，同時也爆發疫苗不足的問題，至同年6月底，全球防疫排名(註1)更從最優的第5名一路滑落到44名，被笑稱是防疫吹牛，讓台灣在國際間顏面盡失，國人也一度陷入恐慌，在擔心疫情加劇封城的心理壓力下引發搶購潮。疫情爆發的原因有很多，我們無需過度批判，但從「吹牛」這個不名譽的稱號卻是值得省思的，是什麼原因讓我們在「佳玲」(註2)光鮮亮麗的外表下，潛藏巨大的隱憂? 在我們日常的專案運作中，是不是也有這種暴風雨前的寧靜? 是我們總是報喜不報憂，還是專案的生存遊戲中有什麼看不見的地雷?
用「吹牛」來形容或許過於嚴重，有些時候專案失敗並非刻意隱藏事實導致問題爆發，而是當下的時空背景會讓人忽略了一些星星之火，倘若專案正巧處在一個危險平衡的狀態下，那麼任何一點點失誤可能就產生牽一髮動全身的影響。不過，專案執行的過程中，確實有些舉動可以避免日後出現重大問題。
1.任務難易度是否分配平均?
簡單的事情先做，這是人之常情，但如果把困難的事情全部往後面排，就會出現專案前半段行雲流水，後半段卻跌跌撞撞的慘況。有個軟體業的朋友曾經跟我分享他的失敗經驗，有一年他的團隊被交辦開發一款企業內部通訊軟體，起初他們從其他部門交接取得一些參考資料，讓他們在初期的分析過程十分順利，期中報告也如期過關，但最關鍵的開發技術卻遲遲沒有進展，不僅團隊的技術尚未純熟，全部壓寶在一位資深工程師身上，也因為這項任務被安排在下半年度才執行，所以始終沒有被揭露風險，直到工程師宣告開發失敗，專案已經來不及調整方向，於是期末開了天窗，隔年一切必須重頭來過。
以上述的案子為例，任務的分配出現前後不均的情況，上半年主要著重分析研究，下半年則集中火力開發，一棒接著一棒進行，極端瀑布式的運作方式顯然必須承受無法回頭的風險。若要避免這種情況發生，就得在瀑布分段的銜接點之間，提早安排一些檢核點，確保下一個步驟可以順利接手進行。例如在企劃階段，工程師可先針對有風險的技術進行小規模實驗試做，一旦研究過程發現問題，還能即早修正產品開發規格。除此之外，每完成一項里程碑，PM最好重新檢視後續任務執行的難易度，評估是否需要調整，確保專案的運作維持適度平衡。
動漫【鬼滅之刃】2020年在台日掀起一波熱潮，劇中的鬼殺隊是經過選拔編制的團隊，負責斬殺惡鬼保護人類，其中主要人物性格鮮明，各自擁有不同專長，角色及任務配置十分明確。從專案管理的角度來看，R&R(註1)雖然是個看似簡單的佈達任務，卻充滿不少眉角需要注意，有時也對專案後續的執行帶來不小影響。本篇文章以【鬼滅之刃】的角色設定當做啟發，來探討專案角色與職責分配的重要性。
為何需要定義R&R
在【鬼滅之刃】劇中，鬼殺隊成員之一的嘴平伊之助從小在野豬群中長大，因此對於如何和人相處，以及身為鬼殺隊的職責並不是十分清楚，導致和炭治郎、善逸初次相見時因故大打出手，這種團隊成員對專案產生負面效應，常見的可能性包括 :
1.未能區分組織和專案之間的角色差異 : 專案的組織分工通常是暫時性的， 和成員原本在組織內的角色定位不一定相同，當成員的思考模式仍停留在原角色思維，或者仍以原角色的KPI目標來看待專案，就可能會產生自我利益與專案目標衝突的情況。這時候他們可能會優先提出對自己有利的規劃(例如投入專案的時間比例)，而間接影響專案的進展。
專案執行的過程中，經常需要透過各種圖表來向利害關係人說明進展，針對不同的階段或對象，所使用的圖表也有所差異。在敏捷軟體開發專案中，常用一種稱之為「燃盡圖(Burndown Chart)」的方式來展示進度。
燃盡圖是用來表示剩餘工作量的圖示。以下圖為例，藍色線段代表基準線表示每一天預估的剩餘工作時數，假設完成某一項任務所需的時間為300小時，在不考慮任何變數影響的情況下，剩餘工作時數會隨時間等量遞減，直到表定完成的日期時，剩餘時數等於零。紅色線段為實際運作後所繪製的曲線，每天消耗的時數不固定(如藍色長條圖所示)，因此線段會出現波動，在起初的5天內，紅色線段位在藍色下方，代表實際的情況較預期落後，直接第5天後，進度開始超前，並且在最後一天完成任務。
專案執行過程難免會遇到各種阻礙和困難，甚至不同專案之間的資源排斥，導致實際能投入的工作時數會經常變化，因此基準線和實際線出現差異是非常正常的現象，只是，利用工作時數來估算工作量及完成度，本身就存在不少盲點，要畫出像上方漂亮的示意圖並不容易，大部分的時候我們可能會得到更加扭曲的結果。
前一陣子重溫了《阿波羅13號》這一部經典電影(註1)，內容是描述NASA於1970年4月執行的登月計畫，發射後兩天因氧氣罐爆炸造成太空船嚴重毀損，三位太空人不得不使用登月艙作為救生艇逃脫，最後克服種種困難成功返回地球，被稱作登月計畫中「最成功的一次失敗」。閱讀過一些相關書籍資料後，發現電影算是相當鉅細靡遺根據紀實拍攝，在回味經典的同時，也讓我找到許多專案管理上可以效法的地方。
【風險應變準備】
風險管理的精神在我過去許多文章內都有提及，在電影中也充分反映了它的重要性，首先在訓練階段，除了預計執行任務的太空人之外，NASA還多徵選了一組預備人員，接受相同的練習課程，目的是當正選太空人因故而無法參與任務時無縫接軌。雖然需要備位太空人遞補的機率並不高，但萬一發生狀況而又無人可替代的時候，卻會直接影響任務的執行，造成的損失將難以估計。風險應變的方式可區分為「迴避」、「減輕」、「轉移」、「接受」四種，備位太空人的機制可以「減輕」風險發生時，人員交接、作業重啟的繁雜程序與資源浪費。此外，劇中我們也看到危機處理過程，地勤人員不斷藉由情境模擬，為受困的太空人尋找最佳的解決方案，這些舉動和成效更加凸顯了風險應變準備的重要性。
風險應變最大的困難在於，必須在事前做到何種程度的準備? 有些風險應變的成本只會發生在處理問題的當下，但有時如同購買醫療保險一樣，必須事前付出一定程度的投資，若風險未發生，投入的成本也無法回收。以阿波羅13的案例來看，備位人選若無法事先接受等質量的訓練，一旦風險發生時，銜接上就會出現斷點，屆時衍生的問題或許更加棘手。因此，為了妥善準備足夠的能量來應對風險，除了做好風險管理外，還必須進行成本效益分析(註2)，決定風險應變的準備程度，並於專案規畫初期就必須將風險應變所需的資源及成本估算出來，才有機會確實推展計畫。
在產品開發過程中，為了有效和不同角色溝通，軟體PM經常需要準備各種形式的資料，例如簡報、範例圖、流程圖、表格....，林林總總的資訊，目的就是要確保每個人對同一件事、同一個產品規格有足夠且具體的了解。資料準備越齊全，即便日後經過人員交替、任務交接，也能遵循相同的規則繼續前進，讓影響降到最小。
一個產品從發想到形成規格，勢必經過一段演進的過程，嚴謹一點來說，應該會有User Story、 Functional Map、Flow Chart、Wireframe、Prototype ...等產出，最後彙整成一份完整的產品規格書，而本篇文章將依據我過去的工作經驗，以及收集各方資訊後，分享一些製作Flow Chart(流程圖)的心得。
1.流程圖基本符號
使用統一的符號繪製，可以減少大家對符號定義的認知誤差，讓Flow Chart更容易閱讀，因此PM務必要熟悉畫法，才能和工程師有效溝通。PM的養成過程很少有一套固定的模式或標準學習曲線，部分原因來自於不同產業、不同公司對PM的定義各有差異，而PM本身要學會的技能也非常多，繪製Flow Chart成為容易被忽視的一項基本能力。多數PM熟悉各種不同的簡報形式，畫過各形各色的圖表，經常會為了簡報效果而美化、更替流程圖圖示，久而久之反而養成習慣，或直接將簡報用的流程圖放到文件規格中，造成其他人閱讀規格上的困難，因此，雖然流程圖基本畫法看似是一項簡單的技能，卻是PM必須要留意、時時提醒自己的。
