產品經理的使用手冊：一個好 PM 要做些什麼？會為團隊帶來哪些價值？

自從轉職當產品經理後，陸續聽到不少周圍的朋友抱怨他們公司的 PM 有多雷、多廢、多會扯後腿：設計師朋友覺得 PM 只會丟需求，連個 user story 和商業目標都講不清楚；工程師朋友抱怨 PM 不懂技術，每次客戶有問題，都還是得由工程人員出面解釋。就連自己先前待過的幾家公司換了新 PM，至今仍能透過各種管道耳聞新 PM 多不會寫 PRD、不懂得判斷優先序，只會透過頭銜壓時程。到底是雷 PM 太多，還是上述這些純屬特例，又或者是好 PM 真的太難當？

寫軟體技術文件有哪些可遵循的原則？注意 4 個重點，幫助你寫出一份好閱讀的產品 / 技術文件

每一個職業都有值得學習的地方。在軟體開發產業，工程師將寫高品質的程式碼技術傳授給其他人的秘訣，是經常總結可遵循的「哲學」與「原則」。但多數人只看到工程師打著複雜指令的一面，卻沒看到軟體設計背後的巧妙思維。

拯救失控專案：談管理機制導入前必要的診斷

某天其他部門的同事跑來詢問我 : 「聽說你們的專案執行得不錯，可以給我們WBS參考嗎?」起初我有點一頭霧水，一問之下才知道原來是主管的指示，要他們前來取經，而且特別指名要看WBS。據我所知，他們的專案範疇大、協作單位多，一直以來是個燙手山芋，卻又是公司轉型階段不得不執行的任務。雖然和我之前的專案有些相似之處，但畢竟團隊不同，產品的屬性也有差異，想用同一招打天下頗有難度，於是我開始思考，專案管理強調的Lessons Learned ( 經驗傳承 ) 精神，要如何落實? 

新任PMO主管該做的三件事（上）

PMO在這幾年其實變成一個新鮮的議題。我身邊還滿多讀者或是朋友，因為公司突然決定要成立一個PMO，而被長官指派要負責這部門的營運。可是因為公司過往從沒做過類似的事情，專案管理在目前又還不像會計有法規上面的要求，所以任何的開展方式好似都說得通：好像什麼都能做、又好像什麼都不能做。若負責PMO的人政治敏感度不夠，缺乏組織變革所需要的知識與經驗，很可能花了很多心力卻碰到大家的抗拒。抗拒下做不出結果，慢慢老闆對此就失去興趣，最後往往就變成一個被冷凍的部門了。

為何某些PMO會夭折？

我在這裡打算分享的，是想很務實地告訴大家一些你在別處不會看到的「小建議」——哪些事情會讓你迅速搞爛這個部門；如果你剛巧接手或是即將接手這樣一個部門，又不希望自己做錯事情，那你實在該好好看完這一篇！ 

你需要一些志同道合的朋友

這篇是針對「PM的成長途徑」所發表的第十篇文章。 到此為止，我提出的建議包含從熟讀專案管理知識、培養工具應用及動態排程能力、歷史資料累積、軟實力的培養，還有專案經歷的增加等事項。 最後這一篇，則建議大家若想要在專案管理這領域走得久，你不能只靠自己奮鬥。 並不是只要自己懂很多知識、念很多書、考很多證照，就能在這領域闖出一片天。 因為管理的效果，其實必須得是一種「眾人的共識」。 唯有很多人理解管理手法，用相同的方式行事，價值才會倍增。

擴大你的專案視野

我在專案管理雜誌之前寫了八篇文章，談的都是PM的「成長途徑」。 在那些文章中，我有建議大家除了PMBOK中的知識外，也該學習一些其他的知識，包含以軟體排程分析、規劃控制、以及舉證的能力，此外歷史資料的累積，還有軟性技能的培養也很重要。