一般软件开发组织，在软件项目结束时会进行项目总结会，利用项目中的统计数据对项目中发生的成败得失进行总结分析，然后制定出改进计划，以希望在下次项目可以做的更好。然而，多年过去之后，对比一下现在的数据和当初的数据，基本上可以得出一个结论：这么多年没有丝毫改进，甚至还有退步的迹象。
这是发生在很多地方的现象。为什么会发生这种现象呢？本人就那些无用的项目总结会以及无用的过程改进建议进行原因分析以及提出解决对策。
项目总结会的原意是遵照戴明环(P-D-C-A)进行改进的一种方式。它通过对项目发生的成败得失进行总结，并且制定详细具体的行动方案，以达到团队能力成熟度提升的目的。
项目总结会要由以下要素构成：
时间、地点、人物、数据、分析过程、分析结果、改进建议、行动方案计划、改进过程监督、改进效果评估、结论。
有些组织甚至连上述的必要要素都不全面，比如：项目总结之后没有改进计划。
对于要素全面的组织来说，他们还有下列问题：
- 时间不对
大部分组织的项目总结会时间不对，他们选择在项目结束后，数据统计完毕再开始召集相关成员召开会议。这是一个错误的时间。基本上软件项目都要半年以上，而人们无法记住海量的事情，并且将细节能够完全还原，尤其是经过了这么长时间。所以，项目总结会，往往变成了项目追思会。
当表达方式中像下面这样的词汇出现比较频繁的时候，基本上就说明了这个问题。
“当时好像是”“我记得当时”“大概情形是这样的”
基于这样的信息如何能够做出准确的判定呢？
所以项目的总结会应该短周期频繁的召开，建议周期为4-6周一次。
总结，前一段时间发生的事情，这时候记忆犹新，可以相对正确指出其中的问题，并且得出合理的改进建议。
但是，反对者认为，对详细设计的总结无助于代码书写的改进。关于这一点，我将在《荒谬过程》里逐步阐述其观点中的基本错误。
- 参加人选有误
有的组织有SQA，基于组织整体改进的要求，项目总结会的时候会叫上SQA，有助于对数据进行分析，例如：整体组织的生产率为300行/人月，但是某团队的生产率为1000行/人月，那么SQA会提出这个数据严重超出平均水平，从而得出：过程不够规范的结论，从而要求一个高效的团队降低其开发速度。这样的荒谬结论就是因为参照了荒谬的标准造成的，而SQA的作用基本上是奖恶罚善，所以，叫SQA来参加项目总结会是大错特错。具体为什么说SQA是奖恶罚善，我将会在《搅混水的SQA》里详细说明。
对于动辄上百人的团队，也考虑到不会让所有人参加会议，于是只叫了几个“管理人员”参会，于是大家开始一场望风扑影的讨论，结果就形成了一套风马牛不相及的结论。
- 数据意义不大
现在团队统计的数据往往都不具备参考价值，即使那个数据是真实而准确的，因为统计的数据意义本身是错误的。具体请参照拙作《你的项目统计这些数据吗？》
基于无意义的数据做出的结论也是无意义的，得出的改进方案也是隔靴搔痒的。
- 分析过程浅尝辄止
分析原因要分析根源原因。很多原因分析过程往往停留在表面，不愿意深入分析，例如，把Bug产生的原因归为代码书写错误，这无助于改进代码书写，代码书写错误的原因是设计有误，还是理解有误，还是技术力不足，还是别的什么原因。分析原因的时候应该不断地问为什么，直到找到真正的原因，并可以制定出改进措施为止。否则，停留在表面的分析是无法得出正确的改进措施的。
- 知识不足，无法分析出真正原因
虽然有些组织，可以通过不断地问为什么，然后制定改进措施，但是由于其知识的不足，其分析原因的路线产生了错误，只能得到错误的结论。
有一个非常生动的例子，是一个关于缺少了某判定条件产生的处理错误的分析过程。
为了后续说明方便，我把每个分析步骤增加了字母标号。
- Bug产生的原因是代码书写错误
- 代码书写错误的是因为设计有误
- 设计有误的原因是条件分析不足
- 条件分析不足的原因是考虑不周
- 考虑不周的原因是因为缺少辅助分析的检查单
- 改进措施就是建立分析辅助工具——条件分歧检查单
这个过程看似无懈可击。但是这个分析过程的根本问题在于知识体系不足。我们让另外一个专家来分析这个问题的产生原因，他是这样分析的，为了区分上述过程，我在字母后面加上了数字1.
A1. Bug产生的原因是代码书写错误
B1.代码书写错误的原因是因为违背了单一职责原则
C1.违背单一职责原则的原因是开发者缺少相关知识
D1.改进措施是进行面向对象技术培训。
为什么两个分析过程的起点相同，却达到了不同的路径。因为前者缺少相关的知识，他认为对于设计过程增加了相关的检查单就可以解决问题，但是，每种情况的复杂度都不同。如何通过一个检查单来覆盖所有的分支处理呢？
其实，原来代码的if-else嵌套可以通过面向对象的一次调用以及若干重载来代替，这样就可以从根本上来规避条件缺少的问题，因为这规避了问题产生的直接原因：影响逻辑的变量太多。但是，第一个分析者并不了解面向对象技术可以很好地解决问题，所以沿着自己的思路得到了错误的结论。
- 改进措施无法实施
有些组织的改进计划都是些笼统的如：提升设计能力，加强沟通。
有的略具体一点，但是却仍然无法指导行动，比如：增加代码复查时间。
有的很具体，但是无法实施；
有的可以实施但是却没有负责人；
有的有负责人，却没有设定完成时间；
有的有完成时间，却没有检验改进效果的方式；
改进措施要具体可行，并且要跟踪改进效果。
首先要具体。
避免使用：加强、提高、提升等模糊的词语，改用增加、减少、替换、交叉、建立等明确可以执行的动作。
其次要可行。
如果设定的改进方案无法执行，那么分析了也无法进行改进。
再次要有时间限制。
改进措施不可能无限期延长。需要有明确的执行时间限制，并且如果有必要还要设定里程碑，分阶段的改进。有些事情不是一蹴而就的。
然后要有负责人。
改进措施如果没有安排负责人，往往会束之高阁，置之不理。最后，也没有进入真正的改进行动。
最后要有检查效果的方式。
如果改进措施实施了，但是却没有检查改进效果，那么到底改进措施是否有效就无从可知了。
- 改进措施无效
改进措施无效往往是由于前面几个原因中的一个或多个产生的。比如：针对“需求变更导致了后期工时的增加，从而引起了项目的延期。”提出的改进措施是及早冻结项目需求。然而，客户根本无法冻结项目需求，因为制定需求是一个Guess work。这个改进措施根本无法执行，也就没有效果。
- 管理人员误导
A． 绝对表达的谬误
常见的管理人员的一句质疑是：“如果xxx是问题的原因，那么解决了这个就能够解决问题吗？”这句话是一种绝对表达的反问句。没有人会回答Yes。因为导致问题发生的原因往往是多方面因素造成的。而并非单方面。因此谁也不能说解决了这个就解决了所有问题。于是一条可以改进的措施就被否决了。
B． 不愿意对固有的但是根本上的东西进行变革
对于很多项目来说，其根本的原因是流程错误，但是很少有分析的时候能够得出这个结论。一方面固然有知识不足的原因，另一方面，即使有人提出是过程的问题，管理人员为了维护自己的尊严，不愿意承认这方面的问题，往往会提出反对意见，顾左右而言他，推卸责任。有时还进行人身攻击。
C． 不愿意承认工具落后
管理人员喜欢用一句话来掩盖工具落后的问题：“明白原理比使用工具更重要”。这句话是正确的废话。
以上是对于无用项目总结会的分析和改进措施。你有什么见解？