以下做法适用于此种情形：
项目历尽波折终于成功了，boss觉得很不错，因为不管怎么样总是成功了嘛；项目组成员感觉很差，觉得boss不在可信，因为干了很多没必要的事情，耽误了进度和生活。此时，boss还没有认识到问题，也不愿意组织讨论项目中遇到的问题，以便下次避免这些问题。

1，为一个特定的realease中的每个feature编号，并制定优先级（高，中，低， not numbers)。
2，基于feature来开发实现，而不是基于架构。完整的架构设计带来的问题远远大于带来的好处，因为不是所有的feature都是真正需要的。
3，开发出交付列表以便在项目开始的时候就讨论什么是真正需要的，不做没意义的工作。

如果这种事情经常发生，尝试一下实践：
1，用一个product backlog（待开发工作列表）并赋予相应的值（数字）代表价值，这样你可以一直做那些最有价值的东西，也是最重要的工作。
2，使用timeboxed进行迭代，并且基于feature来实现，这样每个人都能看到进度，并且总是能提供最有价格的东西给boss或者客户。

所有这些最重要的就是在项目开始的时候经常个boss或者其他项目利益相关者交流，保证要做的东西是最重要，最有价值的。当然，这种交流非常困难，但是是必须的，很有效的。项目组可以集中精力处理什么是最需要的，并且只处理这些问题。

有些老板（也包括一部分项目经理及项目组成员）在项目成功的时候变被胜利冲昏了头脑，不注意总结问题，特别是不注意总结需求上的问题。程序员因为需求的变动而加班时恒古不变的话题，归根到底还是没有集中精力来做最重要的事情。一个系统的核心功能如果每天都在变，那还叫什么核心功能呢？还有什么核心竞争力了呢？我觉得项目结束后最应该总结的就是这些问题。解决的办法在我看来就是开发出一个feature列表，指定优先级，先做（沟通）优先级最高的那些。保持与项目利益相关者的沟通是极其重要的，这也是优秀分析人员（包括系统分析和业务分析）存在的真正价值。