几年前，我接到一个项目的求助电话。等我参与的时候，项目正处于发布周期的中期。我跟团队成员一起识别出他们可以交付什么、应该交付什么、还有哪些应该推迟。项目团队后来也按可交付物列表完成了交付。
发布之后，我建议团队召开回顾会议，看看有哪些工作是在下一次可以改进的。副总裁却认为没有人能从回顾中学到东西。
他忘了我为什么要来帮忙，光注意到了大家的成功。他说：“不过大家这次干得很不错。他们满足了我们对这个版本的所有要求。”
他的话把所有的问题一扫而光——特别是优先级的变更——灰都被扫到地毯下面了。团队里可没人觉得自己做得有多好。副总裁的话不再可靠了。项目团队成员感到疲惫不堪。这个版本一开始要求的有些功能不做也是可以的，如果项目团队一开始就能知道这一点，开发人员就可以集中开发最需要的功能了。
下面这些主意可以避免这个游戏。
- 把某个版本需要的功能先按优先级进行排序，再实现。（排序意味着1、2、3、4、5、6，诸如此类。）参见8.3节。
- 逐个实现各功能。如果按照架构进行开发，就会形成很多部分完成的功能，没有哪个是完全开发完成的。而且架构会随着项目进展演化，很多管理层也认识不到这一点。参见9.3
- 制订发布条件，项目经理在项目开始时就可以讨论当前版本需要的东西。参见2.3节。
如果总是遇到“把灰扫到地毯下面”的问题，可以试试下面的方法。
- 使用产品待办事项列表，功能按业务价值进行排序。这样，你就总是在完成最有价值（也就是最重要）的工作。
- 使用有时间盒限制的迭代，并逐个实现各功能。项目经理和团队成员可以看到进展，并且总是最先提供最有价值的功能。
要想利用上述规避策略，就得在项目开始时与项目干系人对话，而且这些对话很难进行。不过其有益之处在于：如果没有交付任何东西，没人会假装项目是成功的。相反，团队可以把精力放在为了成功交付必须要做的事情上，而且只做这些。
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※