Zi 字媒體

作為「無冕之王」的產品經理，溝通能力是格外重要的一項技能，強溝通下就難免會有爭執，我稍微整理了一下，在實際工作中，與開發人員產生爭執時所處的場景，以及對應的解決方式，分享給大家。為什麼會撕逼？產生的因素實在是太多，可能是性格不合，能力問題，企業文化，天生敵對等等…但有一點毋庸置疑，因為角色的分工不同，因此產品經理考慮內容，問題，方向，範圍一定比程序員考慮的多，因子與因素越多，變數和結果就越多，這也就導致了產品經理們與程序員們，撕逼原因最多的一種情況：更改需求。為什麼會改需求？產品經理設計時，自己沒有考慮到，沒想清楚，忽略，遺漏，錯誤設計…等。失敗的市場調研，錯誤的用戶畫像，導致錯誤的產品設計上線后，不符合用戶胃口。為了配合公司與競品的市場競爭，而展開的戰略性的需求調整。公司內部政策，導致需求的緊急調整。以上僅僅是我所經歷過，最主要的幾點，其中產品市場試錯，是導致需求更改最多的一種情況，也是程序員們最不理解的一種情況，敏捷開發就是為試錯而生，倡導快速思考，快速執行，快速試錯，行就Ok，不行就立即plan B。撕逼場景程序員：我不知道改了需求，你沒有通知，所以下次再改改了需求必須要通知到位，這一點很重要，否則PM會陷入兩頭挨罵的局面。上面或用戶罵你：為什麼沒有改呢？下面程序員罵你：你改了需求並沒有通知我們，這是你的責任。所以改需求別忘記兩點：通知到位，可追溯。我的做法是：每次更改需求時，首先是PRD、線框原型圖、UI設計稿的更新。在項目管理系統中(我們公司使用的是「騰訊敏捷研發平台」)，在對應的需求條目里，增加更改記錄，且寫上更改日期、原因、更改內容。除了口頭通知，必須要在對應的QQ/微信群中，@相關人員，或@全體成員，截圖告知我更改了什麼地方的內容，在哪裡可以查看到。如果再嚴謹一點，還可以發送電子郵件來通知，具體視企業具體情況而定。有可追溯的記錄，能向所有人證明，這次需求的更改，你是做過的且通知過大家，在爭論時能為你提供有力的優勢。如果你真的忘了做這些，且沒有什麼能證明你做過，那就只有自己背鍋吧。程序員：我覺得你這樣做是有問題的，我不建議你這樣考慮有些情況下，如真的是PM考慮欠妥，那麼程序員在開發過程中發現了問題並告訴你，這還真的是好事情，否則別人只管實現，最後上線流程大問題，屁股還是得自己擦。那麼當開發人員，質疑產品經理所設計的內容時，拋出以上的問題，產品經理應該如何應對呢？我的做法是：首先認真傾聽，對方的理由，並結合自己的想法思考。如果你認為對方提出的質疑是錯誤的，那麼立刻把你的想法，告訴對方，糾正並說服對方。如果你認為對方提出的質疑是正確的，那麼你應該「示弱」，並表示馬上重新考慮一下。需要注意的是：無論是你的理解，你的說辭，還是你的想法，都一定要表現出產品經理應有的專業。別暴露出「我沒想好」，「完蛋了，好像真有問題」這類狀態，一旦你這樣，那麼你連反駁的機會都沒有了，自己都沒想好為什麼讓開發人員做？記別做出一副「我是產品經理，我提出想法，你落地實現就行」這類狀態，這樣是很容易發生爭執的，在大部分企業中，PM畢竟不是管理崗，因此別太把自己當回事，只要有利於產品，適當的「示弱和退步」，沒壞處。程序員：又改需求，這個地方已經改了幾次了，為什麼還要改？改需求對開發人員來講，是很痛苦的，寫代碼也講究一個成就感，試想你花了1天的時間研究並實現了一種你曾不會的方法，正在享受著成就感時，PM對你講需求改了，要換一種實現方式，你抓狂不？我的做法是：別因為自己的疏忽，而讓程序員為你買單，宣講前，我會對流程和設計內容過3遍左右。如果是因領導、市場、用戶所決定的，零時需要更改的需求，那麼把實際情況告訴對方就好了，同時你應該無奈的告訴對方：「我也沒辦法啊，這不是我所能控制的」這類話，試著讓程序員感受到，你們是站在同一邊的。如果是你沒想好，不如請別人抽支煙，喝杯咖啡，吃頓飯，用實際行動感化對方，讓對方幫你彌補這個錯誤。爭吵是最沒效果的方法。程序員：這個真的不好實現，你讓我怎麼實現對於此類情況，通常可以分為從兩種類型的程序員口中說出：認真負責或偷奸耍滑。如果是前者，我的做法是：首先傾聽，試著了解，並結合同類功能，儘力判斷，是不是確實不好實現。如果非我所認知的那麼難，我會嘗試說服對方，沖一下，攻克困難。考慮是否有其他方式，代替方案的實現，或更改需求。如果是後者，我的做法是：無論我懂不懂技術，只要我知道對方是抱著想蒙我的態度，那麼我會加入感性的情緒來與他交流，比如故意提高音量，態度強硬，以表明出「別tm想來蒙我，這個東西必須做」的這種氣勢。我會提前背書，如百度搜索相關技術答案，私下詢問朋友等，以便在辯論中有足夠的談資和話語權。當然也要告訴對方，實現后對用戶帶來什麼好處，對平台帶來什麼價值，不實現會有哪些不好的後果…才疏學淺，歡迎補充與指教！ 本文由 @Palowlto 原創發佈於人人都是產品經理。未經許可，禁止轉載。題圖來自PEXELS，基於CC0協議