在一个软件开发项目中进行实际日程安排的十二点提示

Laura Rose , QE Manager, Rational

2005 年 10 月 19 日

来自 Rational Edge：软件开发团队依赖于严谨的计划日程安排。但除了使用基本的日程安排工具以外，项目经理怎样才能权衡相互矛盾的要求或是有足够的时间来应付没有预料到的、对最佳计划构成威胁的事情？这篇文章提供了一些复杂的日程安排技巧，可以用来区分优先级、明确价值目标，并比较不同活动的相对价值。

s你是否有足够的能力领导一个软件开发项目或调整你的孩子的足球课和舞蹈课时间？时间表对如何合理安排一系列的事件是非常有用的工具。许多时间表都包括一个开始和一个截止时间，任务所需时间和任务与任务之间的从属关系。但不管你如何出色地安排了一系列事情，未期望的事件总是会出现，占用你的时间，使项目未能在最终期限之前完成。你事先没有料到的人会参与到你的计划中，并产生影响，控制事情并通常使事情变得复杂。当我们没有办法处理好未预料到的事情和人际关系时，我们的日程表开始支离破碎。

制定好的时间表是非常困难的，这是艺术和科学的结合体。在这篇文章中，我将会讨论如何进行实际的日程安排，力图涵盖所有上面提到的各种类型的事件——计划中的、可能的、难以想象的。有许多技巧可以帮助你保持机智的头脑，这些技巧是你的笔记、清单、重要事件和备忘录里没有的。我的十二个小提示区分优先级、明确价值目标，并比较不同活动的相对价值。它们将传统的清单与经过改进的关系相结合，以得到预期的结果。

进行实际日程安排的十二个小提示

听到一些团队抱怨说我们没有足够的时间是很经常的事。我们经常感觉精疲力尽，对一个迫在眉睫的时间表感到无可奈何，当我们与时间或日程表进行竞争时，总是极力斗争，但是失败的可能性却很大。当我们停止与时间的竞争时1并根据我们的时间表和能力开始工作，我们便增加了成功的可能性

例如，时间表本身可能并不代表什么：它只是表示我们如何选择在有限的时间里完成多少任务。明智地决定将什么放入时间表并如何在这些范围内工作是在我们的控制之中的。

下面的技巧将帮助你重建控制的能力。它们举例说明了怎样区分优先次序，怎样通过比较每个事件的相对价值来弄清事实。

1. 不要用我很忙来推卸责任。

2. 制作出一个详细的任务清单。

3. 尽早判断出关键路径和瓶颈。

4. 做对客户有价值的事情。

5. 执行客户所支持的方案。

6. 知道如何高效且迅速地作出决策

7. 严格执行合乎情理的强制手段。

8. 执行高效的会议管理。

9. 接受革命性的好建议。

10. 只要可能的话，减少存货。

11. 不要制造混乱。

12. 警惕装腔作势的氛围。

注意：我觉得自己的一些小提示带有我称为附加小提示的信息。这些信息包括你在作出自己的判断时将会用到的一些相关的技巧。依赖于有组织的结构体系，一些建议你也许并不欣赏。

小提示 #1 不要用我很忙来推卸责任

你是否发现自己越忙，就越容易有各种各样的干扰和要求？我们中的许多人把许多时间花费在在一个又一个工作之间团团转，而不是真正静下来做成某一件事情。但是，如果我们只是想一个人单干不被打扰的话，就会使得自己失去耐性，甚至失去队友。

我把这称之为忙碌的矛盾，因为你想做的和你需要做的是相反的。

事实上，我们越忙，我们越需要更多的耐性，因为所有的事情都需要更多的时间。2需要做的事情越多，对于人们来说这些事情就越重要。负担越重，我们越需要和他人一起工作，和团队一起工作。

记得你的队友没有必要知道你现在的任务清单；他们只将精力集中于自己需要做的事情。如果你肯花费时间向他们详细解释你的工作和最终期限，他们就会对你的情况有一个框架性的了解。如果你能够在时间表上划分出时间，告诉他们你什么时候能恰当地满足他们的要求，你会看到他们都是非常通情达理的，而且你的时间会与他们的时间配合得很好。所有这些都要求耐心和相互理解。

