編輯導語：似乎在互聯網行業，產品經理和技術經理互掐是一個常見現象，二者是天然對立關系。這篇文章作者詳細介紹了產品經理與技術經理溝通要領，感興趣的小伙伴一起來看看吧。

如果你身在在互聯網行業，就一定會經常聽說產品經理與技術經理互掐的事情，甚至連脫口秀演員編段子都會用到產品與技術對立的梗，這類事情聽多了就會產生一種錯覺，似乎產品和技術天生就是不能和睦相處的，外人看來這兩種職業的人更是成了一種天然對立的符號。

作為一個產品，我可以負責任的說前面提到的這種情況明顯是跟實際情況不符的，雖然有些時候產品和技術的確是會有一些意見上的爭論，但也完全沒必要演變成對立關系。

相反，在實際工作中產品和技術其實是最緊密的合作關系。之所以會流傳出上面提到的那些相互對立的傳說，是因為他們的之間需要溝通和探討的東西實在太多了，稍微有幾次談不好的就會被別人當做熱點事件傳播。

從傳播學角度講，這些負面內容更容易吸引大眾的注意力，所以有一千次良好溝通不會有外人知道，有一次不好的溝通就能傳很久。

我們沒辦法改變傳播學的規律，但可以改變自己的溝通方式，讓那一次可能產生負面傳播的溝通永遠不發生。這也就是我們今天想要展開聊聊的內容，關于產品經理與技術經理溝通時的一些重要事項。

一、認知方面

想要做好什么具體的事情，首先要建立一些最基本的認知。好的認知就像是一個燈塔，能在你偏離航線的時候及時提醒你回歸正確的航向，所以我們在聊具體的溝通細節之前也要先說一下關于產品與技術技術溝通的基本認知。

1. 是協作不是對立

這是一個大前提，很基礎但同時也很容易被忽略。產品和技術作為互聯網產品生產的兩個重要崗位，是完成一個產品必不可少的兩個角色。

在這樣的背景下不難看出他們的目標其實是一致的，就是要完成最終的那個作品。也就是說產品和技術從來就不是對立的關系，而是協作關系，是一條生產線上兩個不同的環節而已。

記住這一點，在未來溝通過程中遇到分歧時優先去思考如何去更好地達成結果，而不是一味地堅持自己的觀點，往往能夠消解矛盾進而找到那個對結果更有利的路徑。

當兩個人為了同一個結果去探討什么內容的時候，他們能夠達成共識的概率一定會比“他們為各自目標努力”更高。

把這一條作為“燈塔”中的第一條就是希望在后面每次遇到阻力的時候，我們都可以想到它，當你能看到更遠的目標時就不會拘泥于眼前的路到底該怎么走。

2. 合理安排溝通頻次

對于完成一項工作來說，溝通只是其中一個環節，雖然重要，但從來都不應該是主線環節。它就像是潤滑油，你不能沒有它，但也不能只有它。

它只應該出現在真正需要它的時候，出現在需要它的地方。溝通太少或者溝通太多都會影響工作目標的達成，所以我們在將溝通之前先要學會把握溝通的節奏。

溝通節奏正常情況下應當依據所要處理事項的具體細節來判定，可能會產生影響的細節有：事情的重要程度、事情的緊急程度、里程碑時間安排、對關聯事件的影響程度等。

這里大致可以分為兩種類型的溝通，一種是有規劃有目的的溝通，比如例行的需求評審、立項評審等在里程碑節點上比較重要的溝通。另一種是遇到突發事件時需要組織的臨時性小規模的溝通。

第一種類型往往有更強的計劃性，溝通幾次在什么時候溝通，往往都是在項目規劃的安排下有序進行的，所要實現的溝通目標也都是比較清晰的。這部分的溝通次數和時間都應當是在公司維度或者項目組維度規定好的。一般情況下形成一定慣例就很少調整。

第二種類型的隨機性就比較大了，往往發生在產品或技術其中一方發現某些可能影響結果的偏離事件時，比如產品發現某個細節的實現邏輯有錯誤，或者技術發現某個流程實現時存在技術障礙等，這時就要根據前面提到的一些具體影響細節來判定是否需要發起溝通，以及溝通的范圍需要多大。

