導讀：一邊是需求提供方，一邊是需求實現方，產品經理和程序員仿佛是「天敵」的關系。有溝通就會有問題，有問題就可能會有矛盾。由于工作方式、工作內容、實際經驗、個性等多種因素上都存在差異，每個產品經理的職業生涯中都會遇到與程序員產生溝通上的問題。

一、產品經理和程序員之間到底有什么溝通上的問題？

比如：有些產品經理沒有產品的決策權，往往是需求的傳話筒，是個需求轉達者的角色，開發在質疑需求的合理性時，產品經理直接將鍋甩給了需求的來源者，用“這是某某確定要做的需求”這類話去回復開發，由于產品經理沒有產品的決策權。這也會需求者的需求多次變更，導致開發硬著頭皮反復反工，甚至帶著情緒去編碼，這無疑會加深兩者的矛盾。

比如：有些產品經理沒有將自己以為的常識性產品功能細節告訴開發，也沒有在產品原型中明確說明。開發以自己的經驗去編碼，由于兩者對同一個功能的認知并不一致，導致開發出來的產品功能與產品經理預期的并不一致，導致雙方互相扯皮。

再比如：產品經理往往在開發階段和程序員去討論具體方案的實現細節問題，產品經理自己覺得很基礎的功能或改動，在開發眼里往往就是系統的大改造。

……

產品經理和程序員在溝通上的問題不勝枚舉，但核心沖突是“有限的開發資源”與“無限的產品需求”之間的矛盾。

要解決這個問題，要么提供更多的開發資源，也就是招更多更合格的工程師；要么就讓產品經理對自己的行為做更多限制，讓產品決策和產品設計方案盡量符合市場和用戶需求，盡量合理。

但顯然這條路絕大部分企業并不行得通。對于開發者，提供更多的開發資源意味著企業要開發成本；對于產品經理，對其行為的限制有太多不可控因素，一個決策的很可能是涉及多方、多種因素的結果；產品經理的個人經驗、認知水平、風格等因素也各不相同。

而且，顯然實際工作中，情況還要比這復雜的多。

二、站在程序員的角度，看產品經理應如何和開發溝通

雙方的矛盾不可能消除，但站在程序員的角度，產品經理如果能做到以下幾點，一定能夠減少和程序員之間的溝通問題甚至是矛盾。

（1）產品經理要點到為止，不越俎代庖

產品經理盡量不要與開發討論具體的實現方案上的細節問題，專業的事情交給專業的人去做，給與充分的信任。

一些技術出身的產品經理經常會與程序員討論需求的具體實現方式的問題，產品經理認為自己的技術方案更適用，導致討論結果不歡而散。程序員對技術發展的認知，個人技術經驗、技術專業程度等方面大概率比技術出身的產品經理更專業。

要相信，每個程序員都是自己代碼的「產品經理」。

（2）產品經理要多了解技術基礎知識

對于一些非技術出身或沒有技術背景的產品經理而言，由于對技術知識的缺乏，很可能陷入學習技術知識的細節中。產品經理需要了解基礎知識，并不需要知道實現細節。產品經理學習技術知識的目的是為了為更合理的設計產品服務，為更好的團隊溝通服務。

對于一些非技術出身或者需要學習技術的產品經理，非常推薦唐韌的《產品經理必懂的技術那點事兒》，這本書詳細介紹了產品經理工作需要用到的技術知識，非常全面且簡單易懂。

（3）沒有程序員希望經常被打擾

專注的時候工作效率一般是最高效的。在程序開發階段，產品經理一定要盡可能少的打擾編碼中的程序員。除了一些緊急且重要的需求，需要及時與開發溝通。其他的需求產品經理可以適當劃分優先級后，跟開發約定時間后，集中時間去討論。

（4）多給程序員時間和空間

具體到細節，程序員與產品經理的目標很可能是迥異的，甚至可能是相反的。如產品經理要求先做一個功能，盡快上線，這一需求即使普通人也能理解。

但程序員考慮的不僅僅是需求本身，還要考慮上線后的維護、升級等，而這部分不懂技術的產品經理是難以理解的，即使是懂技術的產品經理，可能也會覺得實現起來是簡單的，其中的艱辛和沉重就只有程序員能夠體會了。

產品經理要給程序員預留出合理的修整時間。一定不要把研發時間就當作完成時間。研發功能只是一部分，測試、改 BUG 以及處理意外情況的時間都要預留出來。

有兩種情況要多預留出修整的時間。

一種是研發團隊自己對功能沒有把握，可能是全新的功能，可能是比較難做的功能，可能出現許多 BUG 和功能實現糟糕的情況，那就要多預留出時間。

