產品經理要認真的、反覆的說明此產品的市場份額，市場的定位，具體的實施方案和技術難度，智慧財產權的涉及、應用，技術引數和應用程度，市場上反映情況，.....都得給於回覆和說明，就我們說的技術交底。一般情況下一個星期開此會一次，非正常可以隨時開會交流，一個產品成型有很多的資料和圖紙，國家標準和規劃要提現出來，這些要我們的技術人員一筆一劃的寫出的，一個產品基本就是這樣的。謝謝悟空邀請回答！

在產品和專案中，因為參與的多方角度不同，導致看待問題和解決方式也不盡相同，這會在程序中產生阻礙。那麼一般由產品／專案經理做主導的任務中，和技術人員應該如何更好的溝通呢？

說實話，技術人員在產品經理要溝通的人群中（老闆、客戶、運營、銷售、財務、法務、外部門PM、UI、RD）真的算是非常好溝通的一群人，如果你覺得溝通起來很費勁，只能說你自己還沒把事兒理清楚想明白呢。

一般產品跟技術人員溝通的時候是在產品設計已經完成，進行需求評審時容易發生比較大的衝突或分歧。還有就是如果你總是在研發過程中更改需求或者壓縮整個工期，他們肯定也沒有好臉色給你看。那如何避免這種情況的發生呢？

明確產品目標，同步背景

需求評審的時候很多人直接就開始直入主題講這個原型是什麼，互動及邏輯是什麼，這個時候RD會覺得自己就是個執行者，一臉懵逼的看著你。所以為了更好的讓RD明白，一般都會在評審前給大家講我們為什麼要做這個專案/這個需求（千萬不要說因為這個是老闆要求做的……你是產品經理，任何需求到了你這裡都需要進行前期調研到底能不能做，要是老闆讓你做啥就做啥，你就是自己沒帶腦子分析過），然後同步前期的背景，做到資訊同步。這樣研發才會和你有一個共同的認知，意識到自己做的東西的重要性和意義所在。

產品框架結構清晰

在講解具體需求之前，還需要你自己梳理好整個產品框架結構或者內在邏輯。一般的呈現方式有：

1、腦圖：一般用來說明產品整體的結構分幾大塊，每塊包含哪些功能，也可註明優先順序。常用的腦圖工具有mindmanager，visio，我習慣用線上的processon（地址https://www.processon.com/ ）

（舉例，借用網圖）

2、泳道圖：如果系統涉及到的角色比較多，流程很複雜，一般會用泳道圖來說明。這樣方便研發人員一眼能明白整個系統的流轉及每個角色在其中的作用。這個比你用語言去每個頁面描述強太多了。這個visio也可以畫，但是我仍然習慣用線上的processon....

（我自己之前做的一個保養流程的圖）

3、流程圖：一般要說明一個單獨模組裡的複雜邏輯會用到流程圖，比如登入註冊的流程（別看不起登入註冊流程，好的產品經理和差的產品經理往往透過這個流程就能識別出來）。話流程圖的工具最開始我直接用PPT畫，後來換mac之後用Ominigraffle，現在已經習慣用processon……（真的啥都能畫啊……）

原型及文件簡潔

其實如果能在第二步產品框架結構梳理得特別清楚，原型和文件寫出來就很快了，不過很多初級產品經理習慣一邊畫圖一邊想邏輯，這就很慢了，還容易漏。

1、原型：一般產品做低保真原型即可，畫出頁面的主要功能和頁面跳轉邏輯，建議PM不要太多陷入到按鈕顏色、按鈕位置等細節中（這些一般UI同學比你經驗豐富）。常用工具：Axure、AI、Sketch、mockplus、墨刀等。看自己喜好吧，能達到目的就行

2、文件：文件我覺得有幾個原則吧：

1）重複模組只需在第一次出現的時候詳細說明，後面可以一筆帶過（比如翻頁）；

2）能用表格說明的，請不要用長段的文字說明，RD看著結構越清晰越好；

3）異常流程一定要考慮到：還是拿登入來說，比如登入的時候手機號沒輸完怎麼辦？帳號密碼錯誤怎麼辦？驗證碼沒收到怎麼辦？你考慮的異常流程越多，技術GG才會覺得你越專業，信任就是這麼一點一點建立起來的。

評審時要虛心接受意見

