起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識以程序員的視角，給產(chǎn)品經(jīng)理們的一些溝通建議
導讀：一邊是需求提供方，一邊是需求實現(xiàn)方，產(chǎn)品經(jīng)理和程序員仿佛是「天敵」的關系。有溝通就會有問題，有問題就可能會有矛盾。由于工作方式、工作內(nèi)容、實際經(jīng)驗、個性等多種因素上都存在差異，每個產(chǎn)品經(jīng)理的職業(yè)生涯中都會遇到與程序員產(chǎn)生溝通上的問題。
一、產(chǎn)品經(jīng)理和程序員之間到底有什么溝通上的問題？
比如：有些產(chǎn)品經(jīng)理沒有產(chǎn)品的決策權，往往是需求的傳話筒，是個需求轉(zhuǎn)達者的角色，開發(fā)在質(zhì)疑需求的合理性時，產(chǎn)品經(jīng)理直接將鍋甩給了需求的來源者，用“這是某某確定要做的需求”這類話去回復開發(fā)，由于產(chǎn)品經(jīng)理沒有產(chǎn)品的決策權。這也會需求者的需求多次變更，導致開發(fā)硬著頭皮反復反工，甚至帶著情緒去編碼，這無疑會加深兩者的矛盾。
比如：有些產(chǎn)品經(jīng)理沒有將自己以為的常識性產(chǎn)品功能細節(jié)告訴開發(fā)，也沒有在產(chǎn)品原型中明確說明。開發(fā)以自己的經(jīng)驗去編碼，由于兩者對同一個功能的認知并不一致，導致開發(fā)出來的產(chǎn)品功能與產(chǎn)品經(jīng)理預期的并不一致，導致雙方互相扯皮。
再比如：產(chǎn)品經(jīng)理往往在開發(fā)階段和程序員去討論具體方案的實現(xiàn)細節(jié)問題，產(chǎn)品經(jīng)理自己覺得很基礎的功能或改動，在開發(fā)眼里往往就是系統(tǒng)的大改造。
……
產(chǎn)品經(jīng)理和程序員在溝通上的問題不勝枚舉，但核心沖突是“有限的開發(fā)資源”與“無限的產(chǎn)品需求”之間的矛盾。
要解決這個問題，要么提供更多的開發(fā)資源，也就是招更多更合格的工程師；要么就讓產(chǎn)品經(jīng)理對自己的行為做更多限制，讓產(chǎn)品決策和產(chǎn)品設計方案盡量符合市場和用戶需求，盡量合理。
但顯然這條路絕大部分企業(yè)并不行得通。對于開發(fā)者，提供更多的開發(fā)資源意味著企業(yè)要開發(fā)成本；對于產(chǎn)品經(jīng)理，對其行為的限制有太多不可控因素，一個決策的很可能是涉及多方、多種因素的結果；產(chǎn)品經(jīng)理的個人經(jīng)驗、認知水平、風格等因素也各不相同。
而且，顯然實際工作中，情況還要比這復雜的多。
二、站在程序員的角度，看產(chǎn)品經(jīng)理應如何和開發(fā)溝通
雙方的矛盾不可能消除，但站在程序員的角度，產(chǎn)品經(jīng)理如果能做到以下幾點，一定能夠減少和程序員之間的溝通問題甚至是矛盾。
（1）產(chǎn)品經(jīng)理要點到為止，不越俎代庖
產(chǎn)品經(jīng)理盡量不要與開發(fā)討論具體的實現(xiàn)方案上的細節(jié)問題，專業(yè)的事情交給專業(yè)的人去做，給與充分的信任。
一些技術出身的產(chǎn)品經(jīng)理經(jīng)常會與程序員討論需求的具體實現(xiàn)方式的問題，產(chǎn)品經(jīng)理認為自己的技術方案更適用，導致討論結果不歡而散。程序員對技術發(fā)展的認知，個人技術經(jīng)驗、技術專業(yè)程度等方面大概率比技術出身的產(chǎn)品經(jīng)理更專業(yè)。
要相信，每個程序員都是自己代碼的「產(chǎn)品經(jīng)理」。
（2）產(chǎn)品經(jīng)理要多了解技術基礎知識
對于一些非技術出身或沒有技術背景的產(chǎn)品經(jīng)理而言，由于對技術知識的缺乏，很可能陷入學習技術知識的細節(jié)中。產(chǎn)品經(jīng)理需要了解基礎知識，并不需要知道實現(xiàn)細節(jié)。產(chǎn)品經(jīng)理學習技術知識的目的是為了為更合理的設計產(chǎn)品服務，為更好的團隊溝通服務。
對于一些非技術出身或者需要學習技術的產(chǎn)品經(jīng)理，非常推薦唐韌的《產(chǎn)品經(jīng)理必懂的技術那點事兒》，這本書詳細介紹了產(chǎn)品經(jīng)理工作需要用到的技術知識，非常全面且簡單易懂。
（3）沒有程序員希望經(jīng)常被打擾
專注的時候工作效率一般是最高效的。在程序開發(fā)階段，產(chǎn)品經(jīng)理一定要盡可能少的打擾編碼中的程序員。除了一些緊急且重要的需求，需要及時與開發(fā)溝通。其他的需求產(chǎn)品經(jīng)理可以適當劃分優(yōu)先級后，跟開發(fā)約定時間后，集中時間去討論。
（4）多給程序員時間和空間
具體到細節(jié)，程序員與產(chǎn)品經(jīng)理的目標很可能是迥異的，甚至可能是相反的。如產(chǎn)品經(jīng)理要求先做一個功能，盡快上線，這一需求即使普通人也能理解。
但程序員考慮的不僅僅是需求本身，還要考慮上線后的維護、升級等，而這部分不懂技術的產(chǎn)品經(jīng)理是難以理解的，即使是懂技術的產(chǎn)品經(jīng)理，可能也會覺得實現(xiàn)起來是簡單的，其中的艱辛和沉重就只有程序員能夠體會了。
產(chǎn)品經(jīng)理要給程序員預留出合理的修整時間。一定不要把研發(fā)時間就當作完成時間。研發(fā)功能只是一部分，測試、改 BUG 以及處理意外情況的時間都要預留出來。
有兩種情況要多預留出修整的時間。
一種是研發(fā)團隊自己對功能沒有把握，可能是全新的功能，可能是比較難做的功能，可能出現(xiàn)許多 BUG 和功能實現(xiàn)糟糕的情況，那就要多預留出時間。
另一種是產(chǎn)品團隊表示對功能也有疑慮，比如在提供需求時表示這個功能很有可能要調(diào)整，或者對功能本身信心不足，那也要多留時間做調(diào)整。
（5）注意溝通的問題方式和方法
程序員喜歡按照既定的需求優(yōu)先級和產(chǎn)品方案有序的工作。產(chǎn)品經(jīng)理給到開發(fā)的需求一定要是合理劃分優(yōu)先級的，版本需求的提供與團隊的開發(fā)節(jié)奏盡量保持一致；遇到問題先分析、定位問題，而不是遇到問題先把問題直接退給開發(fā)，然后催著開發(fā)短期內(nèi)加急處理。
（6）產(chǎn)品需求變動及時告知，最好給與變更的背景說明
我見過太多的產(chǎn)品需求文檔更改之后沒有及時告知開發(fā)，導致測試驗收階段的需求與產(chǎn)品預期需求不一致的情況。產(chǎn)品經(jīng)理不要想當然的以為改動的需求開發(fā)一定會看，產(chǎn)品經(jīng)理的需求變動一定要及時告知相關開發(fā)相應的改動，有時候需求的變動可能就是簡單的一句話，及時的溝通可以避免后期的大改動和雙方推諉扯皮。
（7）對問題要有自己的判斷
產(chǎn)品經(jīng)理接收到的需求一定要有自己的清晰判斷，哪怕是很小的需求，到產(chǎn)品經(jīng)理這里必須經(jīng)過理性分析后，再安排開發(fā)進行處理。
以bug為例，很多時候一線或者客戶反饋的“bug”極有可能是對系統(tǒng)的不熟悉，對系統(tǒng)的配置性錯誤導致的問題，并非是系統(tǒng)bug。產(chǎn)品經(jīng)理作為需求處理的最后一道防線，提交給開發(fā)要做的一定是確定的事實，提交一個非bug需求給到開發(fā)去處理，不僅會浪費開發(fā)時間，還有質(zhì)疑產(chǎn)品經(jīng)理對業(yè)務的熟悉度和專業(yè)性。
產(chǎn)品方案提交給開發(fā)前，產(chǎn)品經(jīng)理至少應該明確的問題：
- 你提這個需求是要為誰解決什么問題？
- 這個問題是否客觀存在？
- （退一步講，如果客觀存在）你為什么覺得你的解決方案可以解決這個問題？
- 除此之外你想過其他解決方案嗎？你為什么覺得這個方案是最優(yōu)的？
如果你連這些基本問題都沒有想過或是想清楚，被動等著開發(fā)去問的時候才去思考，結果可想而知。
（8）溝通需求、需求文檔要盡量詳細明確
這個是產(chǎn)品經(jīng)理基本功，也是經(jīng)常容易被忽視的一點。
溝通需求一定要有目的，要具體，否則多半是浪費開發(fā)的時間；需求文檔一定要詳細并且明確無歧義，具體文檔詳細到什么程度，可根據(jù)每個團隊的風格、默契程度確定。如果沒法確定，那就說明的越細越好。開發(fā)在編碼的過程其實就是細節(jié)的實現(xiàn)過程，產(chǎn)品經(jīng)理在細節(jié)上深入思考后和程序員溝通會更加順暢。
（9）平等、尊重與理解
從歸屬部門來看，產(chǎn)品經(jīng)理一般屬于產(chǎn)品部，程序員屬于研發(fā)部，歸屬部門上不同，但都處同一個工作流上。
從工作流程來說，產(chǎn)品經(jīng)理處于需求的上游，程序員處于需求的下游，雙方對于用戶、需求、業(yè)務的理解程度有很大的不同，程序員在理解需求時有問題太正常不過，有問題時產(chǎn)品經(jīng)理應該及時給與耐心的回答。
尊重程序員的工作成果，涉及需求改動甚至需要砍掉的需求，盡可能跟開發(fā)說明白為什么。畢竟誰也不想自己費了很長時間、花了很大氣力做的東西，因為產(chǎn)品經(jīng)理一個未經(jīng)思考的決定改動。
要讓程序員從心理上認同做這件事的價值，程序員沒有理由拒絕一個合理的需求，如果需求能給用戶或者企業(yè)帶來價值，或是體驗上的提升，即使開發(fā)量很大或是難度很大，程序員也會激情滿滿。
有許多經(jīng)驗帖都談到產(chǎn)品經(jīng)理與程序員的矛盾癥結在于改需求，其實改需求只是表象，互聯(lián)網(wǎng)本來就是一個快速變化的行業(yè)，改需求不可避免，根源在于產(chǎn)品經(jīng)理是否有獨立思考的能力和意識。
改需求是人云亦云，是老板Push，還是實踐過后從觀察數(shù)據(jù)洞悉人性得來的深刻啟發(fā)，這里大不相同。
因此產(chǎn)品經(jīng)理除了要當團隊的連接器之外，還得鍛煉自己成為團隊的大腦，只有你把需求想踏實了，想細致了，想全面了，才有足夠的底氣去應對各方各面的挑戰(zhàn)，在程序員面前更具信服力。
我自認為優(yōu)秀的產(chǎn)品經(jīng)理都是相對清閑的，因為前期的需求文檔和原型圖都寫得非常細致了，預知研發(fā)人員會問什么問題，都在原型圖上醒目的標識，讓研發(fā)人員很少甚至是無需過問產(chǎn)品經(jīng)理，從此產(chǎn)品經(jīng)理可以在于研發(fā)的糾纏中解放出來，真正去想長遠的規(guī)劃。
產(chǎn)品經(jīng)理最主要的能力之一就是共情能力，遇到溝通問題或是矛盾、沖突時，站在程序員的角度思考下自身可能存在的問題，相信你會和程序員的溝通會更加順暢。
本文由 @PM肖邦 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議。
學到了
確實，覺得產(chǎn)品經(jīng)理如果是學過相關技術的知識，可以更高效的溝通
從JAVA轉(zhuǎn)的產(chǎn)品崗
作為一個小白還沒有遇到過特別難溝通的開發(fā)
我一直把程序員分成三種：
第一種是：老老實實打工，產(chǎn)品經(jīng)理叫我做什么我就做什么，我按照需求文檔做，我按照領導的要求完成任務，我沒有過多的想法，我只是需求的執(zhí)行者。這種一般是經(jīng)驗在0-2年的程序員居多。
第二種是：我覺得我不應該老老實實做需求執(zhí)行者，我還需要給產(chǎn)品提我自己的想法，我也是團隊的一份子，我該為團隊獻計獻策，甚至有時候我還要提出一些合理的改進意見。這種程序員的經(jīng)驗和項目經(jīng)歷一般很豐富，要不就是自身學習能力強，有責任心。
還有一種就是：對需求改動或者是遇到?jīng)]有做過的功能本能的抗拒態(tài)度，不想學習也不愿學習，往大了說，甚至是沒有責任心的佛系程序員。當然，這種程序員很少。
我也是產(chǎn)品經(jīng)理，非常感同身受，一般有些需求提過去，如果研發(fā)說做不到，我都會問無法實現(xiàn)的具體原因，然后再幫著一起想辦法，看看能不能找到折中的方案。但在公司里，確實也有些研發(fā)就不愿意動腦筋，內(nèi)心對要做的需求沒有信心，或者感覺做起來很麻煩，本著多一事不如少一事的心態(tài)來拒絕，這種研發(fā)有時候也是拿他沒辦法。
我一直把程序員分成三種：
第一種是：老老實實打工，產(chǎn)品經(jīng)理叫我做什么我就做什么，我按照需求文檔做，我按照領導的要求完成任務，我沒有過多的想法，我只是需求的執(zhí)行者。這種一般是經(jīng)驗在0-2年的程序員居多。
第二種是：我覺得我不應該老老實實做需求執(zhí)行者，我還需要給產(chǎn)品提我自己的想法，我也是團隊的一份子，我該為團隊獻計獻策，甚至有時候我還要提出一些合理的改進意見。這種程序員的經(jīng)驗和項目經(jīng)歷一般很豐富，要不就是自身學習能力強，有責任心。
還有一種就是：對需求改動或者是遇到?jīng)]有做過的功能本能的抗拒態(tài)度，不想學習也不愿學習，往大了說，甚至是沒有責任心的佛系程序員。當然，這種程序員很少。
對產(chǎn)品狗的9點控訴（手動狗頭）
也可以理解為：對產(chǎn)品狗的9點提升建議~
寫的很在理，也非常有針對性~
研發(fā)各端該怎么與產(chǎn)品溝通也寫一寫唄？
怎么體現(xiàn)研發(fā)團隊接受需求的有效性，不同語言在對需求實現(xiàn)的過程中需要如何響應、如何交付高質(zhì)量代碼~
另外測試從需求評審到用例產(chǎn)出以及對最終結果的保障~
期待看到不同角度的內(nèi)容，產(chǎn)品經(jīng)理是團隊的連接器，但同為工作流上的伙伴，”上”善至”下”之余，也望”下”善承”上”~
評論都是說產(chǎn)品經(jīng)理，雖然但是，其實程序員也有問題。最好的辦法就是兩者相互溝通，程序員了解產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理了解程序員，補一些對應的基礎知識，都不會有這么大的矛盾。
咱就是說，產(chǎn)品經(jīng)里需要一些編程思維和編程能力，這樣也不至于答應太過離譜的需求，
大部分產(chǎn)品經(jīng)理都是：這個簡單，好說好說；
而程序員：這么難的需求你也會答應？我寫不出來，有本事你自己上。
這個需求很簡單？怎么實現(xiàn)我不管？明天馬上上線？…
其實如果是小公司，就是程序員根本不愿意動腦去做新東西，你不找技術文檔給他找好，他就不做，幸好我自己會做。
寫的太好了 都是干貨 句句在理
都是實際工作中和開發(fā)溝通的總結。要相信，每個程序員都是自己代碼的「產(chǎn)品經(jīng)理」。