另一種是產品團隊表示對功能也有疑慮，比如在提供需求時表示這個功能很有可能要調整，或者對功能本身信心不足，那也要多留時間做調整。

（5）注意溝通的問題方式和方法

程序員喜歡按照既定的需求優先級和產品方案有序的工作。產品經理給到開發的需求一定要是合理劃分優先級的，版本需求的提供與團隊的開發節奏盡量保持一致；遇到問題先分析、定位問題，而不是遇到問題先把問題直接退給開發，然后催著開發短期內加急處理。

（6）產品需求變動及時告知，最好給與變更的背景說明

我見過太多的產品需求文檔更改之后沒有及時告知開發，導致測試驗收階段的需求與產品預期需求不一致的情況。產品經理不要想當然的以為改動的需求開發一定會看，產品經理的需求變動一定要及時告知相關開發相應的改動，有時候需求的變動可能就是簡單的一句話，及時的溝通可以避免后期的大改動和雙方推諉扯皮。

（7）對問題要有自己的判斷

產品經理接收到的需求一定要有自己的清晰判斷，哪怕是很小的需求，到產品經理這里必須經過理性分析后，再安排開發進行處理。

以bug為例，很多時候一線或者客戶反饋的“bug”極有可能是對系統的不熟悉，對系統的配置性錯誤導致的問題，并非是系統bug。產品經理作為需求處理的最后一道防線，提交給開發要做的一定是確定的事實，提交一個非bug需求給到開發去處理，不僅會浪費開發時間，還有質疑產品經理對業務的熟悉度和專業性。

產品方案提交給開發前，產品經理至少應該明確的問題：

1. 你提這個需求是要為誰解決什么問題？
2. 這個問題是否客觀存在？
3. （退一步講，如果客觀存在）你為什么覺得你的解決方案可以解決這個問題？
4. 除此之外你想過其他解決方案嗎？你為什么覺得這個方案是最優的？

如果你連這些基本問題都沒有想過或是想清楚，被動等著開發去問的時候才去思考，結果可想而知。

（8）溝通需求、需求文檔要盡量詳細明確

這個是產品經理基本功，也是經常容易被忽視的一點。

溝通需求一定要有目的，要具體，否則多半是浪費開發的時間；需求文檔一定要詳細并且明確無歧義，具體文檔詳細到什么程度，可根據每個團隊的風格、默契程度確定。如果沒法確定，那就說明的越細越好。開發在編碼的過程其實就是細節的實現過程，產品經理在細節上深入思考后和程序員溝通會更加順暢。

（9）平等、尊重與理解

從歸屬部門來看，產品經理一般屬于產品部，程序員屬于研發部，歸屬部門上不同，但都處同一個工作流上。

從工作流程來說，產品經理處于需求的上游，程序員處于需求的下游，雙方對于用戶、需求、業務的理解程度有很大的不同，程序員在理解需求時有問題太正常不過，有問題時產品經理應該及時給與耐心的回答。

尊重程序員的工作成果，涉及需求改動甚至需要砍掉的需求，盡可能跟開發說明白為什么。畢竟誰也不想自己費了很長時間、花了很大氣力做的東西，因為產品經理一個未經思考的決定改動。

要讓程序員從心理上認同做這件事的價值，程序員沒有理由拒絕一個合理的需求，如果需求能給用戶或者企業帶來價值，或是體驗上的提升，即使開發量很大或是難度很大，程序員也會激情滿滿。

有許多經驗帖都談到產品經理與程序員的矛盾癥結在于改需求，其實改需求只是表象，互聯網本來就是一個快速變化的行業，改需求不可避免，根源在于產品經理是否有獨立思考的能力和意識。

改需求是人云亦云，是老板Push，還是實踐過后從觀察數據洞悉人性得來的深刻啟發，這里大不相同。

因此產品經理除了要當團隊的連接器之外，還得鍛煉自己成為團隊的大腦，只有你把需求想踏實了，想細致了，想全面了，才有足夠的底氣去應對各方各面的挑戰，在程序員面前更具信服力。

我自認為優秀的產品經理都是相對清閑的，因為前期的需求文檔和原型圖都寫得非常細致了，預知研發人員會問什么問題，都在原型圖上醒目的標識，讓研發人員很少甚至是無需過問產品經理，從此產品經理可以在于研發的糾纏中解放出來，真正去想長遠的規劃。

產品經理最主要的能力之一就是共情能力，遇到溝通問題或是矛盾、沖突時，站在程序員的角度思考下自身可能存在的問題，相信你會和程序員的溝通會更加順暢。

?

本文由 @PM肖邦 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。