編輯導(dǎo)語：產(chǎn)品經(jīng)理的工作日常與開發(fā)密切相關(guān)，可謂是相愛相殺的關(guān)系。產(chǎn)品經(jīng)理與開發(fā)配合默契，則會促進(jìn)項目順利的推進(jìn)，如果溝通存在隔閡，則會有不少的麻煩。那么，產(chǎn)品經(jīng)理該如何跟技術(shù)人員更好的溝通呢？今天本文作者結(jié)合自己的經(jīng)驗分享了一些關(guān)于溝通的小技巧，希望你也能夠受用。

產(chǎn)品經(jīng)理跟開發(fā)人員在日常工作中有著非常頻繁的溝通與協(xié)作需求，可以說PM跟RD是一對矛盾體，兩者之間因為有著共同的項目驅(qū)動目標(biāo)，而需要相互溝通協(xié)作。

但同時兩者又存在個人利益的對立，比如PM可能會想著RD能夠在最短時間內(nèi)有盡可能多的產(chǎn)出，而RD可能會想著用最小的投入完成自己的工作任務(wù)。

于是，矛盾便產(chǎn)生了。

如果產(chǎn)品經(jīng)理無法處理好與開發(fā)人員的溝通協(xié)助工作，很可能會使得項目舉步維艱。如何高效、和諧的與研發(fā)人員打交道，是產(chǎn)品經(jīng)理需要掌握的一門學(xué)問。

我曾經(jīng)遇過一群關(guān)系很好的開發(fā)同事，當(dāng)時大家都是剛步入職場，彼此成為了朋友，在日常的合作中也很愉快。

我也遇到過一群在家文化的企業(yè)氛圍中成長，情商很高，凡事都耐心溝通，以解決問題為目標(biāo)導(dǎo)向的開發(fā)同事。當(dāng)然，我也遇到過一些缺乏耐心，但凡線上溝通都習(xí)慣帶好幾個問號，懟得產(chǎn)品經(jīng)理極為尷尬的開發(fā)同事。

很多情況下，我們無法選擇共事的同事，但我們可以掌握技巧，把自己的本分做好，追求雙贏。在這里，就結(jié)合自己的經(jīng)驗跟大家分享關(guān)于產(chǎn)品經(jīng)理如何跟開發(fā)同事溝通協(xié)調(diào)的問題吧。

首先我們先看看產(chǎn)品經(jīng)理跟開發(fā)同事產(chǎn)生沖突場景一般有哪些：

前期的需求溝通環(huán)節(jié)：

• 開發(fā)人員不認(rèn)同產(chǎn)品經(jīng)理的解決方案，導(dǎo)致撕逼沖突；
• 開發(fā)人員認(rèn)為產(chǎn)品經(jīng)理輸出的需求文檔不夠清晰，影響開發(fā)工作的展開。

需求開發(fā)與測試環(huán)節(jié)：

• 開發(fā)人員對產(chǎn)品經(jīng)理的需求變更帶來的代碼返工、任務(wù)量加重存在抵觸心理；
• 產(chǎn)品經(jīng)理缺乏技術(shù)相關(guān)知識的沉淀，與開發(fā)人員溝通的效率低下，易引發(fā)矛盾；
• 在開發(fā)過程中，產(chǎn)品經(jīng)理與開發(fā)人員的口頭或者線上溝通調(diào)整方案未及時更新到文檔，導(dǎo)致后期發(fā)生問題雙方存在扯皮的現(xiàn)象；
• 測試暴露的問題在需求文檔中的描述模棱兩可，責(zé)任無法劃清，導(dǎo)致雙方相互發(fā)生爭執(zhí)。

項目進(jìn)度把控環(huán)節(jié)：

• 在項目推進(jìn)的過程中，產(chǎn)品經(jīng)理因不懂需求背后的技術(shù)工作量，與開發(fā)人員就項目的開發(fā)進(jìn)度安排存在分歧；
• 產(chǎn)品經(jīng)理迫于項目上線壓力，繼而轉(zhuǎn)移壓力催促開發(fā)人員，久而久之引發(fā)開發(fā)同事的不滿。

