Review of Debugging the development process 4. Unbridled Enthusiasm

这几天blog太不稳定了，真是有点烦。

Try to limit the number of reports you ask other team members to write. Be sure that every report you ask for will provide more value to you or the company than would be lost by interrupting the writer's work.
有一种很值得花功夫去写和读的报告，就是项目的检讨报告，也就是开发小组在产品刚完成不久所写的分析报告。分析报告主要是针对“我们能从刚完成的项目中学到什么？”这类的主题进行探讨，并且检讨我们哪里做对了(就继续这样做)，哪里做错了(下次如何避免再犯)。
写一份项目检讨报告，除了指出发现的问题，提出看法和意见，还要建议如何防范这个问题，把详细的步骤一并写出来，这样才能让下一次的项目进步，不重蹈覆辙。
最好不要等到项目完成了再来回想有什么值得写(搞不好已经忘了一大半)，应该在每一次遇到问题、并发现好方法可以解决时，就顺手记下这项发现，何必等项目结束时再来学习？经验的累积是随时的。

Postmortem reports are invaluable when you do them correctly. Unless your postmortem reports explain exactly how you intend to fix known problems or exploit known improvements, though, the reports probably aren't worth doing.

Before you call a meeting, be sure the results you think you'll get from that meeting are worth the disruption to the work of the people who would have to attend. Be particularly wary of any regular meeting. Regular, standing meetings often aren't worth the time to walk to them, much less attend.

If you must hold a meeting, minimize the amount of interruption it will cause. Schedule the meeting so that it won't break up an otherwise large block of time.

Whenever you call a meeting, be sure you know ahead of time exactly what you're trying to accomplish, and then make sure you do accomplish it. Remember also that conditional decisions are better than no decisions.
这些关于会议的观点作者好像在第一章就已经提过了，这次只是阐述的更详细了一些。