內化專案管理知識，在跨領域活化應用 @ 電影與生活中的管理學

我自認是一個「不務正業」的人，學生時期主修氣象學，就業後先從氣象產品的應用，慢慢跨足到專案、產品的管理，歷經不同角色的變化。在跨領域的轉換過程中，專案管理知識扮演了很重要的角色，它讓我能夠從容掌握工作進展，並有效整合資源，就算是不甚熟悉的領域，也能夠維持不失控，爭取補足Domain Knowledge的時間。

從跨領域的關聯性切入，隨時練習專案管理
當決定從氣象產業轉換跑道成為專案經理，我深知要能活用管理知識，才是我可以和同業競爭的優勢，因此跨領域前的練習，就成了重要功課。首先，要找到專案管理知識在自己熟知領域裡的關聯性，從中去思考如何運用管理技能來處理? 有沒有其他解決方案? 或是它背後的原理是不是有共通點?
以氣象預報為例，要歷經初始資料分析、綜觀分析，最後才是預報決策，和專案管理有什麼關聯呢?
1.初始資料
在進行正式的預報之前，需先匯集最近的觀測數據，反映環境場的初始狀態。同理，在專案管理的世界，所謂初始資料，可能是人員技能分佈圖、材料設備價格，甚至是市場競業分析等各種有助於理解現況的資訊。
2.綜觀分析
收集資訊的目的，在於藉由這些數據來分析現況，在氣象學中，稱為綜觀分析，所謂綜觀，就是要站在一個完整的視野上，俯視全局，過程中還有一項重要的「尺度」概念，例如當我們探討鋒面移動時，會忽略小尺度如建築物大小帶來的細微變化。若用在管理上，則類似抓大放小的概念。舉例來說，一個創新產品的重點在於快速測試市場反應，並找到對產品有決定性影響的價值，至於一些極細微的UI設計，雖然會對操作體驗有加減分效果，但在這階段或許可以降低一些要求，把資源挹注在更攸關成敗的事情上。
3.預報決策
有足夠的資訊，並且找到關鍵因子，便能針對特定項目進行預報，但預報仍有一定的不準確性，正因為如此，才需要配合日常的監控作業，隨時掌握變化。專案執行的過程中，同樣會遇到許多不可測的因素，所以規劃階段雖然已初步辨識了風險，並訂定可能的對策，但仍需要定時監控，反覆從各種徵兆中判讀風險的狀態並修正應變計畫，才能讓專案穩定維持在正軌。
簡單來說，專案的定義為「有表定的時間、工作範疇與預算，並且通常由一個團隊來運作、完成特定的產出」，因此，除了工作上的關聯，生活中也有許多專案管理的應用，例如居家裝潢的準備與驗收、參與路跑的前置作業及訓練過程等，甚至從電視節目、電影中看到的情節，只要符合上述的某部份條件，都可以拿來做為練習標的。

跨領域的思維 - 如期如質之外的事
跨領域前的暖身練習，只是取得角色轉換的門票，真正的挑戰還是在於被賦予的任務。專案管理貴在如期如質，但sponsor往往期待的是專案成效與延伸效益，所以PM更應該要從商業策略的角度釐清「為何而戰」，讓專案在「不鍍金」的前提下，發揮最大的價值。釐清為何而戰的好處，除了便於讓討論過程對焦，也有助於團隊同仁自發性去努力達成專案目標，專案的成功機會自然就會提升，對PM來說只有利而無害。除此之外，藉由辨識方向的過程，可以看到更多市場上的資訊，同時練習對商務決策的敏感度，對於有心要轉換至產品經理的人來說，是一項非常重要的功課。
在專案管理的起始流程中有一個非常重要的任務是「確認範疇」，它不僅在釐清專案執行的邊界，某種程度來說，也是釐清為何而戰的關鍵步驟。我過去曾有一個失敗的經驗，當時負責一個集團內部的軟體建置案，專案本身的目標是建立一套供內部同仁使用的即時通訊App，但老闆背後的真正盤算，是希望藉由內部專案來建置可商業化的軟體架構。由於我自己和團隊成員未能充分理解專案目的，任務拆解的過程便朝著簡化的方向設計，包含使用open source、建立彈性低的資料庫結構等，專案最後雖然「如期」完成，但它的「質」僅限於專案本身，並未達到老闆心目中的「值」。
那一次經驗之後，我開始對專案的範疇定義更加謹慎，並嘗試從不同的角度來審視專案目標，雖然有時會耗去不少時間，但透過不斷論證的過程，專案的目標就會更加明確，對後續的工作展開有非常大的幫助。
「Do the things right 」是PM所需具備的基本能力，也是執行力的展現，「Do the right things」則是一種思維與原則，是在動手做之前，PM要時時提醒自己去努力的方向。

