起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理跟程序員友好相處的3個技巧
編輯導語：產品經理很重要的一項日常工作就是與程序員打交道，我們不難從網上流傳的各種段子中看出，產品經理與程序員的關系并不是十分融洽。但是只有在融洽的氛圍下開展工作，才能有效推動工作進度，本文作者分享了產品經理跟程序員友好相處的3個技巧，希望對各位產品經理和程序員有所幫助。
在幾年前的一場面試，對方問我：“有沒有和程序員吵過架？”當時的我頗稚嫩，豈圖想在面試中體現自己的完美，回答道：“沒有”，對方皺眉頭嘀咕：“真的沒有嗎？”后來面試結果不了了之。
現在回想起來，做產品跟程序員長時間共事，并不是沒有過爭執，只不過不管大吵小吵，最終我們依舊回歸到工作上，一起打磨產品。
本文不教請客吃飯人情世故，而是從產品經理專業角度，提出幾個可以跟程序員友好相處的技巧；當然，本文提到的幾個技巧已經過本人實踐，有過淚水和笑聲，如有雷同純屬巧合。
了解背景：我們的做事立場有何不同
首先，我們先了解一下程序員與產品經理做事出發的立場有什么不同：
日常工作流流程簡述為：
- 產品經理梳理需求，通過文檔向程序員表達需求邏輯；
- 程序員按照需求文檔開發，期間會涉及到：需求調整、bug處理不等修整；
- 產品經理驗收，再梳理出優化或新的需求。
整體上，程序員的工作事項都圍繞著需求，需求正來自產品經理，因此程序員但凡對需求有任何想法或疑問，都得和產品經理商量，這種從屬關系在某種程度上很容易陷入主觀和客觀之間的抽離。
再結合目前，的確存在產品經理專業能力參差不齊的現象，如果遇到需求來源復雜身不由己，說不清道不明，相處關系自然會貼上“對事不對人”的標簽。
程序員日?？丛汀⒃u審需求、分析文檔和梳理邏輯框架，對需求抱著一個中心思想那就是：這個需求能不能做，能做就能做，不能做就不能做，不存在凌磨兩可，凌磨兩可也只是時間問題。
不難發現，我們常愛調侃程序員是直男，實際上與他們常年工作的思維模式有著密切關系，寫程序是直線思維，相對來說比較嚴謹的，產品經理口中的用戶體驗、產品質量、交互效果，在他們眼里都是：我要怎么實現這個需求。
這段背景秉承開個頭讓產品經理嘗試去理解程序員的思考邏輯，再以此為要點貫徹到我們工作常見的幾個場景里，對應技巧可以是哪些。
一、嘗試去尋找解決方案
不太清楚會不會真的有產品經理對程序員提出“要求APP的主題顏色能根據手機殼自動調整”這樣的需求，但我們常說的“技術可行性”的確是產品需求的硬性前提條件之一。我們通常會這么跟程序員打交道：
- 在提供方案前咨詢程序員需求可行性，程序員不一定深入調研、有空或好溝通；
- 直接找案例的實現效果，實際情況、技術框架或系統不一定適用；
- 憑直覺和經驗覺得可行，產品經理更傾向于獨立思考，高效直接。
第3點最常見，后續也最容易引起挑戰，畢竟組織架構或者跨部門工作流程，都會導致產品經理經測試孤軍作戰去推動項目需求。
我曾在一個項目重構上提出優化ES搜索規則，但搜索結果的權重差如人意，程序員讓我接受現實：涉及全文檢索，列表顯示的結果無法完全精準”，一時僵局，后來在CSDN找到類似案例，把解決方案的鏈接發過去，程序員解決思路就通了。
所以我們可以在梳理需求時，提煉可預測的技術難點，并且學會尋找可解決的方案備著：如果是小程序、微信、企業微信生態的產品，我們可以多逛逛微信開發社區，了解開發、運營文檔更新的內容，了解官方的開放規則。
如果是自主開發的系統，也可以逛逛CSDN、簡書，或者直接帶著問題去百度。切記是有場景才去找解決方案，而不是沉浸式理解學習，畢竟我們是奔著解決問題，而不是為了做一個懂技術的產品經理。
二、嘗試去說明業務背景
- “你為什么這樣設計？”
- “你的需求出于什么目的？”
- “看不懂你寫的A和B是什么關系”
程序員這三連問是不是很熟悉？是不是常常問得讓人語塞，或者反復解釋邏輯，仍然存在“代溝”，很正常。
回憶我們的需求鏈前常常是有很多繁瑣的業務問題、業務流程，不少需求需要產品經理經過深入調研，梳理出一套具備可被標準化的系統架構，如果不是像電商那類ToC的產品，在我們日常生活就能理解到位的操作流程，程序員更難通過一次評審、一份文檔或零碎溝通理解到位。
因此我們除了原型、需求文檔，還會配套輸出業務流程圖、產品流程圖，幫助他們了解業務背景，但仍不夠。
我們可以嘗試對程序員說明業務背景，通過這些方式：
- 在梳理需求中的業務溝通會議帶上部分有意愿的程序員或負責人，讓整個項目團隊都理解難，讓整個項目團隊都參加也難，所以抽一部分擅長對外溝通的人員，讓他們在后續項目出現這類問題時，可以幫助產品經理引導思路或梳理開發內部的工作；
- 講產品方案前，帶上業務同事代表或我們額外整理一些有關業務的示例如數據圖表或業務文檔，幫助程序員理解業務日常工作所面對的痛點、一些專業話術實際上與什么信息對標。
當然，我建議不直接和每個程序員或單個程序員對接挑戰，而是通過轉移矛盾的方式，將對象變成一個組或負責人，用其它層級的利益點去推動這件事情，可能會事半功倍。
比如，我和某個后端程序員說不通，那我就叫上測試、前端或者他的組長一起來理解我為什么這樣考慮產品方案：“你們有什么更好的建議或者方案都可以拿出來一起探討”，讓項目組更多人理解背景，何嘗不是一件省心的事呢？
三、嘗試去跟進項目
現在有不少公司將產品經理的工作職責精細化，產品經理只需要輸出需求文檔，項目管理或跟進的工作則由項目經理全權負責，我對這種模式的優缺點保留意見。首先，我先拋出項目過程中所遇到的風險點都有哪些，不限于：
- 功能模塊、項目排期進度是否如期；
- 需求理解、所呈現的效果是否到位；
- 產品文檔是否有遺漏的地方，是否滿足開發要求。
以上任意一點，在程序員啟動開發后，一旦項目反饋機制不夠健全，產品經理都可能不知情，而錯失在開發期間及時補充完善的機會，最終可能導致產品質量有問題。
所以你還會認為，我們產品經理在評審到交付前就沒事情可做，讓項目經理去跟進就可以了嗎？那當然不是了。
沒人抗拒產品經理“不請自來”，我們可以厚著臉皮參加到程序員的站會中去，旁聽他們工作進度，有什么技術難點、有什么模塊可能被遺漏、有什么風險點被一句帶過沒下文；
我喜歡觀察開發排期或者項目管理系統，在那里可以清晰看到開發對需求細分的模塊（是否有遺漏），每個需求點的估時（是否趕得上交付或安排在節假日前上線等風險）；也可以反哺自查產品經理設計方案內容：整體需求框架是否清晰易理解、層級流程是否合理、閉環異常狀態等等。
四、寫在最后
產品經理跟程序員友好相處的技巧只有3個嗎？
我想遠不止，但不難發現，技巧的核心都是1個方向，那就是“產品經理多做一點”，世界也可以變得更美好：多做一點思考，跳出自己只是個產品設計者的框架，讓自己更全面更專業，相信程序員也會自主思考道：我該怎么跟產品經理友好相處。
本文由 @Miss思思 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議。
不錯哦，主人翁精神