在与许多不同的团队合作过之后，Greg Young发现大家做项目时经常会大幅度的过度设计。比如一个预计要开发9个月的项目，换个角度思考一下，却可能只需要几个星期就可以提交95%的功能。Young在最近伦敦举行的DDD eXchange大会上着重阐述了这一点。
过度设计的原因就是我们在开发错误的东西。在Young看来，我们并没有对客户到底需要什么给以予足够的关注，我们关注的是我们认为客户需要什么，而实际上这是两件非常不同的事。大多数情况下，项目功能的使用情况会遵从帕雷托分布（80/20法则），即只要实现一小部分功能，就可以满足绝大部分场景下的实际使用需要。如果继续开发剩余的使用率极低的功能的话，会需要投入非常多的精力，而只能获得非常少的收益。
Young强调软件只是一个大系统的一小部分。除了软件我们还有一整套的业务流程，而某些细节问题是完全可以用业务流程去解决的，不一定全要通过软件解决。平时我们过多的讨论了最极端的情况下如何用软件解决问题。其实我们完全可以把工作内容的99.9%用软件自动化处理掉，然后把剩余的一小部分留给熟悉业务的人去手工解决。
人工介入是有必要的，人类来了！
“棕地项目”是有可能被过度设计的一类。对于Young来说，这些项目也是最容易避免过度设计的，因为人们对这样的系统已经有了使用经验和数据。根据熟悉业务的人的描述找到系统的基本用例，再对照实际的使用情况，就基本可以确认绝大部分的系统功能了。不幸的是，我们和熟悉业务的人讨论得最多的却常常是系统的边缘功能，就是那些在编码时需要大量复杂处理可实际上却很少在生产环境中能用到的功能。Young也指出，考虑这些复杂处理事实上会误导我们的项目模型设计。
“绿地项目”则是经常被过度设计的一类，因为我们没法接触到实际的使用情况。为了避免过度设计，Young建议与需求方达成协议可以在项目首次提交的两个月后再次部署和发布。期间，需求方要使用这个系统并尽早的提供反馈，这样来避免实现那些几乎用不上的功能。他也建议在第一次发布之后只解决故障而不开发新功能，这样所有缺失的功能就都会被当成故障报告上来。根据他的经验这样工作非常有成效，因为大家只需要分析故障的严重程度来决定处理的优先级就可以了。但他也提到，这种工作方式只适用于给内部用户使用的内部项目，对固定价格的合同或者公用的网站不适合。
我们就是在梦想国里开发绿地项目的。
项目经理或项目协调者是非常容易做过度设计的人。Young几乎没见过什么项目是可以兼顾多种用途而获得成功的，最大的原因是要满足各方面的细节需求就会导致最终做成一个庞大的项目。更过份的是有的项目甚至会迷失，想不明白自己最主要是想实现什么功能了，结果大家就只好把各种可能情况都列举出来，事情就完全不可控了。
Young总结到：我们应该记住现在软件系统已经在取代人工工作了。大多数的情况下能让软件系统完成99%的人工工作就已经非常好了，想再把剩下的1%也搞定，这事算起账来并不划算。
本文转自d1net（转载）
