起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識個人與團隊知識管理方法：AAR事后回顧，向新鮮的過去學習
AAR，短、平、快，輕巧的知識管理方法，真好。推薦大家都學習學習。
事后回顧，AAR（After Action Review）最早是美國陸軍所采用的一種知識管理方法。由于這種方法可以短、平、快的面向新鮮的過去學習，并且能夠馬上響應到下一次的行動中，所以被越來越多的企業所采用。英國石油、摩托、GE、華為等眾多企業先后引入，并且形成了有組織、有認證、有流程的知識管理方法。
結合眾多企業的事后回顧方法實踐，梳理總結出要做好事后回顧的應用場景、三條原則及具體流程。
1.事后回顧的應用場景
事后回顧基于當下已發生的任務、活動、事件等，可以采用正式與非正式的方式展開，并且產生的結果可以直接應用于下一步的有效行動。所以可應用的場景比較廣泛。
- 場景一：市場部剛完成了公司上海大客戶分享活動，下一步要在北京召開，基于此活動開展事后回顧；
- 場景二：知識平臺交付項目分為三個迭代，第一個迭代剛上線，基于此任務開展事后回顧；
- 場景三：公司HR團隊，每月例會，針對當月新招聘人員的入職情況可以做事后回顧；
- 場景四：技術團隊攻堅解決了突發的服務器宕機事件，基于此事件開展事后回顧；
- 場景五：和家人計劃7天的國慶出游計劃，第1天完成了，基于此做事后回顧；
- 場景六：我在梳理與構思AAR文章，完成文章后，自己快速做事后回顧；
- 場景七：…………
由上可以看出來，事后回顧可應用的場景是比較多的，可以是事件的關鍵節點，也可以是重復事件的例行節點，可以由問題觸發的，也可以由成功的案例觸發。并且由于事后回顧方法的輕巧性，可以及時開展，并不限于外在的條件。
2.事后回顧的三條原則
要通過事后回顧，從過去成功或失敗的經驗中學習，并且能夠轉化成下一步的有效行動。就需要掌握這三條基于經驗總結出來的原則。
原則一：新鮮過去
新鮮、及時是事后回顧的關鍵切入點。剛完成的任務、完成的活動、剛經歷的事件。要及時的以剛剛的過去為基礎組織事后回顧活動，特別是對于循環性的活動更有效果。并且事后回顧不會對事件做深度的分析，比如場景二中迭代交付的案例，我們只針對當前的迭代做分析，以此來促進下一次的交付，而不是深入分析整體的迭代是否安排適當。
原則二：簡單結構
事后回顧需要簡單，簡單是指不要局限于當下的條件，也不要做長時間的投入。場景四中，技術團隊解決了宕機的問題可以及時組織相關人做事后回顧，組織正式的會議場所，也可以就地非正式的快速回顧。結構，是指事后回顧需要結構化的組織、流程化的展開，需要有適當的準備。分為準備、執行、跟進三個階段。每個階段都有需要關注的點。
原則三：積極行動
事后回顧不是對失敗事件的批評教育會議，也不是對成功事件的表揚邀功事件。要做好事后回顧，就得團隊整體抱著積極的心態，面向未來，面向下一步的有效行動?；谑聦嵖陀^分析，通過大家的群體智慧，找到好的經驗與改進機會點。事后回顧也需要依照引導原則，杜絕變成領導的一言堂會議。
3.事后回顧的具體流程
事后回顧分為三個階段：準備階段、執行階段、跟進階段。每個階段都有對應的關鍵原則與方法。這里以企明某次客戶知識管理平臺交付第一輪迭代上線完成后的事件為案例。
1）準備階段，做好 5W1H
基于新鮮的過去及時開展事后回顧，準備階段主要由事件的觸發人與事后回顧引導員（或是掌握了事后回顧方法的人員）完成。主要要做好5W1H工作：
Why：為什么召開事后回顧會議，是因為到了一個周期階段點了，還是因為什么事件？
因為知識管理平臺交付項目第一輪迭代上線了。
Who：由誰來組織引導？還需要哪些人員參與？
項目經理@黃江 觸發，公司知識管理人員@王祚引導，項目團隊成員@牛文濤、@申川、@王朋朋、@楊佳勝參與。
What：回顧什么事情？例行的周期結束了，要改進下一步？還是有好的或是壞的經驗可以用在下一步？
回顧第一輪迭代交付的過程，找到問題的原因，找出成功事件的因子。
When：什么時候開展，具體的時間？
2017年10月16日 下午2:00~3:00
Where：在哪里開展，會議室還是站立會議，還是客戶現場？
在公司開放會議區。
How Long：需要多長的時間，建議控制在1小時之內。
需要1個小時的時間。
完成了上述內容也就清晰了事后回顧的基礎范圍，參與人員才可以聚焦的完成目標。
2）執行階段，回答 4 個問題
執行階段，需要要專門的引導人員，也就是熟練掌握事后回顧方法的知識人員。通過輪流發言、小組討論、頭腦風暴的方式，針對一個個事件點回答以下四個問題。這里以場景二項目中的期刊功能點為示例，項目中有多個需要討論的點，就不一一展開。
問題一：我們原先的期望結果是什么？
新功能期刊模塊能夠按時高質量上線。
問題二：實際產生的結果是什么？
變更到測試環境時才發現開發的期刊發布功能與需求不一致。導致期刊沒有能按時上線
問題三：為什么會產生差異，能學到什么？
期刊模塊中的發布功能，需求分析人員、開發人員理解不一致，導致開發的功能不是最終的需求。根本的原因是期刊模塊是基于產品實施的，開發人員想當然的理解成客戶的需求與產品的需求一致。
問題四：下次再發生，我們將怎么辦？
基于下一輪迭代的需求點，需求與開發人員一一溝通，找出可能存在的潛在異義需求點。公司內的其他項目人員也要避免認為對方想當然知道的問題。
基于當前事件，可以拆分出多個點，每一個點都回答上面的四個問題，最終產出本次事后回顧會議的知識與經驗點。
3）跟進階段，完成 2 個閉環
執行階段通過會議的方式分析出所有的關鍵點之后，還需要針對每個點梳理出對應的改進計劃與傳播計劃。也就是要完成行動與經驗的閉環。還以上面的第一輪交付為案例，將會產出如下的表格信息。
事后回顧，通過對已完成事件的回顧，找到問題點或優秀點，應用在下一步的行動中。特別要注意的是，除了要找到問題點跟蹤改進，還需要將此信息分享給可能涉及到的人員，同時也要刷新公司內的知識案例。
本文由 @王寶明 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基于CC0協議
- 目前還沒評論，等你發揮！
