身為產(chǎn)品經(jīng)理，要怎么合理的跟程序員提需求呢择镇？要怎么去處理才能很好的化解產(chǎn)品與技術(shù)的矛盾挡逼，而避免挨揍呢？
最近一個視頻火遍了整個朋友圈腻豌，某公司的產(chǎn)品經(jīng)理和程序員大打出手家坎，據(jù)說背后原因竟是產(chǎn)品經(jīng)理要求用戶App的主題顏色能根據(jù)手機(jī)殼自動調(diào)整嘱能，可能是程序員覺得這個要求太過分了，于是一言不合打了起來虱疏。
作為產(chǎn)品經(jīng)理的我惹骂，也覺得這個需求有點過分，但是也不至于就為這打起來啊做瞪，你看看其他團(tuán)隊人家開始尋找解決方案了析苫。
很佩服這個老哥給的解決方案，一個字：牛逼穿扳，兩個字：真牛逼衩侥！
你咋不直接人工智能呢？如果你是程序員給出這個方案矛物，在佩服你智商的同時茫死，估計也要挨打了，還是下面的老哥給的方案靠譜啊
龍哥一句話履羞，讓整個空氣都靜止了峦萎，對啊，拋開需求的合理性忆首，如果可以這樣做那不就簡單了爱榔。但是你如果碰到很軸的產(chǎn)品經(jīng)理怎么辦？
人家明明說的“根據(jù)手機(jī)殼的顏色自動調(diào)整APP主題顏色”糙及，是自動調(diào)整详幽！給你說三遍，是自動調(diào)整浸锨！怎么辦唇聘？還能怎么辦，揍他Ｖ选３倮伞！（作為產(chǎn)品經(jīng)理的我聪蘸，都忍不住要揍他了宪肖，還是回去好好反思下你的需求吧！）
1健爬、需求分析和描述不到位
如上圖所示控乾，程序員處在流程的最底端，產(chǎn)品經(jīng)理跟客戶/用戶/領(lǐng)導(dǎo)溝通的需求浑劳，最后傳遞到程序員這里阱持，有可能變了味道夭拌。如果產(chǎn)品經(jīng)理把握不好魔熏，可能最終結(jié)果跟客戶想要的完全不一樣衷咽。等到最終客戶/用戶/領(lǐng)導(dǎo)勃然大怒的時候，矛盾可能就激發(fā)了蒜绽。
如何解決镶骗？
產(chǎn)品經(jīng)理首先要了解業(yè)務(wù)，才能更好的理解需求躲雅。如果需求來自客戶鼎姊，那么一定要明確這個需求不是最終可用的需求，一定要做需求分析相赁，幫客戶梳理這個需求相寇，弄清楚客戶提這個需求的最終目的是什么？
客戶的需求如果是“我要一批更快的馬钮科！”唤衫，也許他的目的不是要一匹馬，而是更快的交通工具绵脯。產(chǎn)品經(jīng)理一定不是客戶的傳話筒佳励，他一定要將客戶需求轉(zhuǎn)變?yōu)楫a(chǎn)品需求或者系統(tǒng)需求。
2蛆挫、產(chǎn)品需求經(jīng)常變動
由于產(chǎn)品經(jīng)理經(jīng)常改動需求赃承，導(dǎo)致程序員不得不把做好的東西重新再做，結(jié)果可想而知悴侵。有時候程序員加班加點剛做完的東西瞧剖，產(chǎn)品經(jīng)理說需求變動了，不能這么做可免，嚴(yán)重的時候連核心模塊都完全大變樣筒繁。就一直這樣改完做，做完改巴元，無限循環(huán)下去毡咏。
但是產(chǎn)品經(jīng)理也有怨言，需求變化是正常的啊逮刨，老板的想法經(jīng)常變呕缭，客戶的需求經(jīng)常變，我有什么辦法修己？
需求變化從某種意義上來說是好事恢总，有變化說明有進(jìn)展或者有改進(jìn)，我們不能避免需求變化睬愤，但是作為產(chǎn)品經(jīng)理我們要學(xué)會控制需求片仿，對需求進(jìn)行有效的管理。
首先我們要做需求的合理性討論尤辱，在這個階段如果能讓技術(shù)參與砂豌，發(fā)表意見厢岂，讓他們感到被尊重，對于后期的需求支持是很有幫助的阳距，切莫自己二話不說拍腦袋塔粒！確定需求必須要改變以后，我們要合理的管理這個變化筐摘。
產(chǎn)品經(jīng)理必須得有版本的概念卒茬，當(dāng)前已經(jīng)開發(fā)的版本內(nèi)盡量不發(fā)生變化，把新的變化規(guī)劃到下一版本咖熟；如果實在必須要在當(dāng)前版本需要變化圃酵，那就和技術(shù)溝通工作量和計劃變更。
要么延長上線時間馍管，要么替換其他需求任務(wù)辜昵，讓需求的變化不影響技術(shù)的工作量和計劃，技術(shù)又怎么能給你打架呢咽斧？
當(dāng)然堪置，由于老板的行政命令和對客戶的承諾，你無法更改計劃张惹，那怎么辦呢舀锨？
還是和程序員做朋友，做兄弟吧宛逗，如此也許一頓飯就搞定啦坎匿。
3、產(chǎn)品狗不懂程序猿
遇到一個像我這樣很懂技術(shù)的產(chǎn)品經(jīng)理不容易（有點超自戀O(∩_∩)O）雷激，程序員經(jīng)常聽到的一句話就是——“這么簡單的功能為什么要這么長時間替蔬？”
這樣的話令很多程序員惱火，是最能激發(fā)與產(chǎn)品經(jīng)理矛盾的導(dǎo)火索屎暇。因為你不懂技術(shù)承桥，你就和程序猿沒有共同的話題，你就很難站在對方角度上去看這個問題根悼，你也無法掌控程序猿對工作量的評估是否合理凶异，總是以為他在騙你，如果是這樣的狀態(tài)挤巡，又怎么能不產(chǎn)生矛盾呢剩彬？
從技術(shù)轉(zhuǎn)到產(chǎn)品的人，本身對技術(shù)了解矿卑，可以更好的跟程序員溝通想法喉恋，但是一定注意，千萬不要反客為主，不要干涉技術(shù)轻黑。之前就碰到一個曾經(jīng)做過技術(shù)的產(chǎn)品經(jīng)理糊肤，對于技術(shù)的方案評頭論足，甚至指導(dǎo)技術(shù)苔悦，搞的技術(shù)很郁悶，摔了一句：“既然你這么牛逼椎咧，你自己做好了”玖详。
對于不懂技術(shù)的產(chǎn)品經(jīng)理來說，建議要去了解一下基本的技術(shù)知識勤讽，不需要太深蟋座，但是要知道概念，知道大致的使用場景脚牍。別整出像“你是用Java還是SQL開發(fā)”向臀，“Hodoop比你用Java開發(fā)好吧”等這樣的概念性的錯誤，讓程序員鄙視诸狭，啥都不懂券膀，你還怎么質(zhì)疑人家評估的工作量啊驯遇！
高山流水芹彬，知音難覓！知音不成叉庐，至少我懂舒帮！只有懂對方，才能在一個頻道上溝通陡叠。
為了做一個不想挨揍的產(chǎn)品狗玩郊，一定要不斷修煉上面說的一些能力。當(dāng)然作為一個曾經(jīng)的程序員枉阵，現(xiàn)在雖做產(chǎn)品但依然領(lǐng)導(dǎo)技術(shù)團(tuán)隊的我译红，也有必要給我們的程序員弟弟們點建議：
做好需求變化的準(zhǔn)備，不要排斥變化兴溜。要提高代碼的擴(kuò)展性和維護(hù)性临庇，用不變的架構(gòu)應(yīng)對變化的需求。
對需求理解透徹在開始寫代碼昵慌，要多和產(chǎn)品經(jīng)理確認(rèn)假夺！我們經(jīng)常碰到最后開發(fā)出來的跟產(chǎn)品經(jīng)理想要的不一樣，就是因為沒有理解需求斋攀，或者理解有誤已卷，就開始做了。
評估工作量和計劃時淳蔼，一定要預(yù)留修改bug及其他突發(fā)事件的時間侧蘸，給自己的工作留有余地裁眯。