我们经常假设一个新的请求事关一些紧急、重要、需要马上处理的事情。但事实并非总是如此。和他们一起讨论你的现状和他们的特殊要求，你会对如何区分优先级有一个大致的概念。和你的队友谈论各种任务和时间表的另一个好处是他们也许已经做过一些类似的事情，这可以帮你节约时间。你可能会发现一些令人惊讶的配合、协作以及网络工作机会。

从不同的角度评价事件是很有帮助的。忙碌并不是混乱的同义词。并不意味放弃每件事，虽然一些人认为尽可能快意味着尽可能力所能及地快。忙碌仅仅意味着积极地或完全地投入到工作中，而通常意味着尽可能合乎情理地快。有了耐心和沟通，控制并建构一个紧张有序的时间表是有可能的。

时间表上需要的并行的工作越多，需要的从订货到交货的时间和延迟时间越长。你进行越多工作，你越应该认识到对每一个工作而言，会有更多的意想不到的事件会发生。意想不到的事情本来就是生活的一部分，不管是在办公室外还是在办公室内，高效而实际的时间表里预料到了它们的发生和它们对理想的工作完成顺序造成的影响。如果没有完美地建立起来的安全系统，一个意外（或是额外增加的工作）将会产生多米诺效应。如果没有完美地计划的缓冲措施，我们将会把时间浪费在在一个又一个工作之间团团转，却没有做成任何事情。若在你的时间表上战略性地安排一些缓冲时间，你处理意外事件，使它们不会影响你的整个时间安排的可能性就越大。你现在可以很有把握地说，你可以在下一个可以利用的空当应付意料之外的要求。

冲刺和缓冲

确保你在应对意想不到的紧急事件时有一个方便的停顿时间的一个更好的方法是将短时间的冲刺和缓冲时间结合起来。

考虑如下事例：如图1的上半部分所示，我们有任务A和任务B，我们估计完成它们各需要八天时间，在我们的时间表上它们总共占用了16天的时间。我们开始工作，但是在第三天结束的时候我们突然有了一个紧急事件。于是我们在接下来的一天里把时间都用在处理紧急事件、做清算上，接着我们又开始处理任务 A。由于回忆我们究竟把任务进行到哪一阶段需要一些额外的时间，重新开始进入处理任务 A的工作也需要一些额外的时间，所以我们必须重新估算这个任务所需要的总时间。重新估算之后，我们认为由于任务进程被打断，需要花费比七天更长的时间来完成任务。两天之后，我们又有了另一个紧急事件，同样的情形再次重演。最后，我们花了超过十二天的时间来完成真正的任务A (2天进行任务A + 1天进行打断原来工作的紧急事件A + 2天继续进行任务A + 1天进行打断原来工作的紧急事件B + 6天重估并完成任务 ) 这正如图1的下半部分所示。

我们不仅延迟4天时间把任务交付给需要它们的人，而且还耽误了那些等待任务和进行任务工作的人。

图一：紧急事件样本 A 包括评估任务 A的最初八天。处理任务 A的两天之后，紧急事件发生了。处理完紧急事件之后，我们重新进行评估，预计现在需要花七天的时间才能真正完成任务 A（为了使中断的工作继续下去）。当处理完另一个紧急事件之后，我们重新进行评估，完成任务 A最终需要六天。

如图2所示，处理这种事情的一个更好的方法是将任务 A和紧随的任务B划分成较小的、独立的活动，或进行冲刺。我们在每一次冲刺之间都安排了一些缓冲时间。任务A 的总体时间表现在从原来的八天增加到十一天。让我们看看同样的例子现在会发生什么事。

图2：在我们的时间表里将冲刺和缓冲结合起来，我们可以看到应用冲刺战略(A1 A2 A3 A4)的真正的时间表同时满足了紧急事件和原定日程的要求。原来的任务A方法花费了更长的时间，却没有达到预期的目标。

我们从任务A1开始。两天之后，没有紧急事件发生。我们毫不迟疑地开始进行任务A2。进行任务2的第一天结束时（整个进程的第三天），紧急事件发生了，但是因为我们有一个良好的理由来说明明天结束的时候会是任务终止的一个好的停顿时间，紧急事件的处理被安排在那个时候。3当我们完成A2时，我们开始花时间处理紧急事件。再一次，我们不是自动停止现在所进行的工作，并在这个时间点将工作重心进行转移。这个例子以这种方式继续进行，直到任务A3开始之初另一个紧急事件发生了。

