不要神化產品經理

幾乎每個項目都會時間緊、任務重，在形成快速反映和調整的團隊之前一定會出現這樣那樣的問題。現在的項目幾乎都是多工種共同參與才能產出，職責分工、流程因此很容易成為問題，因為時間緊、任務重而產生的問題也會很嚴重。昨天寫了一篇關於超級產品經理的文章，其實今天要寫的這個東西也和這個有關。我始終認為，每個角色都有話語權，都不應該成為工具，而項目最終的產出一定是所有人智慧的結晶。而且需要從繁雜的項目管理事務中把產品經理解放出來，讓他們迴歸本質。

最近遇到一種情況，開發團隊把開發過程中的反覆、出現大量的bug等問題的根源歸於需求文檔，希望文檔寫的更詳細，更確定。測試團隊把bug的反覆、新功能缺乏開發工程師自測等問題歸於需求文檔，希望文檔寫的更詳細，更確定。現在因為還沒有法務、客服、BD、市場等等其他部門的同事，因此還沒有得到他們的反饋。唯一的欣慰是產品團隊和設計師、前端工程師的溝通比較頻繁和暢通，因此對方沒有提及這個問題。在這個問題上我認為產品經理不是神，需求文檔不是銀彈，軟件工程許多年來的問題通過產品經理解決是不可能的，通過需求文檔解決更是不可能的。

對於要求產品經理全程跟蹤產品，把握每個細節和過程的意見我很贊同，我認為，產品經理是虛擬團隊的領導者，是項目、產品的CEO。還能有誰更清除產品的所有細節?如果產品經理不去全程關注誰回去關注?管理一個產品就要管理它的方方面面，管理它的前世今生。

對於加強流程的建立，加強評審機制的意見我也很贊同，流程很重要，多成員、多角色的項目中流程很重要。每個人的思維和意識都是有侷限的，每個人的經驗和能力也是有侷限的，我們中間的所有人都不是天才，沒有人可以完全的獨當一面、力挽狂瀾。任何產品都需要不同工種同事的討論、建議甚至是拍磚，這樣才能匯聚大家的智慧，幫助產品經理完善產品的細節。

對於細化文檔的意見我也很贊同，文檔很重要，雖然有很多比文檔更重要的東西，但文檔還是很重要。我們的每次思考、每次討論，每次會議、每次變更都要體現在文檔上。我們每個人的腦子都會遺忘，俗話説好記性不如爛筆頭子説的就是這個道理。通過語言的表達根據時間、表情、語氣的不同會產生信息傳遞的偏差。產品的複雜性決定了需求的複雜性，自身的邏輯性和環境內其他部件之間的關聯等內容讓我們不得不採用結構化文檔的方式來記錄。文檔在一些時候也可以提高交流的效率，特別是一對多的時候。文檔也可以是一個存檔式的東西，後續版本的需求變更要依據它，項目成員更替也需要它。

但產品經理不是萬能的，應該解放產品經理，現實的情況是產品經理要做很多事情，完全和我之前提到的“超級產品經理”的情況相反。和管理層溝通，領會公司的策略和方向。和用户溝通，滿足用户的需求。和各種角色的同事溝通，領導大家一起出力。關注公司內外的資源，做項目管理，保證資源，保證溝通，保證進度，保證結果。靠產品經理一個人大權獨攬，什麼都幹，顯然是不行的。我覺得靠譜兒的辦法應該是有專職的項目經理，別以為這個時候項目經理會閒得慌，專職的項目經理應該很忙。而產品經理的主要關注點應該回歸到產品要滿足的需求上面，充分考慮和調研用户的需求，做充分的數據分析和行業觀測，保證產品路線協同公司的發展規劃。説到底，就是我覺得應該解放產品經理，不讓他們兼職做項目經理的事情。

流程對項目本身也會起到負面的'影響，互聯網上的應用要求快速決策、快速開發、快速響應。要求產品團隊及時調整、及時變更、及時應對。要求技術團隊做敏捷開發，做快速響應，不斷重構。使用快速原型的方式活其他更靈活的方式進行迭代式開發，而不是採用傳統的瀑布式的項目開發方式。我希望項目團隊中的每個人都是產品經理，每種角色都貫穿於產品的生命線。產品經理只是個“主事兒”的而已，產品經理決定做什麼，其他角色決定怎麼做。

文檔是問題的一部分而不是解決問題的一部分，寫文檔只佔產品經理工作的很小一部分，產品經理更多的工作是在思考和溝通。一個產品從無到有，在產品經理的腦海中逐漸成型，經過和不同角色人員的溝通不斷的完善，最終通過撰寫的文檔體現出來。撰寫文檔相對簡單，佔用的人力資源也少。這就像系統設計往往需要較多的時間，具體編碼的時間相對較少。

靠產品經理來試圖解決軟件工程這麼多年的問題是不可能的，產品經理撰寫的需求文檔無法解決項目延期的問題、無法解決軟件維護複雜的問題，無法解決成本過高的問題。難道產品經理寫個80頁的詳細需求文檔就可以放假回家了碼?產品就可以完美開發了?用户就喜歡了?公司就掙到錢了?其實文字只是溝通方式的一種而已，要充分利用這種溝通方式但也不能過於依賴。產品經理要寫多少文檔才可以?市場需求文檔、產品需求文檔，會議紀要，方案，策劃，規範，文檔文檔還是文檔!產生更多的文檔肯定不能更好的解決問題，達成項目的目標。

我相信寫個80頁的文檔不會有幾個人會仔細的看，那麼這個文檔給誰看?給領導看?給開發工程師看?給設計看?給前端工程師看?給客服看的?給法務看的?給商務看的?給市場看的?他們要看的、能理解的東西一致嗎?產品經理寫的需求文檔能滿足所有的需求嗎?一定不能滿足。這時候就需要短平快的去通過各種方式去溝通，包括文字、圖像和語言。

另外就是我一直堅持的一個觀念，產品經理的人力資源無法預估!開發可以根據產品需求文檔預估，根據頁面數、產品複雜程度、安全級別等內容進行人力預估，測試可以以開發時間的一半來預估。但產品經理的工作如何預估?答案是沒有人可以預估。但現實是領導總會對產品經理的人力資源做預估，或者產品經理迫於某些壓力自己做人力資源的預估。這樣的情況很普遍，但是需要改變，給產品經理一個相對寬鬆的環境來工作。