作為產品經理最親密的戰友，經常會有程序員找產品經理要求改需求。一般來說都還好，如果是真的不能改，這種情況，如何應對更好呢？

各位小伙伴們！你們有沒有碰到過這種情況？

產品研發過程中，那些聰明的研發或測試小伙伴總是來找你聊需求，哪怕你已經把需求寫得跟字典一樣清楚，他們還是會“孜孜不倦”地試圖說服你改一改。

這時候呢，我發現有些產品經理特別“硬氣”，他們會說：“我就按這需求來，出了問題我扛著誰叫我是產品經理。

有些產品經理就稍顯弱勢，只要研發能安心把活干完，你說怎么改就怎么改。

說到這，大家可能都有點兒迷茫了，這改還是不改，到底應該怎么辦呢？

是硬剛到底，還是隨他去吧？

其實啊，這兩種方式都不太對。

單純以產品經理的身份去拒絕，或者為了討好研發而隨意改動需求，都不是解決問題的最佳途徑。

接下來，我就給大家來分享下關于這個問題的應對策略。

一、研發為什么會找你改需求？

1. 需求設計不合理，存在邏輯實現上的漏洞

對于研發人員而言，一個需求寫的好不好，不是去評判對于用戶好不好用，而是去研究你寫的產品需求文檔邏輯上是否嚴謹。

只要你的原型在邏輯上把該考慮到的都設計出來了，把可能存在的情況都寫的清楚了，那研發人員可就挑不出毛病來了，只能乖乖按照你的需求來。

研發人員經常喜歡diss產品經理的是，你設計的這個功能不合理，存在哪些方面的情況沒有考慮到。

導致他們寫代碼的時候，就碰到了一些“坑”，不知道咋處理，邏輯上有點漏洞，代碼就寫不下去了，寫出來也跑不通。

有些測試人員就更喜歡去做這種從需求中“找bug”的游戲了，一旦發現你的需求文檔有啥遺漏，，那就得揪著你說道一通。

甚至得把你喊到他坐位邊上去，訓仔似的教你怎么“寫需求”。

然后，把你列入需求文檔不嚴謹的重點關注對象之一，逮著機會就喊你過去，這滋味，真是“酸爽‘?。。óa品經理咋個牛逼，還不是被老子呼來喚去）。

同時，他已經處理占據了有利的位置，會盯著、催著、吵著你趕緊把需求文檔完善掉。

催人改東西，和從東西里面找問題，這是測試人員最擅長的兩項基本功。

所以，一旦你寫的需求文檔邏輯上存在問題，就等著被研發和測試來回diss！

2. 功能設計太復雜，實現起來技術難度太大

我們在進行需求評審的時候，研發人員可不是在欣賞你的產品設計設計的多牛逼，他們可是拿著放大鏡在找“坑”。

心里盤算嘀咕著：這個功能要弄起來，得新建多少張表格??？數據要從哪里來？要不要單獨跑個任務？跟現有的功能會不會打架？還有哪里沒考慮到？邏輯上能不能通？

一通分析下來，大概就知道接下來的一段時間的“磚”好不好搬，燙不燙手。

要是你是一個還算比較好說話，或者經驗尚淺容易被說服的產品經理，大概率研發會來找你溝通一下，建議你需求不要這樣做設計，可以簡單一點，整那么復雜干什么，研發起來多費勁。

我在剛開始做產品經理的那幾年，每次設計的需求邏輯規則復雜一點，就會聽到研發總監的那句經典語錄：“這樣設計做不了，要這樣做的話，我的整個架構都要改?！?/p>

一開始我是迫于人家是總監的崗位不好頂嘴，在評審結束之后立馬就去調整需求，但在心里還是會鄙視一番“不就是技術水平不行，瞎逼逼那么多干嘛！”。

后來工作經驗多了，和研發也打了幾百回交道了。才明白過來，只要稍微復雜一點的功能，“改動太大，做不了”這句話就會伴隨著出現。

不是做不了，而是不想做。

當然啦，還有一種情況，研發小伙伴的能力確實不足，把自己的畢生所學都用上了，還是沒有辦法解決。怎么辦，只能兩手一攤，涼拌。

告訴產品經理：“我盡力了，但真的做不了?！比缓笞尞a品經理想辦法，調整需求了。

3. 項目工時太緊張，找產品改需求碰碰運氣

每一個項目都有上線的時間要求，就像有個“小鬧鐘”在耳邊嘀嗒嘀嗒地響，項目經理很多時候都是把“趕工”兩個字時刻掛在嘴邊，鞭策大家抓緊時間干活。

這樣帶來的一個問題就是，在限定的時間內，研發人員有時候真的是沒有思路，如何去實現這個產品功能？

如果想技術實現方式花了一天的時間，那周末可得加一天的班把進度補回來??！

這種情況下，能不加班那是鐵定不加班，人本能的會想著能不能找產品經理這個“甲方”商量下，畢竟是為產品經理做產品（99%的研發都是這種想法，除了不寫代碼的研發經理）。

只要產品經理同意，自己不就不用加班，何必去絞盡腦汁想解決辦法呢？費那個腦子干嘛！

4. 需求性價比太低，做出來沒啥價值不劃算

研發人員可不是那種“你說啥我做啥”的“機械工人”哦！他們也有自己的工作熱情、成就感和小驕傲。

有些功能在他們看來，如果做起來覺得沒有什么價值，就會產生抵觸心理。

