實驗性工廠和增大規模

• 化學工程師很早就意識到：在某個化學反應大規模投產之前必須進行實驗性的生產。
• 軟件系統的構建人員也面臨同樣的問題，但似乎從來沒有吸取教訓。總是設計、應用、然后把第一次開發的產品交付給客戶。
• 對于大多數項目，第一次開發的系統并不合用，必須要不斷的開發更好的系統。
• 即便最優秀的項目經理，也不能完全知曉并解決問題。新的技術和概念總會不斷的出現在項目中，所以我們必須構建一個用來拋棄的系統。
• 不要考慮，“我們是否應該構建一個實驗性系統”，因為這一定是必要的。我們應該問“是否需要將原型展示給用戶”。
• 將原型展示給客戶的有點是：可以獲取時間。但代價是：用戶使用體驗不佳，分散開發者精力，影響產品形象。

唯一不變的是變化本身

• 軟件系統的變化是與生俱來的，并不是不合時宜的令人厭惡的異常情況。
• 開發人員交付的是用戶滿意度，而不是有形的產品。
• 用戶的實際需要和用戶感覺會隨著程序的構建、測試和使用而變化。
• 實體產品階段化了用戶對于變更的需求，然而軟件產品的不可見性，導致它的構建人員面臨永恒的需求變更。
• 并不推薦將所有的可能變化都整合到設計階段中。目標上的變化是不可避免的，甚至技術上、策略上的變化也不可避免。
• 必須學會接受事實，不斷的學習，不斷地更改設計。

為變更而設計系統

• 如何為變化設計系統是一個老生常談的問題。方式包括：模塊化、可擴展的函數、接口設計、文檔編寫。最重要的措施是使用更高級語言。
• 必須為變更劃分出階段，每個產品都有自己的數字編號，每個版本都有屬于自己的日程表，在此之后的變更屬于下一個版本的范疇。

為變更而計劃組織結構

• 為變更組件團隊要比為變更進行設計更加困難。從技術角度而言，整個團隊都可以被靈活的安排。
• 管理人員和技術人才需要具有互換性，這其中的障礙是社會性的。貝爾實驗室采用了廢除所有頭銜的方式，讓每個專業人士都是技術人員中的一員。
• IBM 采用雙線的模式管理項目人員。從技術線向管理線調動時，不能伴隨著待遇的提升，應當稱之為“調動”而不是“晉升”。
• 管理人員與開發人員待遇相同，這對傳統的意識是一種改變。
• 高級人員在參與編程開發時，不會感到自降身份，消除了社會障礙。

前進兩步，后退一步

• 在程序發布給顧客使用之后，并不會停止變化。發布后的變更被稱為“程序維護”，但是對于軟件的維護過程不同于硬件維護。
• 軟件維護主要包含對設計缺陷的修復。軟件維護的變更通常包含了更多的新增功能，通常是用戶能夠察覺的。
• 對于一個廣泛使用的程序，其維護總成本總是開發成本的40%或更多。用戶越多，所發現的錯誤就越多。
• 軟件生命周期中有一個有趣的循環：發現 bug 的數量隨著時間的變化，會先由多變少，再由少變多。可以理解為用戶達到一定熟練水平之后，就會開始運用新的功能。
• 每一次修復缺陷，總有20%~50%的概率引入新的錯誤，這就是走兩步后，退一步。
• 看上去很微小的錯誤，似乎僅僅是局部操作上的失敗，實際上卻是系統級別的問題。
• 理論上，每次修復之后，必須重新運行先前所有的測試用例，從而確保系統不會以更隱蔽的方式被破壞。然而，實際情況中這樣回歸測試的成本非常高。
• 顯然，使用能夠直觀看到副作用的程序設計方法，將帶來巨大收益。另外，越簡單，錯誤越少。

前進一步，后退一步

• 程序的模塊總數總是隨著版本號的增長而線性增長，然而受到影響的模塊數量卻成指數增長。所有的修改都傾向于破壞系統的架構，增加了系統的混亂程度。
• 修復早期設計引發的漏洞的工作越來越少，而維護工作本身引起的漏洞修復工作卻越來越多。
• 老的系統盡管在理論上一直可用，但實際上已經面目全非，無法再繼續成為下一步發展的基礎。
• 用戶的需求永遠在變化，系統卻不能一直可用。一個嶄新的、基于原有系統的重新設計是完全必要的。
• “事物在最初總是最好的”。
• 軟件的開發是減少混亂程度的過程，他本身是平穩的。軟件維護是提高混亂度的過程，即使是最熟練的軟件維護工作，也只是放緩了系統變得不穩定的進程。

以上就是《人月神話》第10章——未雨綢繆的所有內容

本章中作者開篇引用了一句名言“不變只是愿望，變化才是永恒”，以此引出軟件行業中一個重要的概念，那就是開發必須要面向變更。這不是對于開發人員的要求，而是客觀上任何軟件系統的規律，甚至于對于開發團隊的配置都要求可以靈活變更。

