起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識高階產品經理如何做好跨部門協同項目
編輯導語：產品經理經常會經歷一些跨部門協同的項目，在這個過程中，如何協調好雙方或者多方的工作，準確理解對方需求，合理的拆分任務并且進行分工，妥善的解決項目推進過程中存在的問題是很重要的一件事，它關系著項目是否能夠順利的推進。本篇文章中，作者總結了高階產品經理應該如何做好跨部門協同項目。
最近有其它部門的小兄弟拉我做一個的項目，要把公司所有的產品整合到一個會員體系下，進行打包售賣。
筆者對他進行了一些支持，給了相應的產品方案，后續工作由他自己去弄了。
結果等他拉齊各部門的進行需求評審的時候，才發現幾乎只跟筆者一個部門溝通過，其它的部門當場表示一臉蒙B，項目中無法確認的過多，導致評審失敗，具體的細節又得重新聊過。
想了想這種跨部門的項目推動其實跟一個團隊做閉環的項目，從流程上來說雖然大體一樣，但落到細節，還是有很多門道。而且這種跨部門協作的經驗也正是一些產品經理高級崗位的必備技能。
相信大家在招聘網站上，經常能看到資深一些的產品經理崗位會有以下類似的要求；
這一點筆者回顧過去幾年的工作經歷里做過幾個跨部門的項目，有經驗，也有教訓，還沒有好好總結過，搜索了一下網上確實也很罕有這類的文章，所以筆者在此略獻薄技。
一、預備動作1：確定需求
現在的2C產品很少有被做出來后，由產品經理自己負責去做推廣。畢竟你有渠道嘛？有推廣資金嘛？你能服務用戶嘛？你能自己舉辦活動嘛？
小的項目自己團隊閉環，在給定的用戶范圍內試試水，大的項目一般需要面對更多的用戶，以及更大的影響面，就需要由外部力量一起來推動。你的想法最好有實際應用的業務方來支持。
2B業務的產品經理自主性會更強一些，可能會發起比如平臺升級，架構優化的項目。
但依舊牽一發而動全身，這種項目的難點就在于如何說服高層，為什么要在這個時間點做這樣一件事情，如果高層認可，下面支持，需求自然就確認了。
在有明確的業務方后，一定要深刻的理解業務方的需求，主要從以下幾個方面入手：
- 需求來源的依據是什么，是否已經有歷史數據、測試案例；
- 確認需求是短期（臨時）的還是長期的，緊急的還是可規劃的，這將直接影響大家做出來的方案是臨時的還是持久的；
- 如果有多個業務方，可以要求業務方按部門需求進行合并，比如市場、運營、客服等部門同時希望在雙十一有一個聯合售賣項目，如果能夠有時間逐個溝通最好，但之后是需要選擇出一個業務代表，減小溝通量；
- 其次需要對其中的重復需求進行整合，進行抓大放小，排好優先級，小需求根據實際情況進行降級處理；如果業務方不同意，則需要給出相應的理由；
- 最后一定要讓業務方給出預期收益，同時也要配合業務方保證收益的合理性。
作為產品經理的專業性需要體現在盡最大程度的滿足業務方的需求，同時又花相對較小的代價，以及能夠兼顧未來的拓展和可復用性，最后是預估的收益是可計算可預期的，而不是拍腦袋。
否則在之后的環節，將極易受到挑戰，舉倆個例子：
- 你這個需求有沒有先驗證過？能不能做個簡單的頁面看看有沒有用戶點擊？如果沒有，請先做個MVP，否則后續的環節就無法推進展開；
- 這個項目的收益是否夠大，足以說服其它的團隊一起參與。或者有高層領導的明示，有很多項目是高層領導出于實驗性質的，希望能完成一個從0到1的流程，那么收益就不可能太高，甚至本身是公司的未知領域，收益都無從估計，這種情況是一定要狐假虎威的來拿到高層授權的。
之前說的那個小兄弟，既沒有驗證會員在當前公司用戶的意向，自然也無法給出一個令人滿意的項目收益，即使高層覺得項目有價值，但還是無法評審，導致項目延期。所以這個環節請大家先跟業務方一起，細致討論。
如果以上動作都做完了，就可以進入到下一個環節，組建核心團隊。
二、預備動作2：成立核心團隊
漫威電影中的超級英雄即使擁有有宛如神明的力量，在面對更強大的敵人時也會組成《復仇者聯盟》，組成一個團隊，做各自擅長的事情。
同樣的，產品經理在面對這種跨端項目時也需要一個核心團隊來支持自己，一般會有以下幾個主要角色：
其中主產品經理是整個項目能夠順利完成的關鍵。在跟各產研團隊溝通需求的時候，能夠代替業務表達需求的必要性；跟業務溝通產品方案的時候，能夠代表各部門的產品研發提出可行性。
否則每次開會都得叫上十幾個人，低效的開會，頻繁的討論將是項目推進的巨大阻力（當然這不代表不能拉這么多人一起開會，防杠所以請讀者自行領悟），這就要求主產品經理對整個項目有深刻的理解和把控能力。
前面的業務需求聊完了，自然就要開始跟具體的產研團隊的小伙伴們干活啦。
三、開始推進項目
1. 拆解需求，溝通需求
除非公司很小，現在的大公司各個部門都有自己專注的領域和負責的業務，甚至比較過分的則是有些基礎部門在公司的內部形成了一定的壁壘，他人與之合作時，更像是調取了一個第三方公司的服務。
如果這種服務真的足夠完善還是挺方便的，但因為這些部門一般只服務公司內部，其完善性、與項目的匹配度、穩定性都有一定的折扣。所以我們需要將需求進行仔細的拆解，與各部門耐心的溝通，溝通的主要目標：
- 核心團隊，熟悉整個業務流程的實現；
- 與實現各業務環節的團隊進行溝通，補充和完善業務流程；
- 了解各團隊近期的工作重點，確認各端關鍵負責人；
- 核心團隊討論從各團隊收集來的方案，根據實現成本和可持續性等維度，討論最終的產品方案；
- 確認業務數據在各端是否可以準確拿到。
外加筆者之前的一些討論技巧：
- 從業務方的需求出發，和各部門一起繪制業務流程圖，畫到他們的邊界；
- 根據業務流上的關鍵節點進行展開到各部門、組織；
- 在與各部門的溝通中，了解各環節中的上下游，判斷這種依賴是否會影響到本項目，如果影響則添加到項目中，不影響，則由各環節各自去閉環；
- 在與各團隊討論需求時，多討論幾種方便、簡單的、復雜的、臨時的、長期的、低成本的、高成本的等；
- 初次與不熟悉的部門討論需求時，需要與該部門較資深的同學一起討論，避免因為雙方不了解造成的溝通歧義，之后可以選出該部門的關鍵對接人，來承接己方需求即可（可能是產品經理，也可能直接的研發負責人，根據團隊特性來定）減少之后的溝通成本；
- 以上的討論至少需要帶主研發一起，根據情況帶上主測試和PMO，需要他們一起理解整體項目的架構，便于之后評估整個項目的實現成本；
- 不要跟各團隊在此階段過多的討論收益，只討論實現成本和可行性方案，否則最終項目的實現方案難度超過了項目需求，討論將變得沒有意義。
舉個例子：
這一塊的需求溝通環節是整個項目的重中之重，所以筆者這里需要拿一個簡單的案例來說明一下，以上線一門課程進行售賣的需求為例：
1）第一步，根據當前的認知繪制業務流程，依次有：
- 課程配置，做一門新課，需要在平臺里配置一些課程信息，以及必要的學習環節等；
- 前端課程展示，用戶可以看見，有入口等；
- 商品展示，需要創建SKU，讓新用戶可以購買。
如下圖所示：
但以上這些認知一般是不完整的，即使做過的項目，各部門也可能有迭代更新，所以需要進行下一步。
2）第二步，與已知部門溝通，完善業務實現流程：
- 與課程配置部門進行溝通后，發現還有老師的匹配工作；
- 同樣，課程不僅是用戶需求可見，還有中臺上需要可見，否則工作人員沒有辦法進行監督；
- 跟電商平臺的同學了解后，還需要做法務溝通、商品包裝等事宜；
- 最后，電商同學還告訴我們，售后服務需要處理。
如下圖所示：
3）第三步，與核心團隊確認最終方案
如此第二步的多次夠溝通，你將會初步得到項目實現的全部流程，以及有關部門。這時需要跟自己的核心團隊一起商量和討論，是否每個環節都必要，如何在各團隊給出的多個方案中進行選擇。
下圖中，主要是為了保證項目進度，團隊舍棄了多端上線和客服需求，由班主任來代替客服的工作等選擇。
2. 正式立項，明確分工
之前都是各團隊的零散的溝通，是時候把大家拉到一起做一個正式的立項大會了。有些讀者可能會問，不會吧，現在才立項嘛？
因為根據之前的拆解需求，和各團隊的反復溝通，才能確認各端是否需要參與、以及最終的方案是什么，甚至因為實現成本等問題，最初的需求都會發生一些變化。
否則在不了解各端的情況下，先拉上20個團隊一起立項要做A需求，最后聊完發現只需要4個團隊的參與做B需求，會極大的降低團隊可靠程度。
那么，立項大會需要跟大家聊啥呢？
- 正式的介紹項目背景，項目目標，以及項目的最終收益，如果是多期項目，可以回顧之前的成果，用于保證各團隊的投入和參與動力；
- 明確最終的業務方案，這是跟各團隊一起妥協出來的最大公約數，確定各業務團隊所需要配合實現的需求，以及項目中要使用的方案，劃分各端的任務職責；
- 確定溝通機制，確認核心團隊的聯系人，有研發問題找主RD，有產品問題找主PM，人力排期問題找PMO；
- 重要的里程碑節點，如果項目周期較長，可以分階段實現，拆分好各階段需要參與的團隊。
理論上，會議上不應該有特別復雜的討論，只是公布方案，拉齊認知，更不要臨時發現缺少某個關鍵部門的參與，這些都應該是上一環節沒有討論清楚，請反思總結。
當會上大家都默認沒有意見后，此時項目就已經成了60%以上。那我們就接著推進吧！
3. 需求評審，研發推進
有立項大會還是否需要進行項目整體的需求評審呢？根據筆者的個人經驗是需要的。立項大會后，給各團隊一些思考的時間，消化需求，確認風險，人力安排，項目優先級調整等。
一般就安排在立項大會的第二天或者第三天，拉齊之前各部門的對接人進行需求評審。
評審主要是快速把整體產品方案再過一次，作為主產品，要給最終解釋；以及各端遇到的新問題，比如測試數據，配置規則等，收集好后，再單獨跟各端進行反饋。
項目需求評審后，各端就要正式進入到各自的研發階段。此階段如果有PMO參與，則需要由他們來保證項目的推進，如果沒有則主產品也可以來做以下事項：
- 督促各自部門進行需求評審，給出各部門大致的時間安排，研發時間，測試時間，與其它部門的聯調時間；
- 確認各端的人力投入成本，有問題需要立即向上反饋，確認與其它項目的協調；
- 與主測試準備聯合測試方案及測試數據；
- 積極的與各端進行溝通，周期性的關鍵負責人站會、電話會議，確認項目進度，及時發現問題，解決問題。
由主研發和主測試同學去確認之后的項目聯調方案：
- 要求各端在聯調前，保證作為一個獨立模塊的正常使用；
- 有條件有需要的情況下，進行封閉式聯調，以保證項目進度；
- 主產品需要跟進保證整體的產品功能與業務需求的一致性。
最后需要和主研發一起，制定多端上線順序。這是跨端項目與獨立項目最大的不同，獨立項目所有上線流程都是部閉環，上線依賴發生在項目內部?？缍隧椖縿t需要核心團隊根據團隊之間的依賴關系，設計好上線順序。
舉個簡單的例子：商品的付費購買功能與商品的使用功能，誰先上線？如果付費功能上線的一瞬間，有用戶下單，但功能還無法使用就可能造成重大的線上事故。
當這個順序拓展到十幾個部門的上線后，將會產生更多的連鎖反應。
4. 上線總結，復盤優化
到此，項目90%的工作基本完成。只是項目上線交付給業務去使用，真正給到更廣大的用戶使用時，會有更多的問題暴露出來。作為項目的主產品經理，以及最了解項目的人，遇到問題可以最高效的分發到對應團隊，避免問題擴大化。
筆者之前遇到過主產品離職的大型項目，一個工單扭轉十幾個部門不知道誰來承接的情況，錯失了解決問題了良機。
其次主產品需要對各團隊項目數據的進行驗收，這是量化各團隊和最終項目收益的主要指標，要保證大家的勞動成果。如果有問題，找到相應的團隊及時修正。
及時復盤項目，梳理各部門的職能，并對項目中的方案進行評估，提出改進方案。比如臨時方案迭代成持久化的方案，手工方案改自動化方案，寫表方案改管理后臺方案等。
最終，需要確認收益，和大家共享成果。
5. 常見問題
1）問題一：因為邊界的模糊，同樣一個功能，A和B都可以做，那么誰來做？
筆者這里給出一個參考答案：
首先，需要跟主研發進行討論這個項目未來可能的項目架構，即此功能誰最適合長期維護；其次，誰能夠不耽誤項目進度，在當前的情況下，選擇效率更高，成本更低的方案；最后，通過此功能，未來誰的收益更大。如果依舊不服，向上反饋。
2）問題二：很多業務需求未必與需要配合團隊的業績產出所匹配，如何給大家一個信服的收益？
首先確認需求拆分到的團隊是否匹配，是否有分配錯誤的情況，這一點在溝通需求的環節就要消除；其次，拿項目的測試數據說話，拿之前的歷史數據說話，保證項目收益，以提高優先級；最后，如果對方還不滿意，找到對方的領導進行溝通，將項目上線寫入相應同學的業績考核指標中。
3）問題三：如果項目反復進行，還是否需要如此繁瑣的溝通？
同樣的項目如果做第二次和第三次時，部分穩定環節可以進行省略，但基本的通知一定要到位，有些部門經常會有各種迭代升級，之前的老方案有變更時，不一定通知到位。甚至可能已經有了更簡便的方案，可以加入到項目的考慮中來。
四、總結
跨部門項目的核心點，還是在于分解、合并與溝通，主產品經理的溝通占據項目中50%的工作，剩下的則推進團隊以及堅決的執行、推進。項目穩定后，將流程規范化，自動化，程序化，以減少重復的人力投入。
最后，祝大家好運，實踐出真知。
作者：核桃殼，微信：walnutshell911
本文由 @?核桃殼 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
妙啊。