- 相關(guān)推薦
不要神化產(chǎn)品經(jīng)理
幾乎每個項(xiàng)目都會時間緊、任務(wù)重，在形成快速反映和調(diào)整的團(tuán)隊(duì)之前一定會出現(xiàn)這樣那樣的問題�，F(xiàn)在的項(xiàng)目幾乎都是多工種共同參與才能產(chǎn)出，職責(zé)分工、流程因此很容易成為問題，因?yàn)闀r間緊、任務(wù)重而產(chǎn)生的問題也會很嚴(yán)重。昨天寫了一篇關(guān)于超級產(chǎn)品經(jīng)理的文章，其實(shí)今天要寫的這個東西也和這個有關(guān)。我始終認(rèn)為，每個角色都有話語權(quán)，都不應(yīng)該成為工具，而項(xiàng)目最終的產(chǎn)出一定是所有人智慧的結(jié)晶。而且需要從繁雜的項(xiàng)目管理事務(wù)中把產(chǎn)品經(jīng)理解放出來，讓他們回歸本質(zhì)。
最近遇到一種情況，開發(fā)團(tuán)隊(duì)把開發(fā)過程中的反復(fù)、出現(xiàn)大量的bug等問題的根源歸于需求文檔，希望文檔寫的更詳細(xì)，更確定。測試團(tuán)隊(duì)把bug的反復(fù)、新功能缺乏開發(fā)工程師自測等問題歸于需求文檔，希望文檔寫的更詳細(xì)，更確定�，F(xiàn)在因?yàn)檫�沒有法務(wù)、客服、BD、市場等等其他部門的同事，因此還沒有得到他們的反饋。唯一的欣慰是產(chǎn)品團(tuán)隊(duì)和設(shè)計師、前端工程師的溝通比較頻繁和暢通，因此對方?jīng)]有提及這個問題。在這個問題上我認(rèn)為產(chǎn)品經(jīng)理不是神，需求文檔不是銀彈，軟件工程許多年來的問題通過產(chǎn)品經(jīng)理解決是不可能的，通過需求文檔解決更是不可能的。
對于要求產(chǎn)品經(jīng)理全程跟蹤產(chǎn)品，把握每個細(xì)節(jié)和過程的意見我很贊同，我認(rèn)為，產(chǎn)品經(jīng)理是虛擬團(tuán)隊(duì)的領(lǐng)導(dǎo)者，是項(xiàng)目、產(chǎn)品的CEO。還能有誰更清除產(chǎn)品的所有細(xì)節(jié)?如果產(chǎn)品經(jīng)理不去全程關(guān)注誰回去關(guān)注?管理一個產(chǎn)品就要管理它的方方面面，管理它的前世今生。
對于加強(qiáng)流程的建立，加強(qiáng)評審機(jī)制的意見我也很贊同，流程很重要，多成員、多角色的項(xiàng)目中流程很重要。每個人的思維和意識都是有局限的，每個人的經(jīng)驗(yàn)和能力也是有局限的，我們中間的所有人都不是天才，沒有人可以完全的獨(dú)當(dāng)一面、力挽狂瀾。任何產(chǎn)品都需要不同工種同事的討論、建議甚至是拍磚，這樣才能匯聚大家的智慧，幫助產(chǎn)品經(jīng)理完善產(chǎn)品的細(xì)節(jié)。
對于細(xì)化文檔的意見我也很贊同，文檔很重要，雖然有很多比文檔更重要的東西，但文檔還是很重要。我們的每次思考、每次討論，每次會議、每次變更都要體現(xiàn)在文檔上。我們每個人的腦子都會遺忘，俗話說好記性不如爛筆頭子說的就是這個道理。通過語言的表達(dá)根據(jù)時間、表情、語氣的不同會產(chǎn)生信息傳遞的偏差。產(chǎn)品的復(fù)雜性決定了需求的復(fù)雜性，自身的邏輯性和環(huán)境內(nèi)其他部件之間的關(guān)聯(lián)等內(nèi)容讓我們不得不采用結(jié)構(gòu)化文檔的方式來記錄。文檔在一些時候也可以提高交流的效率，特別是一對多的時候。文檔也可以是一個存檔式的東西，后續(xù)版本的需求變更要依據(jù)它，項(xiàng)目成員更替也需要它。
但產(chǎn)品經(jīng)理不是萬能的，應(yīng)該解放產(chǎn)品經(jīng)理，現(xiàn)實(shí)的情況是產(chǎn)品經(jīng)理要做很多事情，完全和我之前提到的“超級產(chǎn)品經(jīng)理”的情況相反。和管理層溝通，領(lǐng)會公司的策略和方向。和用戶溝通，滿足用戶的需求。和各種角色的同事溝通，領(lǐng)導(dǎo)大家一起出力。關(guān)注公司內(nèi)外的資源，做項(xiàng)目管理，保證資源，保證溝通，保證進(jìn)度，保證結(jié)果�？慨a(chǎn)品經(jīng)理一個人大權(quán)獨(dú)攬，什么都干，顯然是不行的。我覺得靠譜兒的辦法應(yīng)該是有專職的項(xiàng)目經(jīng)理，別以為這個時候項(xiàng)目經(jīng)理會閑得慌，專職的項(xiàng)目經(jīng)理應(yīng)該很忙。而產(chǎn)品經(jīng)理的主要關(guān)注點(diǎn)應(yīng)該回歸到產(chǎn)品要滿足的需求上面，充分考慮和調(diào)研用戶的需求，做充分的數(shù)據(jù)分析和行業(yè)觀測，保證產(chǎn)品路線協(xié)同公司的發(fā)展規(guī)劃。說到底，就是我覺得應(yīng)該解放產(chǎn)品經(jīng)理，不讓他們兼職做項(xiàng)目經(jīng)理的事情。
流程對項(xiàng)目本身也會起到負(fù)面的影響，互聯(lián)網(wǎng)上的應(yīng)用要求快速決策、快速開發(fā)、快速響應(yīng)。要求產(chǎn)品團(tuán)隊(duì)及時調(diào)整、及時變更、及時應(yīng)對。要求技術(shù)團(tuán)隊(duì)做敏捷開發(fā)，做快速響應(yīng)，不斷重構(gòu)。使用快速原型的方式活其他更靈活的方式進(jìn)行迭代式開發(fā)，而不是采用傳統(tǒng)的瀑布式的項(xiàng)目開發(fā)方式。我希望項(xiàng)目團(tuán)隊(duì)中的每個人都是產(chǎn)品經(jīng)理，每種角色都貫穿于產(chǎn)品的生命線。產(chǎn)品經(jīng)理只是個“主事兒”的而已，產(chǎn)品經(jīng)理決定做什么，其他角色決定怎么做。
文檔是問題的一部分而不是解決問題的一部分，寫文檔只占產(chǎn)品經(jīng)理工作的很小一部分，產(chǎn)品經(jīng)理更多的工作是在思考和溝通。一個產(chǎn)品從無到有，在產(chǎn)品經(jīng)理的腦海中逐漸成型，經(jīng)過和不同角色人員的溝通不斷的完善，最終通過撰寫的文檔體現(xiàn)出來。撰寫文檔相對簡單，占用的人力資源也少。這就像系統(tǒng)設(shè)計往往需要較多的時間，具體編碼的時間相對較少。
靠產(chǎn)品經(jīng)理來試圖解決軟件工程這么多年的問題是不可能的，產(chǎn)品經(jīng)理撰寫的需求文檔無法解決項(xiàng)目延期的問題、無法解決軟件維護(hù)復(fù)雜的問題，無法解決成本過高的問題。難道產(chǎn)品經(jīng)理寫個80頁的詳細(xì)需求文檔就可以放假回家了碼?產(chǎn)品就可以完美開發(fā)了?用戶就喜歡了?公司就掙到錢了?其實(shí)文字只是溝通方式的一種而已，要充分利用這種溝通方式但也不能過于依賴。產(chǎn)品經(jīng)理要寫多少文檔才可以?市場需求文檔、產(chǎn)品需求文檔，會議紀(jì)要，方案，策劃，規(guī)范，文檔文檔還是文檔!產(chǎn)生更多的文檔肯定不能更好的解決問題，達(dá)成項(xiàng)目的目標(biāo)。
我相信寫個80頁的文檔不會有幾個人會仔細(xì)的看，那么這個文檔給誰看?給領(lǐng)導(dǎo)看?給開發(fā)工程師看?給設(shè)計看?給前端工程師看?給客服看的?給法務(wù)看的?給商務(wù)看的?給市場看的?他們要看的、能理解的東西一致嗎?產(chǎn)品經(jīng)理寫的需求文檔能滿足所有的需求嗎?一定不能滿足。這時候就需要短平快的去通過各種方式去溝通，包括文字、圖像和語言。
另外就是我一直堅持的一個觀念，產(chǎn)品經(jīng)理的人力資源無法預(yù)估!開發(fā)可以根據(jù)產(chǎn)品需求文檔預(yù)估，根據(jù)頁面數(shù)、產(chǎn)品復(fù)雜程度、安全級別等內(nèi)容進(jìn)行人力預(yù)估，測試可以以開發(fā)時間的一半來預(yù)估。但產(chǎn)品經(jīng)理的工作如何預(yù)估?答案是沒有人可以預(yù)估。但現(xiàn)實(shí)是領(lǐng)導(dǎo)總會對產(chǎn)品經(jīng)理的人力資源做預(yù)估，或者產(chǎn)品經(jīng)理迫于某些壓力自己做人力資源的預(yù)估。這樣的情況很普遍，但是需要改變，給產(chǎn)品經(jīng)理一個相對寬松的環(huán)境來工作。
【不要神化產(chǎn)品經(jīng)理】相關(guān)文章：
產(chǎn)品經(jīng)理總結(jié)范文06-29
產(chǎn)品經(jīng)理述職報告06-09
校招產(chǎn)品經(jīng)理和產(chǎn)品經(jīng)理跟你的認(rèn)知有區(qū)別么？07-11
產(chǎn)品經(jīng)理需要具備的特質(zhì)07-10
產(chǎn)品總監(jiān)對產(chǎn)品不熟又不采納產(chǎn)品經(jīng)理建議怎么辦？07-11