電影與生活中的管理學

隨著PM解決的案子越多，交辦到手上的專案也就越來越棘手，因為主管們發現你是專案管理的箇中高手，於是那些陳年無法結束的、犧牲無數同仁的，或者負責人突然消失不見的專案，第一時間就會想到找你來處理。在我的經驗中，多數延宕多年的專案都有一個共通點，那就是範疇過大或難以界定，造成後續經常性變更、專案成員缺乏共識等衍生問題，當問題一個接一個串起來的時候，想要找出根因對症下藥就變得更加困難，因為每一個環節每一項任務看起來都像是壞掉的零件一樣，卡住整個專案的運作。

前幾年有部名為「一屍到底」的日本電影，使用「一鏡到底」及「戲中戲」的拍攝手法，由於成功營造前後劇情的反差效果，加上演出逗趣，因此瞬間爆紅，在全球創下3000萬美元票房佳績，成為小成本電影的成功典範，甚至被譽為「神片」。最近拜讀該部電影相關的書籍，發現它的成功並非偶然，雖然投入的資源、成本極少，拍攝時間亦不長(僅有八天)，但不論事前的企劃準備、臨場應變等，都極需要良好的管理與團隊合作，絕對可以做為專案管理的學習教材。

低成本管理

如期如質是專案的唯一目標，但多數都達不到這樣的境界，那麼，執行專案管理對我們有什麼幫助? 或許從以下的角度切入，能讓被專案dead line追著跑的你釋懷一點...

1.減少過程中的慌亂感，讓自己多一點時間做事，而不是到處救火或時時刻刻開會。同時也可以塑造臨危不亂、先知的專業形象。

專案執行過程最為人詬病的問題，就是用戶或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之間常為一對多關係。

在過去，領導者多半擁有強烈的性格，以及類似東方傳統父權的權威感，但隨著資訊發達、社會氛圍轉變，新世代的領導者也逐漸發展出不同的風格，其中一種類型會謙虛地廣納意見，不以自我為中心，偶而甚至會暴露自己的缺點，尋求部屬協助，我們稱之為懂得「示弱」的領導者。

在日常工作中，尤其跨團隊協作時，難免會遇到已經談定的事情破局，或者本該對方處理的任務卻被甩鍋(註1)，這時候內心鐵定很想用力問候對方。不過，最近看到一些有趣的論點，原來經常性的「甩鍋」其實是一種認知失調，之後只要遇到被甩鍋的鳥事，內心想著「這個人勢必失調得十分嚴重」，心裡就著實舒坦了許多，還不由得替他感到辛酸呢。

根據腦成像的相關研究顯示， 人類在意識到自己做錯事情的時候，腦袋內的某個區塊就會啟用，而且這個區塊和生理疼痛的腦區是相同的，當這種類似疼痛的感覺過度強烈時，大腦就會啟動保護機制。身體碰到疼痛和恐懼時的反制行為是逃避，因此當大腦過度刺激時，將眼前所遭遇的責任推卸掉，就是大腦認為最簡單有效的方法。

製作時程表對於專案管理而言，可以說是一項基本但又容易犯錯的工作。何以說容易犯錯? 因為和風險管理一樣，隨著時間推移，工作時程、任務之間的關聯也會有所變化，如果沒有經常檢視、校正，就無法有效掌控潛在的問題。

今天就以前陣子才剛結束的奧運會為主題，將「舉辦羽球競賽」作為專案任務來簡單說明。製作時程表的方式很多，例如專業的Microsoft Project、免費的GanttProject軟體，或者使用Excel自己建立，只要能充分表達專案任務的時程規劃即可。我個人使用的簡易時程表如下圖，最左方欄位為負責人，橫向以時間軸表示，可以依據專案的規模、預計掌控的程度來決定每一格時間單位(天、周、月)，不同的色塊則是表示不同的工作任務，並且在最右側欄位顯示目前進度(也可以在任務色塊下方用其他顏色依完成比例標示進度)

2021年5月，台灣新冠肺炎確診數激增並進入3級警戒，同時也爆發疫苗不足的問題，至同年6月底，全球防疫排名(註1)更從最優的第5名一路滑落到44名，被笑稱是防疫吹牛，讓台灣在國際間顏面盡失，國人也一度陷入恐慌，在擔心疫情加劇封城的心理壓力下引發搶購潮。疫情爆發的原因有很多，我們無需過度批判，但從「吹牛」這個不名譽的稱號卻是值得省思的，是什麼原因讓我們在「佳玲」(註2)光鮮亮麗的外表下，潛藏巨大的隱憂? 在我們日常的專案運作中，是不是也有這種暴風雨前的寧靜? 是我們總是報喜不報憂，還是專案的生存遊戲中有什麼看不見的地雷?

