頻繁的需求變更對團隊和產品都是巨大的消耗和打擊，作為產品經理，如何讓團隊能夠相對輕松的應對變更？

大家好，我是白白。產品經理在實際工作中會遇到很多坑，有些是與程序員的，有些是與老板的。臨時需求變更以及需求溝通不暢是產品經理界普遍存在的問題。

無論是B端的產品經理還是C端的產品經理，矛盾對象主要是兩類人：一個是程序員，另一個是老板或者甲方。

有兩類問題發生的最為普遍。第一個類是程序員與產品經理對需求理解不一致而產生的矛盾，這種情況發展的主要特征就是“相互甩鍋”，第二類是臨時的需求變更，特別是對于老板的臨床加需求顯得非常無奈。

本文只是總結一下作者工作中的一些經驗，在不同的公司由不同的應對方式，大家可以抓住中心思想靈活應對。這兩個策略在作者公司已經施行多年，取得了比較好的效果。

一、三次評審策略

由于專業知識不同，對事物認知體系不同總會產生出多多少少的溝通障礙。有些產品經理認為非常簡單的改動，往往會導致程序員吐槽。在產品demo開發完成之后，也可能會因為bug不斷而被產品經理吐槽，總之，產品經理與程序員的溝通已經在業界討論了不下10年之久。

在筆者的公司，這種情況也經常發生，對于產品經理與程序員間的交流問題解決辦法分為2個方面。

第一個方面是自我約束

自我約束是指雙方在交流時每句話都需要謹言慎行，必須經過認真的思考之后才能闡述。

產品經理提需求前需要認真思考，程序員提出質疑時前也需要認真思考。雙方都需要對自己的言論負責，只有經過認真思考后表達的觀點才能減少沖突。

可惜的是，自我約束只是一個建議，或者說是一項要求，它很難用制度來規范化，所以也就自然不好管理。

第二個方面是通過制度來管理雙方的交流問題

三次評審機制可以減少產品經理與程序員的溝通不暢，這個機制是筆者在公司中長期推動使用，并取得了良好的效果。

一般來講，產品規劃至少提前3個版本或更多，PRD至少提前2個版本。假設在產品1.3上線的時候，可以進行1.5版本PRD的評審與技術預估，v1.5版本的PRD需要進行三次評審。

第一次評審主要溝通需求，需要產品經理進行詳盡的PRD講解，開發工程師從技術角度可以提出各種問題。產品經理無法解答的要一一記錄在案，會后繼續思考完善。

第二次評審產品經理需要回答上次開發工程師提出的疑問或給出的修改建議，不做出修改的闡述堅持理由。

第三次評審需要解決所有問題，雙方達成一致準備開發。三次評審機制必須在1.4版本上線前完成，而且每次需要謹慎對待，避免把責任推到下一次會議上。

圖1 三次評審機制流程

簡而言之，“三次評審”是通過雙方的多次對話，使溝通障礙降低到最小。三次評審之時間可以間隔很短，只是給雙方預留時間來消化對方的信息，在經過自己的思考加工成自己的內容予以表達。

二、總裁特權策略

產品經理直接與老板溝通，經常聽到的一句話就是“XXX，來一下，我這有個需求，這個版本馬上就要”。產品經理此時肯定是十萬頭神獸在心頭奔過，無論是否是敏捷開發，無論多么快速的產品迭代，臨時加需求都會帶來不可預估的工作量。如果功能簡單還好，如果涉及復雜邏輯，那真是欲哭無淚。

筆者認為臨時加需求本身是合理，誰叫你不是老板，但是這種任意更改的行為需要付出代價。所以，筆者在公司中有提倡建設了分級特權制度。

分級特權制度在于提前預留buffer給所要加的功能，不過并不是每個人都有。

在創業公司中，成為“CEO特權”，通常每一個月有3次機會可以增加需求：第一次免費使用，第二次使用扣除3000工資，第三次使用扣除5000工資，更多的變更原則上是可以拒絕的。

如果在大廠，由所在事業部總經理最終背鍋。該制度在于讓所有變更都具有代價，從而謹言慎行。在創業公司或中型公司中，該制度較好實現。由于與工資掛鉤，在一些大廠并不容易實現。該制度實現并不容易，在筆者公司中也遇到層層阻力。但是制度就是用來約束人的，如果高層都不遵守，公司更難以成體系。

在產品經理的世界中，很有很多坑需要去躲避。不過以后你會感謝這些“坑”，它給你帶來了謙卑，讓你懂得做事留有余地，也讓你懂得了忍耐克己。

#專欄作家#

白白，人人都是產品經理專欄作家。公眾號：白白說話（xiaob-talk）。醫藥行業資深產品專家，負責人工智能行業類產品綜合架構與技術開發。在行業云產品架構，藥物設計AI輔助、醫療知識圖譜等領域有深入研究。

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

題圖來自Unsplash，基于 CC0 協議