以上就是產(chǎn)品經(jīng)理與開發(fā)同事產(chǎn)生矛盾的主要場景，有些產(chǎn)品經(jīng)理可能會遇到一些性格比較獨特的開發(fā)人員，常見的特點就是不茍言笑，說話容易誤傷他人，這屬于比較特殊的性格問題，需要特別注意。

下圖是我在網(wǎng)上看到的，描述的是開發(fā)人員對產(chǎn)品經(jīng)理的各種吐糟，相信很多產(chǎn)品經(jīng)理看到會覺得很受傷。

既然雙方天生存在矛盾，那么如何去緩解或者避免這種矛盾呢？

一、目標(biāo)驅(qū)動

我們在職場中的大部分事情其實都帶有目標(biāo)性，希望實現(xiàn)預(yù)期的效果，如果缺乏目標(biāo)的驅(qū)動性，做什么事情都是茫然的。產(chǎn)品經(jīng)理在跟開發(fā)的過程中，雙方可能會因為觀點的分歧而爭論，有時候爭得面紅耳赤，半天下來都沒有把問題解決。

這時候建議雙方都冷靜下來，想想我們本次溝通的目的究竟是什么？我們希望為用戶解決什么問題?繼而及時回到正確的溝通軌道，減免無效的內(nèi)耗。

之所以提出目標(biāo)驅(qū)動的溝通原則，主要是建議大家溝通之前、溝通過程中需要明確本次溝通的目標(biāo)，避免為了爭論而爭論，面紅耳赤拍桌板，到最后發(fā)現(xiàn)解決不了問題，還影響到雙方的關(guān)系，不歡而散。

二、利益驅(qū)動

最近看了一本書《窮查理芒格》，里面有句話：“如果你想說服別人，要訴諸利益，而非訴諸理性！”

人對自己切身利益的事情顯然更為關(guān)注，假設(shè)一個環(huán)保主義者，想說服大家通過少開空調(diào)減少氟里昂排放，從而減少臭氧層的破壞，保護(hù)環(huán)境。

這個訴求很高尚，然而并非所有人都可以理解。但是如果你換個角度說“經(jīng)常開空調(diào)容易導(dǎo)致關(guān)節(jié)疼痛與呼吸道疾病”，這種說法直接將少開空調(diào)與用戶的利益相關(guān)聯(lián)，可能說服力還更為強(qiáng)些。

產(chǎn)品經(jīng)理與開發(fā)人員的溝通也是同樣的道理，嘗試從開發(fā)的角度出發(fā)，尋找對方的利益點，作為溝通的突破點。

如果你一直跟開發(fā)說這個項目很緊急，這個項目對公司來說很重要，希望早點上線，可能他還是依舊根據(jù)自己的節(jié)奏來走，未能達(dá)到你的預(yù)期，因為你沒有切中他的利益點。

這時候你除了需要按照項目指定的時間節(jié)點定期跟進(jìn)開發(fā)的進(jìn)度外，還可以給予正向激勵與反向激勵。

所謂的正向激勵，指的是你做到了，對自己有什么利益。

比如當(dāng)遇到某個技術(shù)難點時，某些開發(fā)人員可能會先覺得很麻煩，產(chǎn)生了抗拒心理，但是換個角度想，如果開發(fā)人員如果集中精力攻克后，其實是有利于自身的能力提升與職業(yè)成長的，這個可以成為其中一個激勵的要素。

所謂的反向激勵，就是你做不到，對自己有什么利益損失。

比如你跟開發(fā)說，根據(jù)公司的要求，新開發(fā)的功能本周五必須得上線，否則可能需要辛苦團(tuán)隊人員加班加點，為了不周末加班，一般大家都愿意做一下沖刺。

當(dāng)然，這個得建立在對開發(fā)工作量有合理的評估基礎(chǔ)上。

職場上的正向激勵一般包括物質(zhì)的（薪酬福利等）與精神的（職業(yè)晉升與成才、團(tuán)隊認(rèn)可等），適當(dāng)利用某些激勵要素，會有意向不到的效果。