見過很多需求評審到最後都變成了PM和RD的扯皮大會，其實完全沒必要。如果遇到RD有意見的地方，一般3種處理方式：

1、你認為RD說得對：那就採納，然後說“嗯，你這個建議非常好，我下來按照你說的改，下次再評。”

2、你對RD的建議存疑：你說這個我一會下來跟大家討論一下，先擱置爭議，我們繼續評審接下來的部分。然後下來之後你一定要去從使用者角度看這個問題是否應該按照原來的方案還是用RD的方案，或者還有沒有更好的方案，然後及時跟提出建議的RD反饋你的想法。

這樣評審下來，技術GG一定會覺得這個產品經理還是講道理的嘛，並不是胡攪蠻纏，就覺得“我覺得使用者就是這樣想的”“老闆就是要這麼做”。

以上，就是我認為跟技術人員溝通時要注意的問題。程式設計師的世界真的挺簡單的，你自己想清楚了，能說服你自己，你就能說服程式設計師：）

在做產品之前對於這個問題也糾結了很久，在長期的實踐過程中，慢慢總結出一些規律。很多產品人員給開發提需求的時候，只會告知開發需要實現某個功能，而並不具體說明為什麼要做這個功能實現的目的以及如何去實現它，在他們的潛意識裡認為開發人員只管實現功能就好，而且如何更高效地完成他們應該比產品更明白，往往這種情況下，沒有進行充分溝通，產品人員對該功能的理解是一方面，開發人員的理解是另一方面，雙方因此產生理解歧義。

這個場景在很多創業公司中都會出現，我不敢說該問題在我身上已經徹底的解決掉，對於這個問題的思考和分析我發表一些自己的觀點。

對於產品人員，特別是沒有技術背景的產品人員，對於一個需求的實現沒有考慮成本因素往往覺得功能越複雜越高大上，開發人員直接根據產品人員給出的需求定義開發，有時反而做出的東西沒有實際意義卻耗時，導致整體專案的時間成本消耗非常大。因此，對於以上的問題，我認為在前期的需求討論時，開發人員就應該參與，在談論需求的過程中加深對此需求業務背景的瞭解，對於整體開發過程中可以減少因理解歧義產生的無用功；也會因此產生更低實現成本的方案，這對每個公司來說是至關重要的。當然過程中開發人員參與討論固然重要最終的決策權仍必須掌握在產品經理手中。

1、邏輯流程圖：產品人員在給開發人員講解功能需求時，必須準備一份邏輯流程圖加深開發人員對需求的理解，完整的需求概念是需求溝通重要的一步。對於開發人員而言，整體的需求理解影響他們對開發框架的搭建，若沒有得到完整的需求，對彼此功能點的關聯的理解也是存在偏差，那最終實現起來的功能也不會盡如人意。

2、產品需求文件：產品需求文件是開發人員開發產品最直接的文字依據。即使在溝透過程該注意的細節都有過一遍，但是很多開發人員並不能對每個細節記得非常牢固，這就需要我們對於溝透過的細節做出記錄並以提醒的方式警醒開發人員在開發過程中必須要考慮到，這才能使功能需求更完整的開發。很多時候因產品需求文件不夠詳細導致實際開發出來的功能與定義好的功能落差太大，導致功能多次最佳化和返工，時間成本的消耗也是巨大的。因此一份詳細的需求文件也是產品人員和開發人員之間溝通的重要橋樑。產品人員與開發人員之間也不能以產品需求文件作為溝通，為了避免矛盾和整體專案開發的進度，日常工作中也要注意其他細節的溝通。

對於需求要清晰、有條理的表達；因為是合作關係，你表述的越清楚，在開發人員諮詢你的時候，思路越清晰，改動量越少，開發人員的積極性、效率就會越高。

在與開發人員溝通時，要站在對方的角度去理解開發人員的問題，認真聽取對於需求的不同建議，以及開發的實現難度。充分理解並尊重對方的想法，才能提高雙方合作的效率，或許在這種溝通中可以激發你找到更好的解決方案。

當然產品人員在與開發人員溝通的時候要注意開發人員當前的狀態，大多數情況下心情不好的時候不想溝通一些複雜且有爭議的需求讓心裡更不舒坦。因此在溝通需求時儘量選擇開發人員心情愉悅時溝通效率更高，在溝透過程中儘量用和緩的語氣和溫和的態度進行溝通。