回顾过去，展望未来--调查研究你的上一个项目可以改进你的下一个项目 |
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分钟整理本来可以更好的实践。参与者可以在房间内走动，看其他的人在活动挂图上写的东西以激发他们的思考。 [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
|
|
|
|
|
|
|
您的位置：
