寫給產品經理:十條建議幫你與程序員建立天長地久的友情

7 評論 10111 瀏覽 34 收藏 16 分鐘

產品經理與程序員,一個是需求提出方,一個是需求受理方,由于工作內容的差異性以及有時的溝通不得當,極易出現矛盾,這些問題該如何避免呢?

產品經理從出生那一刻開始,似乎就決定了與程序員之間的敵對關系,一個是需求提出方,一個是需求受理方,伴隨著相愛相殺,產品經理與程序員之間的矛盾由來已久。

作為一個產品經理,每天打交道最多的就是程序員,不管是IOS程序員還是安卓程序員,不管是java程序員還是PHP程序員,在產品經理每天的工作過程中都會忙于提需求、解答問題、改需求、再解答問題。

坦誠講,剛開始入門產品經理的時候,對于這些程序員心理還是有點發(fā)怵的,因為他們一個個看上去都非常不好打交道。

這些成天對著電腦看著代碼的人,你都不知道他們到底在想些什么,甚至你都不知道哪一句話會得罪了他們。但是其實產品經理大可不必將自己放在程序員同學的對立面,因為究其本質還是人與人的相處,哪來那么多不可調和的矛盾。

那么,產品經理應該怎樣和程序員友好地合作呢?

一、提清楚需求,這是最重要的第一步

無論是什么樣的程序員,他都希望自己對接的產品經理能夠把需求提清楚,我每到一個公司的時候,都會先跟程序員同事確認他們喜歡什么樣風格的需求,得到的答復基本都是只需要把需求寫明白提清楚就可以了。

所以,產品經理一定要學會把需求提清楚。你可以嘗試畫高保真原型,把一些比較復雜的交互使用動態(tài)效果表現出來,這樣做的目的不是為了炫技,而是為了減少不必要的溝通,提高研發(fā)效率。要知道,很多時候,產品經理的需求多寫一句話,就有可能讓程序員少返工一次。

遇到不了解的邏輯怎么辦?大膽去問,不要怕程序員認為你不懂技術,也不用擔心問他們會丟面子,術業(yè)有專攻,你要做的是給出可以執(zhí)行的需求,如期完成研發(fā)工作發(fā)版上線,面子什么的不重要,都是自家哥們,何必糾結繁文縟節(jié)。

二、技術崇拜,能動手盡量不撕逼

大部分的程序員唯技術論,他們認可一個人的重要指標是這個人的技術能力如何,IT界有一句名言是“Talk is cheap ,show me the code”,大致的意思就是“會說不算什么本事,把你的代碼拿給我看看”。

記得當初在一家公司做產品負責人的時候,新來一個安卓程序員,入職第一天就過來跟我們說他來公司不是寫代碼而是管人的,結果第三天就辭職了,問了個比較熟的程序員哥們,告訴我說這家伙寫不出代碼,導致組員不服他的管理。所以產品經理們一定要注意一點,就是千萬不要炫技。

這一點在那些從程序員轉型做產品經理的人身上是最容易出現的問題,程序員轉型做產品經理的人有一個最大的優(yōu)勢在于,因為非常清楚代碼邏輯,所以在寫需求文檔的時候,可以很好的寫出讓程序員容易理解并執(zhí)行的需求。

但是,這往往也是最容易出現問題的一點,我見過不少程序員轉型的產品經理,會經常與研發(fā)部門的同事之間因為一個功能的代碼應該如何去寫而吵得不可開交,其實這是非常不明智的做法。

很多時候,程序員同學選擇如何去寫代碼,并不是受制于本身的技術水平,而是來源于系統(tǒng)架構、業(yè)務邏輯與其他系統(tǒng)模塊的耦合程度等因素的影響。

既然你選擇了產品經理這個崗位,那么就應該把專業(yè)的事情交給專業(yè)的人去做。你可以提建議,但是不要去教他們怎么寫代碼。

三、程序員說話直接,也希望你說話直接清楚

沉默寡言是大部分程序員給人的第一印象,但是其實這并不完全正確,很多時候你會發(fā)現程序員的沉默寡言只是對你如此,因為他們認為跟你沒有什么好說的。

你既不會寫代碼,也不懂數據庫,但是他們在同組之間的話題永遠不會少,而沉默寡言也會相應的導致程序員們說話會很直接。

如果當你發(fā)現一個程序員同學開始學會跟你講套路的時候,那么他極有可能已經升級為組長級別了。

大部分的程序員在說話的時候通常不會講太多廢話,因為他們與其浪費那么多時間來說話,倒不如多寫幾行代碼,所以能一句話說完的事情,盡量不要三句話。

在你想要跟程序員溝通一件事情的時候,請先把你想要說的話在腦子里過一遍,抓住重點,理清思路,實在不行,你可以拉住別的同事,跟他說一遍你的想法,看看他能不能快速理解你的意思。只有這樣,你才能不引起程序員的厭煩情緒。

四、程序員尊重他人,也希望得到你的尊重

現在越來越多的段子都是在全方位的嘲諷程序員,說什么“找男朋友要找程序員,錢多話少死的早”,什么“程序員沒有女朋友,男朋友到是有很多”這類的話。