虽然基于冲刺——缓冲方法的原先的时间表花费的时间比最初的任务时间表要长，但是我们的预测更现实，所得结果也更符合实际。依靠整个任务(A1 A2 A3 A4)的人们按时完成了任务，有时甚至提前完成任务，而任务B部分也不需要压缩时间。

如果一个请求出现了，而且它比你手头正在进行的工作紧急且重要得多（例如，提出请求的人不能等到你时间表上下一个可利用的间歇时间到来时才进行工作），你应该去找经理并保证每个人都清醒地认识到事件优先级、影响以及时间表改变之后造成的结果。人们通常情况下会表示理解并接受这一方案，因为它是基于对整个工作都造成影响的优先级次序的，而且它也比较了每个工作的相对价值和相互依赖性。通过与你的经理进行优先级讨论和比较，对于整个项目时间表上的每一个活动你都会有更清晰的认识。

时间限制

使得时间表混乱的另一个可能事件是恭维。既然你知道自己在某一领域的专业水准，在另一个相似但不完全相同的领域里你是别人求助的对象。对一个同伴或另一个经理说不是很困难的，特别是当他们以这样的语句提出请求这只会花费你五分钟的时间。我们脑海里一个小小的声音说：好，你只需要为你的朋友和其它经理花费五分钟的时间。但五分钟通常变成半天，而你的经理仍然在等着你的日常进度报告，而这早应该在昨天晚上就已经完成。

一个好的技巧是对这些额外的要求进行时间限制4和你的朋友约定一个方便的五分钟会面，会面中他或她将尽他或她的能力解释所面临的情况。用所得到的信息估计这个工作将花费你多长时间。检查你的日历或时间表，看看你是否有合适的时间并进行解释，我可以在×××天的10：00花×××时间在这上面。如果我们到那时还没有发现或解决问题，我们将需要重新评价完成工作所需要的精力，工作的优先级，并请示经理。合适的时间限制到了之后，停止5并重新评估。时间限制是不引起混乱且回答是的一个很好的方法。

有了上述所说的种种策略，你始终还是团队成员，这没有使你的其它任务完成不了。但是这些策略依赖于一个详尽的清单，清单包括你正在做的事情，该做到何时，为了谁做和为什么（优先级）。

附加小提示

许多时间管理书籍建议只需要说“不”这一技巧。但有些时候，当事情符合你的优先级和价值时，用正确的方法说是更为聪明，当然，这取决于你自己。

小提示 #2：制作出一个详细的任务清单

又一次，如果没有一个包含截止时期的详细的任务清单，先前的提示是没法起作用。如果连你自己都不清楚的话，你根本就不可能有效且可信地向你的搭档们解释每一件你需要完成的事情。详细的任务清单还可以帮助你集中精力，注意每一个活动的重要性。

有效的时间管理者实际上都有一个清单（在他们的白板或是公告牌上）。当某人带着一个新任务而来时，他们有一个看得见的模板，知道从哪开始自己的谈判。

详细的任务清单对认清某项工作该投入多少精力同样很重要。当你的经理问你完成任务需要多长时间时，确保你自己明白他或她所定义的完成是什么意思。如果你的经理认为完成意味着下面各种情况，那你分别会怎么做呢？特征设计，和项目的所有参与者一起重新审视设计，对照编写代码标准和系统企业标准检查编码，在提交编码将这些之前使用编码总廓和状态分析工具来收集和报告编写代码状态的主要特征，单元测试，在自动建立的认证测试中嵌入这些单元测试并使其也自动化，并完成功能认证测试，保证有95%以上的通过率。好，但如果你认为完成只是简单地意味着编码组件并提交，问题就产生了。而且很有可能的是，这种观念上的差异直到很久以后才被发现。

当估计你付出多少努力时，先使用一个详细的任务清单模板。清单模板应该包括每个主要的6需要在这整个的项目中被完成活动。一些行动项目也许并不需要，这取决于我们的特定目标，但至少你已经考虑了它们每一个（与此相对的是一个没有分配任何时间的被遗忘的任务）。当我们没有花时间将任务写下来而仅仅只是在头脑里回顾它们，比起我们花时间写下所有的工作步骤来，我们的预期回报会比较少而且会比较不精确。我的组织发现通过进行纯精神的预计再将预计的结果翻倍之后，我们仍然需要再加30%的时间才能完成这些任务。换句话说，即使我们任意地将我们的精神上的预计进行翻倍，我们还是跟以往一样低估了实际所需要的时间。但当我们将模板内提示的所有步骤都写下来之后，我们提高了自己的估计准确性；当遇到一个隐藏或未知的任务时我们也不再那么惊讶；而且我们在所有需要事先未预计的时间的地方都备有证明文件。

