專案溝通與管理的八大流程心法
如何避免有溝沒有通?分享專案流程把控及溝通文件細節
本篇背景:
我們在管理一個產品和專案時，因為需要與不同的人對接合作，良好的溝通與明確的目標，才能讓參與專案的所有利益關係人用最有效率的時間和方式，滿足客戶或使用者的期待。
近兩年，我到了竹科的半導體產業擔任產品經理，負責公司為了推動數位轉型的雲端 CRM 產品導入專案，在專案過程中，我必須接觸到大量的人，舉凡如對外有產品原廠、外包商、顧問方、產品代理商，對內有內部不同部門的工程師、採購、行銷、業務、法務、財務等不同的團隊。
本篇目的:
為讓這樣的大型專案順利，如何協調與使用資源(人力與金錢成本)的最佳化，中間的溝通管理成了最重要的關鍵，那麼如何達到有效的管理與溝通，是我本篇要闡述的重點。
而好的溝通就仰賴有效率的文件，考慮本篇篇幅過長，後續我會再出下面三篇文章，而此篇先就專案的流程分享給大家。
一份好的 SOW(State of Work)應具備什麼?
一份好的 BRD(Business Requirement Document)應具備什麼?
一份好的 FRD(Functional Requirement Document)需具備什麼?
做專案的角度和產品不太一樣，產品經理關注使用者體驗，可能用迭代的方式產出自行開發的產品開發，並在過程中做許多產品探索與測試，與產品能否受使用者喜歡為重點。
而專案通常因應公司商業目標，有很明確的規格與目的，我們本次專案是期望透過微軟的雲服務產品導入，做資料和不同地端系統的整合和分析，打造完整的客戶關係管理平台。因此是偏向專案管理，而身為專案執行的角度，在做專案時，關注專案的起訖以及專案成敗，因此首先界定範圍很重要，當需求無限上綱，專案就可能因資源不足而導致延後上線或失敗。
以下分享我做專案的整個流程:
1.專案起始:
一開始我們會先定義好專案目的和範圍，若有外包及客戶也會在本階段進行採購、報價和契約簽訂等流程。
2.定義專案背景和目的:
身為專案經理我們先定義了本次專案的背景與目的，是基於什麼樣的公司願景和方向，我們想要達成怎麼樣的事。通常一句話就能精闢說明最好。例如我們就是:
透過導入雲端服務XXX，打造完整的客戶關係管理平台。
3.定義專案範圍:
✔組織範圍:XXX公司全球銷售中心(若集團有不同的業務經營地區，也需劃分清楚)
✔服務範圍:若是你的專案有客戶或是顧問方，這樣的範圍劃分就很重要，傳案過程中的腳色權責，及應負責的事項，也不會產生後續合作不愉快或是成本增加的 CR(change request fee)費用。
✔商業範圍:向我們是打造一個 CRM 系統，就需要界定是基於銷售管理?行銷管理?客服管理?的範圍界定。
✔資料範圍:會使用到哪些資料庫?哪些 table?哪些欄位?
✔技術範圍:如顧問方基於 XXX 雲端產品服務打造平台，而我們自己的 IT 人員就要負責網路環境配置、開通防火牆或地端資料庫整合與建置等工作。
4.Kick off:
啟動後我們進入到規劃之前，我們會先召開一個專案的啟動會議 (kick-off)，在這場會議上我們找來公司的高層主管以及所有利害關係人，在這場會議同時佈達所有人此專案開啟，並在會議上闡述專案的背景目標，以及專案的組織人力架構和專案起訖，此一目的除了幫助大家初步對於專案的執行時間、背景、權責有所了解，其實對於專案經理來說，是一個很好的時間所有關係人佈達權責，未來有需要資源協調時，才好進行溝通。
像我們是屬於大專案，參與這場會議的人員就多達 50 人，並且會設置專案委員會，其中包含到資安、稽核等人員，對於公司第一次做雲端導入的服務，有別於以往我們的系統都在自己地端的資料庫，勢必有許多資安的控管，因此在這面的審慎評估和對於用戶的教育訓練也是很重要的。
5.用戶訪談規劃:
與需求方進行一系列藍圖規畫的溝通，這個階段會先從用戶訪談開始，勾勒出解決方案的架構、藍圖，進而產出有明確規格的技術文件。在需求訪談階段會把 business 的流程畫出來，進而把轉化成產品的流程也畫出來。藍圖包括產品的功能模塊及架構。
用戶訪談技巧:善用 user story 句子，如身為 XXX 單位，我每天處理 XXXX，會花費大量時間或 XXX 成本(造成不變的原因)，因此期望透過本解決方案，可達到 XXX 效益。
6.專案執行:
專案層面的執行包含到技術層面和管理層面，管理部分也分為每個階段的驗收款項及定期匯報溝通，因此有以下兩方面:
6.1溝通管理_例行性會議:
在執行專案過程中，為讓開法者與需求方期望相符，並向高階主管匯報專案進度，我們會定期招開週會和階段性的專案匯報。
週會:讓專案經理追蹤開發進度，並同時對齊開發者與需求方的期望。
月會:讓專案經理向高階主管介紹專案重要里程碑，並請益需要高層下決策的議題。
6.2技術管理:
以下的技術管理也都有其對應的交付文件，才能達到有效符合使用者需求的方案，因此寫以下文件時，文件說明、術語定義和修改人改動的時間都需要註明和記錄到，當初我們在對接雲端和地端的系統欄位時，就因為彼此有修改的時間差，導致資訊落差，並且在每項 task 中定義好負責的 owner，才能達到有效管理與讓 PM 追蹤到對應的人。
• 需求分析
• 方案設計
• 系統部署
• 功能實現
• 測試工作（UT 單元測試，SIT 系統集成測試，UAT 用戶接受測試）
• 系統集成
• 數據初始化
• 用戶培訓
• 知識轉移
• 運維
7.風險管理:
影響專案成敗的有很多，上述的所有文件和溝通管理方法都需註明以下，以達到風險的控制，從人(定義專案組織人力圖)、事(定義功能模塊負責人)、時(定義專案起訖時間和各階段需抵達的里程碑)、物(各階段的交付物，如藍圖、規格書)。
而在規劃之外，仍需預留風險，在初估時間時，就要抓一點 buffer，我們就有因為使用者不斷提出需求變更(CR)，也因為工程師們同時接不同專案的需求，有時候有緊急系統搶修問題，導致的排程不如一開始安排，導致專案延後上線，而這時可以評估這些變更需求的優先順序及是否要做的迫切性，因我們大型專案對接的 user 很多，我們也會從眾多 user 們中劃分 key user (集中蒐集需求)、user lead (最終拍板需求是否做的)，這時候就會請 user lead 出來做最終的資源與成本的權衡，以及對專案風險評估，以決定這項變更需求是否要做。
8.維運管理:
目前我們已成功導入雲端服務，但進入維運期間雖代表專案結束，此時角色又切換為產品經理，需繼續維運產品，並接手接下來的產品需求，當使用者因應商業需求的變動，會有不同的需求提出，而身為產品經理的我們，在接到使用者的反饋需求後，先思考使用者為什麼有這樣的需求，而不是一收到就做，更可以往前想一步，幫助使用者釐清自己的需求和目的，進而衡量技術的可行性，再進行界面和使用者體驗的優化。
除此之外，上線以來也會時不時有使用者反映狀況，這些狀況從原廠的server 掛掉，到平常的復機檢查導致系統排程出錯都有，除了控管系統的狀況，也需要有更多監控系統的效能優化和自動化檢查的機制，確保產品的穩定性，進而在產品成功上線後，持續追蹤使用者體驗並優化迭代！
總體來說，專案及產品管理還有非常多值得分享的細節和注意的避雷點，也因各種不同公司的專案及公司型態會有不同的踩雷點，我會繼續分享，也希望大家一起交流討論！
如果你喜歡我的分享，請幫我拍拍手👏👏👏
我會更加努力產出文章的喔，你們的喜歡是我的動力！如果你對我在祕魯做志工(領導力老師)和背包客的故事感興趣，也歡迎來我的粉專看看：
