產品經理如何與程序員溝通？

12-31

眾所周知的是，除了專業性技能之外，大部分對產品經理的要求都會強調溝通協調能力、項目統籌與把控能力、邏輯思維能力等。

尤其是溝通協調的能力，產品經理一向被要求具備強勢的態度和積極的溝通技巧。

尤其是面對思路不夠開闊，且保守有餘，進去不足，甚至排斥打磨產品的程序員時，做為產品經理，你是如何去溝通的？

是委曲求全？是選擇中和？還是強勢出擊？又或者什麼其他的好方法？

產品經理和項目經理如果是對等關係，那麼對於產品整體的把握誰的權威更大一些呢？

尊重程序員，就像尊重自己一樣

儘可能用程序員的思維來整理邏輯

時刻記得，沒有程序員就沒有互聯網

其實PM和dev的衝突多半跟PM和dev的溝通是無關的，最重要的是政策問題。

到了項目後期的時候，如果老闆同意說，如果PM加需求，要麼就砍掉一個差不多規模的舊的，要麼就延長期限，我覺得肯定不會打起來。

首先，作為一個pm，對於需求要有決斷力，不要一天一個想法。

其次，如果因為需求更改導致dev加班，你最好全程陪同，隨時提供有效的input。

作為一個dev最恨的是如下場景

Pm：這個按鈕改成方的，這裡加一個確認頁，blah,blah…我要趕著回家和女友啪啪啪，你們這群屌絲dev留下加班吧，明天早上我來看結果。

Dev：…

（第二天）

Pm：方按鈕太丑還是改回圓的吧

Dev：…我去年買了個表

不是產品經理，且不是經理。但可以從管理的一個側面（員工）看待你這個問題。

產品經理或者項目經理經常會被要求強勢和更好溝通技巧。但強勢的的態度經常轉化為專制和蠻橫。所以項目經理難於「做人」，不得人心。尤其是程序員出身的產品經理。原因我認為可能是部分優秀的程序員慢慢升職成為產品經理，由於他們本身是優秀的程序員，對代碼質量要求高，所以被能力一般的程序員看成吹毛求疵也不奇怪。員工總會升職到一個無法勝任的崗位，這個是彼得定律的一種吧。又或者不是程序員出身的產品經理，卻也無法搞定能力較強的程序員。提問者可能屬於第一種類型。

溝通協調也是很大的問題。由於產品經理需要全方位的考慮所有問題：客戶、兄弟單位、還有手下程序員。在產品經理身邊，程序員是眾多人里最弱的一個單位（必須地，欺負手下的是最容易的），當各個單位產生矛盾的時候，他們的利益是首先被損害的。所以，恰當的從程序員的角度上考慮比成功產品經理必修課。把握好這一點，和程序員溝通幾乎已經成功了一半。

優秀的程序員是每個PM的希望。就像每個老師都希望有好學生，但重要的是因材施教。所以，因地制宜的分配工作才是必要的。能有少量的優秀程序員就夠用了，手下都是big one也不一定拿到總冠軍啊。

即是溝通，一定要明確彼此需要什麼。高效的會議或會談的前提是，雙方一定有了明確的目的或需求，然後在逐漸達成共識。整體來說，溝通過程分為以下5個階段。

1. 明確你的產品需求和意圖，設計出清晰明確的業務流程和產品原型；

2. 表述你的成果，與程序員反覆探討業務流程，在設計流程時有疑問之處此時可進行交流；

3. 明確業務流程，並讓程序員用自己的理解敘述，直到符合自己或雙方達成共識的結果；

4. 向程序員展示原型交互，如果此時原有業務流程已有改變，則展示關鍵點；

5. 如果一切順利，則在最後明確產品成果，交由技術人員實現；如果存在（較多的）調整，則回到頂部重新再走。

關鍵點：

1. 完整的準備工作；

2. 放平心態，接受自己不是「全能神」的現實；

3. 真誠溝通，虛心傾聽；

4. 快速反饋。

微笑、虔誠、謙虛

多站在技術的角度考慮問題，考慮情緒成本，即情緒因素給整個項目或者產品所帶來的影響