基本原則是重要且緊急的優先安排溝通，重要但不緊急的可以積累多個統一安排溝通，緊急不重要的可小范圍溝通，不重要不緊急的有空余時間再溝通，或者可以選擇性忽略。

控制好溝通頻次是提高溝通效率很重要的一個部分，過多瑣碎的溝通會讓對方覺得你遇事抓不住重點，溝通太少又會留下隱藏的風險。所以在合適的時間通過溝通解決重要的問題才是這個事情中應該重點關注的部分。

二、前期準備

工欲善其事必先利其器，想要達成良好的溝通效果就必須要做好充分的前期準備。前期準備是在溝通開始之前所需要提前完成的一些工作，主要目的是梳理溝通思路，確保溝通過程中可以言之有物，有明確可依靠的內容或材料作為共同討論的主線。

1. 達成目標共識

有一個共同的工作目標是良好溝通的大前提，可以根據溝通事項大小來確定共識內容。目標共識一般情況下要比所要溝通的內容有更高的高度，這個共同目標不是用來限制溝通的，而是用來指導溝通工作的。

一個明確的目標共識可以讓溝通雙方在遇到困難時更快找到核心主線，而不是一直在無關緊要的細致末節上耗費時間和精力。

這個目標可以是項目成立之初確定的項目目標，后續一切工作以完成項目目標為宗旨。也可以是當前階段需要解決的一個小目標，在不影響大目標的前提下，重點關注小目標的完成情況。

必要情況下可以要求團隊先完成目標，再考慮完成的質量怎么樣。確定目標后需要謹記目標是必達項，如果影響到目標達成那其他內容均可稍作讓步。

2. 完善產品規劃框架

產品規劃框架就像是一個攻城拔寨的戰略地圖，是產品設計開發工作中非常重要又容易被忽略的環節，重要性自不必說，而被忽略則是因為產品規劃框架并不影響產品開發工程實施，即便沒有這個框架，只要有具體的產品設計文檔，開發工作也是可以正常推進實施的。

這是一個在產品設計初期經常被討論的內容，但是后面一旦確定了這個產品要做，開始落實到具體實施階段的時候它出現的頻率就逐漸減少了。

作為一個產品經理，需要時刻記著產品規劃框架對產品發展演變是一個十分重要的東西。產品需要熟知產品未來規劃，這樣才好去判斷哪些功能是當前必須要做的，哪些功能是暫時不做長遠規劃要有的。

一個好的規劃框架應當是在穩定基本內容的前提下不斷變化的，要隨著項目推進和行業發展時刻去反思原有的框架是否還是最合適的，并且適時作出調整變更。

就像戰略地圖，不僅要知道我們要攻下哪些城池，也要隨時關注戰局變化往戰事吃緊的地方加派兵力，以確保能夠全面地完成戰略目標。而今天這里之所以把規劃框作為溝通的一個重要前提，是因為它可以起到一個戰略指導的作用。

哪些事要做哪些事不要做，不能空口無憑拍腦袋亂說，根據這份戰略規劃來，可以讓團隊更好地完成當前的工作。

3. 確保產品邏輯清晰

在進行具體內容溝通之前，一定要確保所要溝通的部分邏輯是清晰的。不論溝通事項大小，你想要對方了解的信息，你自己一定要先很熟悉。

溝通的過程中可能會遇到一些質疑和提問，一般情況下對方只是為了通過這種方式來搞清楚你的真實意圖，那就需要我們自己對所闡述的內容有足夠清楚的了解和認知。只有這樣才能在別人提問時穩定地輸出明確可參考的信息。

尤其是在跟技術人員針對一些具體的產品細節展開討論時，明確清晰的邏輯顯得尤為重要。

技術開發人員在寫代碼時尤其會關注產品的邏輯，邏輯的正確與否直接關系到產品最終的成敗，而且他們常常會結合他們自己的經驗對某些地方的具體內容提出質疑，如果產品經理對產品邏輯不夠清晰的話很容易被帶到技術人員的思考路徑上來，進而會因此產生一些不可預見的結果偏差。

所以產品一定要提前熟悉溝通中可能涉及到的產品邏輯內容，在遇到問題時能確保在產品自己的思考路徑上應對和解決問題。