三、維護(hù)好你的PRD文檔

PRD是產(chǎn)品經(jīng)理需求方案的表達(dá)形式，是產(chǎn)品經(jīng)理與開發(fā)同事精準(zhǔn)的溝通工具。如果PRD本身的質(zhì)量不高，將會影響開發(fā)效率與質(zhì)量。

關(guān)于PRD的規(guī)范與標(biāo)準(zhǔn)，各個公司的要求可能還不一樣，但是核心目標(biāo)都是一致的，就是要清楚的向開發(fā)、測試同事轉(zhuǎn)達(dá)你的需求，說明白你想干什么。關(guān)于PRD，有以下幾點建議：

1. 產(chǎn)品解決方案的核心環(huán)節(jié)必須保證邏輯的嚴(yán)謹(jǐn)性，避免低級錯誤

如果一個解決方案的核心環(huán)節(jié)都出現(xiàn)了原則性的錯誤或者出現(xiàn)了某些非常低級的錯誤，那么在需求評審環(huán)節(jié)，就已經(jīng)讓開發(fā)同事對產(chǎn)品經(jīng)理的能力產(chǎn)生了質(zhì)疑。

心理學(xué)有種效應(yīng)叫“刻板印象”，就是一旦某個不好的印象在心理已經(jīng)產(chǎn)生了，那么就會長期形成一種固定而籠統(tǒng)的看法，當(dāng)他人對我們失去了信任，那么后面干什么事情都不會太順利。

2. PRD文檔要注重邏輯，而不止描述

什么是邏輯描述呢？傳統(tǒng)的軟件需求分析領(lǐng)域，在對一個use case（用例）進(jìn)行需求的細(xì)化時，往往會包括以下幾點：前置條件（即用例出現(xiàn)的前提條件）、主干流程（即正常流程）、后置條件（即流程結(jié)束后本體的狀態(tài)）、分支流程（即異常流程)。

在這里并不是要求大家嚴(yán)格按照這種格式去寫需求，只是建議大家在描述一個需求時，要從開發(fā)同事的角度出發(fā)，想想如何表達(dá)，才能讓開發(fā)清楚的知道產(chǎn)品需求是什么，而不是模棱兩可，一頭霧水。

但是如果這名開發(fā)同事比較盡責(zé)，他會追著你問細(xì)節(jié)，但這也造成了效率低下的問題。如果這名開發(fā)同事稍微缺乏點耐心或者責(zé)任心，他可能直接就開懟了或者按照自己的想法去實現(xiàn)，反正需求文檔沒有寫清楚。

下面舉一個文檔描述的反面與正面例子：

錯誤的做法（圖來自開課吧）

正確的做法（圖來自開課吧）

3. 文檔更新要及時

需求方案在落地開發(fā)的時候，不可避免的會產(chǎn)生需求的變更，比如因技術(shù)問題需要對需求進(jìn)行調(diào)整、產(chǎn)品經(jīng)理的PRD未考慮到某些異常的場景，需要補(bǔ)充需求說明等。

考慮到這時候需求已經(jīng)進(jìn)入開發(fā)階段，產(chǎn)品經(jīng)理可能會先跟開發(fā)人員口頭或者線上溝通具體的調(diào)整方案，然后開發(fā)同事可能就先行調(diào)整代碼了。

這時候產(chǎn)品經(jīng)理務(wù)必要將調(diào)整后的結(jié)果及時更新到需求文檔，并且知會相關(guān)人員，主要是開發(fā)與測試同事。

這樣子做的目的在于讓工作有跡，一般產(chǎn)品驗收的標(biāo)準(zhǔn)以PRD為準(zhǔn)，如果PRD未更新，那么可能出現(xiàn)開發(fā)當(dāng)時口頭承諾可以，但是因為其他事情忘記了，導(dǎo)致需求未實現(xiàn)，但是文檔也未更新，很容易導(dǎo)致雙方的扯皮。

4. 需求變更得謹(jǐn)慎

產(chǎn)品經(jīng)理變更需求是正常的，任何方案都沒辦法做到十全十美。

