作為產品經理，就是來解決沖突的嗎？本文作者以自身經驗告訴你“是的”。enjoy~

最近正在做一款培訓相關的APP，研發前期進行了3輪需求評審和1輪測試用例評審，確定了第一版的需求，研發周期為一個月。

在產品研發進行到半個月的時候，一名程序員對我說：

“我覺得教室管理放在這里不合理啊，這里的功能這么復雜，要做成即可選擇又可新增的多復雜??！”

在此之前的一周，該名程序員跟我說了幾次后臺的收銀下單功能完全可以不做，直接手機APP買單就可以了。

整個連鎖店的背景我是跟所有項目組成員描述過的，對于一個現在全部靠線下來運營的連鎖店鋪來說，既需要基本的店務管理功能又需要線上的下單和分享功能。

這兩個在最終需求評審的時候已經反復確認過的問題現在再拿出來說，在我看來是在浪費時間，我覺得現在應該把全部的精力都放在完成這個產品上。

轉念一想，作為產品經理的我不就是來解決沖突的嗎？研發與產品的沖突、運營與產品的沖突、客戶與產品的沖突，現在我要做的是先反思一下遇到沖突的時候該怎么辦，而不是一味地覺得研發不對。

1.?承認沖突

產品經理和研發溝通的時間非常多，完全避免沖突是不現實的。在沖突發生的時候，我們最需要的就是控制自己的情緒。曾經聽說過一個比喻：產品經理就像是化學中的催化劑，既能使得產品加速完成，也能阻礙產品的研發。

和研發保持愉快的合作關系，能夠讓研發產生更加積極的情緒，有利于產品目標的順利完成。若是和研發產生矛盾，研發很有可能會產生懈怠情緒，從而導致產品延期，也有可能對后續的進一步合作產生影響。既然情緒本身不會給我們的產品帶來任何好處，我們就需要在溝通的時候盡量避免負面的情緒，專注于如何解決問題上。

隨后，我冷靜地對研發說：

“當你說教室管理放在排課這里不合適的時候，我感覺有點為難，因為我們在需求評審的時候已經反復確認了這個問題，只有排課這里會用到教室，在這里維護的話，用戶操作起來會更方便，界面也會更簡潔?！?/p>

2.?尋找需求

這時，我也在同步思考為什么研發現在才提出這種想法，為什么之前評審的時候他說沒問題了。于是，我問道：

“那你覺得怎么樣做更合理呢？”

程序員回答：

“把這個功能放在門店管理里面，像分類管理那樣做一個彈出框實現這個功能會更好?！?/p>

我這時候的想法是：你之所以這么說是因為你現在正在開發這個功能，你覺得這樣實現起來需要耗費更多的時間來思考如何實現，用以前的方法來實現的話只需要直接復用以前的功能就行，減少了工作量。而且把這個功能放在門店管理部分，就不屬于你的研發范圍，你只需要調用就可以了，這就是你的需求。而我的需求是如何簡單快速地實現這個功能，不管是誰實現的。

在研發產品的過程中，產品經理實現客戶需求的主線是不變的，在此基礎上，若能夠平衡好內部的需求，我們就能成為了加速產品完成的催化劑。在這次沖突中，也有可能研發真的覺得這樣實現會更好，只是我沒法快速Get到他的思想。

3.?解決矛盾

這個產品的第一版需要在一個月內完成，時間非常緊迫。這個時候產品應該更多地考慮下一期產品的功能，而不是糾結于這個已經確定的功能。

這個時候我把技術經理和相關的人員叫在一起，問問大家對這個解決方案有沒有意見，最終大家都同意了這樣實現。

這個小功能不會對產品本身產生大的影響，不會造成他人的不滿，不影響最終的產品目標，快速確定解決方案就是最重要的。

這對我以后管理需求有什么啟發呢？

需求評審注重細節

需求評審的時候，為了減少研發人員的業務思考，避免產品研發過程中對需求的誤解，一份高保真的原型和詳細的需求描述很重要。前期溝通得越清楚，后期的溝通成本就越小。

迭代應對變化

遇到突發情況更改產品的需求也是正常的。對于需求變更頻繁的產品，用迭代的方式進行研發能夠減少不確定性。特別是C端使用的產品，根據用戶的反饋，一周一迭代就是一個很好的控制需求變更的方法。

以不變應萬變

若在迭代的過程中遇到需求變更，最好的方法就是先不開發此功能，充分考慮變化帶來的后果，放到下一個迭代之后再實現這個需求對應的功能。

有需求就可能有沖突，面對變化的需求，要越來越處變不驚。

共勉。

作者：華華，高級產品經理一枚，坐標長沙，微信公眾號：愛產品愛生活

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

題圖來自 Pexels，基于 CC0 協議