作為一名軟件外包行業的從業者，對本章的感觸的很深的，外包的痛點之一就是客戶在整個開發過程中對于需求的變化是隨時都可能發生的，時間越長變化的可能性就越大，所產生變化的點也就越多。雖然通過各種開發文檔能夠將部分風險轉移到甲方，但轉移的同時甲方對于開發的體驗也就變差了。

而開發人員的目的其實是交付“用戶滿意度”，這就導致了無論前期有多么完善的文檔（大部分項目根本達不到完善的程度），只要發生了需求變化，用戶滿意度總是下降的。一旦下降到一定程度，很可能會再次反作用于項目本身，導致更多的修改。這種情況也就意味著項目整體是失敗的了。

通常我們會采用下面的方法來嘗試擺脫困局：

• 將項目拆分成不同的階段，分開交付。對于功能復雜的項目，就考慮將某些相對獨立的功能拆分開來。所交付的功能越少，對項目的把握就越大。
• 讓開發時間盡可能的短，也就是讓開發人員盡可能的加快開發的進度，開發之前一定要整理好相關的需求文檔。
• 使用已經穩定運行的代碼，也就是采用二次開發的方式，或者叫換殼開發。

對于公司來說這些確實是最容易想到，也行之有效的方法。但是，如果換一個角度思考，例如我們把項目開發過程中涉及到的人員拆分成三個部分，情況則完全是相反的。這三個部分分別是：

公司、開發團隊、客戶

之所以可以這么分是因為各個部分所代表的利益都不同，公司代表的是成本和收益，開發團隊代表的是效率和薪資，客戶代表的是滿意程度。

• 我們將項目拆分時，依據的是公司行業經驗。對于開發團隊來說由于二期、三期的目標不明確，在系統設計階段難免會出現考慮不周，導致后續開發成本增加，甚至難以進行繼續迭代。對于客戶來說，將會難以理解各個階段所產生的成本，很容易出現“我只是加個功能，為什么成本這么高”的感覺。

• 縮短開發時間，意味著開發過程中的溝通是幾乎沒有的，客戶在初期往往是無法將所有的需求都表達清楚的，交付過程會顯得突兀。開發團隊也因此增加了工作量，開發團隊也是需要工作體驗的，壓榨周期會讓團隊變得消極。

• 小型項目進行二次開發是很好的方式，但對于大型項目（特別是定制項目）則完全等于是在碰運氣。在甲乙雙方本身溝通就不太流暢的情況下，還引入了另一個需要照顧的方面，那就是原有的項目，矛盾很容易被放大。

所以說這些很容易想到的對策，其實在三方利益的博弈中只滿足了公司一方。這也是為什么外包公司的開發團隊遠比互聯網公司的開發團隊體驗差的原因了（互聯網公司和其開發團隊往往代表的是相同利益）。

所以正確的方式應該是怎樣的呢？

在博弈論中有一個叫做“壞孩子”的理論，說的是如果父親無條件的對所有孩子好，那么只需要每一個孩子保持“自私”，整個家庭的利益將會最大化。如果包括父親在內的每一個成員都保持“自私”，就會傷害到善良的那個孩子，導致總體家庭利益無法達到最大。

公司在這之中所擔任的角色其實是類似于父親的，甚至可以把成員再細分為：公司、客戶、開發人員、設計人員、首席開發人員、售前經理、程序秘書等等，各自代表著不同的利益。只要公司愿意對其他人員保持無私的付出，整個系統是完全有可能達到最大利益平衡的。

有點說遠了。

上述的團隊是如何解決“變化才是永恒”的問題的呢？

• 對售前階段進行成本核算
• 對客戶進行培訓
• 提高開發團隊配置
• 沉淀公司制度

在競爭市場中，售前成本核算是最難邁出的一步，客戶對此的接受程度有可能是極低的。雖然沒有調查過，但是市場上大量的“模板項目”、“價格戰”，讓客戶對于收費是很敏感的。其次，客戶本身對于軟件行業的了解就不足，很難理解他所購買的“售前服務”到底是什么。即便如此，我依然認為這是可行的解決方法，因為它的影響很大。

售前成本核算意味著客戶能夠得到高質量的售前服務，高質量的售前服務意味著需要安排經驗豐富的工程師，經驗豐富的工程師意味著項目的“概念完整性”將得到保證，概念完整性意味著項目的高質量，高質量意味著高報價，高報價意味著優秀的開發團隊介入，優秀的團隊意味著交付更高的“用戶滿意度”。

又說遠了，其實我能想到的這些方法，目前也都處于尋求“自洽”的階段。還有三個方法，可能隨著《人月神話》的深入會進一步的思考。

自由轉載-非商用-非衍生-保持署名（創意共享3.0許可證）

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的《人月神话》（P11）为舍弃而计划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。