產品經理應該如何與程序員打交道?
產品經理與程序員之間的矛盾沖突,并不特殊,它是一個系統性問題。那么,產品經理應該如何與程序員打交道?
01
與程序員打交道,是產品經理的日常工作之一。從網上流傳的各種產品與技術起沖突的段子可以看出,產品經理與程序員之間的關系,總的來說,并不十分融洽。
我相信,有相當多的同行朋友,都為之苦惱過,我也不例外。
這幾年下來,被程序員懟得多了,漸漸地也就變得波瀾不驚了。雖然技術對產品有諸多不滿,產品也對技術有各種意見,但是,這里我并不想去大書特書雙方的矛盾。
在討論“如何與程序員打交道”之前,我想先對這種矛盾定個調。
我認為,產品經理與程序員之間的矛盾沖突,并不特殊。
如果關注設計師圈子,你會發現,甲方與設計師之間,也有類似的“恩怨情仇”。其實,在任何協作網絡中,處于對接工作的上游和下游之間,普遍存在類似的矛盾沖突。
它是一個系統性問題,簡單地將之歸因為某些人的某些錯誤,是一種思想上的懶惰。
從某種程度上講,我們無需過度關注與程序員的矛盾,等閑視之,做好自己的工作即可。
02
產品經理的工作是圍繞著“需求”進行的。
在與技術部門進行對接時,產品經理需要關注的,始終是“需求”。
產品新人很容易在這上面犯錯。因為外界夸大了產品與技術之間的矛盾,導致產品新人會不自覺地把自己工作的重心,放在“不惹程序員生氣”上面。
在與程序員打交道的過程中,為了避免被懟,過度關注程序員的情緒,想方設法地“討好”程序員,與程序員“交朋友”。而另一方面,卻忽視了“需求”,導致需求傳達得不清不楚。
這其實是不專業的表現,在與技術部門對接時,我認為,產品經理的核心任務,是“及時準確地傳達需求”。
這里面有3個要點:
2.1 核心目的是傳達“需求”
目標是什么,要實現什么效果,產品經理需要將這些“需求”傳達給技術部門。這里面容易犯的錯誤是,混淆了“需求”與“技術實現方案”。
比如說:我要做一個“統計訂單總數”的功能。
當有新訂單產生時,訂單總數需要實時累加,還是說允許一定時間的延遲,這是“需求”。
監控出單情況,一旦有出單就觸發累加操作,或者設置一個定時任務,隔一段時間執行一次,這是“技術實現方案”。
產品經理當然需要與技術團隊協商討論具體的技術實現方案,但大前提是,要先將需求傳達清楚。
所以,我應該這樣表述:我需要做一個“統計訂單總數”的功能。最理想的情況是,一旦有新訂單,這個總數就實時同步累加。考慮到實際業務需要,如果數據只統計到“昨天”,也是可以接受的。
所以,最好是在出單模塊中加個監控,一旦出單,數據同步加一。當然,如果修改出單模塊的風險比較大,也可以設置一個定時任務,每天凌晨自動統計一次。
具體哪個方案合適,請技術部門內部自行評估。
2.2 需求傳達要“準確”
有些同行朋友,可能會錯誤地認為,只要提需求,程序員就會不高興。
因此,當他們在傳達需求時,對“需求”本身,總是輕描淡寫。
“這就是一個小需求?!?/p>
“就是哪里哪里簡單搞下,加個什么什么東西就行了。”
這是不對的。需求是什么,不要拐彎抹角,應該直接了當、條理清晰地表述出來。
顧左右而言他,反而會讓程序員感到混亂。
2.3 需求傳達要“及時”
不同團隊,有不同的協作流程。
產品經理需要熟悉自己團隊的協作流程,在正確的時機,將需求傳達給所有需要傳達的人。
如果需求傳達不及時,導致開發進度出現問題,開發內容有誤,就非常被動了。
03
產品經理在與程序員打交道時,要始終清楚,自己的核心任務是“及時準確地傳達需求”。
明確這個核心之后,我們才能正確地應對各種情況。
具體要怎么做,這里簡單分享幾個建議。
3.1 產品經理需要簡單地向程序員說明一下需求的背景
網上有些做得很精致的PRD,第一頁會寫一些項目的商業背景、市場預期之類的東西,搞得跟商業計劃書一樣。
這里說的“需求背景”,不是指這些東西。老實說,我自己都懶得去看這些“假大空”的套話。
那么,需要說明什么“需求背景”呢?
這個業務的大體情況是什么樣的,為什么要做這個業務,哪位領導對哪個模塊比較重視,哪位領導對哪個地方有特殊的要求,當前需求的討論情況如何,根據經驗后續需求變動的可能性如何,當前與上下游公司對接中出現了什么問題,等等。
很多時候,“技術”會覺得領導、業務和產品都是在瞎搞,“產品”會覺得領導和業務都是在瞎指揮,“業務”會覺得領導總是想一出是一出。
那到底是誰出了問題呢?
其實,沒有人有問題,只是因為各方掌握的情報量不同而已。
在決策鏈的最頂端,領導掌握了所有的情報,清楚自己每一個決策的前因后果。所以對他來說,他下的每一個命令,都是有理有據的。而在決策鏈的最末端,程序員基本就只能被動地去執行。
舉個不太準確的例子,就像富士康流水線上的工人,不清楚自己手上的零部件最終用在什么地方,起到什么作用。
因為情報缺失,程序員只能自己去“想象”,無法確切知道每個要求背后的原因,所以就容易覺得這些要求都是在“瞎搞”。
因此,產品經理需要有意識地與技術團隊共享這些情報。
這樣做,一方面能讓程序員更加了解項目,確保其工作能滿足項目要求。另一方面,也有利于與技術部門建立共識,使程序員能理解配合產品經理的工作。
3.2 需求討論結束之后,產品經理需要做一個明確的、書面化的總結
我一直強調,在溝通過程中,信息要準確不失真地傳達下去,是一件非常困難甚至不常有的事情。
所有人頻頻點頭,看似都達成共識,實際上很可能每個人的理解都不一樣。
舉個簡單的例子:
產品經理:我想要一只黑色的狗。
程序員:給你一只白色的貓可以嗎?
產品經理:不行。
程序員:那黃色可以不?
產品經理:那好吧。
最終,程序員交付了一只“黃色的貓”。
在實際工作溝通中,尤其是在工作群里討論時,經常會發生這種情況。
因此,在討論的最后,產品經理需要將討論的結果,完整準確地表述一遍,最好像寫PRD一樣,用書面化的語言,然后@上所有干系人,一一確認。
3.3 產品經理無需了解技術細節,但需要關心結論
關于“產品經理需不需要懂技術”,我一向的觀點是,產品經理懂技術有好處,但是效用比一般認為的要小很多,而且不是必要的。
產品經理可以不懂技術。要記住我們的核心任務,是“及時準確地傳達需求”。
在開發過程中,產品經理在為技術團隊提供支持和協助時,始終是圍繞著“需求”進行的。注意不要越俎代庖,去“教程序員怎么開發”。
那產品經理不懂技術,怎么和技術團隊討論呢?
很簡單。當程序員拋出一個你不懂的專業名詞時,百度一下,你就知道了。
需要了解到什么程度呢?
我認為,把百度詞條里面前100個字看完,知道這個專業名詞大致說的是什么,就可以了。也可以當場直接請教對方,這是一個非常自然正常的事情,我覺得完全沒有什么問題。向協作方解釋自己負責的工作,本身就是每個職場人的工作職責之一。
當然,更多時候,我們外行是很難簡單弄懂各種技術原理的。而很多程序員,也不善于向別人表達說明。但這沒有關系,產品經理不需要了解全部技術細節。
很多時候,產品經理只需要關心結論就行了。
“具體技術細節我不懂,我想知道的是你專業的判斷,是能做,還是不能做?如果不能做,我們就換一個方案?!?/p>
“這里報錯了。我現在需要知道,具體我要怎么操作,才能得到我想要的結果?”
“我知道現在碰到了問題,那我這邊需要怎么配合你們,需要我提供哪些東西?”
3.4 產品經理下班沒事就回家,不要浪費公司的空調
說到“程序員”,就不能不提“加班”。
現在有一種奇怪的觀點,認為產品經理提需求,導致程序員加班,是產品經理“麻煩了人家”,所以產品經理需要買奶茶買零食“哄著”程序員,需要陪著程序員加班。
加班,是因為自己的任務無法在上班時間按時完成,所以不得不占用下班時間。它本質上是每個職場人自己的事情。
大家都是成年人,都是能為自己的工作負責的專業人士。如果我加班趕PRD,業務的大哥給我買奶茶飲料,坐在我旁邊陪著我、哄著我加班,那情景想想都瘆得慌。
我認為,如果產品經理需要協助答疑,或者驗收,那就應該和技術團隊一起留下來加班。如果沒有產品經理什么事情,那工作安排妥當后,產品經理就不需要再留在公司,該干嘛干嘛去。
3.5 當程序員有情緒時,要在適當的時機將問題升級
有時候,沖突總是不可避免的。其實,在任何場景下的任何兩個對象之間,都不可能完全避免沖突。
一些“職場經驗”會告訴我們,當發生職場沖突時,我們要努力自行解決。因為這個時候領導在看著你,如果你自己無力解決,還需要求助他人,那就說明你能力不足,讓領導失望了。
我認為這種觀點是有問題的,或者說,它最多只適用于直屬上下級之間的沖突。
曾經我被一個程序員狠狠懟過,場面一度十分尷尬,給我留下了不可磨滅的心理陰影。
那是因為什么原因呢?
我個人工作上的失誤,是一部分原因,但這只是導火索。沒過多久,這個程序員就辭職了。
原來,他對公司積怨已久,已經相當不滿,馬上就要辭職走人了。他看我不爽,只不過是因為“我”是這個讓他不滿的“公司”的一部分而已。
一個員工有情緒,是他的直屬上級需要處理的問題,而不是團隊其他成員的責任。當產品經理發現對接的技術同事有情緒,溝通有障礙,甚至已經爆發沖突,當然首先需要自我反思,并主動尋求解決。但是,認為全部都是自己的責任,隨便攬責,其實并不是一直“負責任”的表現。
當產品經理無法單獨解決時,需要及時將情況反饋給對方的直屬上級,由他來負責協調解決。
反之,如果產品經理把事情壓下來,試圖自行解決,最終影響到項目和業務,那反而是產品經理的責任。
04
在工作中,產品經理需要和很多人打交道,和領導、和業務、和技術、和測試、和運營,等等。
越是跟多方打交道,我越覺得,產品經理最終并不是在和“人”打交道,而是在和“需求”打交道。無論是與誰對接,產品經理始終是圍繞著“需求”進行工作的。產品經理的責任是把“需求”做好。做好自己的工作,足矣。
反之,如果忽視了“需求”,哪怕學會了各種溝通的“套路技巧”,也只會顯得“不專業”,難以真正得到團隊的信賴。
自我介紹:
大家好,我是Minami,一個普通小廠的4年產品人。
說來慚愧,我沒進過大廠,只能混跡在各種不知名的普通小廠。也正因如此,我發現,前輩們分享的一些優秀產品經驗,離開了大廠理想的環境之后,其實非常難應用到自己的日常工作之中。
所以,我想分享一些來自普通小廠的經驗教訓,給剛入行的朋友提供一個不同于大廠的觀察視角。
我不是產品大牛,只是作為一個普通產品人,分享一些日常工作的思考。如果能幫到你,非常榮幸。如果哪些說得不對,歡迎你留言賜教。
作者:簡明產品論,微信公眾號:簡明產品論(ID:JianMingPM)
本文由 @簡明產品論 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
懂技術是最好的交流方式,其它的就是個人偏見