The Art of Project Management（中譯本《專案管理之美學》）是作者Scott Berkun根據多年的經驗，以平鋪直敘的方式敘述他的經驗。其中多數屬實務經驗，如lesson learned、以及依據實務經驗所發展出的專案管理的信念和理論。
Scott的工作經驗多數來自於IT界。Scott在Microsoft工作近十年，領導團隊開發軟體專案，如Internet Explorer瀏覽器、Windows作業系統、及MSN服務。Scott 也常受邀在各公開及學院發表演說、提供諮詢顧問服務，是實戰的人物。
要讓一件事情有條不紊地邁向成功，重點不在專業知識、技術、或理論，而是在project management。本書是這些寶貴經驗的知識總整理，內容包括領導團隊的技巧、引導團隊集思廣益的方法、組織專案、管理進度、應付政治、以讓專案平順等務實的技巧。
專案管理應是通識。大至蓋台北101、開發新款汽車、創業，小至規畫一個成功的home party，專案管理知識皆可派上用場。本書提供很大的價值，建議直接閱讀本書的英文版。
垃圾可以變黃金，麻雀有望成鳳凰，只要被專業創投相中，瀕臨關門大吉的公司，也可以轉化為成功的上市公司。by Frederick P. Brooks (Paperback)
Amazon.com
The classic book on the human elements of software engineering. Software tools and development environments may have changed in the 21 years since the first edition of this book, but the peculiarly nonlinear economies of scale in collaborative work and the nature of individuals and groups has not changed an epsilon. If you write code or depend upon those who do, get this book as soon as possible -- from Amazon.com Books, your library, or anyone else. You (and/or your colleagues) will be forever grateful. Very Highest Recommendation.
From Book News, Inc.
The 20th anniversary edition of this classic collection of essays on software engineering and managing complex projects includes revised material, and new chapters condensing the author's original propositions and his views 20 years later, plus a reprint of his 1986 paper "No Silver Bullet," and his recent comments on that essay. Brooks' central argument is that large programming projects suffer different management problems from small ones due to the division of labor, and that conceptual integrity of the product is critical. Annotation copyright Book News, Inc. Portland, Or.
軟體業永遠的神話
軟體工程堪稱變化最快速的行業，過去幾十年來，我們看盡各種軟體神話如驚濤駭浪襲捲而來，轉瞬間就被另一波浪濤殲滅無蹤影。在這樣的景況裡，若有什麼事物是可以歷久仍彌新，那就不僅僅是異數，而是神話，值得你駐足瞻仰了。
《人月神話》就是這樣一本書。原是佛瑞德‧布魯克斯為開發IBM史無前例的巨型軟體系統「OS/360」所寫的專案總結報告，1975年出版迄今，近30年來幾已成為程式設計工作者人手一冊的必讀經典。時至今日，大型複雜軟體的開發與應用，更加緊密地牽動各個層面，也益發彰顯此書的價值，特別是對所有工作環節涉及程式設計這一領域的人，如專案經理，甚至連IT產業的領導者如摩托羅拉對這本書也大力推崇。
簡而言之，《人月神話》談的是軟體開發專案管理的所有方方面面的問題。3個人4個月的工作絕不等於12個人1個月的工作（這也是本書書名的由來），那為什麼進度落後時大家還是直覺反應加人呢？
既然布魯克斯在1975年就已經討論了克服時間壓力和團隊合作之間矛盾的有效方法，為什麼今天產品開發中屢屢延期交付仍是常態呢？
既然布魯克斯早就提醒過我們要注意軟體發展中普遍存在和頻繁出現的目標捨棄、功能調整、預算緊縮等變數，為什麼在專案計畫階段大家還保持樂觀，蔑視一切潛在的風險呢？（文/桑加米卓）
有同好有一樣的困擾 - 如何使用自己的data logging軟體，因此寫了這篇來分享我的簡易改裝。 Background 雲豆子 MERCURY roaster 烘豆機的設計是使用自行開發的軟體，來：1. 操控風門/火力; 2. data logging/自動烘焙。 ...