本著為自己工作貼金和為公司節省資源的角度考慮，和你溝通需求的價值問題，這是一種非常合理的心態。

特別是有些功能做起來實現的技術難度太大，需要投入的時間比較多，并且還有一定的風險做不出來。

在他看來做這個功能價值就不大，就會盤算做出來劃不劃算的問題，也得考慮下保住個人工作飯碗的問題。

二、應對需求改動的四個妙招

1. 化身用戶去思考這個需求要不要

往往很多對用戶比較友好，產品使用起來比較簡單、便捷、智能的功能，其背后實現的邏輯都會比較復雜。

這時候，你的站位就很重要了！

如果你化身成用戶，想想這個功能是不是真的很方便、很實用，那么你就會堅定地支持它，哪怕研發小伙伴覺得這是苦活累活。

但如果你站在研發的角度，想著“打工的何必為難打工的”，那你可能就會被研發小伙伴說服，然后妥協一下，調整需求。

一個優秀的產品經理，一定是代表用戶來發聲，站在用戶的角度去設計產品的。

面臨研發人員找你溝通需求調整的時候，一個萬能的回答方式是“用戶說要這么做的”。不要“你覺得”，也不要“我覺得”，只要“用戶說的”。

2.堅信一點：99%技術問題都有辦法解決

當研發人員告訴你某個需求從技術上搞不定，別慌！咱們來分情況聊聊：

1）現有技術可以實現，只是方法沒有找到

有時候，研發人員覺得某個功能難搞，可能是因為他們還沒找到正確的技術路徑。

這時候，咱們產品經理就要發揮“指路明燈”的作用啦！讓研發說說他們的想法，咱們一起找找邏輯上有沒有問題。

要知道，解決問題的方法從來都不是“華山一條路”，不一定要在一條道上走到黑，此路不通就換一個角度，換一條道路去試試。

2）現有技術實現不了，需要用新技術解決

要是現有技術真的搞不定，那就得考慮引入新技術了。

比如我們要做一個3D地圖，沒第三方接口就做不了。這時候就得去找找外部資源，讓他們來幫個忙。雖然多了一道工序，但總比放棄強吧！

3）需求實現改動太大，得改現有技術框架

有時候，為了滿足某個需求，可能需要改動現有的技術框架。

比如，在一個用FastAdmin框架開發的中臺系統里加視頻和動畫效果，可能就得換個前后端分離的框架。這時候，就得和研發一起商量下，怎么調整需求才能盡可能少地改動框架。

當然，要判斷一個功能到底技術上能不能實現，產品經理也得懂點技術知識。要不自己也是兩眼一抹黑，腦子一團漿糊，那怎么去和研發溝通技術上如何實現。

3. 時間問題多半是分工或能力問題

時間問題導致的研發希望需求調整，主要涉及到兩個方面：

1）本身有別的項目在身，新需求上線時間撞車了

這種情況，咱們在產品需求評審前就得摸清底細，看看研發人員手頭是不是已經有一大堆事兒了。

如果這項目非得這哥們兒參與不可，那咱們就得調整項目排期或者重新排序功能優先級，而不是簡單地調整需求。

2）需求要求的時間太短，個人技術能力上做不到

咱們在做項目時間評估時，通常就是按人天來粗略算的，但往往沒考慮到每個人的能力水平。同樣是做一個功能，高手可能兩小時就搞定了，而新手可能得花上兩天時間。

所以，這種情況下，就需要合理分配項目的人員，進行研發能力的均衡搭配。

有些產品經理可能會覺得，這些問題都是研發總監和產品總監該操心的，跟自己沒關系。

千萬別這么想！產品經理對產品可是負有“終極責任”的，從研發、銷售到交付，每一個環節都跟你有關。產品就像你的孩子一樣，怎么能做這么不負責任的爸爸呢？

4. 有沒有說出需求價值背后的故事

產品經理對于需求的收集大多是直面客戶的，可以通過客戶的言談舉止感受到該需求的強烈程度。

可研發的小伙伴們，他們就只能看你們寫的需求文檔，想象你們描述的“戰場畫面”，這可就容易產生誤會和偏差了。

有時候，你覺得對客戶超有價值的功能，可能在文檔里沒寫清楚，研發就一頭霧水，完全get不到點。

這時候，產品經理們，你們那口才可得派上用場了！從業務場景、用戶、價值等方面，給研發小伙伴們好好講講。

他們不像產品經理，接觸不到客戶，不需要調研市場，很多時候他們也不了解業務，理解能力也稍弱一丟丟，角度跟你不一致，需要多解釋幾遍才行。

實在不行，那就在調研階段，直接把研發人員拉過來，讓他們一起聽聽客戶怎么說。這樣一來，他們就能“身臨其境”，更容易“感同身受”了。

當然，要是這個功能背后的客戶故事你自己都講不出來，需求是自己意淫出來的，自認為對客戶有價值。

這種情況下，還是趁早改掉吧，研發的資源也很寶貴，經不起大家去實踐一些不著邊際的想法。

三、最后的話

在產品制作的過程中，難免會有各種聲音，有人夸，有人罵，有人給你出主意。

但別忘了，你是產品的“親爹”，你代表了“客戶”的心聲。

所以，當各種聲音紛至沓來時，你得堅定信念，保持清醒的頭腦，做出最明智的決策。

畢竟，你是這個產品小寶貝的“守護神”，得讓他茁壯成長，不是嗎？