之前在系统未正式上线之前，我一直很坚信这个系统应该可能正常运转下去，即使出现问题也是一些 BUG 而已。出现 BUG 相应的修改程序和
更正数据就可以了，不会影响到整个系统的正常运转。没想到原来等用户正式使用之后才发现系统和他们的需求还存在这么多出入，系统只运行了两
天又被迫中断了。问题出在那个环节呢？最大的问题出在需求分析上面。但为什么之前系统给用户测试使用时，他们一直没有反馈到多少有利用价值
的信息呢？当系统把之前旧系统的数据导入新系统中去，开始真正运行了。他们要真正在系统上面工作时，使用后才突然发现系统设计存在很大问题，
他们根本没法在上面正常工作，这种重要的设计缺陷最后才反馈到我们。
怎样才可以避免出现这种的设计缺陷问题呢？我觉得应该从下面几方面考虑：
1. 做需求分析时，很多时候用户不会帮你想的很全面的，而是需要你考虑到方方面面和可能出现的问题。
2. 做设计时，系统不可能一步到位，设计时不能限制得太死，要留下足够的灵活性方便以后的扩展。
现在我们这个系统就是凭空想了大多东西，想做到大而全又自动化。最后连用户最基本的续费功能都实现不了。一开始应该是重点把最核心的功能
实现，而不是考虑太多无关的东西。
3. 我们都是凡人不可能把所有问题都考虑到，所以让用户在真正的环境中使用这一步也很重要。这一步我不把它划发为测试，在测试时很多问题用户
都不会测试到，唯有让他们真正在上面工作，很多问题才会浮现出来。这一步会存在个问题真正让用户使用系统那样会更改很多数据，怎样保持
数据的准确性这个问题是必须考虑的。
最后引用他人的一些观点：
“希望设计出来的都是很完美的，一次发布就可以满足个1，2年，但其实从这些年的设计角度来看，首先系统都是不断迭代进化的，因此一步到位的说
法基本上不靠谱（除非就是一模一样的场景代码重复使用），其次系统的架构要做的足够灵活，通常情况就需要先做核心功能，预留出足够的空间和切
入点，这样对未来扩展和需求变化有足够的适应度。从这两点来看，其实设计初期就是要求找到客户最想要的，扩展可以实现客户可能要的，防范客户
没有估量到的。但这其实就需要和我们的产品设计师有充分的交流，好的产品设计师不会告诉你你怎么去实现，但是他会告诉你我想要的是什么，这些
能给客户带来什么，这时候你可以告诉他我能够通过什么方式来满足你的需求。这样的开发和产品设计交流的结果才是技术化的产品，大家各司其职，
同时也通晓对方领域的一些情况，对对方领域的只能给出建议，不是指导，这点在TOP我很庆幸有很好的黑羽同学，我们的交流就是这样产生良性互动。
这有点撤远了，刚才说了第一种场景，然后说说第二种场景，就是初期其实大家都没有明确细节，但是在实施过程中开发人员会根据自己的接触面来选
择一些技术和架构设计，最后看起来很复杂，很完美，但其实越是复杂的设计背后有越多的隐患。但是此时因为已经设计好了，就不愿意再去简化，也
不愿意听任何人的意见，其实这是很危险的。我过去也犯过类似的错误，但是其实当你冷静下来，想想那句话，我们的目标是什么：“满足客户需求”，
这时候你就会考虑，这么复杂的系统会不会给客户带来更多的不稳定以及复杂度，其实客户不关心你背后如何实现的，但是你需要满足客户的最基本的
需求，用起来方便，高效，实实在在提供了解决问题的手段。”
引用地址：http://www.blogjava.net/cenwenchu/archive/2009/12/08/305083.html