如何更好地完成一个项目的「事后分析」？
原文载于FYI - Search and organize all your documents in one place，
作者Marie Prokopets,Co-founder of FYI
「事后分析」的质量，完全取决于你的分析是否到位。
如果进行了正确的分析，团队将会不断地改进每个项目。
如果分析错误，团队就会陷入一个怪圈中，就像在跑步机上跑步一样，虽然跑了很久，但基本上一直待在原地，而且也会不断重复同样的错误。
当我要求我的团队成员对一个失败的项目进行分析的时候，我经常得到这样的回答：
「这个项目之所以失败，是因为客户不想要它。下次我们需要尝试一些其它的东西。」
没有细节，没有对错误的深刻理解，没有下次该如何真正的学习，也没有真正的行动步骤。当被要求进行分析时，大多数人都会默认进行这种宽泛而无用的总结。
虽然这曾让我感到沮丧，但现在我明白了为什么会发生这种情况。让某人对一个项目进行「分析」，是一个极其宽泛的要求。宽泛的要求，通常会得到宽泛的回应和宽泛的结果。
那么，一个优秀的「事后分析」应该是什么样的呢？它将会有下面的一些组成部分：
l 一份列有可以做得更好的问题清单。
l 能够正确识别出少数几个阻碍项目的主要问题。
l 如果项目进展顺利，准确地挑选出成功的部分。
l 对于哪些经验不显而易见的地方，组织可以采取的行动。
l 要对将改善下一个项目成果的行动步骤负责。
现在，我用一种能让人们可靠地核对这些方面的方式来构建「事后分析」。
有什么方法可以得到一份很好的「事后分析」呢？
5个「为什么」分析方法
5个「为什么」，是一种非常经典的分析方法，能够适用于任何类型的项目分析。
与「解释为什么有些事情会发生然后继续前进」相比，我们会连续问五遍「为什么它会发生」。这会迫使我们找到造成问题发生的根本原因，而不只是专注于问题的症状，最后「治标不治本」。
例如，假设因为一封电子邮件发晚了，导致一个营销活动没有达到目标。 以下是如何应用「5个为什么」的步骤：
营销活动的结果=没有达到营销目标。
l 为什么？ 因为电子邮件没有按时发送。
l 为什么？ 负责发送电子邮件经理忘了要发电子邮件。
l 为什么？ 在需要发送邮件的那天，他没有设置任何提醒。
l 为什么？营销经理还没有建立向团队发送提醒的系统。
l 为什么？ 到目前为止，它还没有被列为优先事项。
连续问5次「为什么？」，我们找到了一个可以永久解决问题的方案。一个营销电子邮件发送提醒系统，将减少营销电子邮件在未来被遗忘的机会。
只要你把这种方法传授给你的团队，就很容易添加到「事后分析」中。只需在分析模板的末尾添加一个「5个为什么」部分就行了。
但是，我自己并不使用「5个为什么」。因为，我发现团队在这方面遇到了一些问题。
「5个为什么」分析方法的缺陷
不是每个项目都有足够的时间
「5个为什么」是一个非常耗时的过程，尤其是对一个团队来说。当我试著对每个项目做「5个为什么」时，会议很容易就开上几个小时。
对每个人来说，连续进行多个「5个为什么」的循环都会变得乏味，人们会想要开始逃离。我发现，在两轮「5个为什么」之后，质量就会出现明显下降。
更深层次的「为什么」会变得泛泛而谈
以我的经验来看，团队在深入「5个为什么」时，最后结果往往会变得非常宽泛。 最初的几个「为什么」是切实可见的，但随后就变得宽泛而无用了。例如，一个新产品的发布可能会失败，人们会开始解释，失败是市场变化的结果，不再需要这种类型的产品了。团队在进行「5个为什么」的时候，不会因为内部产品开发过程没有准确发现市场需求而结束，而是会陷入如何把握市场变化的困境。根源问题越深，这种可能性就越大。不过，随著时间的推移，通过大量的指导，团队在这方面确实会做得越来越好。
许多问题都有简单的解决方法
不是每个问题都需要深入分析才能找到根本的解决方案。在任何大型项目中，都会出现各种各样的问题。它们大多数都很小，通常只要有1-2个「为什么」就能解决。「5为什么」对于需要根源分析的主要项目非常有效，但是对于所有小问题来说，这就有点过了。 较小的项目只需要1-2个「为什么」分析，就能得到结论。
假设某人没有将重要信息转发给整个群组，因为他们点击了「回复」而不是「回复所有邮件」。 他们需要做的就是对自己的电子邮件进行设置，默认是「回复所有」，这样问题就解决了。也没必要再深入挖掘。
根本原因不是呈线性呈现的
「5个为什么」以5个步骤的线性过程进行，就像下楼梯一样。从逻辑上讲，每一步都会导致下一步。对于有直接因果关系的情况，这个方法非常有效。
但当情况变得不确定和复杂时，我认为根本原因更像一棵树。多种原因在影响著最终的结果，每一种原因都从各自的根本原因出发。
「5个为什么」鼓励团队只探索一个分支，如果过早的选择一个没有那么关键的分支，其余「5个为什么」在找出更好的根本原因上，基本上是没有帮助的。
对新项目没有帮助
对于任何一个新项目来说，总会有大量的错误和问题。团队第一次学习这种类型的项目是如何工作的时候，这是意料之中的。
当根本原因几乎总是「我们在开始之前不知道这是如何工作的」时，「为什么」过程变得非常多余，我更喜欢在已经建立的过程中使用「5个为什么」，因为，在这些过程中有更困难和更持久的根本原因需要发现。
我的「事后分析」
为了避免「5个为什么」带来的常见问题，我使用了一种不同的方法，这种方法基于我在分析模板的末尾添加的三个部分。
「事后分析」的3个部分
团队反馈
我把团队反馈部分放在项目总结之后，这样人们就有机会回顾我们带来的所有结果。然后他们可以对他们喜欢的任何东西提供反馈。
这是开放式的，我总是让团队随心所欲地填写这一部分。我希望每个「事后分析参与者」在会议之前填写这些反馈，我们将在会上进行深入讨论。
这是项目中每个团队或个人表达不满的机会。这也是一个完美的方法，能够解决所有很容易被忽略的小问题。
有时，团队会给出大量反馈。当他们承受另一个团队的错误的冲击，或者危机对他们打击特别大时，这种情况就会发生。每当团队使用这一部分来给出大量反馈时，我会确保他们的顾虑得到解决，这样他们的挫折感就不会继续积累。
当某个团队进展顺利时，他们的反馈通常是一句话。
为什么我们会得到这样的结果？
这是我在总结会议开始前留下一部分的时间，我们一起填写。
通过这样做，我可以引导团队得到一个更有力的答案。我也可以推动团队关注正确的问题，深入挖掘，探索还有哪些解释，而不是盲目地接受第一个出现的解释。
像这样深入的讨论不是偶然发生的。 我发现，在前几个月会议开始之前，我必须探究并询问很多后续问题，然后团队才开始自己进行这些讨论。换句话说，我承担了领导会议和向团队展示优秀分析是什么样子的责任。
小心，我过去犯的一个错误是直接给团队答案，而不是在讨论中提出问题。 如果我养成了这种习惯，结果就会只有在我参加会议的时候，团队才会进步。但是如果我不在，团队就会迷失。
给出答案，并不能帮助团队建立自己进行分析的技能。虽然较慢的苏格拉底式方法在短期内看起来像是浪费时间，但从长远来看确实有回报。几个月后，我就可以离开这类会议，让团队自己进行分析了。
我们承诺采取哪些行动步骤？
在开会之前，我也会把行动步骤这方面留著空白。 在就我们为什么会得到这样的结果达成一致意见之前，让别人填写这个表格是毫无意义的。 我也希望在房间里的每个人，在行动步骤上得到选择和分配。 这有助于每个人都感觉到自己是这个过程的一部分。
在会议期间，这一部分只需要10分钟左右。我保持它的简单，列出每个行动步骤，并分配一个单独的负责人。一个例子如下：
l 设计并实施一个新的产品创意研究流程—— 苏（Sue），产品负责人
l 重构销售页面上的CSS模板，以减少每次发布时出错的机会——吉尔（Jill），前端开发
l 接触在发布期间购买的10个客户，并寻找为什么他们购买的趋势——约瑟（Jose），产品经理
l 邀请销售总监参加产品路线图会议，从销售总监那里获得关于路线图的初步意见——苏（Sue），产品负责人
l 将新产品中的前三个bug分配给技术团队，并得到解决——艾玛（Emma），技术经理
l 改变客户支持计划，使更多的人可以在产品发布期间处理流入的支持票——约翰（John），客户成功经理
然后，我通过要求每个人采取行动，将该任务添加到他们自己的工作事项中来结束会议。
为什么这种「事后分析」有效？
上面的三个部分看起来很简单，甚至可能过于简单了。
如果我让团队只是填写这些部分，而不是帮助他们推进下去，那么这些就太简单了。关键是在总结会议的大部分时间里，我们一直在思考「为什么我们会得到这样的结果？」部分。 讨论得越好，行动步骤就会越有效。如果行动步骤是有效的，从一个项目到另一个项目，团队将极大地提高他们带来的结果。
这种「事后分析」，确实取决于我在会议期间推动团队进行深入讨论的能力。几个月后，他们就会对这种情况有一个很好的感觉，我可以在这些会议中扮演一个不那么重要的角色。
这种结构，足以引导团队在没有任何繁忙工作的情况下进行出色的「事后分析」。
推荐阅读：
