1.1 利用歷史
項目管理作爲一種概念,可以追溯到很久的歷史。當回想起人類文明史上所取得的成就時，你會發現我們有幾千年的項目經驗可以學習。我們可以用一條虛線把今天的軟件開發者和埃及金字塔的建造者或者羅馬水渠的設計者們連接起來。在不同的時代裏，項目經理扮演着類似的角色，那就是把技術應用到屬於他們的時代的問題上。然而在今天，當許多人想盡辦法來改善他們的web和軟件開發項目的管理時，卻很少從過去汲取經驗和教訓。對於知識的運用，應該把目光放得更遠一些，而不是僅僅侷限於現在。
工程項目的歷史告訴我們，大部分的項目都有着驚人的相似性。它們都有需求、設計和限定條件；它們的完成需要依靠交流、決策以及融合各種創造性和邏輯性的想法；它們通常包括時間表、預算和客戶；最爲重要的是，項目的中心任務就是把不同人的工作融合成爲一個整體並且使其對客戶產生價值。無論項目是建立在HTML、C++之上還是水泥和鋼鐵的基礎上，它們都分享着一套不可否認的核心觀念。
我對於如何更好的領導web和軟件開發產生了濃厚的興趣。我研究了其它領域和產業來挖掘它們是如何解決工程項目中的核心問題，這樣我就可以把一些類似的解決方案應用到自身的工作當中。我想知道像哈勃望遠鏡和波音777這樣的項目是如何設計和構建的，我是否能夠從它們複雜的規範和規劃過程中學習到什麼有用東西? 當建造紐約的克萊斯勒大廈和雅典的帕臺農神廟的時候，這些項目的領導者在計劃和評估它們的建築時是否使用了和我的程序設計者們相同的思考方式?它們之間有趣的差別是什麼，我們可以從這些差別中得到什麼啓示呢？
那些報紙的編輯者是如何組織和計劃新聞的日產量的？在Web出版物出現以前的很長一段時間內，他們就在做關於多媒體方面（畫面和文字）的工作了。那電影產業的特點又是如何呢？阿波羅13號？通過檢視這些問題，我能夠發現以一種新的方式來領導項目團隊。
然而，這些問題並沒有明顯的答案。如果僅僅因爲這本書中的建議受到了這些資料的影響便認爲你會進展的更快或者計劃的更好，我無法給您這樣的保證。但是我知道當我回到軟件世界的時候，我使用的方法和工具看起來會很不一樣。我發現了一些方法來改變它們，而這些是我以前從來都沒想到過的。基本上，我實行了許多有價值的步驟和方法，而這些在大學的計算機課程中並沒有學到，它們也沒有在技術部門的會議上討論過或者在行業雜誌上發表過。
關於我對過去相關工作的調查，其主要內容可以歸納爲以下3點：
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