新手 PM 的建議書單

 A：[ 要如何成為專業的PM ]
我：[ Say NO ]
 A：[ 這好難喔 ]
我：[ 要如何成為優秀的 PM - Say FUCK YOU ]
 A：[ 靠北，這麼硬歐 ]
我：[ 是蠻硬的，因為要如何成為失業的 PM 也是 Say NO 跟 say FUCK YOU ]



這是上個禮拜，有個當兵時的"學長"，但實際上年紀小我很多，在一個我們聊天的群組中說到自己剛從工程師轉為 PM 時的對話，我為了文章效果修飾過。

我自己是一路摸索著如何當個 PM，搞砸了不少專案，甚至到 Appier 也搞砸過。

剛到 Appier 的第一周，CEO 列了一排的書單給我，很多書對我的幫助很大。有些書有點深，我一直到半年後，甚至一年後才開始慢慢看懂。

不敢說自己做得好，因為身邊好幾個 PM 都做得比我好很多，也是我一直在學習的對象。這一段時間以來當 PM 的經驗，把我覺得對我幫助很大的書，且就算是新手 PM 也會比較容易有收穫的書列出來，希望也可以幫助其他人。希望大家可以正確的 say NO 而不會成為失業的 PM。


1. 人月神話

幾乎所有軟體產業相關的推薦書單都有這一本。拜託沒讀過的不要在軟體業當 PM 殘害世人。這本書超級有名，念大學時就被推薦過這一本書，當時完全讀不懂。就跟 design pattern 一樣，沒經驗時完全無法看懂為什麼。

有幾年工作經驗後，可以體會整本書中的字字血淚。必讀。

2. 最後期限 - 專案管理的 101 個成功法則

我會把這本書稱為專案管理的 101 個失敗法則，因為都做到了不一定會成功，但犯了幾個之後，肯定很難成功。

這本書把很多學者的研究結果用小說的型態寫出來，非常非常的好讀，一個下午就可以讀完了。

每個章節的重點提示，背後都是根據大量的資料蒐集，統計，分析，發現成功的專案跟失敗的專案之間的差異。而不是 "我的觀察啦" 這一種水準的建議。也就是說，如果想對裡面的建議有反對意見，最好認真的再多想一次自己的想法到底是不是對的。

這本我大概幾個月就會重看一次，每次體會都不一樣，因為每段時間犯的錯都不一樣（遮臉）。

本來想列幾條例子，但發現可能要列 101 條，我就放棄了，看書吧。

3. Peopleware - 腦力密集產業的人才管理之道

也是軟體產業必看的書，太多太多的重點了。
我尤其喜歡書中的 "團隊殺手" 這個章節，印象最深的就是

[時間分割] : 把一個工程師的時間分到兩個專案，你得到的不會是50% 50%。
(我會說只有 5% 5% )
[產品的品質降低] : 大家討論的都是成本降低的產品，但是卻矇上眼睛不去看同時得到的也是品質降低的產品。
( 這就是欠債阿，不要以為欠債不用還阿)

這都是時時需要警惕的，一不小心就會犯錯阿QQ


4. 與熊共舞:軟體專案的風險管理 

通常 google 看到的各類推薦書單不太會出現這一本書，感謝 Luba 大大的推薦。這本書跟前面兩本的作者是同一個人。是三本中我最愛的一本。

如果搞砸過某個專案，那就該看這本書了。
我當年就是砸過不只一個專案，而且總覺得不是自己的錯，看完書後只能說就是自己的錯。

[ 對風險視而不見不是樂觀，是不負責！ ]

5. SCRUM - 用一半的時間做兩倍的工作

這可能不是非常好的 Scrum 工具書，但是是很好的入門書。出發點，該如何開始，什麼錯不該犯。

雖然我自己的團隊不是完全照著做，但是我會避免對著幹。或是當工程師提醒我在犯做的時後，我會知道自己在犯錯。

附贈一個不錯的影片: https://www.youtube.com/watch?v=502ILHjX9EE

6. Get Things Done 

這就不是侷限軟體產業的好書了。我自己是還沒有完全讀完，但每讀一些都會發現自己的錯誤跟修正。

7 The Design of everyday things

當個 PM 對於基本的一些設計原則有了解，會很有幫助。不管是溝通用，或是設計 prototype，甚至寫user story 。

當設計一個東西之後，發現使用者完全不照設計的方式做，這本書可以幫忙找出到底犯了什麼錯。

不過這本有點硬，我大概斷斷續續讀了一整年。很多東西還看不懂。但是看懂的東西就很有幫助。

8. Lean In : Women, Work and the Will to Lead

這本由 Facebook 營運長 Sheryl Sandberg 所寫的書，目前也列在我的超強力推薦中。如果這是一本只給女人的書，那我大概是女人。
稍為比較偏向自己的心理建設，非常非常棒的一本書。

9. The Lean Startup 精實創業

我覺得最困難的是不要浪費時間做出"大家都想要"，但是沒人想用的東西。

看不懂我說什麼對吧？

當年我做過一個產品，有 prototype 的時後，每一個拜訪到的 TA 都跟我們說這個超棒，超想要，拜託你們快點做。數十家公司，  從 Manager 到 Tech Lead， 100% 的說他們很期待這個產品。

半年後 Beta，找這些人說你們要不要開始試試看，試試看不用錢，早期合作夥伴永遠不用錢。

沒有一個人一間公司願意花一點資源試試看。一個都沒有。
而這件事情發生過不只一次。

True Story QQ

如何判斷你做的東西是不是真的有人要用？
讓他用，而不是問他想不想要。


"Product Management in Practice"

這一本是 Early Release，目前只有 safari books上看得到。
不過我想要拿出中間一小段來分享

書中提到一些 PM 該避免的錯誤跟前面一些書的說法大同小異，但是他提出一個想法說為什麼這些錯誤是會常常發生。

因為會擔心 "看起來自己什麼都沒做"

方向是CEO決定的，真正完成東西的人是工程師們，那 PM 似乎沒有貢獻。

因此為了有貢獻，可能會給開發者不合理的期限、不敢說不、總是想要一個小時問一次更新、擔心有人沒事做所以想要控制到開發者個工作時數.....等等。

不完全同意，但是是個我覺得不錯的自省的檢查點。

========

其實還有很多很多好書，這邊就先列到這裡。還有興趣的話 google 一下關鍵字可以找到一大堆的推薦書單。



最後想講一下，其實這些書的成形，絕大部分不是提出什麼新觀點，新方法。幾乎都是觀察過去專案的紀錄與分析，找出來成功的專案跟失敗專案的差別，高效率團隊的特點，並且歸納出來的方法論。也就是說，都是先有人這樣做，並且取得成果，才有這些方法論。

所以如果你觀察到身邊有人總是可以把事情做好，或許觀察與學習，比起看書的收穫會更多。加入 Appier 之後，我覺得我從同事們身上學到的東西比看書還多。

繼續偷渡招募文
Appier持續招人中，詳情請洽 加入我們 ，尤其缺少 Frontend/Backend 工程師，拜託大家多多推薦。