編輯導讀：一個產品的上線和運轉，離不開公司各個部門的協作。而作為產品“父母”的產品經理，需要經常和其他部門溝通協作，這時候溝通能力就顯得尤為重要了。在團隊協作中，產品經理應該具備什麼能力呢？本文作者針對這個問題，發表了自己的看法，與你分享。
產品經理在企業中要承擔連接器的作用，不管是平衡三環（用户體驗、技術和企業需求）還是跨部門跨公司的合作，其實後面本質上都是人與人的分工協作從而共同完成預定目標，這也是企業運營的核心本質。
不管是初創公司還是互聯網大廠，都要面臨複雜的經營問題，如果企業經營上出現問題，一般都會有三個常見的現象：溝通不暢；高層管理能力不足；相互敵對。所以一個人的溝通協作能力會直接影響個人和項目的發展，作為產品經理就尤為重要，那產品人如何在工作中落地團隊協作進而達成目標那？
讀過劉慈欣《三體》小説的都知道，在宇宙中有兩條不證自明的基本公理：
- 生存是文明的第一需要。
- 文明不斷增長和擴張，但宇宙中的物質總量保持不變。
同樣協作溝通也是兩個公理：
- 沒有那個企業僱傭的全是精英。
- 組織成員都希望從事有趣且興奮的項目，希望通過出色的工作被人認可。
基於以上兩個公理我們就要時刻審視自己出發點是否正確，不要妄想一些沒有根基的談話，比如“這麼簡單的事情你怎麼就這麼難實現”、“老闆安排的事情”。
溝通能力強其實也是高情商的表現，除了一些性格上的特點，產品經理在對接不同崗位人員時也要有不同的策略和角色認知：
研發工程師（技術大牛）：
溝通中避免：
- 沒有基礎技術知識，且不主動學習
- 產品需求表述不清晰
- 低估研發難度
- 不使用產品
- 隨意改變產品設計
- 推卸責任
- 情緒化
- 對需求的背景和原因不進行説明
- 對研發過程指手畫腳
- 亂用技術術語進行説明
- 產品評審沒有經過開發人員
- 對可行性沒有進行技術調研
- 產品的成功和開發無關
產品方案落地是需要程序員通過代碼實現的，所以產品方案對研發的影響很大，我們要把大腦中的想法通過各種方式讓另外一個人清晰無誤的接收到本來就比較複雜，所以我們要降低溝通損耗。
產品表述具象化就可以很好的解決這個問題，所以我們要花更多的精力做原型圖，避免使用大段的文字進行陳述，因為文字的歧義太多了尤其是中文。你會發現一個複雜的流程或者邏輯，自己講兩遍的表述方法都不同，聽的人就需要花費更多的精力去理解。
我的解決路徑是：腦圖-原型map-模塊説明的三步走方式，當然一個好的PRD並不能只是這幾個方面，應該從發起前（來源及目標）、開發中（原型和研發）及上線後（數據和覆盤）三個方面入手，後面我會單獨文章介紹。
腦圖：
注意這裏的腦圖是給別人看的，所以應該是發散後進行整理收斂的完整結構，讓接受者可以有個完整清晰的認知，對目標關鍵節點和主要功能有個框架性的瞭解，可以理解成書的目錄注意同級別模塊間的順序和邏輯性。
原型map：
map應該是整個PRD的核心，可以理解是把所有功能頁面平鋪開，並根據不同的事件觸發進行關聯，這裏要整合好用户的行為路徑，主要還是以用户視角為線索進行連接，説明整個產品功能的結構，整體要和流程圖相結合。
模塊説明：
具體標註某個頁面或者模塊的，狀態、觸發邏輯及響應機制（有些要標註需要的交互效果）。同樣不建議使用大段的文字進行表述，還是要圖文並茂，同時針對不同狀態要用表格的方式進行歸納整理，將所有的可能表達清楚並窮盡。這裏沒有比較好的統一模板，但是表述的樣式在一個文檔或者相同產品中要儘量一致，如果規則選項有規律建議使用表格的方式進行表述，這樣結構更嚴謹有序。
一般成熟的產品經理會對應5-8名研發人員（包括客户端、前端和服務端），即便如此研發的落地速度也不會快於提案的熟讀，這裏就需要引入項目管理進行優先級排序，這裏不展開項目管理的內容，但是開發排序需要遵循規則，這裏建議使用MoSCoW排序法。
產品研發一定要以業務目標為導向把握研發節奏。一個程序員一般不會並行開發多個任務。但如果總是做一些對業務影響不大的需求，對研發的士氣和能力評價都是有害的，所以在開始前就要論證清楚其價值：
- Must have：必須有。產品的基礎能力核心功能。是最小可行產品（MVP）的功能。比如微信的聊天信息、抖音的短視頻播放。
- Should have: 應該有。這些功能很重要，但不是必需的。但是長期確實會對用户體驗造成影響。如微信的表情功能，應用商店中的評論功能。
- Could have： 可以有。用户體驗的加分項，用户想不到，上線了也需要培養用户的使用習慣的。
- Won’t have： 這次不會有。 最不重要，評估回報率最低。建議進入需求池並定期回掃。以上規則並不適用與產品新方向的探索，建議探索新方向的產品經理要獨立並行，畢竟新方向的探索本來就有不確定性，所以以上規則可能並不適用。
設計師（顏值擔當）：
設計師的工作一般會在研發之前，所以在啓動設計之前也要對相應的技術點進行調研，避免實際效果在開發的時候無法實現。
一般交互設計師會注意功能模塊和整體交互效果的統一避免產生交互衝突。產品設計中儘量保持簡單交互設計，尤其是在設計手機APP的時候，要理解深刻的簡單並不是缺少複雜性，而是巧妙地掌握了複雜性。
將複雜的邏輯埋在簡單的交互下面是高級美。所以設計師是通過產品經理深刻理解產品目的（即讓一用户完成特定的任務），而通過各種交互邏輯來幫助用户實現產品功能。這個環節會大量應用換位思考的能力，需要長期在工作中積累尋找感覺。
市場/用研（上帝的代言人）：
市場和用研部門的同事一般都是離用户最近的人，建立良好的關係長期獲取用户的反饋信息，如果收到的是bug的反饋一定要重視，需要驗證或求助QA進行驗證進行落實並排期修復。但是用户需求一定要深挖用户的真正訴求，且配合場景思考進行論證，避免用户要的是錘子其實需求是坐着舒服點的椅子。
用研部分其實專業性比較強，在產品經理大概判斷一個方向的時候就要和用研團隊溝通具體的用研方案，是通過線上問卷的方式還是線下走訪的方式，且問題的設計也是很多學問，這個後面我們找機會聊下這部分。但有個通用的規則，在完成定性的研究後，一定要輔以定量的測試來論證。最好是公司自己的用研團隊和第三方公司同時進行定量測試，來客觀判斷方向的準確性。
部門之間的協作更多是職能上的，實際工作中直接面對的還有上下級關係。這個話題比較大了，而且100個人有100個答案，我這裏只介紹一些基本規則：
管理上級：
一般領導的時間都是很寶貴的，對上管理中最重要的就是彙報，彙報要充分準備，但是要足夠簡短。領導需要擴展瞭解的時候再展開説明且要有邏輯性。核心關注目標、成本和影響面。
管理下級：
對下級不能只有要求，也要放權給出發揮空間。看清能力邊界，在預計可達成的範圍內不斷的提升。（這裏不包含高層管中層的情況，本人還沒有理解到那個層面）瞭解下屬在以下那個階段因人而異。
- 不知道自己不知道（新手從最簡單基礎任務開始做，不會引發大的事故還有機會學習業務。最好有人帶）
- 知道自己不知道（給任務定目標，設定反饋機制幫助成長。給遇到的困難提供指導）
- 知道自己知道（中堅力量最好能獨立負責一塊業務，並委派一些有挑戰的任務嘗試帶人）
- 不知道自己知道（多溝通更多的邀請參與新業務或方向的討論，承擔更多的內部培訓更多的總結機會）
除了以上的方法，產品人因為角色的原因往往會在業務的中心，經常會有一些產品説明會、功能諮詢等非主要工作職責的事情佔用精力。當然如果這個確實是業務的需要，也可以考慮通過其他的方式來解決，比如錄製教程視頻等。當然這個還是和每個公司的文化和工作習慣有所不同。
不過以下三點還是要注意：
- 當面交談比郵件更有效；
- 學會説“不”；
- 注意舉止（言行方式和態度）。
就是這些，已到年底雖然在2020年我們都經歷了好多黑天鵝事件，這不也過來了嗎！一路相信自己！
最後，祝福各位產品人在新的一年，仕途廣順，平泰安康！
本文由@天一 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議