但是在變更需求之前，產(chǎn)品經(jīng)理需要仔細(xì)分析，不要隨意調(diào)整，若真的有變更的必要性，需要明確方案，并且跟開發(fā)人員溝通需求變更的背景，爭取對方的諒解。

沒有嚴(yán)謹(jǐn)?shù)姆治鏊悸?，想到什么就做什么的風(fēng)格，容易導(dǎo)致方案存在考慮不周全的風(fēng)險，繼而引發(fā)下一次的需求變更，開發(fā)人員是很抵觸產(chǎn)品經(jīng)理經(jīng)常性的需求變更的。

首先這個東西，開發(fā)已經(jīng)投入了時間精力去完成了，最終確因為需求不明確而需要多次返工；其次，長期如此，會讓開發(fā)人員對產(chǎn)品經(jīng)理越來越不信任，質(zhì)疑你的能力。

四、掌握一些基本的開發(fā)知識

關(guān)于產(chǎn)品經(jīng)理需不需要懂技術(shù)，這是一個被大家討論了很多遍的話題了。我覺得只需要懂一些基本的開發(fā)知識就可以了，如果是從事B端設(shè)計的產(chǎn)品經(jīng)理，對開發(fā)知識的掌握要求還會稍高些。

掌握適當(dāng)?shù)拈_發(fā)知識便于我們提需求的時候可以考慮技術(shù)的可行性與投入成本，在跟開發(fā)溝通、轉(zhuǎn)達(dá)需求的時候能夠更有效率。

有些產(chǎn)品經(jīng)理甚至?xí)W(xué)習(xí)如何編程，這個我認(rèn)為投入產(chǎn)出比不是很高，實在不建議。

在這里向沒有任何技術(shù)背景的初級產(chǎn)品經(jīng)理推薦這本書《給產(chǎn)品經(jīng)理講技術(shù)》，在微信讀書可以找到。這本書主要講解一些入門的技術(shù)概念，稍作了解即可，不需要太扣里面的技術(shù)細(xì)節(jié)。

下面跟大家分享幾個我覺得需要關(guān)注的一些技術(shù)常識或者與開發(fā)人員在技術(shù)方面的溝通技巧。

1. 了解最基本的前端、后端分工

簡單粗暴的說，前端一般負(fù)責(zé)用戶操作界面的展示、交互處理，后端一般負(fù)責(zé)底層邏輯的實現(xiàn)。

這樣子說可能還是有點抽象，就拿最常見的登錄功能來說吧。你打開某個系統(tǒng)進(jìn)入登錄界面，輸入賬號跟密碼，點擊登錄，最后成功進(jìn)入APP。

這里登錄界面就是前端操作界面，負(fù)責(zé)把需要填寫的字段展示給用戶（賬號與密碼），并且用與用戶產(chǎn)生交互(輸入/清除賬號、密碼)。

當(dāng)賬號與密碼輸入完畢，點擊登錄按鈕后，前端會把登錄請求傳送給后端服務(wù)器，后端會根據(jù)數(shù)據(jù)庫表對賬號跟密碼進(jìn)行校驗，后端會把結(jié)果返回給前端。

如果賬號跟密碼均正確，后端會通知前端登錄成功，否則就會通知對應(yīng)的錯誤類型（比如賬號不存在、密碼錯誤等）。

了解基本的前后端分工的好處在于：

• 在前期的需求溝通環(huán)節(jié)，可以幫助產(chǎn)品經(jīng)理了解本次功能模塊的責(zé)任分工與前后端大致的工作量，有助于產(chǎn)品經(jīng)理做項目進(jìn)程的管理；
• 當(dāng)產(chǎn)品出現(xiàn)問題時，產(chǎn)品經(jīng)理可以快速判斷問題在于前端還是后端，便于快速找到對應(yīng)的責(zé)任人進(jìn)行溝通，避免出現(xiàn)產(chǎn)品經(jīng)理無法定義問題的歸屬，把后端的問題拋給了前端，或者把前端的問題拋給了后端，這會影響我們的工作效率，如果長期如此，也會影響開發(fā)同事對我們的耐心。

