很多时候，一个项目结束了，无论是成功的，还是失败的或者差强人意，教训总结都应该会有的。但是我总觉得在软件开发过程中，项目结束后的总结大多数都被看成了可有可无的阶段。即使像模像样的做了项目的总结，会也开了不少，总结的好的方面，需要改进的方面也都按照模板写了文档。但最后，这些活动的矛头还是指着这个已经过去的项目，因此得出的那些文档，成果只能束之高阁，无人问津。然后下一个项目同样的重复相同的问题和风险。
今天无聊的时候看了一下30多年前美国迈阿密的那个401航班事故的调查，这让我觉得我们有很多可以借鉴的东西。先说一下401航班坠毁的前因后果吧。航班准备降落的时候，放下起落架时候，指示灯坏了，然后机长，副驾驶，机械师都在捣鼓这个事情，结果，飞机在自动驾驶状态鬼使神差的高度由20000英尺下降到了900英尺。等机组人员反应过来已经晚了，惨剧就这样发生了。管理部门调查坠毁原因的目的只有一个，避免相同的惨案再次发生。下边是调查的结果以及对策。
- 当时机长和其他飞行员都把精力放在那个几美元的灯泡上了，没人注意仪表，近地报警。
对策：制定一个叫做CRI的制度，保证机长，飞行员和其他人员各负其责，最大限度避免人为失误。 - 地面塔台控制人员发现飞机高度失常，但当时怀疑是雷达数据错误，并且他的职责只是保证飞机之间保持安全距离。
对策：改变规则，地面指挥人员也负责监控进场飞机的各项数据，有异常时候能及时发现。 - 当时飞机上使用的自动驾驶程序有问题，如果有人触动了方向舵，自动驾驶会退出。正是这种情况造成了飞机高度的下降最后坠毁。而所有空乘人员都对此毫不知情，也没有过相关培训。
对策:飞机制造商对飞机程序进行调整，避免无意识触碰导致程序修改，同时培训飞行人员相关处理手段。 - 由于机长当时起落架的事情总搞不定，很紧张，脾气很坏，这也传染给了其他人，造成动作失误。
对策：对飞行员进行培训，保证操作的一致性，保持冷静不会被其他人情绪感染。
我们能从中看到什么呢？这些措施对我们改进软件开发好像用处不大。除了最后一条，如果我们团队中有人出了错误，我们要知道这是不可避免的，是人就会犯错误。但是我们要把握两点，一是责任明确，不能无端扩大责任面。二是充分认识，保证负责人真正认识到错误。 其实我说的是经过缜密调查得出的这些原因都有非常切实可行的纠正措施，避免相同的问题再次出现，因此这些纠正措施很容易的就都得到了很好的贯彻。
相反，如果我们某个项目出现问题了，通常的解决办法都是很少过问团队事情的某高层领导，召集所有人员召开紧急会议。然后在会上制造紧张空气，大发脾气，然后让大家讨论找出问题所在和解决方案。然后就是一个诉苦大会，开发人员早就牢骚满腹，时间紧，任务重，资源不够，没有外部支持，然后就是具体技术细节的大讨论，你知道技术人员很容易过早的纠缠到具体技术细节上。这时候，高层领导已经蒙了，都知道一般情况下高层领导对技术是知之甚少的。最后么，要么就是不了了之，要么就强调一下贯彻公司开发流程之类的，最后警告一下下不为例。
可以看出，我们从其他行业，产业能够借鉴的东西很多的。其实，其中的理念就涉及到了，组织级的过程改进，开发流程的自我完善等等。CMMI对过程改进是非常重视的，尤其是开发过程中收集量化的数据用来和基准数据进行比较，采取修正措施，并对我们基准数据进行丰富。 这样才能使我们的流程更加合理，更能是人信服，也更能进行贯彻。 大家可以找些相关资料查阅一下。