三、溝通技巧

做好充分的準備，接下來就是正式的溝通環節了。這個部分我們就來拆解一些比較簡單容易時間的溝通技巧。只要能恰當地加以應用就可以在短時間內提高你的溝通效率，讓你的溝通更加暢通。當然，具體場景還需要具體分析，這里只是提供一個可行性方案，切忌盲目套用。

1. 羅列溝通要點

很多人在溝通過程中會遇到這樣的問題，本來打算今天要跟對方溝通8個事，最后結束發現只聊了5個，剩下的3個要么就是沒時間聊，要么就是在溝通的過程中遺忘了。如何有效防止這種狀況發生，就是在溝通開始之前羅列溝通要點。

有一個清晰的溝通要點列表，一方面可以讓對方快速了解你所要講的大體內容，也好提前做好相關準備。

另一方面也可以根據要點溝通進度合理安排溝通時間，如果在某一項耗費太長時間還沒得到結論時可以選擇先跳過這一點講其他內容，等所有事項都聊完以后再回過頭來解決前面擱置的問題，不至于讓某一項內容影響整體溝通效果。當然，最主要的還是可以確保關鍵項都能被提及，而不至于在溝通過程中遺忘。

除此之外，羅列溝通要點還可以起到提前梳理思路的作用，開始之前梳理思路可以提前發現溝通內容中是否有缺漏，或者不同要點之間是否有重復的內容。確保要聊的事情都是必須要講的，不講多余廢話也不遺漏重點，是對自己負責也是對對方的尊重。

2. 統一溝通語境

什么是溝通語境不同呢，舉個例子，產品拿著產品需求文檔去找技術聊產品邏輯，技術卻對著產品文檔將技術實現的困難。

這就是語境不同，兩個人的訴求明顯是不一樣的，產品需要確認的是當前產出的內容在產品層面是否存在問題，而技術反饋的卻是如果要實現這樣的產品構想有哪些技術困難。這個問題不是不能講，但很明顯不是在這個階段。

在產品成型過程中，有些溝通是為了確保產品做的對不對的，有些溝通是用來確認產品具體怎么做的，還有些溝通是用來解決團隊遇到的困難的，雖然相互之間有關聯，但也不能完全混在一起談，總得有個先后順序，不然事情可能永遠被卡在第一步無法往前推進。

所以，這就需要在溝通時約定好當下的溝通是在哪種語境下進行的。偏離語境的內容要及時停止，不然雙方聊半天說的都不是一個事必然會浪費很多精力。

3. 抓住主線內容

眾所周知，會議時間最大的殺手就會那些會議過程中的衍生話題，本來主線內容預計三十分鐘就能聊完的，但是由于在溝通過程中思維發散將溝通內容帶到了其他相關的非主線內容中，一旦開始發散就很容易消耗大量的溝通時間，所以在我們的溝通會議上最常聽到的一句話大概就是“這個我們先不發散”。

于是，抓住溝通的主線內容就成了一次成功溝通的重點。溝通雙方都應該要有這樣的意識，要清楚本次溝通的核心內容是什么，然后還要在溝通過程中時刻關注溝通內容是否還在主線上，一旦發現有偏離主線的趨勢，雙方都有義務指出問題促使溝通重點再次回歸主線。只要大家將這種意識培養成一個習慣，那對于團隊整體的溝通效率就一定會有一個非常大的提升。

4. 跳出糾紛不做無謂爭執

就像我們開頭時候提到的，只要有溝通，就總是難免會有雙方觀點僵持不下的情況。如果這個時候雙方各執一詞堅持要讓對方認同自己的觀點，結果往往會陷入一個大家都不愿意看到的局面。

其實當雙方觀點僵持不下的時候，就該停一下了，停止向對方輸出觀點，給大家一個思考緩沖地帶，去想想對方觀點的是不是真的跟自己的內容完全不能融合，去考慮一下有沒有可以兼容雙方意見的折中做法，要知道觀點不同時不是誰的嗓門大誰就能占上風的，我們溝通的目的是結局問題，是要達成那個大家一致認可的目標，各執一詞很明顯是不能達成這樣的結果的。

