新手PM 的建議書單 - 愛看小說的丹尼

新手PM 的建議書單 · 1. 人月神話 幾乎所有軟體產業相關的推薦書單都有這一本。

· 2. 最後期限- 專案管理的101 個成功法則 · 3. Peopleware - 腦力密集產業的 ... Saturday,July29,2017 新手PM的建議書單  A：[要如何成為專業的PM] 我：[SayNO]  A：[這好難喔] 我：[要如何成為優秀的PM-SayFUCKYOU]  A：[靠北，這麼硬歐] 我：[是蠻硬的，因為要如何成為失業的PM也是SayNO跟sayFUCKYOU] 這是上個禮拜，有個當兵時的"學長"，但實際上年紀小我很多，在一個我們聊天的群組中說到自己剛從工程師轉為PM時的對話，我為了文章效果修飾過。

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

剛到Appier的第一周，CEO列了一排的書單給我，很多書對我的幫助很大。

有些書有點深，我一直到半年後，甚至一年後才開始慢慢看懂。

不敢說自己做得好，因為身邊好幾個PM都做得比我好很多，也是我一直在學習的對象。

這一段時間以來當PM的經驗，把我覺得對我幫助很大的書，且就算是新手PM也會比較容易有收穫的書列出來，希望也可以幫助其他人。

希望大家可以正確的sayNO而不會成為失業的PM。

1.人月神話 幾乎所有軟體產業相關的推薦書單都有這一本。

拜託沒讀過的不要在軟體業當PM殘害世人。

這本書超級有名，念大學時就被推薦過這一本書，當時完全讀不懂。

就跟designpattern一樣，沒經驗時完全無法看懂為什麼。

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

必讀。

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.GetThingsDone  這就不是侷限軟體產業的好書了。

我自己是還沒有完全讀完，但每讀一些都會發現自己的錯誤跟修正。

7TheDesignofeverydaythings 當個PM對於基本的一些設計原則有了解，會很有幫助。

不管是溝通用，或是設計prototype，甚至寫userstory。

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

不過這本有點硬，我大概斷斷續續讀了一整年。

很多東西還看不懂。

但是看懂的東西就很有幫助。

8.LeanIn:Women,WorkandtheWilltoLead 這本由Facebook營運長SherylSandberg所寫的書，目前也列在我的超強力推薦中。

如果這是一本只給女人的書，那我大概是女人。

稍為比較偏向自己的心理建設，非常非常棒的一本書。

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

看不懂我說什麼對吧？ 當年我做過一個產品，有prototype的時後，每一個拜訪到的TA都跟我們說這個超棒，超想要，拜託你們快點做。

數十家公司， 從Manager到TechLead，100%的說他們很期待這個產品。

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

沒有一個人一間公司願意花一點資源試試看。

一個都沒有。

而這件事情發生過不只一次。

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

"ProductManagementinPractice" 這一本是EarlyRelease，目前只有safaribooks上看得到。

不過我想要拿出中間一小段來分享 書中提到一些PM該避免的錯誤跟前面一些書的說法大同小異，但是他提出一個想法說為什麼這些錯誤是會常常發生。

因為會擔心"看起來自己什麼都沒做" 方向是CEO決定的，真正完成東西的人是工程師們，那PM似乎沒有貢獻。

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

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

======== 其實還有很多很多好書，這邊就先列到這裡。

還有興趣的話google一下關鍵字可以找到一大堆的推薦書單。

最後想講一下，其實這些書的成形，絕大部分不是提出什麼新觀點，新方法。

幾乎都是觀察過去專案的紀錄與分析，找出來成功的專案跟失敗專案的差別，高效率團隊的特點，並且歸納出來的方法論。

也就是說，都是先有人這樣做，並且取得成果，才有這些方法論。

所以如果你觀察到身邊有人總是可以把事情做好，或許觀察與學習，比起看書的收穫會更多。

加入Appier之後，我覺得我從同事們身上學到的東西比看書還多。

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

Postedby Danny at 1:00PM 3comments: SOC said... 因為你的文章開始看了一下人月神話，看人月神話遇到最大的困難似乎不是在技術細節，而是成書時代(1960,1970)過早所造成的時代感。

譬如說在講記憶體的章節好了，有寫說程式佔用160K記憶體，然後寫得好像非常嚴重。

儘管知道這是時代的眼淚，但仍有WTF感然後完全無法了解到底這個是在講什麼。

不過也有可能是因為我是做硬體PM而不是軟體PM就是了。

5:26PM jerrylinblog said... 要自己帶換，e.g.公差從0.1mm弄錯成1mm 6:51PM Unknown said... good 11:37AM PostaComment OlderPost Home Subscribeto: PostComments(Atom) PopularPosts [專案管理工具]JIRA使用心得（一）基本功能介紹 新手PM的建議書單 [專案管理工具]JIRA使用心得（三）KanbanBoard介紹 [專案管理工具]JIRA使用心得（四）ScrumBoard介紹 [專案管理工具]JIRA使用心得（二）進階功能介紹 BlogArchive ▼  2017 (4) ▼  July (3) 新手PM的建議書單 什麼樣的創業團隊可以拿到投資?賺錢，或是看起來會賺錢。

軟體開發的溝通落差 ►  June (1) ►  2016 (6) ►  July (2) ►  April (4) ►  2015 (7) ►  December (2) ►  November (1) ►  July (2) ►  June (1) ►  April (1) ►  2014 (10) ►  March (6) ►  February (3) ►  January (1) ►  2013 (4) ►  November (1) ►  October (1) ►  September (1) ►  March (1) ►  2012 (2) ►  July (1) ►  March (1) ►  2011 (8) ►  November (4) ►  September (1) ►  August (3) ►  2010 (4) ►  September (1) ►  April (1) ►  March (2) ►  2009 (1) ►  June (1) ►  2008 (9) ►  December (3) ►  November (6) ►  2006 (1) ►  November (1) SubscribeTo Posts Atom Posts Comments Atom Comments