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

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

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

這時候呢，我發(fā)現(xiàn)有些產(chǎn)品經(jīng)理特別“硬氣”，他們會說：“我就按這需求來，出了問題我扛著誰叫我是產(chǎn)品經(jīng)理。

有些產(chǎn)品經(jīng)理就稍顯弱勢，只要研發(fā)能安心把活干完，你說怎么改就怎么改。

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

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

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

B端产品经理的能力模型与学习提升

B端产品经理面临的第一大挑战，是如何正确的分析诊断业务问题。 这也是最难的部分，产品设计知识对这部分工作基本没有帮助，如果想做好业务分析诊断，必须具备扎实 ...

查看详情 >

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

接下來，我就給大家來分享下關(guān)于這個問題的應(yīng)對策略。

一、研發(fā)為什么會找你改需求？

1. 需求設(shè)計不合理，存在邏輯實現(xiàn)上的漏洞

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

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

研發(fā)人員經(jīng)常喜歡diss產(chǎn)品經(jīng)理的是，你設(shè)計的這個功能不合理，存在哪些方面的情況沒有考慮到。

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

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

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

然后，把你列入需求文檔不嚴謹?shù)闹攸c關(guān)注對象之一，逮著機會就喊你過去，這滋味，真是“酸爽‘?。。óa(chǎn)品經(jīng)理咋個牛逼，還不是被老子呼來喚去）。

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

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

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

2. 功能設(shè)計太復(fù)雜，實現(xiàn)起來技術(shù)難度太大

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

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

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

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

我在剛開始做產(chǎn)品經(jīng)理的那幾年，每次設(shè)計的需求邏輯規(guī)則復(fù)雜一點，就會聽到研發(fā)總監(jiān)的那句經(jīng)典語錄：“這樣設(shè)計做不了，要這樣做的話，我的整個架構(gòu)都要改?！?/p>

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

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

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

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

告訴產(chǎn)品經(jīng)理：“我盡力了，但真的做不了。”然后讓產(chǎn)品經(jīng)理想辦法，調(diào)整需求了。

3. 項目工時太緊張，找產(chǎn)品改需求碰碰運氣

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

這樣帶來的一個問題就是，在限定的時間內(nèi)，研發(fā)人員有時候真的是沒有思路，如何去實現(xiàn)這個產(chǎn)品功能？

如果想技術(shù)實現(xiàn)方式花了一天的時間，那周末可得加一天的班把進度補回來啊！

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

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

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

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

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

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

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

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

二、應(yīng)對需求改動的四個妙招

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

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

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

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

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

一個優(yōu)秀的產(chǎn)品經(jīng)理，一定是代表用戶來發(fā)聲，站在用戶的角度去設(shè)計產(chǎn)品的。

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

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

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

1）現(xiàn)有技術(shù)可以實現(xiàn)，只是方法沒有找到

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

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

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

2）現(xiàn)有技術(shù)實現(xiàn)不了，需要用新技術(shù)解決

要是現(xiàn)有技術(shù)真的搞不定，那就得考慮引入新技術(shù)了。

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

3）需求實現(xiàn)改動太大，得改現(xiàn)有技術(shù)框架

有時候，為了滿足某個需求，可能需要改動現(xiàn)有的技術(shù)框架。

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

當然，要判斷一個功能到底技術(shù)上能不能實現(xiàn)，產(chǎn)品經(jīng)理也得懂點技術(shù)知識。要不自己也是兩眼一抹黑，腦子一團漿糊，那怎么去和研發(fā)溝通技術(shù)上如何實現(xiàn)。

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

時間問題導(dǎo)致的研發(fā)希望需求調(diào)整，主要涉及到兩個方面：

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

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

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

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

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

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

有些產(chǎn)品經(jīng)理可能會覺得，這些問題都是研發(fā)總監(jiān)和產(chǎn)品總監(jiān)該操心的，跟自己沒關(guān)系。

千萬別這么想！產(chǎn)品經(jīng)理對產(chǎn)品可是負有“終極責任”的，從研發(fā)、銷售到交付，每一個環(huán)節(jié)都跟你有關(guān)。產(chǎn)品就像你的孩子一樣，怎么能做這么不負責任的爸爸呢？

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

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

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

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

這時候，產(chǎn)品經(jīng)理們，你們那口才可得派上用場了！從業(yè)務(wù)場景、用戶、價值等方面，給研發(fā)小伙伴們好好講講。

他們不像產(chǎn)品經(jīng)理，接觸不到客戶，不需要調(diào)研市場，很多時候他們也不了解業(yè)務(wù)，理解能力也稍弱一丟丟，角度跟你不一致，需要多解釋幾遍才行。

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

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

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

三、最后的話

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

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

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

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