身為產(chǎn)品經(jīng)理，要怎么合理的跟程序員提需求呢？要怎么去處理才能很好的化解產(chǎn)品與技術(shù)的矛盾，而避免挨揍呢？

最近一個(gè)視頻火遍了整個(gè)朋友圈，某公司的產(chǎn)品經(jīng)理和程序員大打出手，據(jù)說背后原因竟是產(chǎn)品經(jīng)理要求用戶App的主題顏色能根據(jù)手機(jī)殼自動調(diào)整，可能是程序員覺得這個(gè)要求太過分了，于是一言不合打了起來。

產(chǎn)品狗和程序猿打架，誰會贏？真是看熱鬧的不怕事大！

作為產(chǎn)品經(jīng)理的我，也覺得這個(gè)需求有點(diǎn)過分，但是也不至于就為這打起來啊，你看看其他團(tuán)隊(duì)人家開始尋找解決方案了。

尼瑪，厲害！你咋不分析手機(jī)附近的光譜呢？

很佩服這個(gè)老哥給的解決方案，一個(gè)字：牛逼，兩個(gè)字：真牛逼！

你咋不直接人工智能呢？如果你是程序員給出這個(gè)方案，在佩服你智商的同時(shí)，估計(jì)也要挨打了，還是下面的老哥給的方案靠譜啊

龍哥一句話，讓整個(gè)空氣都靜止了，對啊，拋開需求的合理性，如果可以這樣做那不就簡單了。但是你如果碰到很軸的產(chǎn)品經(jīng)理怎么辦？

人家明明說的“根據(jù)手機(jī)殼的顏色自動調(diào)整APP主題顏色”，是自動調(diào)整！給你說三遍，是自動調(diào)整！怎么辦？還能怎么辦，揍他！?。。ㄗ鳛楫a(chǎn)品經(jīng)理的我，都忍不住要揍他了，還是回去好好反思下你的需求吧?。?/p>

我本身程序員出身，做到技術(shù)總監(jiān)，后來由于業(yè)務(wù)的需要，不得不做產(chǎn)品和運(yùn)營。有過技術(shù)和產(chǎn)品的雙重經(jīng)歷，我能深刻的體會到技術(shù)和產(chǎn)品的矛盾，也更了解如何去化解這個(gè)矛盾。

1、需求分析和描述不到位

程序員在流程的最下游

如上圖所示，程序員處在流程的最底端，產(chǎn)品經(jīng)理跟客戶/用戶/領(lǐng)導(dǎo)溝通的需求，最后傳遞到程序員這里，有可能變了味道。如果產(chǎn)品經(jīng)理把握不好，可能最終結(jié)果跟客戶想要的完全不一樣。等到最終客戶/用戶/領(lǐng)導(dǎo)勃然大怒的時(shí)候，矛盾可能就激發(fā)了。

如何解決？

簡單，一個(gè)杯墊搞定！尼瑪，你咋不放把水果刀呢？

產(chǎn)品經(jīng)理首先要了解業(yè)務(wù)，才能更好的理解需求。如果需求來自客戶，那么一定要明確這個(gè)需求不是最終可用的需求，一定要做需求分析，幫客戶梳理這個(gè)需求，弄清楚客戶提這個(gè)需求的最終目的是什么？

客戶的需求如果是“我要一批更快的馬！”，也許他的目的不是要一匹馬，而是更快的交通工具。產(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é)果可想而知。有時(shí)候程序員加班加點(diǎn)剛做完的東西，產(chǎn)品經(jīng)理說需求變動了，不能這么做，嚴(yán)重的時(shí)候連核心模塊都完全大變樣。就一直這樣改完做，做完改，無限循環(huán)下去。

但是產(chǎn)品經(jīng)理也有怨言，需求變化是正常的啊，老板的想法經(jīng)常變，客戶的需求經(jīng)常變，我有什么辦法？

產(chǎn)品經(jīng)理必須掌握需求管理

需求變化從某種意義上來說是好事，有變化說明有進(jìn)展或者有改進(jìn)，我們不能避免需求變化，但是作為產(chǎn)品經(jīng)理我們要學(xué)會控制需求，對需求進(jìn)行有效的管理。

首先我們要做需求的合理性討論，在這個(gè)階段如果能讓技術(shù)參與，發(fā)表意見，讓他們感到被尊重，對于后期的需求支持是很有幫助的，切莫自己二話不說拍腦袋！確定需求必須要改變以后，我們要合理的管理這個(gè)變化。