非工作時間，可以多和技術閑聊，曾進友好度，把技術當初自己的朋友

不要把自己位置擺的太高，要知道我們的目的只有一個，做好產品

其實，在工作中一般是不會出現溝通問題的，一般出現溝通問題，大多數是因為產品經理的不合理要、新增需求、頻繁改動所導致的，這時候，我們應該不斷的完善自己，同時要有虛心與正確的態度。

一個好的PM需要一群優秀的程序員，一群優秀的程序員，也同時需要一個更加優秀的PM。

汪！汪汪汪

喵。。。這裡有個bug。。。喵。。。

在跟開發人員溝通的過程中，產品人員要做的工作主要有三點：第一是跟開發人員講解產品需求；第二是怎麼去說服開發人員信服產品人員的想法；第三點就是跟進開
發，避免開發出來的產品與預期不符。我從來都不覺得第一點有難度，難點在於第二點和第三點。在原型設計完後，產品都會組織開發人員一起開會做產品的講解，
這時候總是會面臨的一個問題就是如何說服開發的同事。因為每個人都是有思想的，看到產品規劃後，開發人員也總是會提出一些自己的看法，所以產品需要去說服
技術，在跟開發講解產品的時候也要適當的畫餅，描繪一下產品上線成功後的美好未來，這樣會帶動起開發人員的積極性。個人在工作中總結了一點，就是平時可以
跟開發員多聊聊天，增進了解，多觀察開發人員經常上的哪些網站。在溝通說服他們的過程中，可以拿他們經常上的網站舉例，這樣的話他們本身對那個產品更熟
悉，自然也更好理解。至於說到第三點，項目跟進，這需要產品人員極大的責任心和積極性。一個項目立項後，公司通常會把參與人員列為一個小組。產品需求文檔
是開發人員開發的依據，但即便文檔再詳細，在開發過程中也難免需要當面溝通。產品人員需要根據開發排期跟進開發進展，驗收產品功能是否與產品期望一致。這
個過程產品人員的工作往往會比較繁瑣，也會比較忙，同時也會極大鍛煉產品人員的溝通能力。

當提交一個產品無論是給設計還是開發部門制定排期，你會發現他們都會把時間定的很充足。也許你會因此對其他同事有看法，但其實在工作中都是這樣子，每個人
都不會為自己的時間安排的太緊張，而且大家要考慮過程中可能會出現的風險因素，例如請假的情況。當然也並不是讓開發人員越快越好，所以最好是產品人員根據
上線時間與開發人員定一個時間結點，讓開發人員在該時間前完成即可。

跟程序說話如果他不回你的話，基本上你說的是：

1.這個請問什麼時候能弄完

2.這個搞定了告訴我

3.能不能快點

如果他給你正面反饋，基本上你說的是：

1.帥哥，我這個需求你看看寫的有沒有什麼問題

2.哥們，這個東西比較緊急，百人大會決議通過，你看看啥時候弄完

3.大哥，這個月銷售額就靠你這個功能了

以德服人，

以理悅人，

畢竟程序員是最終執行者，

最終的產品是否能滿足用戶需求，

還得看產品經理前期做的功課和本身的功力+溝通能力，

優秀的產品經理應該是讓程序員膜拜和敬仰的

如果程序員不喜歡你或者討厭跟你在一起合作，那麼你應該轉行或者你還不算一個真正的產品經理。

DevStore辦公室小故事

程序員甲：怎麼給我臃腫不堪的代碼找個理由呢？

程序員乙：你就說產品經理是2B就行了~

小美：嗚嗚...

小胖：無論你們以什麼理由發動戰爭，表打我就行。

老徐：小胖，趕緊去安慰小美，小美又哭了。

小胖：又不是我惹哭的，幹嘛要我過去挨打......

小編：程序員離不開產品，產品離不開程序員，你們是唇齒相依的關係，一定要好好相處哦~（終於輪到小編作總結了，以前程序與產品鬧矛盾都是CEO出面調解，想到這兒，還有點小激動~）

（本劇純屬虛構，如有雷同，純屬巧合）

跪著……

