產品專案管理全書

 

產品管理類別的書籍中，這是我最推薦的一本「入門」書。

雖說「入門」，但內容又不僅只入門，值得反覆閱讀和做為實務上的參考。

我認為一本好的純商業類別書籍，必須能清楚說明方向，又有足夠的行動指引，讓閱讀者能在心領神會之餘，還能考量自身面對的狀況而有的後續行動。這大概不知道提幾次了XD

作為一本入門的「全書」，談的內容有一定的廣度，包含了角色職責、流程設計、團隊運作和管理文化等內容。即使如此，不少的篇章都有足夠的內容說明WHY、WHAT和HOW這三個重要問題來支持實務的行動指引，不全然為蜻蜓點水，騷不到癢處(當然詳細內容，特別是執行操作還是需尋他路)。

近年的經驗一直在財管的專案和系統管理打轉，直到去年開始涉入業務轉型的設計和推動，又在年尾時開始專注於打造相關的系統/功能來協助轉型後的業務運作和管理。書的內容有些應證了經驗、有些則是修正了原本的想法。這篇想提一個我很有感也遭遇過，超級常見的錯誤。

「打造產品時，產品經理提供需求予工程師評估，然後不斷地迭迨衝刺，敏捷開發」

這種做法局限了解決方案的設計，而在花費時間規畫後，才將需求給工程師做可行性評估，更讓來回討論重新設計的風險大增，也因為往往會有上線時程壓力(早已在高層次的時程評估時對高管做了承諾)只能從中取捨和妥協，最終交付的是趕上架的作品。更精確地說，這樣充其量只是敏捷交付，而不是敏捷開發。

而真正好的做法其實是

「整個產品探索與交付的過程中，工程師在一開始就已經加入」

說起來輕鬆，但為什麼錯誤如此常見？

因為這其實有點反直覺，所以執行起來往往會有障礙。

組織內的每個人都有各自的角色和職責，業務負責銷售和維繫客戶關係、行銷人員負責廣告宣傳、產品經理負責產品規劃與最終成敗、工程師負責寫程式。這些都是習以為常的事情。

而現在你讓工程師一起參與規劃？  這豈不是浪費時間不務正業!對寫程式打造產品又沒有幫助!!!

正是因為這樣的習以為常和僵固，使得大家總是困惑，執行總有困難。

當從每個角色的主要職責出發，思考承擔的責任和價值時，我們會發現這並不衝突。

也因為一開始就涉入其中，使得解決方案有了更多的可能，時程和可行性的評估也更準確，團隊從一開始就處理這些重要風險，並在環境限制下做更好的規劃，而不是等到開發階段又需要進一步處理。這些都讓時間、成本和產品有了最好的平衡，企業資源的應用有最高的效益。

另一個讓我推薦的原因，或許是從中又獲知了三本好書，能進一步補充產品開發管理的實務知識和做法。未來有機會再繼續分享。