【PM 心得】對專案負責：從 2 個面向看 PM 如何發揮價值
踏入數位專案領域已近 3 年，對於 PM 應該扮演什麼樣的角色有些粗淺的心得，現在回頭看剛入行的自己，滿慶幸中間經歷了許多事而有所成長，因此也把心得分享給各位，希望能對正在閱讀的你有所幫助。
回想剛入行半年時，我發現了 PM 這個職位的尷尬處境：
專案執行的每件事都是我的事，但視覺設計、前端開發、程式串接，卻沒有一個是我的專業領域。每天在做的就是接到客戶修改，換句話說給設計師 / 工程師聽，然後再被設計師 / 工程師檢討一輪後，回去把難處或建議解法告訴客戶，客戶再把問題重複一次，如此周而復始，各種待辦事項也跟著春風吹又生。
接著隨上線時程逼近，客戶照三餐打來問候進度，客戶主管好說歹說要求再加緊趕工，同時各種無中生有的修改如潮水般湧入，上線時間迫在眉睫，需求單位還在繼續天馬行空的許願。而我，看著當初埋頭苦幹拉出來的時程表，如此的精美卻無法實現。
在這樣一個專案裡，PM 到底管了什麼、發揮了什麼價值？除了擋需求、為客戶提出的修改判斷是否合理之外，PM還能扮演什麼角色？
每每心中浮起這個疑問，前輩的話就會冒上心頭「你是公司的窗口，你會最了解客戶要的是什麼」，但真的就只有這樣而已嗎？最了解客戶的不是客戶自己嗎？我在中間當傳聲筒的意義是什麼？
隨著經驗慢慢累積，我觀察到周圍總有些 PM 能快速驅動團隊、贏得客戶的信任，並讓團隊運作的有條不紊；也有些 PM 則經驗略顯不足，拼命向各成員來回傳話的同時，整個團隊卻還是一片混亂。記得我負責的第一個大案子需要跟工程師合作，因為第一次接觸較具規模的前端開發方式，我明顯力不從心，害工程師需要不停幫我擦屁股。最後工程師實在受不了，對我說了一句「窗口的責任，就是要預先看見問題，必要時跟客戶打預防針」，雖然這句話指出了非常具體的「該做什麼」，但也讓我意識到 PM 的角色，除了被動應對專案執行的各種狀況外，還有更重要的，主動去做讓專案順利進行的事，算是幫我開啟了第一扇成長的大門。
不知道你有沒有經歷過，有時其他專案夥伴展現出來的某個行為，會讓你突然感覺「啊~ 他真適合做 PM !」。我自己常常在工作中經歷到這些瞬間，在海棠積極自主的工作環境下，更是很頻繁的在腦海閃過這個念頭，讓我忍不住好奇：這種突然的感受為何冒出來？隨著觀察次數變多，我漸漸能歸納出 PM 是如何影響專案的執行，以及能如何發揮價值。
一、隨時記住，自己是專案的負責人
若從市場上各家公司的 Job Description 著眼，PM 要略懂開發程式、UX、撰寫需求規格書、關注細節、追蹤合約及款項等等各式各樣的工作要求。首先這些論述並沒有錯，但我認為它們都只描述了 PM 實際執行的任務而已，而若要用一句話說出 PM 的職責，我認為是「擔任專案的負責人」，這代表 PM 要有對專案的最終結果，完全負責的心態。因此，PM 的職責分界比較模糊，也可以說比較有「人性」，除了處理必要的行政流程外，還有很多該做、能做的事情，有時連事情怎麼做都需要琢磨一下，比如同樣是告訴客戶專案 scope 已經改變，PM 要考量透過電話告知、email 告知、簡報告知，或甚至在討論時程時順便帶出這個議題，每次的做法可能因實際狀況而有很大的差異。而有時怎麼做或有沒有去做，影響到的不是此時此刻，而是影響到未來專案的執行能否順暢，換句話說，許多任務是在替未來掃除地雷。
這邊我必須要提，每間公司對 PM 的職責界定都不同，有些公司偏向文件彙整、合約簽訂等較為制式的檔案或規格管理而完全不會接觸金流，也有公司要 PM 負責業務開發和產品規劃，如海棠的 PM 就有較高的自主性，並且不必身兼 BD 或 UX 開發，而可以將時間專注在專案的進度和資源管理，如此可以確保專案的「管理」不會被「執行」排擠掉。但無論是哪一種 PM，其實都能選擇把自己的角色走得更大更主動，避免單純以被動的方式，接受執行時出現的各種狀況。總之，PM 要像照顧小孩一樣守在專案旁邊，一旦專案從提案階段轉移到執行階段，PM 就要打開風險雷達，敏感地發現任何可能出現的岔子，並提前找出應對策略。
二、主動找出解決方法，避免陷入 yes / no 死胡同
許多時候，PM 在執行的任務都有來自其他人的指示，比如按鈕樣式應如何調整、前端開發是否要使用框架、第一階段要在年底前建置完成等等等等，有些需求有商業上的考量，有些則是執行上的考量。但當PM傳遞的是非常具體的要求時，常常遇到的狀況是，執行端 (工程師 / 設計師 / UXD) 會直覺地以 yes / no 的方式評估可行性，一旦執行端表示無法照要求執行，就會碰到文章前面那個不斷在各方打轉的場景。比如客戶希望給網站新增一個線上客服功能，但工程師認為這會大幅延後上線時間，而網站的上線時程早已買好媒體曝光，連新聞稿都發出去了，更不可能延後。這時 PM 若直接把 no 做為答案回覆給客戶，就陷入了 yes / no 死胡同，要嘛客戶接受這項功能無法完成，要嘛工程師牙一咬把他生出來。一旦陷入零和遊戲，雙方都會認識到，不是你吃虧就是我吃虧，此時濃濃的對峙感就會蔓延開來。
經驗豐富的執行夥伴這時可能會跳出來 cover PM 的任務，也就是找出客戶需求背後的原因，也許只是要一個即時回覆的文字客服？那加一個按鈕外連到 Facebook 粉專私訊是否可行？也許是想要增加網站易用性？那是否能在網站上線後再補上此功能？無論解法是哪種，解決問題的第一步總在先找到客戶需求的核心，瞭解哪些是可以妥協的，哪些是不動如山的要求，只要找到了問題的施力點，就可以撬開這個僵局。
專案執行總有不照計劃的時候，此時 PM 的 mindset 很重要，要有目標導向的心態，積極尋找繞過問題的方法，否則如果像三師兄田雞的心態「要不就是公，要不就是字，永遠沒有中間的！」，那最後可能逼死自己的專案夥伴之外，跟客戶的關係也臭了，落的一個賠了夫人又折兵的下場。
專案管理是門很專業的學問，光是 PMP 執照就有很多要學的術語，比如 WBS 、專案要徑，或是風險管理等等等等，我也不在各位面前班門弄斧了。專業知識對一位 PM 相當重要，而同時健康的 PM 心態，也對專案成果有決定性的影響。這篇文章嘗試整理出我在數位 PM 領域打滾3年的一點點體悟，把籠統模糊的「健康的 PM 心態」做了點個人闡釋。當然它只能涵蓋到這 3 年的冰山一角，還有許多有趣的主題，如「領導跟管理的差別」、「職權跟責任的平衡」等等值得整理分享。
簡單概括，PM 身為商業考量和執行端的轉換層，一方面要考量專案目的及成果，如上線時間、執行品質、視覺效果有多 fancy；一方面又要注意想法如何落地，如實際製作工天、效果的可行性、上線後的維護性。這中間需求端跟製作端一定會不斷角力，而我的體會是，PM 的價值就在找出各方都可以接受的解決方案，確保利害關係人都能認同專案的成果。這可不只是遇到問題時提出替代方案而已，還有事前的避免風險發生、小心注意團隊的執行氛圍等等，都可以讓問題發生時，把影響降到最小。
結語
用說的總是比較簡單：專案管理就是 PDCA，把專案的四個要素 cost、time、performance、scope 都顧到，但實際做下去總是會遇到一堆雜七雜八的問題，所以 PM 要有鐵打的韌性，以目標為導向的看待自己的專案，並陪著每個專案走到最後一步。相信在網站上線的那一刻，用手機把玩自己一手拉拔長大的網站，你也會體驗到苦盡甘來的滿滿成就感。
希望以上的經驗分享，有點出一些值得讓你思考的觀點。如果這篇文章有帶給你一些收穫，歡迎按 clap 讓我知道喔！
