中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

產品經理跟開發人員在日常工作中有著非常頻繁的溝通與協作需求，可以說PM跟RD是一對矛盾體，兩者之間因為有著共同的項目驅動目標，而需要相互溝通協作。

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

于是，矛盾便產生了。

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

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

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

很多情況下，我們無法選擇共事的同事，但我們可以掌握技巧，把自己的本分做好，追求雙贏。在這里，就結合自己的經驗跟大家分享關于產品經理如何跟開發同事溝通協調的問題吧。

首先我們先看看產品經理跟開發同事產生沖突場景一般有哪些：

前期的需求溝通環節：

• 開發人員不認同產品經理的解決方案，導致撕逼沖突；
• 開發人員認為產品經理輸出的需求文檔不夠清晰，影響開發工作的展開。

需求開發與測試環節：

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

項目進度把控環節：

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

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

下圖是我在網上看到的，描述的是開發人員對產品經理的各種吐糟，相信很多產品經理看到會覺得很受傷。

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

一、目標驅動

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

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

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

二、利益驅動

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

人對自己切身利益的事情顯然更為關注，假設一個環保主義者，想說服大家通過少開空調減少氟里昂排放，從而減少臭氧層的破壞，保護環境。

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

產品經理與開發人員的溝通也是同樣的道理，嘗試從開發的角度出發，尋找對方的利益點，作為溝通的突破點。

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

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

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

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

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

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

當然，這個得建立在對開發工作量有合理的評估基礎上。

職場上的正向激勵一般包括物質的（薪酬福利等）與精神的（職業晉升與成才、團隊認可等），適當利用某些激勵要素，會有意向不到的效果。

三、維護好你的PRD文檔

PRD是產品經理需求方案的表達形式，是產品經理與開發同事精準的溝通工具。如果PRD本身的質量不高，將會影響開發效率與質量。

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

1. 產品解決方案的核心環節必須保證邏輯的嚴謹性，避免低級錯誤

如果一個解決方案的核心環節都出現了原則性的錯誤或者出現了某些非常低級的錯誤，那么在需求評審環節，就已經讓開發同事對產品經理的能力產生了質疑。

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

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

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

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

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

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

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

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

3. 文檔更新要及時

需求方案在落地開發的時候，不可避免的會產生需求的變更，比如因技術問題需要對需求進行調整、產品經理的PRD未考慮到某些異常的場景，需要補充需求說明等。

考慮到這時候需求已經進入開發階段，產品經理可能會先跟開發人員口頭或者線上溝通具體的調整方案，然后開發同事可能就先行調整代碼了。

這時候產品經理務必要將調整后的結果及時更新到需求文檔，并且知會相關人員，主要是開發與測試同事。

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

4. 需求變更得謹慎

產品經理變更需求是正常的，任何方案都沒辦法做到十全十美。

但是在變更需求之前，產品經理需要仔細分析，不要隨意調整，若真的有變更的必要性，需要明確方案，并且跟開發人員溝通需求變更的背景，爭取對方的諒解。

沒有嚴謹的分析思路，想到什么就做什么的風格，容易導致方案存在考慮不周全的風險，繼而引發下一次的需求變更，開發人員是很抵觸產品經理經常性的需求變更的。

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

四、掌握一些基本的開發知識

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

掌握適當的開發知識便于我們提需求的時候可以考慮技術的可行性與投入成本，在跟開發溝通、轉達需求的時候能夠更有效率。

有些產品經理甚至會去學習如何編程，這個我認為投入產出比不是很高，實在不建議。

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

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

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

簡單粗暴的說，前端一般負責用戶操作界面的展示、交互處理，后端一般負責底層邏輯的實現。

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

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

當賬號與密碼輸入完畢，點擊登錄按鈕后，前端會把登錄請求傳送給后端服務器，后端會根據數據庫表對賬號跟密碼進行校驗，后端會把結果返回給前端。

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

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

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

2. 與開發的溝通重在邏輯

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

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

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

多跟開發溝通，久而久之，你會發現，跟他們溝通起來會越來越輕松。

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

3. 不懂多查，不懂多問

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

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

比如什么是同步、異步、API、URL、APP技術框架（Native App、Web App、Hybrid App）、寫死，了解相關技術術語，相當于掌握了與開發溝通的語言，是自己專業素質的體現。

五、維護基本的人際關系

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

你跟開發關系不錯，他可能會幫你提出產品的某些問題，你的需求他也愿意幫你完成。

有些時候，產品經理跟開發人員可能到了水火不容的地步了，這個其實不太利于工作的開展。

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

六、寫在最后

一個好的產品，背后往往有優秀的產品經理與優秀的研發人員，外界喜歡把產品經理跟研發人員的關系調侃成互相對立的局面。

我相信大部分的研發人員不會因為產品經理不是技術領域的專家就產生排斥，但是產品經理需要不斷提升自己的專業能力與溝通協作能力，爭取得到開發人員足夠的信任，這是一個需要長期努力的過程。

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

本文由 @ 小狼人? 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

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