当你有可能在截止日期之前完不成任务时，详细的任务清单帮助你和你的经理高效地审视这个项目。也就是说，如果风险存在，我们还有许多备选方案包含问题的解决方案：1）修改时间表，2）聪明地增加一些资源，3）降低质量，4）减少范围（将我们即将要做的一些事情从任务清单中划掉）。如果你没有一个包含你计划要做的事情的详细清单，聪明地减小一些活动以在截止日期之前完成任务是非常困难的。聪明地减少任务，我想说的是应该使得减少的那些任务不会影响编码质量或它在整个项目进程中的独立性。

明确的活动同样使得你可以知道自己是否有可能准时完成任务。举例说明，请你考虑图3所示的非常含糊的时间表。

图3：时间表

在时间表中，我们给出的完成组件任务1的精确估计时间是十天。当我们开始着手工作之后，第九天开发者说他想要我们提交编码。团队却认为我们在按照原定计划执行。

图4：时间表

在时间表中，我们可以看见只有五天的时间真正被用来进行编写代码。剩下的时间被分配用于检查、测试和错误修复。所以当开发者在第九天的时候说编写代码马上结束时，我们实际在时间表上已经有了四天的检查时间。虽然这些任务在时间表上并不明确可见，但这些在时间表上没有特别标出的活动仍然需要被完成以满足我们的反复检验标准。

所以，同意提前完成任务是完成的意思，会促进沟通并使得我们更好地了解自己的状态。

小提示 #3 尽早判断出关键路径和瓶颈

风险管理在重要的项目管理工具中一直被高调宣扬。但是，我们实际上并没有花时间来建模或是研究我们的工作流程以尽早定义风险、关键路径或瓶颈。就像定义我们应该付出多少努力一样，我们经常依赖于一个快速且临时的方法，这取决于我们对过去经验的重新审视。风险管理不像项目中的其它所有任务和工作流程那样，它非常少被考虑到。如果我们不能完全理解所有的任务和耗时，我们也就不能认识到绝大多数风险。如果你没有认识到风险，你就不能克服它们。

快速而显而易见地定义风险的一个非常有效且方便的方法是在项目中用可视化的流程图的方式勾勒出进展的工作流程。工作流程方法可以被用来分析任何事情：工作流程分析在组件独立性、进展步骤独立性甚至资源矛盾方面都是有效的。考虑图5中工作进展的图表，它勾勒出了开发中的不同组件。特定的颜色代表完成这项活动所需要的不同的人力资源，估计的持续时间在（）中。

图5：进展工作流程：图示法画出工作流程使得我们可以清楚地看出步骤3和资源“桔红色”是瓶颈。

图表显示出考虑到被提议的资源分配后的一些重要含义。注意到如果不考虑资源，通过关键路径的时间是9天（通过各种各样顺序排列的步骤所需的最长时间）。但由于我们使用了同样的资源进行步骤2a、2b和3，我们需要额外增加两天时间。为什么？因为即使这些步骤不取决于其它任何一个步骤，它们仍然受到资源的限制。我们现在需要多于11天的时间。

继续我们的分析。如果对一个步骤或资源来说有几条输入线，你就非常明显地定义了一个架构或结构上所说的瓶颈。在这个简单的例子中，有多个小项目取决于步骤3；因此，我们不仅在资源上有一个瓶颈，而且在项目结构上也有一个瓶颈。除非步骤2a、2b、 2c和 2d都在指定时间里全部完成，否则其它步骤都没法进行。如果步骤3中的资源在进行步骤2b的时候消耗太多，则整个进程都不能继续进行。没有其它的步骤可以开始着手。这就在关键路径上放置了一个“桔红色”资源。如果我们直到团队开始编写代码之前一直在等待，那我们实际上就陷入了瓶颈，而且我们对此无能为力，因为“桔红色”资源已经产生了。如果有人是唯一知道步骤2a、2b编写代码的人，那么因为他是唯一拥有那个编码的人，他有可能在所有三个步骤中都加入了一些额外的一些假设。他使得相互的独立性变得复杂，但使得完成任务变得较快（再一次，因为它是编码的唯一拥有者）。他使关系变得复杂，而我们不能有效地通过增加资源来帮助他一样。

