经验和教训的总结通常放在项目的最后

　　如果问题不针对特定的团队、项目或技术，也会因为太过模糊而失败

　　让我们逐个分析上述三个方面为何失败。

　　针对特定团队、项目和技术方面找问题

　　大多数在经验教训总结会上被提出的问题只集中在那些已经完成的项目。但即使同一个团队，也不会可能会再做一个项目，一些与具体项目相关的问题也可能也不会出现在下一个项目里。另外，不同项目中采用的技术手段也会出现差异。结果就造成，针对特定团队、项目或者技术的经验教训总结会变得一无用处。

　　经验教训总结会通常放在项目的最后

　　传统的经验教训总结通常会在项目结束之后进行，大概是为了提醒团队在下一个项目不犯类似的错误。但这种的方式的问题在于，很多人甚至不记得两周之前发生过什么，更别说有的长达半年后两年的项目了。试图回忆一年前项目中经验教训几乎是不可能的。此外，前文已经说过，如果是对已经完工项目的经验总结会，那么几乎是没有任何意义的：没有人能从中学到什么，也不会产生任何对未来项目有用的知识。这两方面决定这项措施必然会失败。

　　如果问题不针对特定的团队、项目或技术，也会因为太过模糊而失败

　　为了解决上述两个问题的困境，人们会将某些概念或问题一般化，希望能形成指导任何项目实行的一般性建议。如果我们试图这么做，那么这些所谓的普世经验或教训显得荒谬和可笑。我听过像“沟通是很重要的”、“股东们应该更关注公司发展”、“预算一定是可控的”之类的“普世经验”。这些表述是确实非常正确，但也是没有意义的，因为他们没有从根源探寻问题本质，也没有给出创造性的解决方法。那该怎么办?几乎每一个可提供真正生产效率的问题都是由特定的团队、项目或技术相互作用的复杂产物。任何一个项目都有其特定的问题，很有能有放之四海而皆准的解决方案。

　　从精益或敏感管理方法里会学到什么?

　　传统的经验教训总结会与精益或敏感管理方法里的经验教训总结有着本质上的不同，具体来说，表现在方法、时间以及为什么要进行经验教训总结等方面。传统的经验教训总结为了不再重犯之前的错误，而精益或敏捷的经验教训总结(通常称作回顾或改进会)则是为了立刻纠正现有项目中的错误。他们会非常频繁的开会，花时间去解决现有项目中的一些问题。

　　改变项目经验教训总结会的目的和周期，可以克服传统方法里的三大困难。下面我们来看一下是如何解决这些难题的。

　　针对特定团队、项目和技术方面找问题。

　　依然是针对特定的团队、项目或技术寻找问题，但因为队员们正在使用技术执行项目，所以这时的总结很有效。团队成员在总结会上对一些问题解决起来得心应手。

　　经验教训总结会通常放在项目的最后

　　精益或敏捷的总结会不会放在项目收尾阶段。他们会两到四周举行一次会议。这会产生以下三个方面的成效：

　　你很容易记住那些做的很棒的工作，也明白哪些工作还需要提升。同时，你也可以非常方便的制定短期目标，待到下次总结时确认是否完成。

　　总结会放在项目中间阶段，会使得团队根据项目进展情况迅速解决。

　　因为总结会每隔几周就有一次，团队可以及时检查哪些措施比较有效，并对一些无用的措施进行改进。

　　如果问题不针对特定的团队、项目或技术，也会因为太过模糊而失败

　　在回顾或改善总结会，问题是不会一般化处理的。如果会议能对问题进行根本分析，并提出非常明确地解决方案，那么这个会议是不会结束的。这些解决方案会在下一次总结会上就实施情况再做总结。

　　即使某个项目是由传统方法驱动的，任何人也可以将精益或敏捷方法实施在项目的经验教训总结上。