作為產品經理,這樣的段子自己知道就好,不要不適時宜的去拿來跟你的同事們開玩笑。

要知道,你在天馬行空設計出好玩、酷炫的功能的時候,是程序員一行一行的寫出代碼實現的;公司盈利、上市,是程序員熬了無數個通宵創(chuàng)造出來的價值。

拿程序員來進行調侃,實在不是一件多有趣的事情,所以請尊重他們,能閉嘴的時候,盡量不要開口。

五、提出問題之前,請先稱贊程序員

很多人都知道,程序員最不喜歡聽到的一句話就是“你這個功能有BUG啊”,“你這個功能做得不對”,先不說到底是不是真的有BUG,當你說出這句話的時候,就意味著你完全無視了他們工作的過程,這會讓他們本能地產生抵抗的情緒。

雖然程序員不一定是玻璃心,但是人都是習慣于聽好話而不喜歡聽壞話。所以在你提出你的問題之前,先稱贊他們,你可以告訴他們,功能做得挺不錯的,但是好像還存在著一些問題。

所以,你也可以告訴他們,代碼寫得挺快的,但是結果好像跟預期的不一樣。你也可以直接讓他們來現場操作功能給你看,如果真有BUG,相信他們也一定會發(fā)現。

六、如果程序員想多了解業(yè)務,花點時間溝通

在我職業(yè)生涯里,一直是以懟天懟地懟空氣自居,曾經在一家公司撕遍全公司所有組長,卻在一次對話中,頭一次讓我覺得啞口無言。

當時是我在提交了版本需求給研發(fā)部們了以后,接著規(guī)劃下個版本的需求。按照慣例,接手我需求的程序員組長會把根據需求評審會上的內容,將版本功能進行拆分,然后分配到每個組員身上。

其中,PHP的組長在分配完工作以后,就其中的一個功能跟我進行了討論,大致對話如下:

程序員:這個功能的邏輯感覺有點不太對啊,這樣做沒問題么?

我:我在評審會上講清楚了,需求里也寫清楚了,你們就按照這個來做就好。

程序員:但是我沒見過有這樣的做法的,是因為什么原因要這樣設計功能呢?

我:因為公司業(yè)務要求這樣去做,所以你們就按照這個來做就好了。

程序員:那你能跟我講講是什么樣的業(yè)務要求么?

我:你很煩啊,你不要管業(yè)務要求是什么,你只要按照需求來寫代碼就好了。

程序員:你怎么這樣呢,我作為程序員,想了解多一點業(yè)務,只是怕到時候功能寫錯了,又要返工,到時候你也會挨罵。你作為產品經理,還不如我一個程序員對業(yè)務上心!

當時因為頻繁加班,而且拼命趕進度,我的狀態(tài)并不是很好,所以在跟這位程序員同學溝通的時候,難免有一些不耐煩,原話我不太記得了,但是我承認他在說那句話的時候,我瞬間感覺很難堪,他只不過是對項目負責,對系統(tǒng)負責,而我甚至都不愿意抽點時間來回答他的問題。

所以,自那一次開始,我對于任何一個程序員同事都會或多或少的講一講公司的業(yè)務模式、業(yè)務發(fā)展需要,即使是他們不一定能聽得進去,或者不一定能夠理解的了。但是我相信,會有很多程序員需要對業(yè)務有一定的了解。

七、不要只是告訴程序員做什么,還要告訴原因

提需求很簡單,但是講清楚故事就會很難,很多產品經理在提需求的時候,往往會忽略了一件事情,那就是應該要告訴他們?yōu)槭裁匆@么做。

特別是在提出臨時的緊急需求的時候,為了避免引起不必要的麻煩,你其實是可以好好跟他們溝通的。

你可以告訴他是因為老板臨時調整了思路,你已經為他們爭取最大程度降低工作量了,希望他們能抽出點時間幫你改一下需求;也可以告訴他們因為運營這個月打算沖一沖注冊量,這樣一來,這個月的新注冊用戶數可以破百萬,這是產品的非常重要的里程碑時間。

要知道,程序員也是這個團隊中的重要參與者,他們是有權力知道項目的所有事情的,雖然很多時候出于崗位職責不同,你往往忽略了這些東西,但是不代表你就可以完全不用告訴他們。

得到他們發(fā)起內心的認可,是為對你們的工作有很大的幫助的。

八、聊聊家常,不要刻意得去營造隔閡

見過很多的產品經理,好像生來跟程序員就有仇一樣,除了正常提需求、解答問題以外,甚至都不愿意跟他們多說一句話,更不用說聊天了。

要知道,程序員也是人,他們也會有喜怒哀樂,也會經歷悲歡離合。你們之間不應該只有工作上的交流,還應該有朋友之間的友情。

我可以清楚的知道研發(fā)部門大部分人的籍貫、家庭狀況、哪個學校畢業(yè)的、有沒有結婚、女兒還是兒子等等。

