项目后会议浪费时间？

在我的工作地点，我们遇到了一些严重的成长难题。我们的开发团队从3人增加到10人，过去一年公司本身增长了30％。从大多数方面来看，我们做的很好。不幸的是，我们的软件质量受到了影响。

在今天与部门经理的会面中，我提议了一个项目团队，在产品发布后一两天会面。我们可以讨论预算问题，范围，出了什么问题以及什么是正确的事情。理想地，从我们的错误中学习。我们为其他人构建网站/应用程序，因此我们的时间要么是可计费的，要么是不可计费的。这样的会议将属于后者。

我的经理几乎立即就把它拒之门外：“那段时间是不值得的。这会使我们落后于另一个项目，因为在那个项目结束时我们会浪费时间。” 我对这种逻辑感到措手不及，以至于我什至没有打扰他。

所以我的问题是：我认为最有价值的是项目后会议，但他没有。是否有文件证明的项目后会议可以长期或短期节省时间和金钱？直觉上，我认为这会/将会，但是他显然更担心需要在那里的5个人提供​​少量的非计费时间。

回顾，展望未来将接近该想法的书面证明。 项目后事态：持续改进的重要工具将是有关此事的博客文章。

关于后概念的艺术对这一观点有以下观点：

后事态的起源是军队，他们通常使用这种程序向前线人员汇报。但是其管理应用程序对于任何高性能，学习型组织都是必不可少的。

您的经理不理解技术债务的概念。

项目后会议是投资，而不是费用。那就是你必须出售它们的方式。任何会议的目的都是就长期节省金钱和实现公司目标交换意见。

您的经理是经理，因为他负责这些长期目标。因此，在我看来，有两个可能的真理：您的经理想要自己掌握所有控制权，或者您的经理没有做好自己的工作。如果公司有“正确地做事”并为自己的成功进行投资的历史和哲学，请考虑将问题置于您的经理之上。

这本质上是事后审查，在许多不同的情况下特别有用，而不仅仅是军事方面。

我自己的开发周期包括分析在下一个迭代或项目中应该做什么以及在上一个项目中可以更好地完成。即使一个项目被搁置了一段时间，当项目现成的（或后备式的……）又是一个活跃的项目时，列出要处理的事情也是有帮助的。下次我触摸它时，我不必花费太多时间来回顾我需要做的事情。

另外，通过审查一个项目并找到我或其他人已经实施的巧妙技巧，可以传播这些技巧，下一个项目或下一个迭代要好得多。（我经常在迭代方面考虑不足为奇。）

其价值是简单的逻辑，并且本质上显而易见。如果您从以前的项目中从未汲取教训，您将如何改进未来的项目？

尽管没有专门的文档，但对流程的审查（在过程中或完成后）是我所知道的几乎每个基于标准的质量控制系统（尤其是CMMI和Lean 6 Sigma）的主要组成部分。

也许您可以将其提议为一项义务，而不是在午餐会上自愿完成的事情或其他提议？很有可能您的开发团队中的很多人都渴望来尝试新事物……因此，如果您至少可以摇摆第一个，结果将说明一切。

可能是您的经理承受预算压力。在短时间内从3个开发人员扩展到10个开发人员时，这是一个大问题。如果是这样，那么最好暂时跳过事后会议，再过几个月再提出建议，这是希望立即预算问题不会那么紧迫。

质量可能受到影响的一个原因是，十个人之间的交流比三个人之间的交流要困难得多：3！<< 10 !. 虽然您可能会混在一起一段时间，但最终您将不得不进行一些更改，以促进开发人员之间更好的沟通，并确保将最初3位开发人员建立的原则传播到较新的人，并且已更新，可以在新的较大人群中很好地工作。项目验尸会议是做到这一点的一种方法。定期代码审查是另一回事。指出验尸会议是从医学到制造业等行业质量改进的关键部分，这一点无可厚非。

很难想象您的经理相信他可以通过雇用更多人员来扩展自己的开发团队。绝对必须在培训和团队建设上进行一些投资；没有这些，您的组织将在自己的负担下崩溃。如果稍等片刻，您的组织可能会开始遇到一些具体问题，这些问题直接归因于沟通不畅。那时，您的经理可能会说：“我们必须让所有人都在同一页面上！安排与所有开发人员开会。” 如果看起来有帮助，他可能会说：“我们应该在每个项目之后都这样做！” ;-)

因此，要耐心，但要坚持不懈。

我会逆势行事：我同意经理的说法。

我发现项目后的审查基本上没有意义，因为为纠正所发现的问题而做任何事情都为时已晚。

我最强烈推荐的是在项目期间进行的定期回顾。 每个月要让团队讨论一次或两次进展顺利的事情，而不是一次。多做些什么，少做些什么。在项目执行期间执行此操作，以便您可以立即应用建议并查看其效果如何。

看一下如何使会议变得愚蠢。许多项目后会议都很热闹，您的经理绝对正确地表示不支持他们。

邀请您参加会议（请他主持/主持会议），分发议程并取得具体成果。作为经理，他然后可以在会议中看到其价值。

我们使用并且我推荐de Bono的“ 6 顶帽子”审查过程（请参阅Wikipidia）。结果是会议将其识别为最重要的学习教训的几个（2或3个）行动要点。最初的几次，我们很难摆脱起跑的障碍，但是一旦我们习惯了，就再也回不去了。

不执行项目后审查会使您犯下与上一个项目相同的错误。