回顾过去项目，展望未来项目
摘要：回顾过去项目，展望未来项目
回顾过去，展望未来
--调查研究你的上一个项目可以改进你的下一个项目
Karl Wiegers，Johanna Rothman 著 亚玲 译 (umlchina)
Pat，一位刚刚起步的Internet公司的副总裁，对她的项目组先前发布的产品版本感到自豪的同时，对产品发布的时间比预期的时间要晚好几个星期也很关注。在项目回顾会议上，Pat听到好几个组员说：“我本来可以更早完成的，但是我无法准确知道’完成’的含义。如果我知道我的部分什么时候真正完成的话，我们可能会更早地发布产品。”她感到非常惊讶。这是一个有价值的评论，Pat根据她下个项目的信息定义了清晰的发布标准，从而帮助她改善了项目组的时间安排。
回顾提供了一个有组织的机会，来回顾项目或者项目的某个阶段。你可能从中总结可以继续保持的、很有效的实践，或者差的实践并且知道该如何去改善。回顾帮助你从通常很痛苦的经验中得到教训。
一个聪明的项目管理人员在开始一个新项目之前，会温习从先前项目中得到的教训以节约时间和避免不眠之夜。你可能不能对从过去的经验中得到的价值进行定量分析。但是，回顾，这种小小的投资，将几乎肯定地获取比它大的收益。在今天速度驱动和有明显交货底线的开发世界里，你无法承受重犯过去的错误和一个项目接一个项目地遇到相同的意外。
对回顾的定义
回顾是从一个已经完成的项目或者项目阶段中收集知识、洞察力、可能的度量和工具。度量可能包括进度表的真实结果，努力成果，成本和质量，它们可以提高你未来的估算水平。你可以将关键的项目文档，计划和规格说明书存档，以便作为未来项目的范例。
回顾提供一种使参与者远离日复一日的压力，共享他们的观察结果的方式。即使这个项目是一个巨大的失败，你从评价失败中得到的经验教训也会带来积极的影响和有益的改进机会。
谈论什么是回顾可能看起来很傻，但是名字使人产生很多联想。当某个人称回顾某个已死的人，我们就会想知道谁死了；但有时候项目是成功的！如果解释回顾为分娩后的新生命则意味着新“婴儿”产品可能某天会长大，但是离成熟还很远。回顾和事后项目回顾是中性的术语，意思是通过思考分析先前的项目经验，获取实践真知。
无论何时你需要收集项目信息或者评价工作进行方式，请进行回顾。许许多多的项目重复一系列的开发周期，所以你可以在每个开发周期后积累经验教训以帮助你后续的开发周期。当先前项目中有特别有效的实践或者特别差的实践时，思考反省经验教训特别值得。对于持续几个月的项目的早期所发生的事情往往很容易忘记，所以一个持续时间长的项目在到达每个主要里程碑时进行一个短回顾是很必要的。时间的治疗效果和最近成功的喜悦通常会减轻你在前些时候所遭受的痛苦，但是那些痛苦的记忆往往包含未来改进的种子。
回顾过程
一个有效的回顾过程如图1所示。这个过程的关键人物是发起回顾的项目经理，项目组组员和一个项目协助人员。关键人物是发起回顾的项目经理，项目组组员和一个项目协助人员。
图1. 回顾过程
计划。计划开始于要求回顾的项目经理和项目协助人员共同决定回顾的范围(整个项目或者一部分)，要检查的活动和任何需要仔细研究的具体问题。在计划阶段，还需要你确定需要访问的人，选择合适的设备(最好是不在现场并且避免分心)，选择你将使用的协助技巧，并定义日程表。
将参与者分到不同组中，我们得到了不同的结果。在一次回顾中，Karl和另外一个项目协助人员分开主持了两个讨论。其中一组包括6个管理人员，而另一组由15个软件专业人员组成。项目协助人员和发起回顾的项目经理认为，如果软件专业人员的项目管理人员在场的话他们会不愿意提一些问题。在这种情况下将参与人员分开效果很好，虽然我们必须仔细将两组的问题合并和决定问题的优先级别。但是在另外一种情况下，将参与者分开是不应该的。参与的两组人员包括一个软件开发小组和在一个较大的Web站点开发项目的可视化设计小组。Karl低估了参与者的合作倾向。尽管两组之间对于某些问题看法有摩擦，两个组在一起讨论他们共同的问题将会更好。
Johanna从来没有把参与者分组，因为她认为分组将会降低人们的感知力。在培训管理人员时告诉他们回顾可能发现让他们感觉不舒服的问题，是非常重要的。正如Weinberg在“The Secrets of Consulting (Dorset House, 1985)”一书中所说，“不管它看起来像什么，它始终是人的问题”，有时候人的问题是因为管理产生的。如果管理人员阻碍了讨论的话，可以考虑请求管理人员离开房间。
开始。在有所有参与者在场的短暂的开始期间，发起回顾的项目经理介绍项目协助人员和其他不认识的面孔。项目经理还需要指出回顾的目标，并首先感谢所有参与者的参与和诚实的意见。项目经理应该基于回顾结果清楚地陈诉他将采取具体行动的承诺。然后由项目协助人员列出日程安排。要建立良好的建设性环境，项目协助人员要定义一些基本的规则，包括：
l 允许每个人发言。
l 尊重他人的经验和观点。
l 避免批评其他参与者的意见和思想。
l 避免为已经过去的事件批评他人。
l 找出根本原因，而不仅仅是现象。
l 集中精力于理解、学习和向前看。
数据收集。当某些回顾收集具体数据和项目工件时, 核心活动是从参与者那儿收集问题，观察报告和关注的问题。在回顾时我们探索三个基本问题：什么是好的实践(我们想在将来重复),什么本来可以做得更好(我们可能想要改善它),什么是使我们意外的(这些可能是要在以后的项目中继续观察的一些风险)？
一个有经验的项目协助人员会使用很多技巧从不同的参与组里引出信息。传统的方法是让协助人员站在挂在组员之前的活动挂图(一种由很多页组成的顶部夹在一起的图表，翻动时能够连续地展示资料)旁边，并要求参与者提出问题。项目协助人员标记好的经验为正而标记不好的经验为负。还可以采用循环的方法，协助人员要求每个参与者轮流提出一个问题并且循环通过每个听众直到每个人都通过。这种产生问题的途径通常需要60-90分钟。一旦问题被提出之后，项目协助人员(或者记录人员)在分开的索引卡片上记录提出的每个问题。参与者将卡片分成相关组(或者相似组)并且为它们命名。
这种传统的协助途径有下面几个缺点：
l 顺序地产生问题速度很慢
l 很容易让少数直率的参与者主宰讨论
l 很容易陷入讨论某个热门话题，而不是找出所有问题
l 一些人对在公共讨论会提出问题不太自在
l 有影响力或者有强控制欲的参与者可能阻止其他人提出问题
如果你担心上述任何一个因素，可以考虑使用其它的协助途径。让参与者安静地产生问题的技巧可能会比公众的顺序的方法更为有效和全面。在使用这种方法的一次实践中，协助人员和回顾组织人员在回顾会议之前标出了可能会提出的几种问题。软件开发项目的通用种类包括交流、组织、联合作业、管理、需求、设计、建造、测试、子承包工厂、商业问题和过程。可能不是每个回顾都包括所有这些问题。提前定义问题种类可能会冒限制提出问题范围的风险，所以你可能更愿意进行小组讨论，并在问题产生之后为这些问题的种类命名。
在每一页写下每个问题种类的名称，然后将每页分成几个部分：好的实践、可以本来更好的实践, 以及吸取到的经验。在会议期间，让参与者在分开的3个部分(每部分有5个夹在一起的页)写下他们的每个问题，并指出它们相应的问题类别。项目协助人员将这些问题放在活动挂图页的相应部分。花费大约20分钟整理好的实践，然后花另外20或30分钟整理本来可以更好的实践。参与者可以在房间内走动，看其他的人在活动挂图上写的东西以激发他们的思考。
这种方法克服了传统的“协助人员在活动挂图旁边”的大多数缺点。参与者一起工作可以在给定时间内产生更多问题。每个问题被提出时被打搅的可能性较小。而且，那些可能不愿意大声陈述他们观点的人，可以以安静和匿名的方式陈述问题。但是，项目协助人将不得不大声地读出活动挂图上所有棘手的意见，以确保每个问题被清楚地陈述和合适地分类。他还必须集合相关的问题。
要结束回顾的数据收集部分，你可能会对每个项目组组员提出两个问题：这个项目的哪一点你想在将来的项目中保持？这个项目的哪一点你想在将来的项目中有所改变？
定义问题的优先级别。一个成功的回顾将产生远比项目组实际陈述多得多的问题。你必须从这些问题中找出参与者同意的最有价值的东西。一些高优先级的问题可能针对有效的实践，这些有效的实践你可能想在将来的项目中固定下来。而其它反映当前项目实践缺点的方面也需要迅速地陈述出来。
一个典型的划分优先级的技巧是由pareto提出的。 每个参与者投票给他认为优先考虑的问题，通常是所有问题的20%。为了简化一个大组里的数据收集，一些项目协助人员给每个参与者3-5票。投票过程中将优先问题着色是一个好方法。参与者环绕房间走动，检查活动挂图，然后将他们认为最重要的问题做彩色标记。那些获得点数最高的问题就是最成熟的要立刻采取行动的问题。但是，看见意见簿上的点数可能影响后面投票的人，他们可能不想浪费票数在前面投票人没有投的问题上。要避免这种情况发生，参与者可以将投票点数放在意见簿的后面。
分析。 如果你在回顾期间有时间的话，花费15或20分钟讨论每个有高优先级的条目。或者，在回顾会议之后，聚集一个小组来研究这些问题。对于实践效果很好的条目，要确定它们成功的原因以及它们带来的好处。找出可以确保当前项目中行之有效的实践也可在将来项目中行之有效的方法。对于高优先级别的“本可以做得更好”的条目，找出不如人意的原因，每个条目(问题)不如人意的结果，和下次可以做得更好的建议。
影响回顾成功的因素
只有在无偏见的，没有指责的环境下，回顾才能成功，并且开放式的交流也是不可缺少的。如果一个项目困难重重或者不成功，必须寻找一些出路；但是，项目协助人员必须限制寻找的出路和方法是在建设性的轨道上。确保你的回顾不沦落成迫害。回顾必须强调从共享的项目经验中无指责地进行学习。让我们看一下一些回顾的关键成功因素。
确定你的目标。作为项目管理组织人员，你应该确定你回顾的目标和应该聚焦的项目的某些具体方面，以及某些行动的潜在好处。如果在回顾过程中收集的信息导致某个建设性的过程改变，谁应该首先公开宣布？另外，如果问题的根本原因被揭示出来，谁的脸色将会很难看？ 记住，你不是寻找替罪羊，但是你需要明白什么是确实已经发生的，为什么会发生。
派用一位熟练的无偏见的项目协助员。期望项目管理人员客观协助回顾是不现实的。项目管理人员可能另有苦衷或者想要维护他的声誉。一些项目管理人员可能无意识地阻碍了参与，尽管他们的意图是好的。其他参与者可能被迫对重要问题保持缄默或者管理人员可能对某些问题只看重自己的意见。
要避免这些问题，邀请一个该项目组外、有经验、无偏见的项目协助人来主持回顾。项目协助人的主要目标是在一个建设性和学习性的环境中触及关键性的问题，使回顾成功。考虑让一个在回顾活动中不活跃的人记录产生的问题。
安排合适的参与者。当然，基本的参与人员是项目组组员。管理人员代表只有在他们是项目组的成员时才被邀请入回顾会议。但是，你应该提供经验教训的总结给可以从中获益的公司高级管理人员或者其他管理人员。
有些项目组可能太忙了，太大或者在地理位置上分布太远，以致让所有的项目组组员同时参加回顾会议不太可能。在这种情况下，可以从这个项目包括的多个功能领域内选择代表。如果一个大项目被划分为多个子项目，每个子项目应该进行自己的回顾会议。然后每个子项目的代表可以在总项目回顾会议上进行回顾。
当某些我们认为对项目有重要看法的人太忙不能参加回顾会议时，我们询问他们是否认为项目的一切都进行顺利。通常，他们对项目有一些重要的看法和建设性的意见。然后我们帮助他们妥善安排当前的时间，以使我们能够听取他们对先前项目的意见。
如果项目涉及多个组，并且这些项目组互相指责项目问题或者拒绝一起坐下来研究共同的问题。我们可能首先讨论这些组之间的矛盾。很多情况下会发现一些重要的项目问题。如果这些组在回顾中合作不愉快，他们极有可能在项目中也存在冲突。回顾可能说出这些组在下次合作中需要改进以更好合作的地方。
培训参与者。如果参与者不习惯于回顾，并且被研究的项目具有严重的问题，邀请参加回顾将会引起混淆或者抵抗。一些参与者可能会非常焦虑，而其他人将会急于摆脱指责。通过邀请材料提供信息和保证给参与者。提前描述回顾过程，通过强调回顾是一个面向未来的，改进项目过程的活动，建立一个合适的建设性的倾向。
聚焦事实。回顾应该陈述项目的过程和结果，而不是对参与者进行人身攻击或者指出他们的错误。项目协助人员应该确保参与者不互相指责或调和矛盾，而是集中讨论已经发生的事情。但是，人们通常以不同的方式体验事情。理解不同的解释可以敞开心扉，增加新的见识。
找出行动计划领导人。找出要写下并负责采取改进行动计划的人，由他观察这些计划是否能导致可见的好处。为计划中的每个行动条目指定一个人，他负责实现并报告进度给计划行动领导人。行动计划领导人必须对这些人完成他们行动项目的能力了如指掌。
回顾行动计划
回顾完以后，不要立即应付所有提出来的问题。从最高优先级的问题清单中选择三个问题，其它的留待以后处理。写下你的行动方案，包括你的改进目标，纠正问题的步骤，说明谁负责什么行动以及行动完毕后可以交付的文挡清单。在下一次回顾中，检查这些行动的结果是否理想。记住，一个不能导致具体行动的行动计划是无用的。Karl曾经协助同一个Internet开发小组两年。一些在后来回顾中的问题曾经在两年前就提过。不能从过去的实践中吸取经验一定会使你重复失败。没有什么能够比不实施建议能更快地阻止项目组织进行回顾了。
吸取的教训
要使项目组织获取最大的利益，请积累从回顾中获取的经验。我们更愿意以一种无偏见的方式记录教训，所以，我们是从好的实践中还是从坏的实践中获取经验并不重要。在“吸取的经验”数据库中的信息可以包括：
l 教训的陈述
l 吸取的教训种类
l 标明教训入库的时间
l 项目名称
l 忽略教训的代价
l 实施教训的建议
l 涉及的工作产品
l 相关的生命周期
人的因素
因为我们是人类，我们的个性影响我们对各种问题的反映方式。在Johanna协助的一次回顾中，当他描述一个特殊的问题时，某个管理人员参与者流下了眼泪。Johanna在休息时和他交谈，他说他感到管理层不信任他，但是他觉得说这些也并不舒服。他同意让Johanna提出这个敏感的问题。
重新开会后，Johanna说某个参与者感觉到不被管理层信任，理由是她在活动图表上写下的三点。整个房间保持沉默了一分钟。这时候有个人也说：“我也是”。其他几个人也有共鸣，然后他们看着高层管理人员。Johanna提醒项目组：我们不是评价个人，而是提出我们关注的问题并解决它们。高层管理人员然后问道：“这里有人信任我吗？”没有人回应。这是一个奏效的时刻。高层管理人员列出了信任作为一个问题。
项目组是最好的信息来源，他们提供一个刚刚结束的项目或者开发阶段的真实情况。使用回顾帮助项目组组合整个项目的情况，以便项目领导人可以利用这些信息，在下个项目中创造一个更有效的环境。但是记住，所有的项目组改变都需要一定时间、耐心和涉众的许诺。如果人们不想改变，他们就不会改变。
原文链接 http://www.umlchina.com/ProjMan/lookback.htm
