PM‧002｜產品經理該如何解決人力、資源不足的問題？新專案新產品開發須知

身為一位產品經理（Product manager），與需求、資源、數據、開發奮戰，是再自然不過的事。每天，PM 都需要參與計畫和執行，從決定設計方案，到開發細節的取捨，甚至資源的整合與切割，都需要參與決策。其中，也不乏跨團隊的溝通與協作。

不過，有時方向雖然確定了，卻缺乏資源、沒有足夠人力執行，這時候該怎麼辦呢？

資源，一般而言指人力、時間、金錢，而本篇想要討論的問題，主要聚焦於「人力不足」。

舉例來說，我目前負責公司主要 APP 中的一項獨立服務（此服務可以視為獨立產品線），常常需要與其他功能／服務整合，因此頻繁與不同團隊對接，以下是我曾經遇過的幾個情況：

• 公司有一個功能，可以用比較遊戲化的方式行銷；我們也想要使用這個功能來推廣使用，但原本的架構不包含我們服務。
• 公司的主要搜尋流程不包含我們，但我們希望能被搜尋到，也希望能出現在某些主要入口。
• 使用者帳戶頁面，希望能增添我們服務的某些功能連結。

這聽起來很殘忍，但從該 PM 的角度來看，追求並排出符合最大效益的開發優先順序，是相當正確的一件事。問題不在他，而在你的服務還太小，他看不到利益點，自然無法撥人手給你。

如果只從自己的角度思考、缺乏溝通，別人看不到你的需求與目標，你也看不到他的難處。

因此，身為新產品／新服務的 PM，除了必須讓其他人看到做這件事的價值。我們可以試著與對方溝通，換個角度遊說：「如果凡事都用既有的 ROI （投資報酬率）角度評估，那麼新服務當然分不到更多資源，也無法獲取更多曝光。但這樣的評估未必是正確的。」

除了說服對方從其他方向檢視資源調撥順序，還有什麼是產品經理可以做的呢？當我們遇到產品開發需要更多資源，直接溝通卻不被支持時，我們可以是著爭取產品高層的共識與協助。

與高層溝通時，旨在定調既有的產品線，應該分出多少版面或資源，投資在新服務／新產品的開發。獲得共識後，再與相關功能團隊溝通，同步所有利益相關人（Stakeholders）的認知。

與此同時，提供你自己的數據與用戶研究成果，分析這樣的調整，可以為新服務（非整體服務）帶來多大影響。

舉例來說，若我們改善新服務的搜尋成果，對整體服務只有 2% 的影響，但卻能改善 80% 新服務所帶來的用戶之體驗，提升20%留存。如果新服務具有可預見的未來影響力，那這份投資就值得。

從上而下取得共識後，溝通的阻力會比較小。只要過了共識這一關，提需求的困難就會小一點。

溝通時，身為新產品／服務的 PM，也當盡其所能拆解需求（breakdown），讓需求限縮在最小但有效率的實作與測試，避免提出龐大卻難以執行的期望。

我的作法是，先將需求盡量視覺化，帶著圖示與流程圖先找工程主管討論。在「能交付最小且最快的測試模型、並能完成初步成效測試」的前提下，排出開發階段、工項與階段交付目標。

視覺化的優點，是將對方想像中的「需求怪物」拆成小塊，降低「很麻煩」的感覺。而討論開發順序與目標，則可以幫助你在進一步的跨團隊協調時，藉由較為具體的規劃，幫助所有人聚焦同一方向，先做最優先的調整，同樣也能降低對方心中的阻礙。

先做最優先調整，其他則看測試成效再來開發，也能避免過度開發或過度設計。萬一之前的假設有誤，還有機會盡快收手或調整，避免過多的資源浪費。

在帶過多個產品團隊，經歷不同公司體制以後，我認為 PM 無論有沒有技術背景，都應該盡可能與工程主管討論清楚，避免有太多潛在的 dependency，或遇到「快速開發未必是最佳選擇」的情況。

PM 要能清楚提出對於商業、用戶難題的假想解方，工程主管則針對方案提出實作方法與建議，進而一起衡量最終解法，因此兩者的合作相當重要。

當然，有的情況是，即使拆分順利，溝通順暢，大家都同意該做、也對開發順序與階段有共識了，但還是擠不出資源。

這時我們該怎麼應對呢？

這時有個做法是，交出自己的工程師，由我們自行開發，對方工程師只協助 code review 與 merge pull request （PR）。

由於自己工程師是外部進入開發，程式架構、語言準則未必統一，對原先的產品也不一定熟悉，因此這個方法必然會比直接由原本的工程師開發還更慢。不過，有開始總比完全沒動靜好，至少不會一等就一年過去，開發還是遙遙無期。

當然，不是什麼開發項目都會這樣處理。

畢竟讓對該項目完全陌生的工程師，去研究別人的功能並完成開發，有時候還不如等一兩個月，對方有空再來做。但遇到不得已中的不得已、非改不可且預期成效很好的時候，跟工程團隊協調好就跳下去，就是個不得不的解法。

如果你也是新產品／新服務的主導人，下次遇到其他團隊因為各種考量無法幫忙時，不妨試試先尋求多數共識與支持，並適當協調資源共享。

就主管與我分享的經驗談，「不敢討資源」、「不敢尋求高層資源」、「不敢堅定與其他 PMs 協商」、「不敢開口說：只要你同意，我們可以自己做」，是很多新產品／新服務主持人的問題。

但很多時候時機過了就沒有了，拖下去只會讓產品失去機會／越做越爛，還是應該果決點爭取看看。

若你的假設看似合理，需求切分後也能讓人認同，不妨先嘗試要點最小資源，跑概念測試，再以實證結果爭取更多支持。畢竟，公司找我們來是尋求解法，而不是找你來看問題而已。看到問題卻不行動，跟沒看到問題是一樣的。

延伸閱讀：〈產品經理如何掌控「合理的」進度跟時程？〉