起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理與技術溝通，需要注意這幾點
編輯導讀：因為產品經理需要和很多部門同事合作，所以產品經理的溝通能力非常重要。技術人員作為溝通最密切的人員之一，經常容易發生沖突。本文作者基于自身工作經驗，從四個方面分析如何和技術人員溝通，希望對你有幫助。
其實這個話題舊文《產品經理的軟性能力：協同力與領導力》已經聊過，我覺得我已經講的很清楚了，回看覺得再細化具體一點。
其實，協同能力和領導力都是需要靠溝通能去實現，今天就聊聊[溝通]。
我們在研發生產過程中，需求反復和雙方理解偏差導致研發周期總是被拖，還有產品與技術各種撕，等等。
這些情景在網上被吐槽了很多很多了，而且是更古不變的話題。也是我們產品經理最為頭疼的問題。
我有些方法能夠解決一些問題，但是我不能保證解決所有的溝通問題，畢竟人是復雜的，取決于溝通雙方個人因素。
在舊文中，我說產品經理是首席解釋官。
因為整個項目只有你最清楚項目的背景。
所以一個產品項目溝通你需要基于背景/目標、業務范圍及流程、功能及流程、交互元素和操作邏輯去溝通。
01?介紹項目背景/目標
很多產品人員經常這樣做項目，直接告訴工程師我要做一個產品需要什么功能，多久能夠實現。
并不說明，我為什么要做這個，我做這個的背景因素是什么，在什么情景下解決用戶的什么問題？達到什么目標？
也許你覺得，工程師知道這些干什么？工程師只需要實現功能就好了。但實際上，這往往造成雙方理解的偏差。
舉個例子，在一個項目立項會后，我們一位硬件技術負責人跟我說，我們為什么不像誰誰那樣做一些高精尖技術的產品，總是做這些我們做過很多次的成熟技術項目，沒什么意思。
因為他不明白我做這個產品的市場目的，以及這個產品誕生的背景。
當我告訴他我們目前產品線遇到的問題，同行競爭的狀態，公司目前能力和資源，以及我們的市場狀況以及之后的規劃后。
他說，原來是這樣啊！那我們快馬加鞭把這個問題解決，爭取我們提前上馬既定的規劃。
我們總是說，工程師不給力，你看這樣工程師馬上從消極狀態變成積極狀態。
這是針對市場的背景和目標。
另外，還有針對技術的，產品經理應該清晰的表達出產品的使用場景。
還是舉個例子，比如我們要做一個人臉識別設備，你直接告訴技術要實現人臉識別可行嗎？
你想想，設備看不見人臉怎么辦，哪種安全度更好？
當你跟工程師充分溝通之后，才能設計出合理的、成本合適的產品。
因為，我們產品經理很多往往沒有技術背景或者技術背景很弱，你自己吭哧吭哧設計的產品，技術人員按照你的定義設計的不一定滿足場景的需要，或者不一定有經濟性、效率性。
當然，有些公司不希望技術人員知道的太多，比如項目背景，都是極其保密的。但是至少項目要達成的目標你應該與技術人員溝通。
這樣有幾個好處：
- 技術人員能夠更好的理解產品，減少對需求理解的偏差。避免出現做出來的功能/性能達不到要求；
- 在技術實現方案上可以獲得更優解，也可能在實現成本上具備優勢（時間和經濟成本）；
- 提高項目組的積極性，因為對產品不再是一知半解，不明白的全靠腦補；明確目標更加熱愛產品，因為有期望。
02?梳理出項目的業務及流程圖
我們常說，功能組成業務；業務組成模塊；模塊組成產品；產品組成產品線。用產品及產品線和服務來實現你的戰略。
很多產品經理在設計產品的時候及立項會上，一上來就從功能開始。
不僅自己腦子是一團漿糊，聽的人更是。
在做具體的功能設計和介紹的之前，應該給一個業務范圍和流程。
先介紹，你的產品為了解決什么問題需要做什么業務，又為了什么規劃要將范圍做到哪里。
這樣做是為了加深項目組成員對需求的理解。以此更好的做產品技術設計。
很多時候，產品經理覺得我已經講的很清楚了，那是因為你從一開始就知道這個項目是什么，你知道整體的背景、產品與產品與云服務之間的關系。你早就把自己帶入了實際的場景之中，
但是工程師不一樣，他只從你一個個的功能上去自己腦補，他總感覺挺亂的，一會兒到這兒，一會兒到哪兒。到底要怎樣？他們不明白其中的邏輯關系。
比如，我們智能硬件，物聯網。通常是 A 產品與 B 產品連接，數據傳輸，從云端處理或者中轉等等。
你應該首先給一個產品關系圖，怎么連接到一起的，通過什么連接的。
然后介紹，你的產品做了什么業務，然后這個業務流轉到哪里？
一項一項的介紹，介紹完某幾個相關業務之后，給出他們的邏輯關系，最好用圖的形式表示。
03?梳理功能及功能流程圖
業務及業務流程圖梳理清楚了，那整個系統產品的輪廓就行了。
還記得我們說功能組成業務吧！
將業務拆解成一個個的功能，因為業務是由功能完成的結果。
所以需要將一個個的功能串起來，形成關系。
將這些背景向工程師解釋清楚，功能需求的目的。
有時候，產品經理認為自己已經說的很清楚了，為什么工程師并不明白呢？
主要是因為產品人員在項目早期，深入到用戶的使用環境，已經了解了工作流程，遇到的困難和麻煩。
對產品的背景、結構、要實現的目標有了親身的體會，非常清晰其中的功能關系。
那工程師就不一樣，他們了解的信息是支離破碎的。
他們需要你梳理功能范圍以及功能流程，異常處理機制，所產生的信息流向是哪里？
比如，用無人機進行一個繞自身一周的自拍視頻發朋友圈。
這個業務，是由多個功能組成的實現的。
無人機離拍攝者多遠，離地面多高？以什么速度繞圈，怎么去設置這些功能？什么條件下可以執行，什么條件下不可以執行任務，執行完任務，又作何處理？等等。
如果，產品人員在設計需求的時候，沒給出整個業務的結構和流程，那么工程師只能靠自己的腦補。那這樣就徹底偏離了產品的方向。
要么產品偏向，那么整個系統不完整，漏洞百出。像無人機這樣的產品會出現人身安全風險。
還有一個重要的溝通，我們產品經理可能不懂，那就是算法。智能硬件很多都涉及算法，包括我們做自主移動機器人，前幾天還寫了一篇關于 PID 的文章。但是產品經理需要與工程師溝通，了解其邏輯，實際表現出來的效果，參與其中，是否符合用戶需求和預期。
04?交互元素和操作邏輯
智能硬件產品多是具備聯網功能和與人交互的。無論是人與機器的交互，還是人與 App 的交互，還有操作邏輯。
App 這個咱們就先不講，我們看看人與機器的交互需求設計。
人機交互有很多方式，比如揚聲器、顯示屏、燈光、按鈕等等。
產品經理應該清楚的交代表現和動作方式。
拿按鈕來講，為了安全和誤觸需要設計成“短按+長按”來實現開關機，間隔多久；按鈕的設計元素。
顯示屏顯示哪些內容信息，格局如何？是否可以進行觸摸操作，操作邏輯。界面元素是怎樣的？如何表現？如果進行操作，產生的數據邏輯是怎么樣的？等等！
這塊兒就不多講了，互聯網在交互上有很多我們學習的地方。
05 最后
關于產品文檔的事情，真的不需要找什么模版，沒有用。只要清楚的交代出產品需求就好了，至于什么格式，用什么軟件那都不重要。
哪怕在紙片上龍飛鳳舞都行。
說說我自己關于文檔的事情吧！我往往是將文檔寫的越細越好，當然存在一個問題是，溝通的時間成本比較高，我認為，寫的越精確越好。好記性真不如爛筆頭，無論是后期查閱，還是當你不在的時候，技術不能及時的溝通，查閱文檔也是一個比好優質的方法。
后期復盤也是重要的依據，知道產品是如何演進的。
文字多了確實麻煩，工程師也不愛看。
但是，業務、功能流程圖，操作邏輯，數據流向等結構/關系圖一定要畫。
所謂文不如表，表不如圖。
好了，產品與技術溝通的方法技巧還有很多，但總體原則是不變的。
作者：Arvinzhou，微信號：zf519678391；公眾號：面壁求知，ID：AIPM001）歡迎關注我！
本文由 @周較瘦 發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
總結的挺好！
咨詢下樓主，在轉行產品經理，是從事什么崗位？
公眾號內有介紹