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