图示法给出工作流程使得问题清晰可视，并给我们提供了甚至在项目未开始之前就避免问题和一个途径。考虑图6所举事例中的改进方面。

图6：工作流程：一旦你用图表表示出你最初的流程，你就已经在独立的组件和资源附近尽已所能纠正风险和瓶颈。

一旦你用图表表示出你最初的流程，你就已经在独立的组件和资源附近尽已所能纠正风险和瓶颈。在这个例子时，虽然我将我的任务划分成许多小步骤，我的关键路径却只有七天（比我最初的预计要短）。我仍然可以感觉到“桔红色”资源——步骤3——是一个潜在的瓶颈，所以我在潜在的瓶颈之前安排了两天缓冲时间。这允许接下去的步骤（步骤2、2、 2和 2）以一种轻微的停止模式累积。稳定时间是将中间环节合并、修复错误和质量审查的好方法。7虽然我已经降低瓶径的风险并在关键路径上提供了一些额外的时间，但是我在整个项目计划中没有增加时间。

我同样知道资源的技术水平并不是100%可以互相交换的。但事实是，如果我们没有做诸如此类的工作流程分析，我们就不知道那些我们不能重新分配、再订购或更改结构以更好地利用我们所拥有的资源和技术水平的地方。在这个例子中，工作流程中的“桔红色”资源需要在步骤3中使用，这仅仅是因为步骤3的一部分需要高水平的多线设计。当我们花些时间将那个部分从步骤的其它部分中剥离出来之后，我们可以发现许多其它资源可以完成步骤3的剩余部分。如果我们以另一种方式定义的没人可以替代至关重要的“桔红色”资源，我们可以将“桔红色”资源放置在设计和建构的其它地方，使得其它人可以得到已经设计好的编码说明书，并对这些原始模板进行简单编程。

这种项目管理技巧的另一个优点是它避免了在个人单独负责各自的项目时我们会遇到的资源的过度集中（或是资源的紧缺）。我们允许一个在关键路径上添加附加时间来进行缓冲，但并不是在某一任务中添加时间。非关键路径上的其它任务已经有了一个内在的缓冲时间。

如果你没有在工作之初就图示出备选的工作流程，你可能很容易就陷入困境。当你已经进行到项目的中间，在编码的所需要的程序员也已经确定时，这些备选方案的多数已经不需要了。所以这个小提示的关键在于尽早图示或构建你的工作流程可以为你提供多种选择和备选方案。

附加小提示

不要使用你最喜爱的日程安排工具（像 Microsoft Project, Modeling tool, 或 Gantt charts）来绘制最初的工作流程。这些工具会在无形中使你陷入同一种模式。使用即时贴®贴纸和一个大的白板，这对参与到该项目的团队和小组进行讨论是更简单的方法，同时便于重新建模。多个人的眼睛可以看到单个人的眼睛所看不到的东西。这同样帮助你同时建立交互的人际关系和团队责任心。只有当你的团队为决策的最优化而感到高兴的时候，你才能使用你最喜爱的日程安排或建模工具创建路径，用于周期性和反复的检查和更新。

小提示#4 做对客户有价值的事情

来自斯坦迪什团队( 2002)的詹姆斯 琼森所做的一个大型研究指出，45%8的嵌入到各种应用设备的特征从来未被使用（见图7）。将时间花费没有人使用的东西上面看起来非常可笑，所以所有这些特征是哪里来的？

图7：嵌入特征的使用：来自2002会议的斯坦迪什团队( 2002)

特征清单来自很多地方。一些来自商业分析，这些商业分析需要可以看得到的、保证公司仍然具有竞争力的文件。这听起似乎合乎情理且非常重要。我们需要有竞争力的与众不同之处。但我们达到这一点的方式可能对客户并不产生价值。举例来说，考虑一下，所有的客户报告分析，甚至你自己的分析都基于来自技术资源的比较。通常这些图表列举了100个以上的特征通过贴着不同方案的特定工具的相互比较，每一个特征都在其具有的方案对应的那一栏里有一个相应的分数。粗粗看来，似乎有最多分数的那个方案就是最佳方案。

我们所不清楚的是，在那100个特征里面，有整整64%的特征是很少或者从来没有被使用的。但为了使自己的品牌相对于其它品牌而言更具有竞争力，我们将不需要的64个特征合并到自己的方案中，这使得我们可以对那些栏目标记分数（使得我们的产品更复杂，更难使用）。