這個案子是個跨年度的案子，實作歷經17個月，從選商到上線大約2年。做專案從來沒有容易的，但這個案子特別難，難在組織的複雜度、溝通文化及公司的期待，與其說是專案的過程整理，不如說是做零售業數位轉型這幾年的縮影吧！這篇先寫一些專案管理面的事情；另外再寫一篇關於產品設計的。
專案背景
先從專案背景開始說起吧。這是一個新產品，要取代過去既有的產品，不是從原有的東西上面進行翻修、迭代，而是要重新做一個。因此，也被期待保有既有的功能，大部份是會員功能，再加上一些新的應用流程。過去的營運，沒有太多數據可以參考，把App當作一個無機行銷工具，缺乏量化數據作為迭代基礎，再加上營運單位完全站在業務角度在做設計，一般消費者只是把這個App作為會員卡在使用，其他的行銷及產品內容露出，因為使用動線不佳，並沒有太多人使用。
另外，我所屬的部門是公司內部新興部門，在組織中雖被賦予數位轉型的任務，但過去從沒有營運或行銷任何數位產品，既有需求雖可與營運單位討論，但溝通不是很暢通，整個產品的規劃、提案都只能自己來。再者，公司過去（其實到目前為止都是）沒有數位產品的認知，談整個App是從各項功能去拼湊堆疊起來，事業體很多，大家都覺得自己的功能很重要，不太考慮使用者的角度。
最後是我的角色及定位，我的大主管是軟體導入顧問出身的，在他的認知中的PM是Project Manager，負責時程跟需求範圍的控管，成果應該怎麼設計、長什麼樣子，是顧問（廠商）的工作；Product manager產品經理這樣的角色，不只在意時程，更要勾畫產品藍圖，為之後做準備，對他來說就只是範圍管理，聽說戰死在沙灘上已離職的前輩也跟他做了許多次深度的溝通，仍沒有太大的效用。在接到這個案子的時候，不管上面的期待是什麼，我就不是以project management的角色在看自己，做了很多產品經理的工作，事後也證實這樣做是比較恰當的，特別是在我們這麼複雜的組織當中。 App的設計及開發，是找了外部的開發商，負責需求訪談、wireframe到整個app前後台的開發。
組織的複雜度
這個專案是跨事業體、跨部門的案子，就是A公司跟B公司的行銷單位跟營業單位，還有中心化的C處以及奇妙的D部，前前後後參與專案的業務單位大概有8個，超過40個人。
先說說A公司吧，過程中最好溝通的事業體，營業單位可以提供零售現場的服務流程，甚至整理成流程圖，不過因線上、線下定價不同、業績分屬不同單位，在設計流程確認的時候，常常會變成利潤爭奪戰，也反映在最後的成品上面，某些地方會突然岔出一條路。商場的部分則是由行銷主導、整合營業單位的需求，在需求訪談的過程中，時任B公司行銷主管屬於較強勢型，嘗試爭取首頁的版位，但相對的，做事也很有效率，能夠快速的給回饋、與營業單位取得共識。C處在組織屬性上有點像是營運單位及行銷單位的綜合體，再加上配合新的制度推動，App中至少有50%的規劃都與他們有關，要求參與所有的會議，偶爾在會議中會提出超過範圍的需求，需要花一些時間去協商。再來是很妙的D部，整個App與他們業務相關的功能是「聯絡客服」，卻也要求參與所有的會議，並且在各種會議上大鳴大放，代表各種客戶立場，有時候會以少數的客人意見或反應當作全貌，並希望被納入整體設計，非人工或特案處理，而且相當堅持，花費許多的溝通成本。
系統、技術的複雜度是因為為了要支撐龐雜的業務，每個業務單位至少會有一個對應的系統在協助他們的業務進行，但因為這些業務單位都提了需求，自然串接少不了，最後成了一個與10個系統串接超過100個接口的App；有些開發又是系統在外包，系統負責同事就讓我直接對他們的廠商。在這樣的情況下，沒有一個技術PM或是架構師作搭配，在過程中磨到我都會看規格書，可以直接跟他們溝通。遇到開發同事沒有花心思去了解前端的業務需求，開出來的規格跟系統運作邏輯根本對不上，又或是開發完了，但品質很差根本不能用，真的困難到一度好想放棄，也曾經氣到哭。只好自己開後台研究其他的系統，轉化成業務邏輯，再度溝通；自己寫串接測試的腳本，拉著工程師坐在旁邊直接開程式驗證給我看。現在回頭看真的不知道自己到底經歷了什麼。
溝通文化
身為一個文創公司，大家都是知書達禮的文化人，溝通文化就是以和為貴，什麼事情都要共識決，就算有意見的人提出意見也都是說「我建議xxx」、「請專案團隊評估ooo」，若評估結果是不執行，就會說要開會，想知道其他人的想法呢等等，決策流程很長，大家不喜歡下決策，卻又希望別人的決策是按照他們的想法走。PM是專案團隊不是產品團隊，沒有最終的決策權，卻又為最終的決策負責，還有各種跨部門的工作，有些只是跟App沾到一點點邊，大家也都會丟給我去溝通，為了要讓事成、為了不被影響時程，很多時候真的只能跳下去推動。在過程中常常會有每個人都是我老闆，可以叫我做什麼的感覺。
公司的期待
如同一開始說的，從產品定位跟規劃是由我做提案，交由開發商做後續的需求訪談、設計跟開發，每個月需要跟董事長報告進度。一開始只是被當作一個新的行銷工具，後來隨著公司「全通路」的策略發展，逐漸轉變成一個串聯線上線下的重要應用，開始有些期待。這樣的轉換讓上線行銷活動開始被重視，也爭取到了一些行銷資源，很樂見這樣的發展；但也因為是串聯線上線下重要的點，變成一個兵家之爭的應用，顧問、高階主管隨時都可能來一個隕石需求，即使有些聽起來不是很合理的應用場景，也需要花時間討論並給出迭代建議，偶爾也會被壓著在哪時間之前做完。面對隕石需求的管理，真的是一門藝術，必須要說的不得罪人，但又不影響原本的時程，是非常難的事情。
如何讓專案運行更順利
看完了專案管理的各種疑難雜症，還是要分享一下在能熬的過程中如何讓我活下來的一些小技巧。
- 善用公司文化 、掌握發言權： 在需求訪談及設計期間，我是每週都要發週報給公司的管理層（aka專案sponsor and PMO)，大部份的時間多為報告進度，沒得到什麼回應。但如果遇到有業務單位拖累進度（大概2天）或是有很多發散的意見，當週的週報就會直接亮紅字，有正面的得到回覆跟協助，後來就比較不會遇到被刁難的情況。掌握發言權：如果遇到一些爭執不下的意見，需要到管理層做決策，絕對把專案團隊（其實只有我一個人）的建議寫在簡報中並且在會議前寄出、會議上投影出來，做與不做的建議順便寫清楚，大部份業務單位喜歡在會議上用說的，比較難說服人。
- 手握長劍、戴上鋼盔往前衝：在跟廠商或是同事合作的過程中，先瞭解對方的個性可以提前預測後續事情被處理的效率跟成果，預先做好風險管理，當看到火柴點起來，就開始想辦法滅火，不能讓火燒起來，看到有可能會影響目標達成（如期、如質的上線），要自己跳下救火也在所不惜。例如這次有一些新的功能是跟第三方服務廠商合作的，權責的業務單位要嘛消極抵抗、要嘛說自己官階不夠無法整合，我寫了效益評估給權責單位看，也不太能夠推動，眼看就要上線了合作內容還是空的。在一次的會議上，直接給出建議的KPI，讓管理層親自確認目標，並指定業務單位主管去執行。
- 良好、暢通地向上管理 ： 雖然說專案團隊，但其實只有我一個人在管理專案，上面有個直屬主管。每當我遇到困難的時候，我會自己先想好一些可能的解決方案，再與他討論；發現問題（覺得要起風了）的第一時間一定先用line跟他回報，盡量不要讓他先從別人口中聽到這件事情。若是涉及跨部門的溝通，也通常是由我先去溝通，多次嘗試無效，才會請他出面回信或是開會。養成良好的溝通及默契讓主管當我的應援團，畢竟太多讓人心累的事情了，有時候不小心帶入情緒他也會帶著我從不同角度去思考，跳脫當下的情緒跟迴圈。
留言列表
