个人与团队知识管理方法：AAR事后回顾，向新鲜的过去学习

　　AAR，短、平、快，轻巧的知识管理方法，真好。推荐大家都学习学习。
　　事后回顾，AAR（AfterActionReview）最早是美国陆军所采用的一种知识管理方法。由于这种方法可以短、平、快的面向新鲜的过去学习，并且能够马上响应到下一次的行动中，所以被越来越多的企业所采用。英国石油、摩托、GE、华为等众多企业先后引入，并且形成了有组织、有认证、有流程的知识管理方法。
　　结合众多企业的事后回顾方法实践，梳理总结出要做好事后回顾的应用场景、三条原则及具体流程。
　　1。事后回顾的应用场景
　　事后回顾基于当下已发生的任务、活动、事件等，可以采用正式与非正式的方式展开，并且产生的结果可以直接应用于下一步的有效行动。所以可应用的场景比较广泛。
　　场景一：市场部刚完成了公司上海大客户分享活动，下一步要在北京召开，基于此活动开展事后回顾；
　　场景二：知识平台交付项目分为三个迭代，第一个迭代刚上线，基于此任务开展事后回顾；
　　场景三：公司HR团队，每月例会，针对当月新招聘人员的入职情况可以做事后回顾；
　　场景四：技术团队攻坚解决了突发的服务器宕机事件，基于此事件开展事后回顾；
　　场景五：和家人计划7天的国庆出游计划，第1天完成了，基于此做事后回顾；
　　场景六：我在梳理与构思AAR文章，完成文章后，自己快速做事后回顾；
　　场景七：
　　由上可以看出来，事后回顾可应用的场景是比较多的，可以是事件的关键节点，也可以是重复事件的例行节点，可以由问题触发的，也可以由成功的案例触发。并且由于事后回顾方法的轻巧性，可以及时开展，并不限于外在的条件。
　　2。事后回顾的三条原则
　　要通过事后回顾，从过去成功或失败的经验中学习，并且能够转化成下一步的有效行动。就需要掌握这三条基于经验总结出来的原则。
　　原则一：新鲜过去
　　新鲜、及时是事后回顾的关键切入点。刚完成的任务、完成的活动、刚经历的事件。要及时的以刚刚的过去为基础组织事后回顾活动，特别是对于循环性的活动更有效果。并且事后回顾不会对事件做深度的分析，比如场景二中迭代交付的案例，我们只针对当前的迭代做分析，以此来促进下一次的交付，而不是深入分析整体的迭代是否安排适当。
　　原则二：简单结构
　　事后回顾需要简单，简单是指不要局限于当下的条件，也不要做长时间的投入。场景四中，技术团队解决了宕机的问题可以及时组织相关人做事后回顾，组织正式的会议场所，也可以就地非正式的快速回顾。结构，是指事后回顾需要结构化的组织、流程化的展开，需要有适当的准备。分为准备、执行、跟进三个阶段。每个阶段都有需要关注的点。
　　原则三：积极行动
　　事后回顾不是对失败事件的批评教育会议，也不是对成功事件的表扬邀功事件。要做好事后回顾，就得团队整体抱着积极的心态，面向未来，面向下一步的有效行动。基于事实客观分析，通过大家的群体智慧，找到好的经验与改进机会点。事后回顾也需要依照引导原则，杜绝变成领导的一言堂会议。
　　3。事后回顾的具体流程
　　事后回顾分为三个阶段：准备阶段、执行阶段、跟进阶段。每个阶段都有对应的关键原则与方法。这里以企明某次客户知识管理平台交付第一轮迭代上线完成后的事件为案例。
　　1）准备阶段，做好5W1H
　　基于新鲜的过去及时开展事后回顾，准备阶段主要由事件的触发人与事后回顾引导员（或是掌握了事后回顾方法的人员）完成。主要要做好5W1H工作：
　　Why：为什么召开事后回顾会议，是因为到了一个周期阶段点了，还是因为什么事件？
　　因为知识管理平台交付项目第一轮迭代上线了。
　　Who：由谁来组织引导？还需要哪些人员参与？
　　项目经理黄江触发，公司知识管理人员王祚引导，项目团队成员牛文涛、申川、王朋朋、杨佳胜参与。
　　What：回顾什么事情？例行的周期结束了，要改进下一步？还是有好的或是坏的经验可以用在下一步？
　　回顾第一轮迭代交付的过程，找到问题的原因，找出成功事件的因子。
　　When：什么时候开展，具体的时间？
　　2017年10月16日下午2：003：00
　　Where：在哪里开展，会议室还是站立会议，还是客户现场？
　　在公司开放会议区。
　　HowLong：需要多长的时间，建议控制在1小时之内。
　　需要1个小时的时间。
　　完成了上述内容也就清晰了事后回顾的基础范围，参与人员才可以聚焦的完成目标。
　　2）执行阶段，回答4个问题
　　执行阶段，需要要专门的引导人员，也就是熟练掌握事后回顾方法的知识人员。通过轮流发言、小组讨论、头脑风暴的方式，针对一个个事件点回答以下四个问题。这里以场景二项目中的期刊功能点为示例，项目中有多个需要讨论的点，就不一一展开。
　　问题一：我们原先的期望结果是什么？
　　新功能期刊模块能够按时高质量上线。
　　问题二：实际产生的结果是什么？
　　变更到测试环境时才发现开发的期刊发布功能与需求不一致。导致期刊没有能按时上线
　　问题三：为什么会产生差异，能学到什么？
　　期刊模块中的发布功能，需求分析人员、开发人员理解不一致，导致开发的功能不是最终的需求。根本的原因是期刊模块是基于产品实施的，开发人员想当然的理解成客户的需求与产品的需求一致。
　　问题四：下次再发生，我们将怎么办？
　　基于下一轮迭代的需求点，需求与开发人员一一沟通，找出可能存在的潜在异义需求点。公司内的其他项目人员也要避免认为对方想当然知道的问题。
　　基于当前事件，可以拆分出多个点，每一个点都回答上面的四个问题，最终产出本次事后回顾会议的知识与经验点。
　　3）跟进阶段，完成2个闭环
　　执行阶段通过会议的方式分析出所有的关键点之后，还需要针对每个点梳理出对应的改进计划与传播计划。也就是要完成行动与经验的闭环。还以上面的第一轮交付为案例，将会产出如下的表格信息。
　　事后回顾，通过对已完成事件的回顾，找到问题点或优秀点，应用在下一步的行动中。特别要注意的是，除了要找到问题点跟踪改进，还需要将此信息分享给可能涉及到的人员，同时也要刷新公司内的知识案例。