产品提出需求了， 然后开发人员按照自己的理解去编码，向产品提测后，产品按照自己当时的需求去测试。产品提bug→开发解决完善→产品回归测试。这本来是一个合理的测试过程，结果呢，回归测试后，发现很多bug并未有效fix。究其原因，好多细节，开发人员在开发时没想清楚。
补充说明一下现状，公司现在缺乏测试人员，项目一般是由产品负责管理和推进，产品做好原型，产品部简单评审后，就开始向开发人员说需求。大家经过简单讨论，开发就启动，同时产品找UI设计和制作页面。开发完成后，向产品提测。
按照上面的流程，好在还没有测试人员，如果有了测试人员，很多的bug恐怕要去找产品去仲裁。 因为事先各方未就要做的项目有一致的认识。
我经常跟产品和开发提的是：事先把流程想清楚，然后设计出来，设计的过程就是思考的过程。设计工作开发和产品都要参与，然后再一起讨论。很多的逻辑，如订单的处理流程，涉及到数据试算，即需要简单的做一些测试用例，进行试错，这样才可能设计出可行性高的产品。——设计流程和用例的好处，1st，一目了然，开发、测试人员易懂，2nd，反过来推敲产品，让产品更合理；3rd，指导后续的开发、测试。 一个产品，如果只有一个原型，缺乏必要的文字描述和流程说明，我表示质疑，这个产品经理是否真正的了解自己的产品？
如果不事先明确需求，如上是一个恶性循环，同时浪费了大家的时间，项目绩效也不高。毕竟，项目管理是要考虑时间和人力成本的。可以相信，事先尽可能的明确需求，对后续的开发和测试，不说事半功倍，但一定能提高项目的绩效。要不，要开发流程干毛用。
现在讲究TDD，其实就是为了规避大家一开始对需求理解不一致，然后用用例来驱动的开发、测试过程。
重要的事情说三遍：
最近媳妇工作忙了，我今天不加班了，8点前回家，帮着老娘看孩子
最近媳妇工作忙了，我今天不加班了，8点前回家，帮着老娘看孩子
最近媳妇工作忙了，我今天不加班了，8点前回家，帮着老娘看孩子