在與許多不同的團隊合作過之后，Greg Young發(fā)現(xiàn)大家做項目時經(jīng)常會大幅度的過度設計。比如一個預計要開發(fā)9個月的項目，換個角度思考一下，卻可能只需要幾個星期就可以提交95%的功能。Young在最近倫敦舉行的DDD eXchange大會上著重闡述了這一點。

過度設計的原因就是我們在開發(fā)錯誤的東西。在Young看來，我們并沒有對客戶到底需要什么給以予足夠的關注，我們關注的是我們認為客戶需要什么，而實際上這是兩件非常不同的事。大多數(shù)情況下，項目功能的使用情況會遵從帕雷托分布（80/20法則），即只要實現(xiàn)一小部分功能，就可以滿足絕大部分場景下的實際使用需要。如果繼續(xù)開發(fā)剩余的使用率極低的功能的話，會需要投入非常多的精力，而只能獲得非常少的收益。

Young強調(diào)軟件只是一個大系統(tǒng)的一小部分。除了軟件我們還有一整套的業(yè)務流程，而某些細節(jié)問題是完全可以用業(yè)務流程去解決的，不一定全要通過軟件解決。平時我們過多的討論了最極端的情況下如何用軟件解決問題。其實我們完全可以把工作內(nèi)容的99.9%用軟件自動化處理掉，然后把剩余的一小部分留給熟悉業(yè)務的人去手工解決。

人工介入是有必要的，人類來了！

“棕地項目”是有可能被過度設計的一類。對于Young來說，這些項目也是最容易避免過度設計的，因為人們對這樣的系統(tǒng)已經(jīng)有了使用經(jīng)驗和數(shù)據(jù)。根據(jù)熟悉業(yè)務的人的描述找到系統(tǒng)的基本用例，再對照實際的使用情況，就基本可以確認絕大部分的系統(tǒng)功能了。不幸的是，我們和熟悉業(yè)務的人討論得最多的卻常常是系統(tǒng)的邊緣功能，就是那些在編碼時需要大量復雜處理可實際上卻很少在生產(chǎn)環(huán)境中能用到的功能。Young也指出，考慮這些復雜處理事實上會誤導我們的項目模型設計。

“綠地項目”則是經(jīng)常被過度設計的一類，因為我們沒法接觸到實際的使用情況。為了避免過度設計，Young建議與需求方達成協(xié)議可以在項目首次提交的兩個月后再次部署和發(fā)布。期間，需求方要使用這個系統(tǒng)并盡早的提供反饋，這樣來避免實現(xiàn)那些幾乎用不上的功能。他也建議在第一次發(fā)布之后只解決故障而不開發(fā)新功能，這樣所有缺失的功能就都會被當成故障報告上來。根據(jù)他的經(jīng)驗這樣工作非常有成效，因為大家只需要分析故障的嚴重程度來決定處理的優(yōu)先級就可以了。但他也提到，這種工作方式只適用于給內(nèi)部用戶使用的內(nèi)部項目，對固定價格的合同或者公用的網(wǎng)站不適合。

我們就是在夢想國里開發(fā)綠地項目的。

項目經(jīng)理或項目協(xié)調(diào)者是非常容易做過度設計的人。Young幾乎沒見過什么項目是可以兼顧多種用途而獲得成功的，最大的原因是要滿足各方面的細節(jié)需求就會導致最終做成一個龐大的項目。更過份的是有的項目甚至會迷失，想不明白自己最主要是想實現(xiàn)什么功能了，結果大家就只好把各種可能情況都列舉出來，事情就完全不可控了。

Young總結到：我們應該記住現(xiàn)在軟件系統(tǒng)已經(jīng)在取代人工工作了。大多數(shù)的情況下能讓軟件系統(tǒng)完成99%的人工工作就已經(jīng)非常好了，想再把剩下的1%也搞定，這事算起賬來并不劃算。

明年的DDD Exchange大會計劃在2017年四月下旬如開，現(xiàn)在正在開放注冊。

查看英文原文：Stop Over-Engineering, Build What the Customer Really Needs