跨領域的執行1 - 掌握流程，事半功倍
專案經理和產品經理的英文簡稱都是PM，一個是Project Manager，一個是Product Manager，由於角色定位的關係，工作思維也會不太一樣，但在某些產業裡，兩種PM不一定有明顯的區分，至少在我的職涯歷程中，幾乎都是處在兩者並行的狀態。企業對人才的期許是多元的，不會因為你是專案經理就只求如期如質，而對產品經來說，專案管理也是必備的知識之一。人本來就不是全能，有些人靠專案管理技巧彌補對產品的熟悉度，有些人則從產品規格去找問題的答案。
我過去經手的案子常以新功能開發為主，在釐清為何而戰、定義範疇之後，我會強迫自己勾勒第一版的WBS及時程表，雖然某些工作彼此有相依性，無法準確估算，但有了第一版後，至少對於後續的工作有初步的認知，才能辨識要將資源投入哪些關鍵任務，或者趁此時補強自己的domain knowledge。除此之外，初接手不熟悉的工作時，不只PM本身，sponsor可能也會有不安感，若能夠先提供可視的專案里程碑，也可以減緩來自sponsor的關注壓力。
這套工作的基本邏輯，曾經讓我在短短4個月內，空降主導一個流程管理軟體的2.0版建置。如同前述氣象預報的流程，我先收集了大量1.0版本的相關資訊，作為改版規劃的「初始資料」，接著和主管及相關同仁討論改版的主要目的與方向 – 特別是商務面的考量，完成我的「綜觀分析」、釐清為何而戰。最後，再將這些資訊轉為具體化的工作包與時程，並且確保訂定的里程碑能有效呼應專案目標，如此一來就能向sponsor進一步爭取更多的資源與時間。

跨領域的執行2 - 產品是持續不斷的小專案
釐清為何而戰、定義了範疇、也拆解了工作任務，另一個重要的工作是風險管理的運用。這裡所謂的風險管理，不單指「執行」過程的風險控管，一個產品的走向通常會歷經多面向的商務決策，每一個決定的背後，都有衍生的風險或放棄的機會成本，PM務必要將風險管理的層級往上拉升到整個專案甚至整個產品本身。

新產品為了快速測試市場反應，有時會簡化UI設計，造成客戶操作體驗變得較差，這就是商務決策上的風險。以專案的角度來看，被捨棄的UI原本就不屬於專案範疇，但換個角度來思考，何不將它視為下一個專案?

產品開發過程有一個重要的PDCA循環(Plan、Do、Check、Action)，每一次PDCA的運作，都可以視為一個專案的生命週期。專案本身在結束的階段，就對Lessons Learned有所著墨，狹義來說是將專案執行的經驗透過文件記錄來保存，提供給其他專案參考，廣義來說，也可以用來闡述這一個專案還有哪些被捨棄而未執行的項目，是否值得下一個專案繼承? 如此一來，產品便拆解成數個延續的專案，對專案經理來說，執行上就相對容易了。

依據上述的邏輯，我的2.0版軟體實際上也可視為一個過渡專案。我和主管們釐清目標客戶的優先順序，拆解客戶需求，將重要的、可快速改善的功能列入2.0版範疇，其他暫時被捨棄的功能如客製化表單、外部檔案匯入等，可能會造成部分客戶抱怨，這就是我們所要面對的風險。源自於風險管理的精神，我習慣將重大決策的論證過程紀錄下來，作為下一次爭議發生時的佐證資料，這個習慣也讓我無形中養成對商務策略的理解，同時也成為後續2.1、2.2版「為何而戰」的重要資訊。

當產品被拆分成數個專案，專案之間彼此就有強大的關聯性，於是我們在定義2.0版範疇的時候，就同時保留部分擴充性，而每一種功能的擴充，又會依據預計實現的時間點而有不同設計。藉由這種專案拆解模式，不斷練習、改善，讓我對於產品規格有更深的認知，清楚了解每一個功能的存在原因，久而久之，也就更能勝任產品經理的職務。

檢視我自己的職涯發展，我將專案管理視為一種工作邏輯，而不侷限在專案經理的角色應用上，當內化了專案管理知識後，可以應用在許多不同的地方，不論工作或是生活上。一旦知識被活化應用，就如同程式語言內的物件一樣，隨時可以被繼承使用，不管跨足到哪一個領域，都能找到立足點。