產(chǎn)品經(jīng)理，別這樣行嗎？

一直以來，產(chǎn)品經(jīng)理與程序員之間就像是水與火般難以相融。許多初入社會的年輕開發(fā)，估計都曾動過要跟產(chǎn)品經(jīng)理打一架的念想。

但這種壞念頭一定只能壓抑在心底，不然會被產(chǎn)品經(jīng)理們通過一系列抓手對需求的底層邏輯的論證，同時結(jié)合產(chǎn)品思維、用戶意識以及培養(yǎng)心智等概念上的組合拳，直接拉通對齊你的直屬領(lǐng)導，從而將具體問題抽象成不同顆粒度的方法論，進行形成辯證閉環(huán)，說得你手無縛雞之力。初入職場的我，也經(jīng)歷過數(shù)次想要與產(chǎn)品經(jīng)理唇槍舌戰(zhàn)的大場面，想要與之辯證唯物主義，不醉方休。后來想了想，還是不至于、沒必要、莫生氣。于是今天在這里總結(jié)幾點程序員眼中最討厭的七大產(chǎn)品行徑。

1 需求文檔不完善

俗話說的好，代碼未敲，文檔先行。這意味著研發(fā)的代碼并不是無中生有，而是圍繞著需求文檔來進行設計和實現(xiàn)。特別是以業(yè)務為主的技術(shù)團隊。

在這個過程中，研發(fā)與產(chǎn)品經(jīng)理交戰(zhàn)的第一個場地便是需求文檔，一個充滿了硝煙和孤魂野鬼的戰(zhàn)場。

一個好的產(chǎn)品經(jīng)理的基礎(chǔ)就應該能夠產(chǎn)出完善且細致的需求文檔，能夠?qū)⑿枨蟮谋尘澳康囊约案倪M細節(jié)都描述的恰到好處，同時在產(chǎn)品維度上能夠提出關(guān)鍵性兜底或兼容方案。

盡可能的將需求改動的重點描述清楚，降低不同角色的理解成本，能夠讓研發(fā)圍繞著這一份文檔來進行技術(shù)設計，這樣的文檔或許才稱得上完善。

但是實際上許多產(chǎn)品的文檔并不盡如意，要么完全沉溺在自己的表達中，讓人抓不住重點；要么大篇大論，或苛求一些并不核心的細節(jié)點。

一旦遇到這樣的需求文檔，通常意味著需要永無止境的確認、爭論以及成本取舍。最終影響的就是開發(fā)流程中負責每個節(jié)點的負責人的體驗。

可能有些人會覺得產(chǎn)品提出的需求文檔就是要跟開發(fā)一起討論才能得出最終的完善版本。我覺得這種觀點完全就是產(chǎn)品不負責任的表現(xiàn)，可以根據(jù)需求文檔來進行更深層次的討論。

但是前提一定是文檔是完善的，是需要產(chǎn)品經(jīng)理事先站在產(chǎn)品的維度上進行過思考和沉淀。而不是依賴別人來幫忙查漏補缺。

2 需求進行反復變更

這一點相信是讓所有參與需求推進的人員都最為惡心的事情。在我眼中，需求變更的程度與產(chǎn)品經(jīng)理的能力直接掛鉤。

很多時候，經(jīng)常性的需求已然進入開發(fā)階段，甚至是臨近開發(fā)完成時，產(chǎn)品經(jīng)理總是陰差陽錯的發(fā)現(xiàn)了某些功能或改動的不合理性，從而肆意發(fā)起需求變更，甚至是需求反復變更。

需求的反復變更不僅影響的是整體需求推進效率，還有可能會導致開發(fā)質(zhì)量降低以及多方協(xié)作不對齊的問題。說起來可能只是工作量的問題，但其實影響面十分廣泛。

站在開發(fā)的視角，我覺得作為一個成熟的產(chǎn)品經(jīng)理，就應該在開發(fā)介入前或者開發(fā)前期能夠?qū)⑺行枨簏c都確認下來，并且能夠打通各方都質(zhì)疑以及資源支持，不該想到一茬是一茬。

我見過很多產(chǎn)品經(jīng)常受不了別人的質(zhì)疑，一旦聽到有質(zhì)疑的聲音，就會去變更需求以避免爭議。這種的行為實在是無力吐槽。

3 對需求缺乏關(guān)注度

這一點或許跟個人的責任心直接掛鉤。對需求缺乏關(guān)注度，意味著產(chǎn)品經(jīng)理在需求上線甚至需求進入開發(fā)階段后，就不再關(guān)注需求進展。甚至是產(chǎn)出需求文檔后，就像已經(jīng)完成了任務一樣。

許多產(chǎn)品經(jīng)理往往會同步跟進多個需求，每個需求可能都會對接不同的開發(fā)人員。因而當需求較多時就會忽視掉某些需求的關(guān)注度。

我見過挺多產(chǎn)品經(jīng)理在完善好產(chǎn)品文檔后，或者是推進完需求評審之后，便不怎么管需求開發(fā)的進展了。當遇到一些需要溝通兜底策略或者取舍方案時，積極性都不高。

這應該也是最讓研發(fā)人員頭疼的一件事。

4 不考慮工程成本

「這個做不了」想必絕對是程序員的口頭禪之一。

很多時候產(chǎn)品經(jīng)理找過來，說要實現(xiàn)某個需求時，我們都會禮貌的回復他，這個做不了。

很顯然，這并不是我們開發(fā)好逸惡勞想要偷懶的行為，而是很多時候，基于工程現(xiàn)狀以及技術(shù)成本，的確沒辦法實現(xiàn)某些功能。

所以每當產(chǎn)品提出這樣的改動，我們都會很頭疼。當我們明確說明的確在技術(shù)上實現(xiàn)不了的時候，可能還會引起產(chǎn)品的不滿。