其實,很多時候你會發(fā)現,和他們相處,有的時候真的很簡單。不要老覺得程序員很沉悶,跟你之間不會有太多的話題可以聊,但是其實他們很多時候也會想要把自己的快樂分享給別人,也會想要找個人來傾訴自己的痛苦。把你們之間的隔閡去掉,拉近點距離。

九、學會承擔責任,不要老甩鍋

不知道從什么時候開始,教產品經理如何把鍋甩到程序員身上成了一種主流論調,居然還會有人寫出課程長篇大論的分析應該怎么去甩鍋,這是非??尚Φ南敕ā?/p>

作為一個產品經理,要先想著承擔責任,然后再想甩鍋,而不是先想著甩鍋,再去承擔責任。思想的先后順序不一樣,所造成的影響也是不一樣的。

前者是以甩鍋為己任,只有當遇到甩不出去的時候,才想著應該要由自己來承擔責任了;而后者是以承擔責任為目標,只有在必要的時候甩鍋給程序員,懲罰不是目的,而是為了避免下次出現同樣的問題。

十、你和程序員都該知道彼此的底線在哪

了解并堅守彼此的底線,是與程序員相處時候的關鍵,你可以告訴他們你可以允許研發(fā)進度延期,但是最多能延期多少天。

你也可以告訴他們允許出現BUG,但是在多久的時間內必須解決BUG并發(fā)版上線,你也可以嘗試去了解他們的底線,彼此保留一點神秘感,不是更好么?

只要你還在做產品經理的一天,你就要學會如何去跟程序員打交道,不要把他們想成是豺狼虎豹,也不要把他們視為洪水猛獸,以平常心來對待,你將會感受到不一樣。

結尾

當你了解程序員多一點,你離成為優(yōu)秀的產品經理更近一步,你會越來越清楚怎樣和程序員合作是最有效率的。

 

作者:夏老師,微信號公眾號:PM咖說(PMzone),10年互聯(lián)網產品實戰(zhàn)經驗

本文由 @夏老師 原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 第5條的方法其實根本沒做到正確的說問題,先夸獎再但是這種溝通結構,會把談話目標轉到是在照顧情緒而不是要解決問題,而且只要但是出現,一般人都會帶上情緒,當領導每次這么和你說的時候,你是不是更希望直接說但是。因為你知道前面的夸獎并不是這次談話的目的;“你這個功能有BUG啊”,“你這個功能做得不對”這種話的問題本質在于,是在評價而不是說問題!面對評價,問題就會被轉移到責任,利益,得失等等和問題本身無關的方面;其實看第6條舉的例子,也是程序,PM在互相評價,而沒有從事實入手,尋找解決方案!最終轉變成帶有攻擊性的指責。

    說問題要先做到不評價,講事實,然后講差異,商量解決問題的方法,這樣才能達成溝通的目的! 講事實描述現在這個邏輯是實現出來是什么樣的?講差異:我本來希望是這樣的,現在實現的情況確是這樣? 商量解決問題的方法:你覺得造成這樣的差異是什么原因?一起坐下來分析,找到解決方案。

    要夸獎,就要真心的在別人作對的時候立馬說出來,而且是針對行為的夸獎而不是對人的。比如:嗯,你看到需求不合理,立刻給予反饋,很贊! 千萬不要習慣性的加上“但是你要能控制下情緒就更好了!”這樣會讓夸獎的效果付諸東流。 可以停頓,看到對方領回到你的善意以后,再繼續(xù)說,你剛才給出反饋的時候看起來有些生氣,我當時也嚇了一跳!然后停頓等待對方做出反應。這樣,夸獎了對方,也點出了問題??洫労蛦栴}都有了意義。

    來自云南 回復
    1. 點贊,雖然寫的有點看不太明白,不過大體能搞懂。這篇文章的主要目的并不是針對每一個場景以及每一種情況去做分析,而是告訴產品經理一個核心的觀點就是要端正態(tài)度,與別人相處不僅僅只是工作上的交流這么簡單。當然你可以認為這篇文章對你沒有幫助,但是至少我?guī)У难邪l(fā)團隊我都是這樣去做,而且都沒有任何問題。關于第五條和第六條,我建議你多去與開發(fā)近距離接觸一下,你就知道我說的到底有沒有道理了

      來自廣東 回復
  2. 尊重對方很重要!

    回復
  3. 甩鍋這點真的很認同,有些鍋是不是自己的其實大家心里都有一面明鏡,承應下來了有時候開發(fā)童靴雖然不說,但是他們會更加高效的把問題改好。

    來自江西 回復
    1. 退一步海闊天空,其實提高的是你的情商,屬于你為人處事的能力了,加個微信交流吧。l5600201789

      來自北京 回復
    2. 好像搜不到你呢,方便的話可以加一下我Zampano_

      來自江西 回復
  4. 溝通真的是產品和程序員間最重要的部分啊,想請教一個問題如果開發(fā)故意拖延時間怎么辦,總是沒有按照公司的deadlin交付項目怎么辦呢。就像需求評審時研發(fā)給的時間節(jié)點都是研發(fā)們自己預估的。

    來自上海 回復