動漫【鬼滅之刃】2020年在台日掀起一波熱潮，劇中的鬼殺隊是經過選拔編制的團隊，負責斬殺惡鬼保護人類，其中主要人物性格鮮明，各自擁有不同專長，角色及任務配置十分明確。從專案管理的角度來看，R&R(註1)雖然是個看似簡單的佈達任務，卻充滿不少眉角需要注意，有時也對專案後續的執行帶來不小影響。本篇文章以【鬼滅之刃】的角色設定當做啟發，來探討專案角色與職責分配的重要性。

專案執行的過程中，經常需要透過各種圖表來向利害關係人說明進展，針對不同的階段或對象，所使用的圖表也有所差異。在敏捷軟體開發專案中，常用一種稱之為「燃盡圖(Burndown Chart)」的方式來展示進度。

燃盡圖是用來表示剩餘工作量的圖示。以下圖為例，藍色線段代表基準線表示每一天預估的剩餘工作時數，假設完成某一項任務所需的時間為300小時，在不考慮任何變數影響的情況下，剩餘工作時數會隨時間等量遞減，直到表定完成的日期時，剩餘時數等於零。紅色線段為實際運作後所繪製的曲線，每天消耗的時數不固定(如藍色長條圖所示)，因此線段會出現波動，在起初的5天內，紅色線段位在藍色下方，代表實際的情況較預期落後，直接第5天後，進度開始超前，並且在最後一天完成任務。

前一陣子重溫了《阿波羅13號》這一部經典電影(註1)，內容是描述NASA於1970年4月執行的登月計畫，發射後兩天因氧氣罐爆炸造成太空船嚴重毀損，三位太空人不得不使用登月艙作為救生艇逃脫，最後克服種種困難成功返回地球，被稱作登月計畫中「最成功的一次失敗」。閱讀過一些相關書籍資料後，發現電影算是相當鉅細靡遺根據紀實拍攝，在回味經典的同時，也讓我找到許多專案管理上可以效法的地方。

【風險應變準備】

在產品開發過程中，為了有效和不同角色溝通，軟體PM經常需要準備各種形式的資料，例如簡報、範例圖、流程圖、表格....，林林總總的資訊，目的就是要確保每個人對同一件事、同一個產品規格有足夠且具體的了解。資料準備越齊全，即便日後經過人員交替、任務交接，也能遵循相同的規則繼續前進，讓影響降到最小。

一個產品從發想到形成規格，勢必經過一段演進的過程，嚴謹一點來說，應該會有User Story、 Functional Map、Flow Chart、Wireframe、Prototype ...等產出，最後彙整成一份完整的產品規格書，而本篇文章將依據我過去的工作經驗，以及收集各方資訊後，分享一些製作Flow Chart(流程圖)的心得。

一個好的產品從企劃到完成，就好比主廚費心烹煮佳餚的過程，從一開始決定方向、挑選食材、構思做法，到料理時不斷測試口感並調整，最後確認品質、擺盤、出菜，步驟缺一不可。也因此，讓我想到MasterChef Australia(註1)這部澳洲烹飪實境秀的電視節目，該節目透過一連串不同主題的競賽，每周淘汰一位參賽者，直到選出冠軍為止，在過程中，可以看到不同參賽者對同一種主題或料理的詮釋，在口味、擺盤等各個面向皆有差異，但執行時所展現的精神卻與產品及專案管理思維不謀而合。

從專案管理的角度來看，廚師製作料理的過程，符合專案「在有限時間、資源內，交付特定產出」的基本定義，節目單位所設計的題目，則可視為sponsor的專案章程，它定義了料理的概念(可能要求參賽者複製經典異國料理，可能是針對某個季節、某段回憶去發想)，也提供可選用的食材，相當於專案的基本方向及限制條件。在這初步的範疇之內，便是廚師可依照自己的想法去發揮創意的空間，而他們接下來所展開的工作，約略可以歸納為以下幾點 : 