很多時候我們都在說，技術(shù)是為業(yè)務服務的，脫離業(yè)務的架構(gòu)也是沒有意義的。

但是事實上很多時候技術(shù)的現(xiàn)狀就是沒辦法滿足產(chǎn)品的天馬行空。所以產(chǎn)品并不是一昧的為達到自己的目的而不考慮技術(shù)現(xiàn)狀和工程成本。

5 壓縮需求排期

一般在大廠，都是遵循所謂「重流程，輕人情」的規(guī)則。也就是說，在項目或者需求開發(fā)過程中，更多是以流程規(guī)則為準，包括研發(fā)階段的各個節(jié)點，比如需求評審、技術(shù)評審以及開發(fā)估時排期等。

項目實際需要的開發(fā)時間是通過對工程的現(xiàn)狀調(diào)研以及實現(xiàn)成本來綜合考量的，而不是領(lǐng)導或者產(chǎn)品經(jīng)理強行給出的開發(fā)周期。

當然這只是最理想的情況，大廠之所以內(nèi)卷這么嚴重，很大程度還是因為有些職能并不能遵守流程規(guī)則。

產(chǎn)品經(jīng)理可能在節(jié)假日來臨，或者與競品賽馬時，總是會突破流程規(guī)則的限制，瘋狂擠壓項目或需求的排期。

這就導致本來需要一個月開發(fā)量的改動被壓縮成兩周甚至一周，這造成的結(jié)果就是人員的工作壓力驟增，開發(fā)體驗驟降，以及工程項目的逐漸「屎山化」。

盲目追求熱點，應對節(jié)假日缺乏提前規(guī)劃，只著重于產(chǎn)品競爭，這些問題都會導致開發(fā)流程的形同虛設，造成產(chǎn)品經(jīng)理為了上需求而肆意妄為。

6 強行堆砌實驗變量

對于一個大型的產(chǎn)品而言，往往會采取AB實驗的方式來驗證新增特性是否滿足用戶需求。

AB實驗本質(zhì)上就是初中生物化學里學的設置對照組和實驗組。然后通過控制變量法來驗證某一個改動是否存在收益。

本身用這種方式來驗證需求的價值性無可厚非，但是很多時候控制變量會被濫用。

比如想驗證一個對用戶來說體驗最好的按鈕顏色，那么在做AB實驗時，唯一的變量就是按鈕的顏色，然后不同的顏色就可以作為不同的實驗組。最終看哪個實驗組的數(shù)據(jù)最好就能夠回收結(jié)論。

但是顏色數(shù)量那么多，該怎么去選取呢？缺乏產(chǎn)品設計經(jīng)驗的產(chǎn)品經(jīng)理估計可能就會盡可能羅列所有的顏色來驗證，而缺乏自己的判斷和篩選。

這實際上是一個很常見的問題，產(chǎn)品往往因為自己也摸不清楚用戶想要的東西，于是在需求開發(fā)中會選擇堆砌或者排列組合所有實驗變量。

看起來沒什么毛病，但是過多的實驗組合會導致開發(fā)復雜度變高，同時也嚴重影響業(yè)務代碼的邏輯和架構(gòu)。

所以我認為一個好的產(chǎn)品經(jīng)理應該能夠在排列組合的實驗變量中有自己出于產(chǎn)品調(diào)性和用戶理解的判斷，篩選出真正值得去實驗的變量組合。這樣才能凈利益最大化。

7 忽略體驗，數(shù)據(jù)為王

產(chǎn)品經(jīng)理是一個偏感性以及藝術(shù)性的崗位，但是在產(chǎn)品快速迭代的過程中，卻沒辦法從感性和藝術(shù)性的角度來衡量產(chǎn)品的價值。

于是在實際的需求迭代過程，會引入理性的量化標準來衡量產(chǎn)品的發(fā)展水平。比如我們熟知的DAU，MAU等等。

漸漸的，許多需求提出的目的可能就是為了提升某項指標，而評估某個改動是否有價值的標準也是看其對于核心指標是否有影響。

時間一長，就會陷入數(shù)據(jù)的陷阱。

某些改動有些需求，可能最終實驗的結(jié)果在指標上有很好的提升，但是可能并不是一個好的產(chǎn)品體驗。

數(shù)據(jù)本身就是將歷史量化所作出的歸納和整理，并沒有辦法完全代表或預測未來。所以數(shù)據(jù)只能作為一個先驗參考，卻不能完全作為一個標準。

我們都說好的產(chǎn)品經(jīng)理往往都是極為克制的，好的想法有很多，但是真正有價值并且值得讓人接受的卻并不多。

雖然說產(chǎn)品經(jīng)理在廣大程序員中并不是一個十分討喜的角色，但是吐槽歸吐槽。很多時候產(chǎn)研矛盾還是很大程度上取決于個人的能力和做事水平。

事實上，在很久之前，當我還在上大一的時候，就差點成為了一名產(chǎn)品經(jīng)理。當時是學校的一個創(chuàng)新團隊在招新，連C語言都沒學過的我就去參加了面試。但是我并不清楚每個崗位之間的差別。

直到我注意到產(chǎn)品經(jīng)理這個崗位，「這聽起來就是個經(jīng)理，是個大官，說不定是管程序員的那種」。

于是我便充滿期待的應聘了產(chǎn)品經(jīng)理崗位。不過最后終面并沒有通過，不然現(xiàn)在可能會成就另一番人生了。

說到底，作為在整個項目流程中最為重要的一個角色，產(chǎn)品經(jīng)理的工作能力會很大程度上決定項目的整體進展。

希望在與產(chǎn)品的合作協(xié)作過程中，少一點套路，多一點真誠；少一分苛責，多一分責任。