產品經理與程序員之間的矛盾沖突，并不特殊，它是一個系統性問題。那么，產品經理應該如何與程序員打交道？

01

與程序員打交道，是產品經理的日常工作之一。從網上流傳的各種產品與技術起沖突的段子可以看出，產品經理與程序員之間的關系，總的來說，并不十分融洽。

我相信，有相當多的同行朋友，都為之苦惱過，我也不例外。

這幾年下來，被程序員懟得多了，漸漸地也就變得波瀾不驚了。雖然技術對產品有諸多不滿，產品也對技術有各種意見，但是，這里我并不想去大書特書雙方的矛盾。

在討論“如何與程序員打交道”之前，我想先對這種矛盾定個調。

我認為，產品經理與程序員之間的矛盾沖突，并不特殊。

如果關注設計師圈子，你會發現，甲方與設計師之間，也有類似的“恩怨情仇”。其實，在任何協作網絡中，處于對接工作的上游和下游之間，普遍存在類似的矛盾沖突。

它是一個系統性問題，簡單地將之歸因為某些人的某些錯誤，是一種思想上的懶惰。

從某種程度上講，我們無需過度關注與程序員的矛盾，等閑視之，做好自己的工作即可。

02

產品經理的工作是圍繞著“需求”進行的。

在與技術部門進行對接時，產品經理需要關注的，始終是“需求”。

產品新人很容易在這上面犯錯。因為外界夸大了產品與技術之間的矛盾，導致產品新人會不自覺地把自己工作的重心，放在“不惹程序員生氣”上面。

在與程序員打交道的過程中，為了避免被懟，過度關注程序員的情緒，想方設法地“討好”程序員，與程序員“交朋友”。而另一方面，卻忽視了“需求”，導致需求傳達得不清不楚。

這其實是不專業的表現，在與技術部門對接時，我認為，產品經理的核心任務，是“及時準確地傳達需求”。

這里面有3個要點：

2.1 核心目的是傳達“需求”

目標是什么，要實現什么效果，產品經理需要將這些“需求”傳達給技術部門。這里面容易犯的錯誤是，混淆了“需求”與“技術實現方案”。

比如說：我要做一個“統計訂單總數”的功能。

當有新訂單產生時，訂單總數需要實時累加，還是說允許一定時間的延遲，這是“需求”。

監控出單情況，一旦有出單就觸發累加操作，或者設置一個定時任務，隔一段時間執行一次，這是“技術實現方案”。

產品經理當然需要與技術團隊協商討論具體的技術實現方案，但大前提是，要先將需求傳達清楚。

所以，我應該這樣表述：我需要做一個“統計訂單總數”的功能。最理想的情況是，一旦有新訂單，這個總數就實時同步累加?？紤]到實際業務需要，如果數據只統計到“昨天”，也是可以接受的。

所以，最好是在出單模塊中加個監控，一旦出單，數據同步加一。當然，如果修改出單模塊的風險比較大，也可以設置一個定時任務，每天凌晨自動統計一次。

具體哪個方案合適，請技術部門內部自行評估。

2.2 需求傳達要“準確”

有些同行朋友，可能會錯誤地認為，只要提需求，程序員就會不高興。

因此，當他們在傳達需求時，對“需求”本身，總是輕描淡寫。

“這就是一個小需求?！?/p>

“就是哪里哪里簡單搞下，加個什么什么東西就行了?！?/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協議。