不要神化產品經理
幾乎每個項目都會時間緊、任務重,在形成快速反映和調整的團隊之前一定會出現這樣那樣的問題。現在的項目幾乎都是多工種共同參與才能產出,職責分工、流程因此很容易成為問題,因為時間緊、任務重而產生的問題也會很嚴重。昨天寫了一篇關於超級產品經理的文章,其實今天要寫的這個東西也和這個有關。我始終認為,每個角色都有話語權,都不應該成為工具,而項目最終的產出一定是所有人智慧的結晶。而且需要從繁雜的項目管理事務中把產品經理解放出來,讓他們迴歸本質。
最近遇到一種情況,開發團隊把開發過程中的反覆、出現大量的bug等問題的根源歸於需求文檔,希望文檔寫的更詳細,更確定。測試團隊把bug的反覆、新功能缺乏開發工程師自測等問題歸於需求文檔,希望文檔寫的更詳細,更確定。現在因為還沒有法務、客服、BD、市場等等其他部門的同事,因此還沒有得到他們的反饋。唯一的欣慰是產品團隊和設計師、前端工程師的溝通比較頻繁和暢通,因此對方沒有提及這個問題。在這個問題上我認為產品經理不是神,需求文檔不是銀彈,軟件工程許多年來的問題通過產品經理解決是不可能的,通過需求文檔解決更是不可能的。
對於要求產品經理全程跟蹤產品,把握每個細節和過程的意見我很贊同,我認為,產品經理是虛擬團隊的領導者,是項目、產品的CEO。還能有誰更清除產品的所有細節?如果產品經理不去全程關注誰回去關注?管理一個產品就要管理它的方方面面,管理它的前世今生。
對於加強流程的建立,加強評審機制的意見我也很贊同,流程很重要,多成員、多角色的項目中流程很重要。每個人的思維和意識都是有侷限的,每個人的經驗和能力也是有侷限的,我們中間的所有人都不是天才,沒有人可以完全的獨當一面、力挽狂瀾。任何產品都需要不同工種同事的討論、建議甚至是拍磚,這樣才能匯聚大家的智慧,幫助產品經理完善產品的細節。
對於細化文檔的意見我也很贊同,文檔很重要,雖然有很多比文檔更重要的東西,但文檔還是很重要。我們的每次思考、每次討論,每次會議、每次變更都要體現在文檔上。我們每個人的腦子都會遺忘,俗話説好記性不如爛筆頭子説的就是這個道理。通過語言的表達根據時間、表情、語氣的不同會產生信息傳遞的偏差。產品的複雜性決定了需求的複雜性,自身的邏輯性和環境內其他部件之間的關聯等內容讓我們不得不採用結構化文檔的方式來記錄。文檔在一些時候也可以提高交流的效率,特別是一對多的時候。文檔也可以是一個存檔式的東西,後續版本的需求變更要依據它,項目成員更替也需要它。
但產品經理不是萬能的,應該解放產品經理,現實的情況是產品經理要做很多事情,完全和我之前提到的“超級產品經理”的情況相反。和管理層溝通,領會公司的策略和方向。和用户溝通,滿足用户的需求。和各種角色的同事溝通,領導大家一起出力。關注公司內外的資源,做項目管理,保證資源,保證溝通,保證進度,保證結果。靠產品經理一個人大權獨攬,什麼都幹,顯然是不行的。我覺得靠譜兒的辦法應該是有專職的項目經理,別以為這個時候項目經理會閒得慌,專職的項目經理應該很忙。而產品經理的主要關注點應該回歸到產品要滿足的需求上面,充分考慮和調研用户的需求,做充分的數據分析和行業觀測,保證產品路線協同公司的發展規劃。説到底,就是我覺得應該解放產品經理,不讓他們兼職做項目經理的事情。
流程對項目本身也會起到負面的'影響,互聯網上的應用要求快速決策、快速開發、快速響應。要求產品團隊及時調整、及時變更、及時應對。要求技術團隊做敏捷開發,做快速響應,不斷重構。使用快速原型的方式活其他更靈活的方式進行迭代式開發,而不是採用傳統的瀑布式的項目開發方式。我希望項目團隊中的每個人都是產品經理,每種角色都貫穿於產品的生命線。產品經理只是個“主事兒”的而已,產品經理決定做什麼,其他角色決定怎麼做。
文檔是問題的一部分而不是解決問題的一部分,寫文檔只佔產品經理工作的很小一部分,產品經理更多的工作是在思考和溝通。一個產品從無到有,在產品經理的腦海中逐漸成型,經過和不同角色人員的溝通不斷的完善,最終通過撰寫的文檔體現出來。撰寫文檔相對簡單,佔用的人力資源也少。這就像系統設計往往需要較多的時間,具體編碼的時間相對較少。
靠產品經理來試圖解決軟件工程這麼多年的問題是不可能的,產品經理撰寫的需求文檔無法解決項目延期的問題、無法解決軟件維護複雜的問題,無法解決成本過高的問題。難道產品經理寫個80頁的詳細需求文檔就可以放假回家了碼?產品就可以完美開發了?用户就喜歡了?公司就掙到錢了?其實文字只是溝通方式的一種而已,要充分利用這種溝通方式但也不能過於依賴。產品經理要寫多少文檔才可以?市場需求文檔、產品需求文檔,會議紀要,方案,策劃,規範,文檔文檔還是文檔!產生更多的文檔肯定不能更好的解決問題,達成項目的目標。
我相信寫個80頁的文檔不會有幾個人會仔細的看,那麼這個文檔給誰看?給領導看?給開發工程師看?給設計看?給前端工程師看?給客服看的?給法務看的?給商務看的?給市場看的?他們要看的、能理解的東西一致嗎?產品經理寫的需求文檔能滿足所有的需求嗎?一定不能滿足。這時候就需要短平快的去通過各種方式去溝通,包括文字、圖像和語言。
另外就是我一直堅持的一個觀念,產品經理的人力資源無法預估!開發可以根據產品需求文檔預估,根據頁面數、產品複雜程度、安全級別等內容進行人力預估,測試可以以開發時間的一半來預估。但產品經理的工作如何預估?答案是沒有人可以預估。但現實是領導總會對產品經理的人力資源做預估,或者產品經理迫於某些壓力自己做人力資源的預估。這樣的情況很普遍,但是需要改變,給產品經理一個相對寬鬆的環境來工作。
相關文章
-
產品總監對產品不熟又不採納產品經理建議怎麼辦?
對於這樣的產品總監,怎麼對付呢?難道只能畫圈圈詛咒他嗎?沒有數據的情況下,靠什麼來支撐自己的理論呢?眼看着產品越來越爛,快被這廝整瘋了。總監最近準備更改的一個頁面是這樣的:1,頁面內超鏈接文字和普通文字一個顏色;2,目 -
產品經理到底要不要懂技術?
[導讀]我不是做產品的,只是對產品設計頗有興趣,所以個人並不代表產品經理的立場;我是技術出身,但不熱衷技術,所以也不能代表研發工程師的立場。我所説的可能會比較中立,也可能帶有極強的個人偏見,不過我也只是個無知無畏的 -
不以盈利為目的的產品經理不是好產品經理
下個星期是新生考試,每個同學都要考,這也將會選出我們的學霸。我感覺這個班的同學很好,不懂就問,可就對這位學霸,誰都不願意去請教她問題,剛開始我以為這個班的學生很好,不懂就問,後來我漸漸發現了她們非常注重外表,甚至還欺負 -
你不得不看的九大產品經理把脈產品運營的心得
產品的生命週期內產品經理/運營經理在不斷的思索、分析、定位產品的目標用户羣,哪些才是產品的真正用户。通常,一個產品要經歷市場調研、需求分析、產品設計、產品開發、產品上線運營到產品優化的過程,而整個過程都是在 -
產品經理與項目經理的不同
有一句話説的很精闢:產品經理靠想。產品經理是做正確的事,其所領導的產品是否符合市場的需求,是否能給公司帶來利潤的。項目經理靠做。項目經理是把事情做正確,把事情作得完美,在時間,成本和資源約束的條件下完成目標。從管 -
騰訊資深產品經理對產品經理團隊管理的看法
做團隊管理和做業務不同,特別是面對一羣高智商高素質的產品經理,需要一些策略和耐心;這期間也有一些感悟,也簡單整理沉澱一下,有8個點吧,在內部團隊經常講,這裏簡單刪減處理後分享一下 :1. 將員工個人能力成長與團隊業績發展 -
產品的不同階段,產品經理的角色及職責
市場研究:組織對所負責產品的市場調研,跟蹤並研究相關產品用户需求,收集和分析競爭對手信息,研究其發展動態和和行業動態,並提出市場研究成果報告;根據公司產品戰略,對產品市場進行細分,選取目標細分市場,確定產品定位;組織制 -
產品經理需要和技術解釋產品的未來需求嗎?
最開始的時候我習慣跟技術講清產品的來龍去脈,需求是怎麼來的,以及未來有可能會上什麼樣的功能。可那時候程序總是很不耐煩,不願意聽,只關心當前要做什麼。因為產品未來的需求確實是多變和不確定的,所以我也就逐漸適應了技 -
你不得不看的產品經理技能篇
產品經理技能篇1、產品經理需求技能產品經理的需求技能,包含需求獲取、需求篩選、需求分析、需求執行,這一系列過程是對產品經理綜合素質的一個考驗和全面衡量。如:對知識的要求,對行業市場的理解和經驗。而且在這整個過 -
《人人都是產品經理》一書,為什麼成了產品經理的入門聖經?
《人人都是產品經理》一書,幾乎成了產品經理的入門聖經。現在經過歲月洗禮時間沉澱,您回頭看您當時寫的這本書,您會做哪些方面的補充?會做哪些方面的修正?又會做哪些方面的修正?為什麼?謝謝您!《人人都是產品經理》由阿里巴