2. 與開發(fā)的溝通重在邏輯

有時候我們跟開發(fā)同事溝通的時候，他們很容易就突然冒出很多技術(shù)術(shù)語，你還沒來及反應(yīng)過來，對方已經(jīng)表達(dá)完了。因為開發(fā)人員有自己的思維習(xí)慣，他們需要從技術(shù)的角度向外界闡述自己的觀點，這個是正常的。

遇到這種情況，我一般會謙虛的請求開發(fā)同事把我覺得有疑惑的地方重新表述一遍，有些時候我還會讓其用紙筆畫出對應(yīng)的邏輯思路，方便我直觀的理解。

如果涉及到后端，則會更為復(fù)雜些，后端重在邏輯的搭建，所以產(chǎn)品經(jīng)理一定要明白對應(yīng)功能點的技術(shù)實現(xiàn)邏輯，甚至有時候你可以指出某些邏輯上的漏洞。

多跟開發(fā)溝通，久而久之，你會發(fā)現(xiàn)，跟他們溝通起來會越來越輕松。

當(dāng)開發(fā)同事說某個功能不好實現(xiàn)或者無法實現(xiàn)時，我習(xí)慣通過這種方式去了解背后的原因，有時候你會發(fā)現(xiàn)開發(fā)的邏輯是存在漏洞的，或者對需求的理解有誤，這才導(dǎo)致功能實現(xiàn)的出現(xiàn)了難度。

3. 不懂多查，不懂多問

當(dāng)我們跟開發(fā)溝通時候時，你可能聽不懂某個術(shù)語，比如開發(fā)說這個下載功能我用的是異步處理方式，這個時候如果你不懂這個東西，就得多問了。

平常自己看到某個陌生的技術(shù)術(shù)語，可以多百度，基本上多看幾遍就知道是怎么回事了，技術(shù)術(shù)語是溝通的關(guān)鍵，我們需要多主動去了解。

比如什么是同步、異步、API、URL、APP技術(shù)框架（Native App、Web App、Hybrid App）、寫死，了解相關(guān)技術(shù)術(shù)語，相當(dāng)于掌握了與開發(fā)溝通的語言，是自己專業(yè)素質(zhì)的體現(xiàn)。

五、維護(hù)基本的人際關(guān)系

雖然這個是一個人盡皆知的大道理，但還是在這里提出來。如果你的人際交往能力不錯，那么跟開發(fā)維持友好的人際關(guān)系將能使自己的產(chǎn)品工作事半功倍。

你跟開發(fā)關(guān)系不錯，他可能會幫你提出產(chǎn)品的某些問題，你的需求他也愿意幫你完成。

有些時候，產(chǎn)品經(jīng)理跟開發(fā)人員可能到了水火不容的地步了，這個其實不太利于工作的開展。

當(dāng)然了，不是誰都有能力可以把周邊的人際關(guān)系處理得很好，但是互相尊重，互相理解，減少不理性的沖突與矛盾，這是我們的一個理想的目標(biāo)。人際溝通與交往是一門藝術(shù)，值得我們好好琢磨。

六、寫在最后

一個好的產(chǎn)品，背后往往有優(yōu)秀的產(chǎn)品經(jīng)理與優(yōu)秀的研發(fā)人員，外界喜歡把產(chǎn)品經(jīng)理跟研發(fā)人員的關(guān)系調(diào)侃成互相對立的局面。

我相信大部分的研發(fā)人員不會因為產(chǎn)品經(jīng)理不是技術(shù)領(lǐng)域的專家就產(chǎn)生排斥，但是產(chǎn)品經(jīng)理需要不斷提升自己的專業(yè)能力與溝通協(xié)作能力，爭取得到開發(fā)人員足夠的信任，這是一個需要長期努力的過程。

作者：小狼人，微信公眾號：人稱產(chǎn)品汪。不定期更新本人在對接第三方支付平臺與銀行存管系統(tǒng)中的經(jīng)驗心得、支付知識、產(chǎn)品心得等。

本文由 @ 小狼人? 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。