產品經理（下文簡稱“PM”）在工作中，不可避免要和研發（下文簡稱“RD”）打交道。本文將通過筆者的三個親身經歷，講述這幾年從事PM工作時與RD溝通的心得體會，希望能對讀者有所啟發。

由于雙方所處的立場不同，看問題的角度也不同，所以出現矛盾是在所難免的。筆者在此想通過三個案例，來講講PM和RD在溝通中出現分歧、爭吵時，該如何處理，以及通過案例總結出的經驗與教訓。

案例一

曾經在某個項目中，測試人員（下文簡稱“QA”）發現系統的某項功能不符合需求文檔的要求。雖然不影響業務流程，但是影響用戶體驗，因此告知RD修改。RD回復說需要改代碼，只要涉及到改代碼的，都必須發郵件告知，否則不處理。眼看爭吵漸起，我作為PM必須要站出來處理。

為了不過多占據篇幅，在此不詳細描述當時的問題，簡單來講就是系統需要調第三方接口返回指令，但是指令返回有延遲，這會影響到用戶登錄后看到的頁面狀態，所以需要在調用接口查狀態時延時2秒。

需求文檔中只寫了用戶操作后的系統狀態和頁面展示，沒有寫需要延遲2秒查狀態，因此RD認為這相當于提了個新需求，而不是原來代碼的bug，所以需要發郵件走流程。

我們和他說，需求文檔在評審時已經講過，里面的要求是用戶在操作后看到的狀態必須是準確的。需求始終沒有變化，至于如何實現是技術上的問題，作為PM要保證的是設計方案沒有超出技術邊界，而不是對每一個技術方案的實現都去深入了解。

解決方法

雖然我自認為言之有理，但是最后并未說服對方，甚至還讓他產生了抗拒情緒?？紤]到項目上線時間緊急，如果堅持爭執，只會耽誤項目進度，造成雙輸的結果。

因此我和他說可以發郵件，甚至在郵件中說明是需求變動了，但是項目必須要按時完成，不能因此耽誤進度。在得到我的保證后，大家繼續討論了方案，然后各自按照討論的結果去執行了。

案例總結

1. 溝通時不要忘記最終目標

上述案例中，表面上要解決的是用戶體驗問題，但最終目標是保證需求按時上線且功能滿足要求。堅持爭論到最后或許能有結果，但是會耽誤更多的時間，并對項目中成員的情緒造成不良影響，可能會產生更大的風險。

因此，PM在和RD溝通時要著眼全局來思考，把項目的進度放在首位，不要過于在意一時得失和責任歸屬。就算一時爭吵贏了，從長遠的角度來講，也是雙輸的局面。畢竟PM是設計方案的人，RD才是實現設計方案的人。

2. PM要明白自己與RD關注點的區別

對大多數RD來講，看到的是眼前自己負責的系統，想到的是如何實現功能、要多久才能實現、性能如何等。

而對于PM，從需求的角度來講，要考慮用戶的使用場景、用戶的痛點、用戶的使用習慣、使用后的反饋等。從項目進展的角度來講，要協調項目資源、保證項目進度、解決項目過程中的問題，還有些PM甚至要考慮成本、盈利等問題，這都需要從整體的角度來看待項目。

當然，這里想表達的并非孰優孰劣，而是想借此說明，兩者負責事項的類型和考慮問題的角度存在很大差異。就像上述事例中，筆者關注的是項目的進展和用戶的體驗，而RD關注的是這個算不算bug，以及如果不是bug為什么讓他改。只有明白了彼此關注點的不同，才能更好地進行溝通。

3. 和RD溝通時適當講講宏觀層面的內容

這里所說的宏觀層面，并非是市場走向、公司戰略這類的，而是產品的定位、策略、用戶、場景、需求等。這么做的目的是為了讓RD對需求有一定了解，能感受到自己的工作為用戶解決了問題，為公司帶來了收益。

只有項目組中的每個人有共同的目標，才能激發斗志，帶動工作的積極性。所以筆者一直認為，PM在評審時一定要和RD講清楚需求背景、使用場景、解決的痛點、面向的用戶等。

其實不單是需求評審，平時的溝通中，像上述案例中的處理bug，開發過程中的需求調整，或是平時開會講的產品路線，都可以講講宏觀層面的內容，讓RD了解到自己工作的價值。

案例二

筆者至今仍記得，第一次和RD爭吵時的情景。這位RD平時不喜歡看文檔，更不喜歡按照文檔寫的做，因此總出現問題。一般來說只要不影響用戶使用，我就睜一只眼閉一只眼了（那時候剛去公司，存量需求十幾個，涉及三個系統，忙不過來）。

某次需要修復數據（也是因為沒有按照文檔開發造成的），我便給他發郵件說明需求修復的字段和內容。因為怕他遺漏，所以我特意在郵件中將需要修復的字段標紅加粗，結果還是漏了一個字段。想到他之前幾次不按照文檔開發產生的問題，一股無名火從我心頭冒出，氣勢洶洶前去理論。

誰知這位振振有詞，表示漏的那個字段是因為我沒有當面和他說，他怕改錯了擔責任，所以沒有改。借此機會，我問他為什么平時總不能按照需求文檔開發，是評審時我沒講明白，還是我對開發進度不夠關注。答案讓我啼笑皆非，沒按文檔做不是開發的問題，是測試時沒有測出來。

