1.1
利用歷史
專案管理作為一種概念,可以追溯到很久的歷史。當回想起人類文明史上所取得的成就時，你會發現我們有幾千年的專案經驗可以學習。我們可以用一條虛線把今天的軟體開發者和埃及金字塔的建造者或者羅馬水渠的設計者們連線起來。在不同的時代裡，專案經理扮演著類似的角色，那就是把技術應用到屬於他們的時代的問題上。然而在今天，當許多人想盡辦法來改善他們的web和軟體開發專案的管理時，卻很少從過去汲取經驗和教訓。對於知識的運用，應該把目光放得更遠一些，而不是僅僅侷限於現在。
工程專案的歷史告訴我們，大部分的專案都有著驚人的相似性。它們都有需求、設計和限定條件；它們的完成需要依靠交流、決策以及融合各種創造性和邏輯性的想法；它們通常包括時間表、預算和客戶；最為重要的是，專案的中心任務就是把不同人的工作融合成為乙個整體並且使其對客戶產生價值。無論專案是建立在html、c++之上還是水泥和鋼鐵的基礎上，它們都分享著一套不可否認的核心觀念。
我對於如何更好的領導web和軟體開發產生了濃厚的興趣。我研究了其它領域和產業來挖掘它們是如何解決工程專案中的核心問題，這樣我就可以把一些類似的解決方案應用到自身的工作當中。我想知道像哈勃望遠鏡和波音777這樣的專案是如何設計和構建的，我是否能夠從它們複雜的規範和規劃過程中學習到什麼有用東西? 當建造紐約的克萊斯勒大廈和雅典的帕台農神廟的時候，這些專案的領導者在計畫和評估它們的建築時是否使用了和我的程式設計者們相同的思考方式?它們之間有趣的差別是什麼，我們可以從這些差別中得到什麼啟示呢？
那些報紙的編輯者是如何組織和計畫新聞的日產量的？在web出版物出現以前的很長一段時間內，他們就在做關於多**方面（畫面和文字）的工作了。那電影產業的特點又是如何呢？阿波羅13號？通過檢視這些問題，我能夠發現以一種新的方式來領導專案團隊。
然而，這些問題並沒有明顯的答案。如果僅僅因為這本書中的建議受到了這些資料的影響便認為你會進展的更快或者計畫的更好，我無法給您這樣的保證。但是我知道當我回到軟體世界的時候，我使用的方法和工具看起來會很不一樣。我發現了一些方法來改變它們，而這些是我以前從來都沒想到過的。基本上，我實行了許多有價值的步驟和方法，而這些在大學的計算機課程中並沒有學到，它們也沒有在技術部門的會議上討論過或者在行業雜誌上發表過。
1.專案管理和軟體開發並不是什麼神聖的藝術。任何現代的工程專案都只是在生產產品的漫長歷史中提供了一種新的生產方式而已，雖然工藝和技巧可能會改變，但是那些使工程專案變得困難的核心挑戰仍然存在。所有的事情，無論是程式語言還是開發方法，在某些方面是獨一無二的而在其他方面則是衍生出來的。但是如果想盡可能多的應用過去的知識，我們就需要保證在與過去的事物做比較的時候保持一種開放的態度，不僅要審視它們獨特的地方，同時也不能忽略其衍生的方面。
2.通常如果你把你所做的事情看得越簡單
,那麼你越能集中精神和注意力在你做的事情上。如果我們能夠週期性的把工作維持在這種簡單的檢視上， 我們就可以和許多不同的做事方式相比較並找出其中有價值的方法來達成我們的目的。從歷史和現代工業中可以找出更多的例子和教訓來進行比較和對照，這與日語中的詞
shoshin(
初心 )所表達出的概念類似，它代表了初學者的觀點（1），或者開放的觀點，而這也是許多武術訓練的基本原則。保持好奇和坦率是你成長的動力，而這是需要經過訓練才能維持那種心態。為了能夠保持學習的態度，我們需要避免陷入那種狹隘保守的狀態。
3.簡單並不代表著容易。最好的田徑運動員、作家、程式設計師和經理往往是那些在作著看起來簡單其實卻很複雜的事情的人。請記住簡單並不意味著容易。例如，跑馬拉松是一件簡單的事情，你起跑後必須一直跑到26.2英里才停止。什麼能更簡單？實際情況是在承認困難的同時並不能否認它的簡單。領導力和管理也是很困難的，但是它們的本質是很簡單的，那就是用一些明確的方法來完成明確的目標。
我將會在許多章節中提及這些觀念。因此，如果我做的一些參考超出了軟體開發的範疇，我希望你能明白我這麼做的原因。當我提出決策和安排計畫是很簡單的功能的時候，我假設你已經知道這些並不是容易的事情。
1.1.1. 從失敗中汲取教訓
人類具有互相學習經驗的本領，這在所有動物中幾乎是獨一無二的。但是同時值得注意的是，他們也會對此表現出明顯的厭惡感。
douglas adams
在向專案的歷史學習的時候存在乙個簡單的問題：為什麼有人願意經受那種本來可以避免的由錯誤和失望所帶來的痛苦？如果從公共領域的觀點來看古老和現代工程的歷史，無論靈感來自於何處，我們都會因為做了一些明智的事情而受到獎賞，為什麼鮮有公司獎勵那些從過去的經驗取得收穫的人？當專案完成或者取消的時候（許多開發的專案都是如此終止的（2）），很少有人去研究究竟發生了什麼事情。看起來大部分公司的經理並不會獎勵那些探求這些知識的人，可能是害怕他們會找到的東西（害怕會承擔責任）。或者是對於回顧那些痛苦和失敗的經歷不感興趣，取而代之的是，他們會把時間花費新的事物上面。
在henry petroski所寫的
to engineer is human: the role of failure in successful design (vintage books, 1992)中，他闡述了在工程中許多的突破都是從失敗中取得的。這種現象在某種程度上確實存在，因為失敗常常更能引起我們的注意，它要求我們重新檢查那些我們遺漏的設想，(當原型都已經被火燒掉了，我們很難還裝作若無其事)。正如karl poppe（3）r所說的那樣，只存在兩種理論：錯誤的理論和不完全的理論。如果不是失敗，我們總會自大的忘記我們對事物的理解總是不完全的。
竅門就是盡可能多的從其他人的失敗中吸取教訓。我們應該利用他們的經驗來調控未來。儘管從表面看來，不同專案的失敗原因不盡相同，但是導致其失敗的根源或者團隊的行為是可以被轉移（避免）的。即使是在我們自己的專案上，我們也需要避免養成逃避或者隱藏錯誤的習慣。反之，我們應該將其看成是學習的機會。是什麼因素導致這些失敗發生的？哪乙個因素可以被降低或者被消除？根據petroski的理論，如果我們有勇氣來仔細的檢查究竟發生了什麼，那麼從實際的失敗中獲得的知識是我們取得進步的強大動力。
可能這就是波音公司，世界上最大飛機設計和製造公司之一，保留了一本關於設計和製造失敗經驗的黑皮書的原因（4）。自從公司成立以來，波音公司就一直保留著這份文件，它被用來幫助那些現在的設計者們能夠從過去的經歷中學到有用的東西。任何一家這樣做的公司不僅是為了提高專案的成功率，而且也能幫助他們創造乙個敢於面對討論和面對失敗的環境，而不是否認和隱藏它們。看起來軟體開發者也應該儲存一本屬於自己的黑皮書。
translated by geng
專案管理藝術 1 1
1.1 利用歷史 專案管理作為一種概念,可以追溯到很久的歷史。當回想起人類文明史上所取得的成就時，你會發現我們有幾千年的專案經驗可以學習。我們可以用一條虛線把今天的軟體開發者和埃及金字塔的建造者或者羅馬水渠的設計者們連線起來。在不同的時代裡，專案經理扮演著類似的角色，那就是把技術應用到屬於他們的時代...
《專案管理藝術》
以前看過英文電子版的，上次訂書時，發現8月底出了中譯本，就順便訂了，書不厚，幾天就可以看完，算是通俗易懂的專案管理代表作，呵呵。轉貼個目錄 前言第一章 專案管理簡史 以及你為何應該關心 第一部分 規則 第二章 進度表的真相 第三章 如何知道該做什麼事 第四章 編寫優質遠景檔案 第五章 想法來自何處 ...
專案管理的藝術
專案 管理首要任務是管理專案 廢話 專案管理的隱含目標是還在於管理一系列特定的資源。這是通過和客戶，專案團隊和外部支援團隊之間的協作來完成的。在這種情況下，我覺得這麼講比較合適，專案管理的首要功能在於管理人。很多經理人跟我說，我應該管理我的專案，但是我卻沒有足夠時間來我專案裡面的人。對於這種說法，我...