實驗性工廠和增大規(guī)模

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

唯一不變的是變化本身

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

為變更而設(shè)計系統(tǒng)

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

為變更而計劃組織結(jié)構(gòu)

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

前進(jìn)兩步，后退一步

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

前進(jìn)一步，后退一步

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

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

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

作為一名軟件外包行業(yè)的從業(yè)者，對本章的感觸的很深的，外包的痛點之一就是客戶在整個開發(fā)過程中對于需求的變化是隨時都可能發(fā)生的，時間越長變化的可能性就越大，所產(chǎn)生變化的點也就越多。雖然通過各種開發(fā)文檔能夠?qū)⒉糠诛L(fēng)險轉(zhuǎn)移到甲方，但轉(zhuǎn)移的同時甲方對于開發(fā)的體驗也就變差了。

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

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

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

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

公司、開發(fā)團隊、客戶

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

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

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

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

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

所以正確的方式應(yīng)該是怎樣的呢？

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

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

有點說遠(yuǎn)了。

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

• 對售前階段進(jìn)行成本核算
• 對客戶進(jìn)行培訓(xùn)
• 提高開發(fā)團隊配置
• 沉淀公司制度

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

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

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

自由轉(zhuǎn)載-非商用-非衍生-保持署名（創(chuàng)意共享3.0許可證）

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。