參考的一篇文章模板，結合自己的經歷，簡單寫了如下一些觀點。

因為我是學習計算機專業的，可以體會到當自己熬夜加班做項目，最後產品上線後的那種喜悅。由於大部分研發人員溝通交流比較少，不像PM、BD那樣有過多業務上的往來，他們的作品乃至體現個人價值的東西就是最終的研發成果。所以，他們需要認同與尊重。個人在與開發同學相處的幾點心得：

第一、用戶反饋的緊急需求

這通常是最常見也是最緊迫的需求。比如之前我們做的一個活動功能，在上線的那天，有用戶反饋Bug：「如果不同意授權地理位置信息功能，活動頁面將無法進入」。當時開發同學剛開發好新功能，整個狀態是比較消極比較忙的，但是我會強調這是用戶反饋的Bug，如果不修復好的話，初次推出的口碑效應很快就會散播開來，對於後續活動推廣都會有很大影響！其實也可以站在開發的立場上，和他們一起抱怨用戶，當然前提是為了修復產品Bug。

第二、認真闡述需求方案的重要性

產品新功能的方案，必須要得到開發人員的一致認可。其實挺困難的，產品人員花了好多精力設計的方案，大部分開發同學總是意識性的提出反對意見。這時，我們必須要和他認真闡述需求方案的設計初衷，「為什麼需要這個功能？如果沒有了這個功能又會怎麼樣？」儘力說服他，如果他提出的可行建議，我們也要虛心接受。

第三、討論是否有可變通的方案

如果產品方案遭到了開發人員的強烈抵制，比如：「這個功能我根本做不了！」「這個功能沒有意義」。碰到此類話語，很可能是開發同學出於情感發言，而不是真正能力受限。這時，我們可以討論下是否有折中的方案可以實現這個需求？是否其他的開發同學可以開發出這個功能呢？

第三、多思考需求問題再討論

對於用戶反饋的問題產品問題，最忌諱產品人員什麼都不看，直接轉給開發。無論是對於問題解決還是個人能力素質提升都是非常不利的。產品人員最需要做的，應該是多思考這個問題的產生的來源？下次還會不會再出現？修復成什麼樣比較好？對以後有什麼樣的幫助？然後和開發人員多討論，共同解決好問題，這樣也可快速拉近與開發人員的距離，更好進入狀態。

第四、採用請教式的交流方式

主要是找到切入點，吸引開發人員的興趣，抓住開發人員「好為人師」的特點。比如產品人員想設計一個Material Design風格的H5宣傳頁，在設計前後，可以多和前端同學討論Material Design的設計常識，注意要點等。這樣一個自己也順帶複習了Material Design的專業知識，也利於後期產品功能的開發推進工作！

第五、留有餘地但一定要有時間點

做事情一定要留有餘地，很多時候要站在對方角度上思考問題。不同公司的開發人員配置也會有差異，比如有些公司是一條產品線或一個產品組配備若干開發人員，而有些公司可能是幾個產品組共享開發資源，就是說開發資源是共用的。這裡就會涉及到一個優先順序的問題，如果你去找開發人員解決問題時，恰逢他手裡有比較重要的事情，假使你的問題不是非常著急，這時需要有一定的同理心，但是一定要確定個時間點，什麼時候再來，最好別忘了再問一句，他是否需要你幫忙等。

第六、通過上級領導與開發同學溝通

這是最後的溝通方案，一般不推薦。只有碰到非常重要的需求，而且溝通進入僵局時才推薦使用。產品新人往往氣場弱、資歷淺，技術人員難免會「輕視」。比如溝通的時候強調，「這個功能對於公司的發展戰略非常重要？」"我們經理說這個需求方案必須落地"，先傳遞類似的信息，最後實在不行了，再找自己的Leader過來一起溝通。

第、加深感情與開發同學的感情

日常工作中，可以有意識和開發同學多溝通交流。比如下班後，可以和開發人員一起打籃球，玩遊戲等，或者周末聚聚餐，一起遊玩都是非常不錯的聚集方式。上班時，相互可以幫忙的也盡量伸出援助之手。當然，溝通不僅局限在與開發人員，與運營、BD，甚至整個公司的其他人員也應該這樣，這對於個人成長也是非常有幫助的。