產(chǎn)品經(jīng)理必須得有版本的概念，當(dāng)前已經(jīng)開發(fā)的版本內(nèi)盡量不發(fā)生變化，把新的變化規(guī)劃到下一版本；如果實(shí)在必須要在當(dāng)前版本需要變化，那就和技術(shù)溝通工作量和計(jì)劃變更。

要么延長上線時(shí)間，要么替換其他需求任務(wù)，讓需求的變化不影響技術(shù)的工作量和計(jì)劃，技術(shù)又怎么能給你打架呢？

當(dāng)然，由于老板的行政命令和對客戶的承諾，你無法更改計(jì)劃，那怎么辦呢？

還是和程序員做朋友，做兄弟吧，如此也許一頓飯就搞定啦。

3、產(chǎn)品狗不懂程序猿

遇到一個(gè)像我這樣很懂技術(shù)的產(chǎn)品經(jīng)理不容易（有點(diǎn)超自戀O(∩_∩)O），程序員經(jīng)常聽到的一句話就是——“這么簡單的功能為什么要這么長時(shí)間？”

這樣的話令很多程序員惱火，是最能激發(fā)與產(chǎn)品經(jīng)理矛盾的導(dǎo)火索。因?yàn)槟悴欢夹g(shù)，你就和程序猿沒有共同的話題，你就很難站在對方角度上去看這個(gè)問題，你也無法掌控程序猿對工作量的評估是否合理，總是以為他在騙你，如果是這樣的狀態(tài)，又怎么能不產(chǎn)生矛盾呢？

從技術(shù)轉(zhuǎn)到產(chǎn)品的人，本身對技術(shù)了解，可以更好的跟程序員溝通想法，但是一定注意，千萬不要反客為主，不要干涉技術(shù)。之前就碰到一個(gè)曾經(jīng)做過技術(shù)的產(chǎn)品經(jīng)理，對于技術(shù)的方案評頭論足，甚至指導(dǎo)技術(shù)，搞的技術(shù)很郁悶，摔了一句：“既然你這么牛逼，你自己做好了”。

對于不懂技術(shù)的產(chǎn)品經(jīng)理來說，建議要去了解一下基本的技術(shù)知識，不需要太深，但是要知道概念，知道大致的使用場景。別整出像“你是用Java還是SQL開發(fā)”，“Hodoop比你用Java開發(fā)好吧”等這樣的概念性的錯(cuò)誤，讓程序員鄙視，啥都不懂，你還怎么質(zhì)疑人家評估的工作量??！

高山流水，知音難覓！知音不成，至少我懂！只有懂對方，才能在一個(gè)頻道上溝通。

為了做一個(gè)不想挨揍的產(chǎn)品狗，一定要不斷修煉上面說的一些能力。當(dāng)然作為一個(gè)曾經(jīng)的程序員，現(xiàn)在雖做產(chǎn)品但依然領(lǐng)導(dǎo)技術(shù)團(tuán)隊(duì)的我，也有必要給我們的程序員弟弟們點(diǎn)建議：

1. 做好需求變化的準(zhǔn)備，不要排斥變化。要提高代碼的擴(kuò)展性和維護(hù)性，用不變的架構(gòu)應(yīng)對變化的需求。
2. 對需求理解透徹在開始寫代碼，要多和產(chǎn)品經(jīng)理確認(rèn)！我們經(jīng)常碰到最后開發(fā)出來的跟產(chǎn)品經(jīng)理想要的不一樣，就是因?yàn)闆]有理解需求，或者理解有誤，就開始做了。
3. 評估工作量和計(jì)劃時(shí)，一定要預(yù)留修改bug及其他突發(fā)事件的時(shí)間，給自己的工作留有余地。

#專欄作家#

菜根亂譚，微信公眾號：CGLT_TAN，人人都是產(chǎn)品經(jīng)理專欄作家。經(jīng)歷程序員、技術(shù)總監(jiān)等技術(shù)崗位，現(xiàn)在從事掌上醫(yī)訊的產(chǎn)品運(yùn)營和公司發(fā)展。關(guān)注醫(yī)療，早教領(lǐng)域，擅長技術(shù)應(yīng)用型產(chǎn)品的設(shè)計(jì)和運(yùn)營。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Pixabay，基于 CC0 協(xié)議