雖然聽了很生氣，但是看到他的態度，我明白除非把這件事鬧大，否則不可能解決。依照案例一中說的，溝通時要時刻記得最終目標，我的目標有兩個：一是讓RD知道我對于不按照文檔開發的態度，二是解決修復數據的問題。既然目標已經達到，就沒有必要再爭論下去。

解決方法

1. 不把本次爭論的重點放在事情的對錯上，而是關注如何盡快解決數據修復的問題。在之后的需求評審中重點關照下這位同事，多問問他對需求的理解，聽聽他的意見和反饋。

2. 和QA溝通，告知他之前測試過的項目有問題，今后需要再仔細些。同時在進行驗收時，我也會更加認真，盡量把每一個點都驗收到。

3. 幸運的是當時來了個新的QA，負責我這個系統。我給他講了不少業務、系統相關內容，他遇到的問題我也會及時幫忙解決，一段時間下來配合得很默契。再加上他做事認真有章法，不論是寫測試用例還是提bug都很規范（之前的QA這些都沒有），對于RD不按文檔做的問題堅決指出，一段時間內居然沒再出現問題。

案例總結

1. 解決問題的方式有很多，不一定要直面問題

如案例二所述，與RD溝通不能解決問題，就需要從QA著手，加強QA對工作的重視，從而倒逼RD按照文檔來做。這種做法看起來好像是在為難RD，但是從全局出發，是為了避免出現因為功能問題而回滾或者需要修復的情況。

其實，這件事還有其他的解決方法，例如把問題反饋給開發團隊的leader，或者等到項目出現問題引起領導層的重視后再解決，又或者放下手中的工作掰扯清楚責任的歸屬等?？傊?，不同的人有不同的解決方式。筆者認為，在項目中個人的得失永遠是小事，一切的溝通和處理問題，都要以項目進展為最優目標。

2. 維持良好的溝通氛圍

案例二中筆者沒有選擇其他幾種處理方法的原因，一方面是團隊文化和內部氛圍不允許，但是主要原因在于想要維持良好的溝通氛圍。

工作中的每個人都會犯錯，設想如果PM的設計出現漏洞，RD揪住問題不停責問，PM除了不爽外，還會感到壓力山大。長期這樣下去很難形成穩定、良好的合作關系。這樣的氛圍也會讓項目組內人人自危，出現問題不愿意承擔責任，甚至不想接手工作。

筆者在團隊中總強調一個觀點，即出了問題不可怕，應該把注意力應該放在解決問題上，而不是追責?；ハ嘀肛煵荒芙鉀Q問題，只能把團隊氛圍搞差，如果出了問題后每個人都只想著如何甩鍋，那么問題誰來處理呢。

所以筆者認為，一個好的產品經理所維持的溝通氛圍，應該是人人都愿意暢所欲言，人人都把處理問題放在首位，人人都愿意承擔責任的。

案例三

最近新上線的項目，由于某些原因存在很多問題。這個項目上線前已經忙了兩個多月，大家為了它停了手里的不少工作，原以為上線后可以松一口氣，可是誰想到是這個樣子，每個人心頭都憋著火。

在某一次修復問題的討論中，矛盾爆發了，項目組內的成員發生了激烈的爭吵。爭吵的內容毫無意外是責任歸屬，雙方都認為是對方在系統對接時沒有交代清楚才導致的問題。雖然爭論雙方都是RD，這次的問題也和PM沒有關系，但是我還是介入其中希望能通過自己的努力來解決問題。

解決方法

先讓同事停止爭吵，然后告知項目組的每一個人現在討論的目標不是為了追責，而是要讓大家集思廣益，盡快解決問題。目前還沒到追責這一步，如果真到了這一步，我作為PM也會站出來承擔責任。

最后讓每個人明白，項目做了這么久很辛苦，上線后出現問題大家心里都不舒服，這個可以理解。但是有問題必須要解決，所以希望每個人在遇到問題時把注意力放在問題上，盡快把問題解決完，這樣一個項目才算做的有始有終。

由于本項目中出現的不少問題都是溝通不到位導致的，因為我表示在解決問題的過程中，有需要我去溝通、協調、確認的，可以隨時找我。然后大家又討論了處理方案及分工，就各自歸位去執行了。

案例總結

通過這個案例想要告訴讀者，盡管有的問題并非PM的責任，但是PM在出現問題后不要想著置身事外，而是要主動參與其中調動團隊成員去解決問題。

上述案例中，項目上線后出現問題，人心浮動時，PM要及時給項目組的成員鼓勁，告訴大家出現問題不可怕，只要按部就班解決問題就好。當團隊成員出現矛盾、分歧時，PM要能站出來搞清楚問題的所在，幫助大家解決問題并時刻提醒大家牢記項目的最終目標。

總之，PM可以說既是項目的指明燈，同時也是項目的粘合劑。

受篇幅和案例所限，還有一些溝通方法和溝通時需要了解的注意事項，就不一一列出了。本文的目的是拋磚引玉，希望對讀者能有啟發，也希望讀者能留言說說自己的溝通方法，不論是站在PM的角度還是站在RD的角度。

作者：打醬油的熊，公眾號：打醬油的白熊

本文由 @打醬油的熊 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議