編輯導(dǎo)語：產(chǎn)品經(jīng)理很重要的一項(xiàng)日常工作就是與程序員打交道，我們不難從網(wǎng)上流傳的各種段子中看出，產(chǎn)品經(jīng)理與程序員的關(guān)系并不是十分融洽。但是只有在融洽的氛圍下開展工作，才能有效推動(dòng)工作進(jìn)度，本文作者分享了產(chǎn)品經(jīng)理跟程序員友好相處的3個(gè)技巧，希望對(duì)各位產(chǎn)品經(jīng)理和程序員有所幫助。

在幾年前的一場面試，對(duì)方問我：“有沒有和程序員吵過架？”當(dāng)時(shí)的我頗稚嫩，豈圖想在面試中體現(xiàn)自己的完美，回答道：“沒有”，對(duì)方皺眉頭嘀咕：“真的沒有嗎？”后來面試結(jié)果不了了之。

現(xiàn)在回想起來，做產(chǎn)品跟程序員長時(shí)間共事，并不是沒有過爭執(zhí)，只不過不管大吵小吵，最終我們依舊回歸到工作上，一起打磨產(chǎn)品。

本文不教請(qǐng)客吃飯人情世故，而是從產(chǎn)品經(jīng)理專業(yè)角度，提出幾個(gè)可以跟程序員友好相處的技巧；當(dāng)然，本文提到的幾個(gè)技巧已經(jīng)過本人實(shí)踐，有過淚水和笑聲，如有雷同純屬巧合。

了解背景：我們的做事立場有何不同

首先，我們先了解一下程序員與產(chǎn)品經(jīng)理做事出發(fā)的立場有什么不同：

日常工作流流程簡述為：

• 產(chǎn)品經(jīng)理梳理需求，通過文檔向程序員表達(dá)需求邏輯；
• 程序員按照需求文檔開發(fā)，期間會(huì)涉及到：需求調(diào)整、bug處理不等修整；
• 產(chǎn)品經(jīng)理驗(yàn)收，再梳理出優(yōu)化或新的需求。

整體上，程序員的工作事項(xiàng)都圍繞著需求，需求正來自產(chǎn)品經(jīng)理，因此程序員但凡對(duì)需求有任何想法或疑問，都得和產(chǎn)品經(jīng)理商量，這種從屬關(guān)系在某種程度上很容易陷入主觀和客觀之間的抽離。

再結(jié)合目前，的確存在產(chǎn)品經(jīng)理專業(yè)能力參差不齊的現(xiàn)象，如果遇到需求來源復(fù)雜身不由己，說不清道不明，相處關(guān)系自然會(huì)貼上“對(duì)事不對(duì)人”的標(biāo)簽。

程序員日?？丛?、評(píng)審需求、分析文檔和梳理邏輯框架，對(duì)需求抱著一個(gè)中心思想那就是：這個(gè)需求能不能做，能做就能做，不能做就不能做，不存在凌磨兩可，凌磨兩可也只是時(shí)間問題。

不難發(fā)現(xiàn)，我們常愛調(diào)侃程序員是直男，實(shí)際上與他們常年工作的思維模式有著密切關(guān)系，寫程序是直線思維，相對(duì)來說比較嚴(yán)謹(jǐn)?shù)?，產(chǎn)品經(jīng)理口中的用戶體驗(yàn)、產(chǎn)品質(zhì)量、交互效果，在他們眼里都是：我要怎么實(shí)現(xiàn)這個(gè)需求。

這段背景秉承開個(gè)頭讓產(chǎn)品經(jīng)理嘗試去理解程序員的思考邏輯，再以此為要點(diǎn)貫徹到我們工作常見的幾個(gè)場景里，對(duì)應(yīng)技巧可以是哪些。

一、嘗試去尋找解決方案

不太清楚會(huì)不會(huì)真的有產(chǎn)品經(jīng)理對(duì)程序員提出“要求APP的主題顏色能根據(jù)手機(jī)殼自動(dòng)調(diào)整”這樣的需求，但我們常說的“技術(shù)可行性”的確是產(chǎn)品需求的硬性前提條件之一。我們通常會(huì)這么跟程序員打交道：