職棒場上有一句名言 : 贏球治百病。意思是說球隊若是能贏球，很多缺點都可以被忽略，相反的，一旦球隊處於戰績低迷狀態，團隊向心力(也就是所謂的休息室氣氛)就會成為重要的檢討項目。

團隊建立的過程大約會歷經幾個階段 : 

在產品的生命週期中，必須先歷經新創期、成長期後，才能進入穩定發展的成熟期，但多數新創產品在進入成熟期之前，就紛紛失敗退出市場，這些失敗的寶貴經驗，都是下一個新產品茁壯發展的養分。我曾經待過兩家新創公司，過去的職涯也參與多次大大小小的新產品、新服務開發，這裡列出幾個我認為導致產品失敗的關鍵，一方面讓自己作為警惕，另一方面也提供給大家當參考，避免重蹈覆轍。

雖然產品失敗的原因很多，且環環相扣，我還是依自己的經驗，盡量將之歸納為三個關鍵，分別為市場認知、團隊認同、執行力，這篇文章就先來談談新產品在導入前，對市場的掌握程度，產品人或多或少知道，或聽過STP理論，我想從中來進行一些簡單的剖析。

加利口罩商在2020年9月遭爆進口大陸製非醫療口罩，並且混充MIT醫療口罩在藥局及實名制通路販售，不當獲利，但加利負責人林明進卻反批評政府壓榨口罩商，不但以低於市場價格徵收，且徵用量高、時間緊迫，加利為了達到政府的徵用量，員工只能日以繼夜趕工無法休息。關於加利是否違法，以及政府徵用口罩的過程是否有瑕疵，這點得交由相關單位調查，我們不予評論，但從專案管理的角度來看，當目標時程緊迫的時候，真的只有加班一條路嗎? 或許我們可以從幾個方向來著手。

1. 確認Deadline的可調整性

時程估算一向是讓PM頭痛的工作，應該有許多人和我一樣，經常會陷入期望值和估算值的拔河。所謂期望值，是利害關係人對專案完成時間的期望，和可行性無關，通常較為偏向情感導向。估算值則是經過團隊成員討論取得共識的預估時程， 一般來說，時程估算有幾種方式 :

1.專家判斷 : 顧名思義，可請團隊中對該項任務較熟悉的成員來評估，或者尋求專案外部專案提供意見。

身為產品經理，經常需要製作product roadmap來說明產品的相關資訊，但到底一個好的product roadmap需要包含哪些資訊呢? 工作多年以來，我發現一直很難找到一個明確的定義，似乎每一個主管要求的都不太一樣，大家所繪製出來的roadmap形式也各有不同，直到最近在國外網站上看到一篇相關文章，原文標題為Product Roadmap: Key Features, Types, Building Tips, and Roadmap Examples，看完後覺得心有戚戚焉，決定分享一下我的心得。

首先，什麼叫做product roadmap? 顧名思義，它叫做產品地圖，目的是指出產品所在位置的一份地圖，而它要勾勒的相對位置，是產品願景和公司業務目標之間的距離，因此我們通常會用一條時間軸，再加上幾個重要的產品要素來組成。

這一篇是舊聞新發，來自 馬克 畫作所衍生的發想。

老闆影響專案效率、不受下屬喜愛，這個問題不管在哪一個管理階層都會發生，不論下屬貴為經理、協理、副總等，或多或少也聽過抱怨，只是不同位階的人表達的方式有異，情緒轉換的功力也有深淺之別，謾罵之餘，還是可以學學人家的情緒管理與正面思考的態度。

雖然溝通占了專案管理百分之八十的時間，但這並不代表專案經理的工作就是出一張嘴，因為溝通的方式有很多種，除了當面對談之外，舉凡信件、會議、簡報、文件等，用來將某些事情傳達給另一方的方式，都在溝通管理的範疇內。那麼，專案經理顯然是紙上談兵的高手囉? 事實不然，為了產出足以說服所有利害關係人的資料，專案經理必須將原本雜亂的訊息彙整成有條理的報告，一份60分的簡報或許花不了太多時間，但要完成一份80分的簡報，除了讓數字說話之外，背後要付出的吸收時間就非常多。

我的第二份工作是擔任App的專案經理，當時公司導入CMMI管理框架，因此有數量非常多的文件必須在專案生命週期中產出，和第一份工作放任式管理有著天壤之別，因此也了解到同樣身為PM，在不同的組織管理政策下，會衍生出截然不同的工作型態。