其實，實際工作中，很多開發人員還是比較好溝通的。他們大都比較簡單，只要多從他們的角度出發，尊敬對方，遇到問題找他們都能儘快解決。總之在具體的產品工作中，不可避免地會與開發人員產生一些溝通上的分歧。作為一個產品人，必須根據實際情況，做好需求與溝通工作，這是產品人素質要求核心之一。只有這樣，才能把產品工作做的更好！

與攻城獅的溝通日常

背景：攻城獅大大，覺得開發狀態回傳介面太麻煩，就讓底層和系統頁面實時回傳響應狀態。底層反饋響應成功之前，系統頁面不能關閉，否則底層與系統頁面斷開，任務提交失敗。

問題：響應時間過長，需要用戶彈窗內容提交後，等1分鐘左右。這1分鐘內，頁面不能關，不能動，否則任務提交失敗。

產品汪 : 用戶不可能有耐心等1分鐘，很可能會認為系統出錯，直接關閉頁面。

攻城獅 : 就讓用戶等1分鐘怎麼了，1分鐘還等不了了，想用我系統就得等1分鐘。

產品汪（內心戲）：

知道你們看戲的以為戰事一觸即發，不過……

面對傲嬌滴攻城獅大大，臉皮千錘百鍊的產品汪，是絕對不會發脾氣滴，也是絕對不會拖鞋（妥協）滴。

開玩笑，做好系統交互，保證用戶體驗，是產品汪的天職啊天職。

讓我們來面對疾風吧，勇士！

產品汪祭出大殺器

（下面這段話請腦補武林外傳里大家辯論時的語速）


產品是給甲方的，如果甲方著急產品上線，並不在意這些細節，那我們就讓用戶等1分鐘。

如果甲方不著急產品上線，更在意用戶體驗，那我們就底層開發介面，解決這個問題。
那麼問題來了，需要甲方做判斷，是犧牲用戶體驗，按時上線；還是保障用戶體驗，延期上線。
甲方做判斷，是衡量 工期延長時間造成的影響不好，還是用戶體驗差造成的影響不好。
所以，現在我們要做的，就是 攻城獅 您這邊給出解決此問題所需開發時間，我產品汪要做的就是跟客戶溝通，看客戶接受哪個方案。

所以，攻城獅大大，你工期評估時間什麼時候能給我？

攻城獅：下班前給你。

產品汪：

產品經理跟程序之間的關係呢，打個不好的比方，程序好比是外科醫生，正在給病人開刀，這個病人是誰，你懂的。所以不要在自己被開膛破肚的情況下對醫生喊：老子是消費者，你敢開壞了老子搞死你。畢竟人家隨便就能給你一個心臟流血級別的攻擊。產品經理跟程序溝通的時候不用特別矯情，但是需要技巧。「醫生，我知道這個刀難開，我也知道開得不好有什麼後果，但是不開不行，請務必儘力。」一般來說這個醫生都是有醫德的，但是遇到的就是個痞子那就跟項目經理聯繫換人，這種人就算低聲下氣也沒什麼好結果。再有就是平時對程序施點小恩惠，非常受用。

至於產品經理跟項目經理之間的話，反正明確項目經理的使命跟底線就是項目可以按計劃完成。誰話語權大這個問題是根據情況來的，如果團隊岌岌可危，那就先照顧項目經理，老老實實二萬五千里長征去，如果團隊有能力跟敵人正面肛，那就產品經理髮揮，去大會戰去。不過這兩個崗位之間關係微妙，只能自己體會。

最後糾正一點，不懂程序就是不懂，不可能理解程序，就像不能理解醫生一樣，假裝了解會令人反感，所以遇事討論事就行了，別耍小聰明，很智障的行為，還要程序配合一起演戲，逗猴子的感覺，很不爽。（最無法理解的是竟然有人真的以為這種行為獲得了程序的青睞，大家都是裝瘋賣傻，沒想到你是真傻，世界觀都改變了。）