1. 在提供方案前咨詢程序員需求可行性，程序員不一定深入調(diào)研、有空或好溝通；
2. 直接找案例的實(shí)現(xiàn)效果，實(shí)際情況、技術(shù)框架或系統(tǒng)不一定適用；
3. 憑直覺和經(jīng)驗(yàn)覺得可行，產(chǎn)品經(jīng)理更傾向于獨(dú)立思考，高效直接。

第3點(diǎn)最常見，后續(xù)也最容易引起挑戰(zhàn)，畢竟組織架構(gòu)或者跨部門工作流程，都會(huì)導(dǎo)致產(chǎn)品經(jīng)理經(jīng)測(cè)試孤軍作戰(zhàn)去推動(dòng)項(xiàng)目需求。

我曾在一個(gè)項(xiàng)目重構(gòu)上提出優(yōu)化ES搜索規(guī)則，但搜索結(jié)果的權(quán)重差如人意，程序員讓我接受現(xiàn)實(shí)：涉及全文檢索，列表顯示的結(jié)果無法完全精準(zhǔn)”，一時(shí)僵局，后來在CSDN找到類似案例，把解決方案的鏈接發(fā)過去，程序員解決思路就通了。

所以我們可以在梳理需求時(shí)，提煉可預(yù)測(cè)的技術(shù)難點(diǎn)，并且學(xué)會(huì)尋找可解決的方案備著：如果是小程序、微信、企業(yè)微信生態(tài)的產(chǎn)品，我們可以多逛逛微信開發(fā)社區(qū)，了解開發(fā)、運(yùn)營文檔更新的內(nèi)容，了解官方的開放規(guī)則。

如果是自主開發(fā)的系統(tǒng)，也可以逛逛CSDN、簡書，或者直接帶著問題去百度。切記是有場景才去找解決方案，而不是沉浸式理解學(xué)習(xí)，畢竟我們是奔著解決問題，而不是為了做一個(gè)懂技術(shù)的產(chǎn)品經(jīng)理。

二、嘗試去說明業(yè)務(wù)背景

• “你為什么這樣設(shè)計(jì)？”
• “你的需求出于什么目的？”
• “看不懂你寫的A和B是什么關(guān)系”

程序員這三連問是不是很熟悉？是不是常常問得讓人語塞，或者反復(fù)解釋邏輯，仍然存在“代溝”，很正常。

回憶我們的需求鏈前常常是有很多繁瑣的業(yè)務(wù)問題、業(yè)務(wù)流程，不少需求需要產(chǎn)品經(jīng)理經(jīng)過深入調(diào)研，梳理出一套具備可被標(biāo)準(zhǔn)化的系統(tǒng)架構(gòu)，如果不是像電商那類ToC的產(chǎn)品，在我們?nèi)粘Ｉ罹湍芾斫獾轿坏牟僮髁鞒蹋绦騿T更難通過一次評(píng)審、一份文檔或零碎溝通理解到位。

因此我們除了原型、需求文檔，還會(huì)配套輸出業(yè)務(wù)流程圖、產(chǎn)品流程圖，幫助他們了解業(yè)務(wù)背景，但仍不夠。

我們可以嘗試對(duì)程序員說明業(yè)務(wù)背景，通過這些方式：

1. 在梳理需求中的業(yè)務(wù)溝通會(huì)議帶上部分有意愿的程序員或負(fù)責(zé)人，讓整個(gè)項(xiàng)目團(tuán)隊(duì)都理解難，讓整個(gè)項(xiàng)目團(tuán)隊(duì)都參加也難，所以抽一部分擅長對(duì)外溝通的人員，讓他們?cè)诤罄m(xù)項(xiàng)目出現(xiàn)這類問題時(shí)，可以幫助產(chǎn)品經(jīng)理引導(dǎo)思路或梳理開發(fā)內(nèi)部的工作；
2. 講產(chǎn)品方案前，帶上業(yè)務(wù)同事代表或我們額外整理一些有關(guān)業(yè)務(wù)的示例如數(shù)據(jù)圖表或業(yè)務(wù)文檔，幫助程序員理解業(yè)務(wù)日常工作所面對(duì)的痛點(diǎn)、一些專業(yè)話術(shù)實(shí)際上與什么信息對(duì)標(biāo)。