如果真的沒有折中的辦法也不需要一直糾結在一個問題上，把無法達成一致意見的部分先放一放，先去完成其他溝通要點。等把能解決的問題都解決了，再回過頭來看當時遺留的這個問題能不能解決。

5. 擴大溝通范圍讓更多人參與決策

上面一條的問題，如果回頭看還是不能有一個雙方都認同的解決方案，那就可以使用這一條技巧了，擴大溝通范圍讓更多人參與決策。

一個項目的推進往往不會只有產品和技術兩個角色，還會涉及到項目經理或者測試人員，所以當產品和技術討論不出來確定觀點的時候不妨也聽取一下他們的意見。

一般情況下，當出現雙方誰也無法說服對方的時候，應該是兩種方案都可行，就看哪種更合適。所以對于這種沒有絕對標準的問題，可以采取更加民主的方式，讓參與項目的各方共同決定最終的選擇。

正常到這一步就肯定會有一個確定的結論了，實在不行就只能再把范圍擴大一下了。

把最終的決策權給到項目總負責人或者雙方共同的領導，由更高一級的人來最終拍板該怎么做。只要最終能達成結果，中間選擇什么路徑其實不是最重要的，不要讓這個不重要的東西阻塞的項目目標的達成。

6. 公示明確的溝通結論

判斷溝通是否完成的標準，就是關于一個溝通要點是否已經有了一個明確的溝通結論。產品經理可以有意識地記錄每個溝通要點對應的結論，這個結論一定要是明確清晰的，要有明確可量化的目標，有具體的事項負責人，有計劃的達成時間等等。

而且不管小范圍臨時性的溝通，還是專門組織會議的正式溝通，達成共識的溝通結論最好都專門公示一下。小范圍的可以在大家共同的群里公示，有組織會議的最好發個會議紀要的郵件抄送相關人員。

結果公示一方面是對溝通成果的梳理，可以確保我們想要解決的問題都已經通過溝通得到了可以進一步執行的明確結論。另一方面也可以通過文字記錄的形式為大家留下一個可查詢的依據，后面執行過程中有不清楚的地方時還可以翻看記錄找到對應的內容，減少重復溝通同一個問題的可能性。

四、相關原則

1. 哪些部分要聽技術的

由于產品和技術本身的知識體系基礎不同，雙方都會有一些認知盲區存在。當遇到技術的認知盲區是產品有義務將相關的內容盡可能闡述清楚，一些邏輯性的或者涉及用戶使用場景的東西都可以大致歸為此類。

同時，產品也應當能夠判斷，哪些東西是技術占主導的內容，算是在自己的認知盲區內的東西。比如技術實現方式、不同技術實現方案的選擇、技術實現的成本等。

在遇到這些技術更了解的內容時，產品是應該多去聽技術同事的觀點。千萬不要不懂裝懂在自己不擅長的領域過多地增加自己的干預意見，可能會影響技術同事的工作節奏。

而且屬于外行指導內行，本來也是不合理的事情，我們的日常工作中應當盡可能避免這種情況出現。大家各自做好自己擅長的工作，整體的工作效率才會提高。

2. 沒有明確結論的內容寧可不做

在項目推進過程中，會出現一些暫時沒有達成統一意見的內容。如果是涉及到功能開發的話，這種不明確的內容是不可以貿然進入開發階段的，不明確的部分寧可暫時不做，等后面事情討論清楚了，結論明確了以后再做開發工作。這種情況即便提前做了也可能會在后期出現返工重做的可能，影響可能會更大。

五、其他約定

1. 建立常規細節共識

在長期合作的產品和技術之間，會有很多常見的重復內容。比如頁面打開時默認的用戶識別規則，登錄后持續在線時長，頁面跳轉時是覆蓋原頁面還是打開新的標簽頁，或者一些頁面上常用的細節內容。這些都可以匯總成一套標準化的細節共識文檔，所有在文檔中約定好的細節都直接按照文檔中的標準來執行。

這樣做一方面可以減少在細節上的反復溝通，減少溝通成本；另一方面也可以促進產品在細節上的標準化程度；除此之外有這樣的共識文檔也會方便相同體系下的不同產品統一產品風格，有助于形成比較整齊的對外展示風格。

作者：多云轉晴，公眾號：互聯網從業筆記

本文由 @多云轉晴 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。