當(dāng)然，我建議不直接和每個(gè)程序員或單個(gè)程序員對(duì)接挑戰(zhàn)，而是通過轉(zhuǎn)移矛盾的方式，將對(duì)象變成一個(gè)組或負(fù)責(zé)人，用其它層級(jí)的利益點(diǎn)去推動(dòng)這件事情，可能會(huì)事半功倍。

比如，我和某個(gè)后端程序員說不通，那我就叫上測(cè)試、前端或者他的組長一起來理解我為什么這樣考慮產(chǎn)品方案：“你們有什么更好的建議或者方案都可以拿出來一起探討”，讓項(xiàng)目組更多人理解背景，何嘗不是一件省心的事呢？

三、嘗試去跟進(jìn)項(xiàng)目

現(xiàn)在有不少公司將產(chǎn)品經(jīng)理的工作職責(zé)精細(xì)化，產(chǎn)品經(jīng)理只需要輸出需求文檔，項(xiàng)目管理或跟進(jìn)的工作則由項(xiàng)目經(jīng)理全權(quán)負(fù)責(zé)，我對(duì)這種模式的優(yōu)缺點(diǎn)保留意見。首先，我先拋出項(xiàng)目過程中所遇到的風(fēng)險(xiǎn)點(diǎn)都有哪些，不限于：

1. 功能模塊、項(xiàng)目排期進(jìn)度是否如期；
2. 需求理解、所呈現(xiàn)的效果是否到位；
3. 產(chǎn)品文檔是否有遺漏的地方，是否滿足開發(fā)要求。

以上任意一點(diǎn)，在程序員啟動(dòng)開發(fā)后，一旦項(xiàng)目反饋機(jī)制不夠健全，產(chǎn)品經(jīng)理都可能不知情，而錯(cuò)失在開發(fā)期間及時(shí)補(bǔ)充完善的機(jī)會(huì)，最終可能導(dǎo)致產(chǎn)品質(zhì)量有問題。

所以你還會(huì)認(rèn)為，我們產(chǎn)品經(jīng)理在評(píng)審到交付前就沒事情可做，讓項(xiàng)目經(jīng)理去跟進(jìn)就可以了嗎？那當(dāng)然不是了。

沒人抗拒產(chǎn)品經(jīng)理“不請(qǐng)自來”，我們可以厚著臉皮參加到程序員的站會(huì)中去，旁聽他們工作進(jìn)度，有什么技術(shù)難點(diǎn)、有什么模塊可能被遺漏、有什么風(fēng)險(xiǎn)點(diǎn)被一句帶過沒下文；

我喜歡觀察開發(fā)排期或者項(xiàng)目管理系統(tǒng)，在那里可以清晰看到開發(fā)對(duì)需求細(xì)分的模塊（是否有遺漏），每個(gè)需求點(diǎn)的估時(shí)（是否趕得上交付或安排在節(jié)假日前上線等風(fēng)險(xiǎn)）；也可以反哺自查產(chǎn)品經(jīng)理設(shè)計(jì)方案內(nèi)容：整體需求框架是否清晰易理解、層級(jí)流程是否合理、閉環(huán)異常狀態(tài)等等。

四、寫在最后

產(chǎn)品經(jīng)理跟程序員友好相處的技巧只有3個(gè)嗎？

我想遠(yuǎn)不止，但不難發(fā)現(xiàn)，技巧的核心都是1個(gè)方向，那就是“產(chǎn)品經(jīng)理多做一點(diǎn)”，世界也可以變得更美好：多做一點(diǎn)思考，跳出自己只是個(gè)產(chǎn)品設(shè)計(jì)者的框架，讓自己更全面更專業(yè)，相信程序員也會(huì)自主思考道：我該怎么跟產(chǎn)品經(jīng)理友好相處。

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

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