【在一个软件开发项目中进行实际日程安排的十二点提示(ZT) 】
声明:此文摘自网络,仅供学习研究之用.
来自 Rational Edge：软件开发团队依赖于严谨的计划日程安排。但除了使用基本的日程安排工具以外，项目经理怎样才能权衡相互矛盾的要求或是有足够的时间来应付没有预料到的、对最佳计划构成威胁的事情？这篇文章提供了一些复杂的日程安排技巧，可以用来区分优先级、明确价值目标，并比较不同活动的相对价值。
你是否有足够的能力领导一个软件开发项目或调整你的孩子的足球课和舞蹈课时间？时间表对如何合理安排一系列的事件是非常有用的工具。许多时间表都包括一个开始和一个截止时间，任务所需时间和任务与任务之间的从属关系。但不管你如何出色地安排了一系列事情，未期望的事件总是会出现，占用你的时间，使项目未能在最终期限之前完成。你事先没有料到的人会参与到你的计划中，并产生影响，控制事情并通常使事情变得复杂。当我们没有办法处理好未预料到的事情和人际关系时，我们的日程表开始支离破碎。
制定好的时间表是非常困难的，这是艺术和科学的结合体。在这篇文章中，我将会讨论如何进行实际的日程安排，力图涵盖所有上面提到的各种类型的事件——计划中的、可能的、难以想象的。有许多技巧可以帮助你保持机智的头脑，这些技巧是你的笔记、清单、重要事件和备忘录里没有的。我的十二个小提示区分优先级、明确价值目标，并比较不同活动的相对价值。它们将传统的清单与经过改进的关系相结合，以得到预期的结果。
听到一些团队抱怨说我们没有足够的时间是很经常的事。我们经常感觉精疲力尽，对一个迫在眉睫的时间表感到无可奈何，当我们与时间或日程表进行竞争时，总是极力斗争，但是失败的可能性却很大。当我们停止与时间的竞争时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并重新评估。时间限制是不引起混乱且回答是的一个很好的方法。
有了上述所说的种种策略，你始终还是团队成员，这没有使你的其它任务完成不了。但是这些策略依赖于一个详尽的清单，清单包括你正在做的事情，该做到何时，为了谁做和为什么（优先级）。
| 许多时间管理书籍建议只需要说“不”这一技巧。但有些时候，当事情符合你的优先级和价值时，用正确的方法说是更为聪明，当然，这取决于你自己。 |
|---|
又一次，如果没有一个包含截止时期的详细的任务清单，先前的提示是没法起作用。如果连你自己都不清楚的话，你根本就不可能有效且可信地向你的搭档们解释每一件你需要完成的事情。详细的任务清单还可以帮助你集中精力，注意每一个活动的重要性。
有效的时间管理者实际上都有一个清单（在他们的白板或是公告牌上）。当某人带着一个新任务而来时，他们有一个看得见的模板，知道从哪开始自己的谈判。
详细的任务清单对认清某项工作该投入多少精力同样很重要。当你的经理问你完成任务需要多长时间时，确保你自己明白他或她所定义的完成是什么意思。如果你的经理认为完成意味着下面各种情况，那你分别会怎么做呢？特征设计，和项目的所有参与者一起重新审视设计，对照编写代码标准和系统企业标准检查编码，在提交编码将这些之前使用编码总廓和状态分析工具来收集和报告编写代码状态的主要特征，单元测试，在自动建立的认证测试中嵌入这些单元测试并使其也自动化，并完成功能认证测试，保证有95%以上的通过率。好，但如果你认为完成只是简单地意味着编码组件并提交，问题就产生了。而且很有可能的是，这种观念上的差异直到很久以后才被发现。
当估计你付出多少努力时，先使用一个详细的任务清单模板。清单模板应该包括每个主要的6需要在这整个的项目中被完成活动。一些行动项目也许并不需要，这取决于我们的特定目标，但至少你已经考虑了它们每一个（与此相对的是一个没有分配任何时间的被遗忘的任务）。当我们没有花时间将任务写下来而仅仅只是在头脑里回顾它们，比起我们花时间写下所有的工作步骤来，我们的预期回报会比较少而且会比较不精确。我的组织发现通过进行纯精神的预计再将预计的结果翻倍之后，我们仍然需要再加30%的时间才能完成这些任务。换句话说，即使我们任意地将我们的精神上的预计进行翻倍，我们还是跟以往一样低估了实际所需要的时间。但当我们将模板内提示的所有步骤都写下来之后，我们提高了自己的估计准确性；当遇到一个隐藏或未知的任务时我们也不再那么惊讶；而且我们在所有需要事先未预计的时间的地方都备有证明文件。
当你有可能在截止日期之前完不成任务时，详细的任务清单帮助你和你的经理高效地审视这个项目。也就是说，如果风险存在，我们还有许多备选方案包含问题的解决方案：1）修改时间表，2）聪明地增加一些资源，3）降低质量，4）减少范围（将我们即将要做的一些事情从任务清单中划掉）。如果你没有一个包含你计划要做的事情的详细清单，聪明地减小一些活动以在截止日期之前完成任务是非常困难的。聪明地减少任务，我想说的是应该使得减少的那些任务不会影响编码质量或它在整个项目进程中的独立性。
明确的活动同样使得你可以知道自己是否有可能准时完成任务。举例说明，请你考虑图3所示的非常含糊的时间表。
图3：时间表
在时间表中，我们给出的完成组件任务1的精确估计时间是十天。当我们开始着手工作之后，第九天开发者说他想要我们提交编码。团队却认为我们在按照原定计划执行。
图4：时间表
在时间表中，我们可以看见只有五天的时间真正被用来进行编写代码。剩下的时间被分配用于检查、测试和错误修复。所以当开发者在第九天的时候说编写代码马上结束时，我们实际在时间表上已经有了四天的检查时间。虽然这些任务在时间表上并不明确可见，但这些在时间表上没有特别标出的活动仍然需要被完成以满足我们的反复检验标准。
所以，同意提前完成任务是完成的意思，会促进沟通并使得我们更好地了解自己的状态。
风险管理在重要的项目管理工具中一直被高调宣扬。但是，我们实际上并没有花时间来建模或是研究我们的工作流程以尽早定义风险、关键路径或瓶颈。就像定义我们应该付出多少努力一样，我们经常依赖于一个快速且临时的方法，这取决于我们对过去经验的重新审视。风险管理不像项目中的其它所有任务和工作流程那样，它非常少被考虑到。如果我们不能完全理解所有的任务和耗时，我们也就不能认识到绝大多数风险。如果你没有认识到风险，你就不能克服它们。
快速而显而易见地定义风险的一个非常有效且方便的方法是在项目中用可视化的流程图的方式勾勒出进展的工作流程。工作流程方法可以被用来分析任何事情：工作流程分析在组件独立性、进展步骤独立性甚至资源矛盾方面都是有效的。考虑图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）来绘制最初的工作流程。这些工具会在无形中使你陷入同一种模式。使用即时贴®贴纸和一个大的白板，这对参与到该项目的团队和小组进行讨论是更简单的方法，同时便于重新建模。多个人的眼睛可以看到单个人的眼睛所看不到的东西。这同样帮助你同时建立交互的人际关系和团队责任心。 只有当你的团队为决策的最优化而感到高兴的时候，你才能使用你最喜爱的日程安排或建模工具创建路径，用于周期性和反复的检查和更新。 |
|---|
来自斯坦迪什团队( 2002)的詹姆斯 琼森所做的一个大型研究指出，45%8的嵌入到各种应用设备的特征从来未被使用（见图7）。将时间花费没有人使用的东西上面看起来非常可笑，所以所有这些特征是哪里来的？
图7：嵌入特征的使用：来自2002会议的斯坦迪什团队( 2002)
特征清单来自很多地方。一些来自商业分析，这些商业分析需要可以看得到的、保证公司仍然具有竞争力的文件。这听起似乎合乎情理且非常重要。我们需要有竞争力的与众不同之处。但我们达到这一点的方式可能对客户并不产生价值。举例来说，考虑一下，所有的客户报告分析，甚至你自己的分析都基于来自技术资源的比较。通常这些图表列举了100个以上的特征通过贴着不同方案的特定工具的相互比较，每一个特征都在其具有的方案对应的那一栏里有一个相应的分数。粗粗看来，似乎有最多分数的那个方案就是最佳方案。
我们所不清楚的是，在那100个特征里面，有整整64%的特征是很少或者从来没有被使用的。但为了使自己的品牌相对于其它品牌而言更具有竞争力，我们将不需要的64个特征合并到自己的方案中，这使得我们可以对那些栏目标记分数（使得我们的产品更复杂，更难使用）。
需要承认的是，对许多项目经理来说在项目的一开始就把一个客户列举的所需特征里的64%排除也许是不可能的。但是，我们可以指定一个客户，让他在整个产品开发周期内反复检查这些特征的可用性（要求、原型、样本）。通过这样做，你的最终产品将具有更多会真正被使用的特征，你也可以获知有什么特征你需要花费时间进行开发。即使你的产品中有100个特征，通过持续的沟通并和你的客户相互合作，你就知道有哪36个特征是应该集中精力的，哪64个特征应该降低优先级。所以，即使你可能没有能力影响商业机构列举所谓的的客户要求的特征清单，至少你知道什么东西能够使你的客户在项目结束后感到最满意。
这种加入客户价值的特征回顾的另一方面是客户价值特征的移除（更经常地，这被我们称为仔细研究，保证与时间表相吻合）。许多时候，正是客户们最为看重的特征（例如易用性或用户文件）被放在了一个较低的优先级。适用性（可以帮助客户们决定什么是错的、什么应该做并且马上开始做的有用特征）和故障检修数据库分类通常不被重视。这些对我们所热衷于从事的纯技术而言并不是必要的部分，但这却是我们的客户所看重的。通过认识到我们所认为的价值较低的一些特征也许是我们的客户高度评价的特征这一可能性，我们可以同客户讨论这些方面以改进整体的满意度。
如果你没有一个客户赞助者，那么当对某一个方案进行要求的重新评估时（不管是增加或者移除特征），要让你的团队明确地知道答案并仔细考虑以下问题：
- 这一特征真的会对客户有所帮助吗？
- 你能量化附加值吗？
- 我们的目标是什么？
- 这个目标是切合实际的吗？
- 你怎么进行测试？
如果你有有效的答案并对上述问题进行量化，你就能精确地提出我们所需要花费的精力、切合实际且对客户来说有价值的时间表。
导致软件特征膨胀的另一个常见因素是我们共同的系统需求和安全功能。我们的许多公司系统要求来自非常常规的模板，模板包含了很多数量的应用场合和产品。举例而言，一些对网络和安全系统的考虑在一个孤立、隔离、单一用户模型里是不存在的，对用户而言也不存在这样的需求。但是，为了与公司的其它产品一起出售，这一种特殊的应用需要按照特定的公司规定去做（特别是当它准备推向国际市场的时候）。9
另一个常见的贡献者是“我们，开发团队”这一概念。我们热爱自己的工作。我们热爱玩简洁而有技术性的高级把戏。有些时候我们设计某样东西只是因为设计它有很多乐趣。或者我们挑选某一个特征，把它设计得完美无缺，以致于它包含了所有我们（但不是客户）所可能想象的东西。这很有趣，而且我们实际上并未因为这些创造性的附加劳动而占用项目的时间表进程。
为你的特征清单增加客户价值的另一个途径是使每一个方案都得到客户的支持。相比于在小提示#4中所建议的那种客户重新审视的方法，这对客户参与而言是一个更为正式的途径。
过去，我们的产品经理从各种各样的途径收集了各种各样的要求，然后他们会根据是否有竞争力、需要花费多少精力、产品研发周期来对这些要求进行优先级的排序。现在，产品经理需要通过挑选一名客户代言人，他在我们试图要完成的工作中起着核心团队的功能，通过他来使得这些要求的使用范围更加广泛。客户代言人需要参与到要求收集活动中，重新审视并设计某一特定的方案。他们对每一个方案的交付都要进行反复的评估。他们的测试结果和使用流程说明他们的目标是要成为我们的头号必须通过的测试方案。他们遇到的障碍和缺陷成为我们最高优先级的缺陷。他们最终的评价将成为我们做出做/不做这一决定的一部分。
有了客户支持的方案，就有了所有人都可以理解的切实的团队目标（对客户而言这个目标是成功的）。优先级和重点也随之而来。最后，我们并不是在寻找成功，而是我们一直在创造成功。
创造切合实际的日程表最困难的一个方面就是做出决策
通常情况下，延迟做出决定的一个原因是你害怕做出错误的决定。讽刺的是，选择不去做决定本身就延迟了行动的时间，这并不会帮助你做出正确的抉择。即使是错误的决定也能使你更快进入一个可操做的方案，这是因为你可以立即处理一个已经做出的决定所带来的种种结果。你越快做出决定，你就能越快地开始前进，并在积极的和消极的方面都做出行动。
我并不是建议不计后果或是草率地做出决定。我推荐在可逆的方向上尽快行动，而在不可逆、高风险的方向上推迟行动。如果错误的选择所带来的不良后果很小，那么你应该基于现在所知道的事情做出最好的决策并进一步行动。在我们反复而持续地改变的技术环境中，我们不可能100%知道自己的决定是否是正确的，因为这个决定将在未来产生作用。所以只要做出决策，不要为它担心。一旦做出决策，不要再去讨论它。执行，从任何随之发生的错误中学习，继续前进。
对于你现在不能作出决定的一些事情，定义出可以弥补你现在在哪和你需要在哪这两者之间矛盾的特定行动项目，这可以帮助你做出决策。确保你的每一个行动都有清楚的客户和截止时间（见小提示#7：严格执行合乎情理的强制手段）。在我的产品团队中，我们经常出席会议，用尽一切办法讨论一个问题。在经历许多争论之后我们解散（通常因为我们需要参加有关另一项目的另一个会议）。因此，我们不但延迟作出决定，而且我们没有使一连串事情中的任何一件事更接近目标。10
| 如果没有人对一个有至关重要的影响的项目的截止时间负起责任或是义务，那么这并不是一个真正的问题。将它从日程安排里划掉，清楚地了解没有了那个决策，什么时候也不会发生，你的项目不会发生改变。 |
|---|
就像你可以从先前的提示中看见的那样，我已经提到过定义明确的行动项目、任务、负责人和截止日期。这本质上来说正是合乎情理的强制手段的真正含义。为了能确保成功，你不仅需要一个成功的计划，而且还需要一个明确的、带时间限制的任务清单，清单应该是责任人非常清楚的，且预知结果。
你同样需要对各种各样的行动或项目定义成功的标准。斯蒂芬 卡维将这个描述为任务的一开始，你的脑海里就已经知道会有什么的结果。如果要使一项活动取得成功，我们需要理解成功的定义是什么。11
用一个早期的例子来说明：成功地完成了一件事是否意味着：a）开发者向上级提交程序编码；或者b）你的同事重新检查并认同了这一设计，再次进行编码检查以保证多于一个开发者理解这一机制，这一部分的设计以100%的通过率，通过了100%的单元测试，且在这一部分编码中没有明显的大错误？
成功准则是否起作用，取决于是不是所有人都同意成功的意思。
| 在你出席的每一个会议里都使用合乎情理的强制手段这一措词。不要只将它用于提醒你的团队使用合乎情理的强制手段，而且应该让他们认识到应该在什么时候使用它们。重复是令使用合乎情理的强制手段成为习惯的关键。 |
|---|
正如小提示#1所描述的那样，我们越忙，我们发现自己越需要沟通和在团队中工作。这经常导致更多的会议。由于我们把自己的大多数沟通时间都花在开会上，所以会议应该变得更有目的性且更有意义。这在高效的会议管理中已经谈得够多了，所以我不打算再多说什么。我们都明白，最好是：
- 对这个会议有一个目标和成功准则。
- 在时间表上有一个日程安排。
- 严格遵守你的时间和会议基本准则。
- 在确定你遵守了你关于行动项目、负责人和截止日期的会议成功准则之前，不要中止会议（复习小提示#7）。
我们都知道一个成功的会议所具有的属性，但是对我们中的大多数人而言，确保我们所参加的会议具有这些属性仍然是我们的奋斗目标。
| 如果你觉得你刚从一个低效率的会议中解脱出来，这是你的错。不管是不是你在推动这个会议或是只是参与这个会议，这都不重要。你应该为你花费时间的方式负最终责任。如果你不知道会议的目的、议程或合乎情理的强制成功准则就去参加会议，那么让那次会议成为你没有得到这些重要答案而去参加的最后一次会议。 |
|---|
我们都听过这样的叹息：我们的时间表实在安排得太紧迫了。事实是，并不是时间表安排得太紧近，而是我们应该怎样调整自己去适应它。12就像我先前提到的那样，我们不能100%肯定某一个决定是否是正确的，因为它只在将来产生影响。接受时间改变我们的环境甚至有时候改变我们的目的这一事实之后，我们同样需要接受革命性的好建议。这就是说，要在项目的最初阶段以一个非常保守的姿态出来。仅仅接受非常少的（3——5）个特征，并对剩下的特征给予一定的上升空间。当项目进行之后，随着我们认识的深入，我们会相应地重新调整自己的预计和时间表。这可以使得我们把精力从抱怨紧迫的时间表转移到切合实际但却更富挑战性的最优特征清单。
革命性的好建议并不是要在时间表上延迟做出决定。我们事实上做出了一系列决定，并在整个项目进行过程中不断地进行重新审视和微小调整。
我并不赞同过多的预防措施。然而，你应该在每一个项目的关键路径和瓶颈处留出一个合乎情理的稳定缓和时间（见小提示#3：尽早定义关键路径和瓶颈），并把一个较为有把握的百分比（例如我们已经70%肯定……）作为你的时间表估计和重温准则的一部分。
通常在开发阶段，我们对在一个时间表签字并早早地负起责任感到压力。13就你现在所知的情况看来，时间表可能是完善的，所以你不能断然对其进行否定。问题仅仅在于你不知道你究竟要做些什么。把较为有把握的百分比策略加入你的考虑可以使得你欣然同意并举例说出你对你所在领域的相关考虑。
举例来说，当下一代版本1产品开始开发时——你对你原先的时间表和预计水平可能只有40%的自信。这意味着你对你自己的估计的自信只有40%，而你的估计可能最多也只有60%是正确的。和你的队友们讨论你的自信水平，包括你所不知道的东西——例如，活动、负责人和截止日期——在你的时间表估计上。
| 在没有可以弥补你现在在哪和你需要在哪这两者之间矛盾的行动计划之时，不要给出自信百分比。 |
|---|
零售业——例如服装商场、杂货店和五金店——可以理解维持一个庞大的库存所需要的花费。他们的目标是在架子上仅仅摆放足够使得商品进行流通的数量的货物。大的库存意味着不确定的开支，因为裙子可能会过时，食品可能会过期，机器也许卖不出去，而你却被所有这些东西缠住而无法脱身。
在软件行业有着相似的概念，除非我们的库存品有很多缺陷，有一整张单子的特性还没被开发出来，而且还有一连串的决定还没做出。这些项目的等待周期也是要花钱的，因为技术和客户是一直在改变的。减少等待时间的方法有：
- 分配周期性的且较频繁的稳定时间来修复和减少产品缺陷。
- 制定计划和时间表以使得你的每一个稳定时间的现行标准都能传达给某一特定的客户（这在某种程度上就像α、β、客户旅行、实习计划等等）。
- 着手工作时要制定时间表并尽早做出决定。举例来说，对每一个稳定时间使用频繁的现行准则来整理并执行你的最终部署，将决策进行集中而不是一直等待直到你的软件应用最终版本的发行。
- 在工作进行当中，对你的设计文档和测试计划进行修改。不进行改变，而是积压需要改变的地方直到你有时间去更新你的设计会导致混乱和时间延迟。记住这些文档需要转交给其它相关当事人，而不是你，而如果他们需要这些文件，他们会对文件进行评估。所以你不能什么也不做直到你有时间去做这些事情。如果这些文件是过时的，你的文件阅读者会做出不准确的决定。要在一个有秩序的基础上持续更新并重新检查需要的文档。让你的例行文档检查成为图4中给出的决策时间表在制定时必须要做的事情。
| 如果没有人负责保持设计文档的准确性并不断对其重新检查，那么一开始就不要把它写下来。如果已经写下来了，但没有人宣称对其负责，那就把它删掉。 |
|---|
降低存货的另一种方式是将你的电子邮件、你的日历、机器的维护和你将要做的事情的清单中不重要的、对你和你的客户们都没有价值的事情删去。
斯蒂芬 卡维是高效能人士的七个习惯的作者。他把四种常见的活动划分为四种类型：重要而且紧急（象限I），重要但不紧急（象限II），紧急但不重要（象限III），不紧急也不重要（象限IV）。始终在看起来非常紧急的象限（第I和第III）工作的危险是你没有把时间花在不紧急的事情上，而那些事情可能过后可以帮你摆脱一些紧急事务。象限 II 中的项目是重要但不紧急的。因此，我们经常推迟、延期、耽搁这些项目，而它们却可能帮我们摆脱紧急事务。
图8：卡维的紧急事务象限图 8
当你开始着手整理和减少存货时，分配给象限II中的项目时间的唯一方法是不去做象限III和IV中的事情。但在我们开始不去做象限III和IV中的事情之前，我们需要先认识他们。让我们考虑一些看起来紧急的事情所具有的一些混淆视听的特征，这些特征通常使得软件开发组织遇到困难。
我建议你在消除积压的缺陷和不断膨胀的特征时毫不留情。不间断地重新检查你的缺陷清单。如果缺陷或不断膨胀的请求在你生产线研发的下两个发布产品中都是没有预料到的，那么不要去理会它们了。这样做的原因是我们的工业和技术是不断在改变的。如果你生产线研发的下两个发布产品已经出现了这些问题，那么许多其它的事情也会接踵而来：
- 新的技术和方法被引进，使得原先遇到的问题迎刃而解。
- 现在的客户不是找到了一个工作区就是转向一个完全不同的产品。
- 如果你在下两个发布产品中没能解决问题，那么相对于解决其后出现的问题而言，其已经不再重要了。
| 如果你的技术支持员工或产品经理不同意不修复也不去理会某一个特殊的缺陷，那么你可以以这样的方式来挑战他们：把紧急且重要的事情放在这个产品必须修复的盘子里，除非完成修复这项工作，否则推迟产品的研发。 |
|---|
许多公司对机器安全和维护问题有各种各样消防演习式的训练。如果已经计划了消防演习，对参与者和那些需要做这项工作的人来说，在某种程度上应该是保密的。通常情况下这是“一个丢掉所有的东西”的困境。而且由于这些需要花费大力气的项目并不是显而易见地与其它任何一个项目、程序或产品紧密相关，所以通常情况下我们没有为这些项目安排时间和提供资源。每一个人都认识到安全是一个需要重视的问题，一个病毒就可以使我们停止生产，而这对每个人来说都是代价惨重的。所以，我并不是在建议跳过这些重要步骤的任何一个；我只是认为在好的研发过程中应该使它们更有效。可以试试如下建议：
- 自动更新进程
- 提前让大家都熟悉时间表（见小提示#1）
- 维修机器，扔掉没用的。如果没有人愿意负责机器的维修，那就把机器扔掉。
- 在你的公司里找到正在做相似的事情的姐妹团队，让他们共享机器和交互使用资源。
你所做的决定中约有80%是不合理的。它们中很多应该由其它人来做决定。它们中有很多从长期看来都是无关紧要的。在花费时间做出决定之前，应该保证这个决定是足够重要的。如果不是这样，不要去理会它或者让其它人来做这个决定。在某些时候，你可以问你自己：我应该是那个代表整个团队做出那个决定的人吗？
例如，如果团队花了一个小时讨论如何处理一个临时安装程序（但是在下周我们所要的程序就能送到了），这个团队正在浪费时间。这个决定根本无足轻重。你应该让某个开发成员决定怎样临时修复它并确保他没有花太多时间来做决定。不去做决定有时候是恰当的，特别是当这个决定对解决问题而言没什么帮助时。如果一个决定对任何人都不重要的话（例如，没人愿意签字对其负责，没有截止时间和行动），那么根本没有必要考虑它。这里有一个简单的例子：如果没有人感到肚子饿，那午饭吃什么就是完全不相干的事情。简单地不去谈论午饭，那就没有做出决定的必要了。
自动邮件列表对你的个人时间可以是非常有帮助的，也可以是一个障碍。如果你正在听关于结构或详尽设计的每天例行报告，而你自己却不关心这些，那会花费你的时间去过滤和重温这些项目。摆脱这些清单，将通知放在网上或中心区域（这样当你需要时你可以随时重温），或者将它们放在单独的文件夹里，从收件箱里清除。所以在你收件箱内留着但已经超过一个星期了还未阅读的电子邮件，将它移除你的收件箱。
我认识的一个忙碌的二线经理在凌晨1：00给许多团队发了电子邮件，宣布在那个早晨8：00钟的时候要开一个团队会议。由于他过去已经干过多次同样的事情，所以我认为是时候和他谈谈他所发送的消息和他的期望。
我指出并不是很多人真正到达办公室的时间是早上8：00以前；因此，早上8：00以前他们看见这封紧急邮件通知是不太可能的。因为他们没有任何时间为会议做准备，他们就不能为他提供任何有价值的意见或是他所寻找的反馈信息。这个二线经理的回复是：但是我的时间表太混乱了，以致于这是我通知召开会议的第一时间。接下去的几天里我都会很忙，因此早上8：00是我的日历上我唯一有空做这件事的时间。
他的目的是让每一个都被通知到，也真诚地希望听到他人的建议，但他没有意识到人们即使收到这封信也不代表什么。团队和一线经理已经加班加点使得自己能够完成紧迫的时间表上的事情。他们正在试图建构、过滤和控制他们自己的工作量时间表，周旋在既定的计划会议中，努力使自己的工作准时完成。凌晨1：00通知他们说早上8：00有一个会议，会产生紧急且重要的错误感觉。他们没有收到议程，所以团队假设自己可以不带任何东西，并重新安排了他们的工作时间表来满足这个通知会议的要求。这要求一个未计划的一系列任务转换。由于没有会议细节或议程，他们会质疑他们的出席对这个会议有多重要，如果他们没有时间适当为这个会议做准备，他们也会质疑自己的意见到底有多重要。同时，他们想知道是否有一个不成文的期待，每个人都必须工作到凌晨1：00以后，或者是在早上8：00之前就到达办公室，只有这样才能收到这些紧急的通知。未被计划好的会议通知造成了氛围和士气不自觉的变化。
这并不是那个二线经理想要传递的信息。在重新考虑了会议的真正目的之后，这个二线经理可以定义一个议程和需要参加会议的成员，将会议出席者的名单缩减。一旦目标和议程被勾勒出来了，他就意识到不一定非得是他来做演示；因此，这个特殊会议现在也并不取决于他那紧迫的日历了。其它的人可以在一个更合适的时间主持这个会议。一旦目标、议程和新的出席者名单出炉，团队就能够根据自己现在正在负责的其它事情，自己判断这个特殊会议的紧急性和重要性。
总是会有一大堆紧急而且重要的事情发生，使得我们的时间表短时间内产生混乱。即使如此，不要把混乱带入你的时间表或你的团队，使得形势更加复杂。
当装腔作势变成标准，而不是混乱的时候，另一种形式的混乱爆发了。公司经常会预计到会有附加的时间和一些装腔作势的言论使产品研发失败。非常普遍的是，这并不会使事情变好。让装腔作势使你的产品出局是最糟糕的项目管理。如果你首先建立了一个切合实际的时间表，那么就不需要装腔作势了。不能正确定义任务和延迟也是糟糕的项目管理。分配单一资源给并行进行的项目，其中没有合适的缓冲以及一些执行，也是糟糕的项目管理。能力成熟度模型简单将此称为级别1的状态。
对于例行日常需要以外的，为了开发产品或满足顾客而附加的意想不到的任务，收起装腔作势。一些例子是关于对客户来说成功的产品部署、提示和技巧的白皮书，在一些会议中已经做了演示。
 |
虽然这并不是改进时间表制定的所有方法的清单，但我可以自信地说它们为一些成长且工作量正在缓慢增加的公司提供了好的建议。我非常高兴能听到你关于任何一个小提示的建议，特别是当它们中的任何一个帮助了你和你的团队的时候。
|
1由于我们既不能创造也不能毁灭时间，所以与它做斗争是没有意义的。
2游手好闲非常容易失去你现在所拥有的一切东西。所以我们不需要游手好闲的人。我们更倾向于找出用少量东西创造巨大价值的方法。因此，我们需要创造出一种可以转移、有支持性的方法来改变我们忙碌的生活。
3虽然紧急事件也许不能等到任务完成（最初需要8天时间）以后才着手进行，但它也许可以等一天时间，这使得你可以继续完成你任务2的冲刺。
4对额外的请求，我指的是那些没有列在你今天的详细任务清单中的请求。额外请求是指你的经理或测试领导没有要求你必须做的事情。即使这些额外的任务没有明确提出来，它也可以使得团队的相互独立性和组织功能减弱。关键就在于要有高效的网络和和谐的环境，而由于我们都知道的原因，说不是很困难的。
5在工作断点重新进行评估并使得工作持续进行下去是很重要的。我们通常只在头脑里思考30分钟，然后就开始着手工作，但我们在时间限制之后并没有真正地停下来。执行停这一概念是这一技巧的关键。
6决定什么是主要活动是很困难的。我们不想被琐事压垮；但在某种程度上应该擅于把时间和资源划分成小块。
7有策略地在时间表上安插一些稳定时间有助于减少失误、文档回顾和整个工程的清理（见小提示#10：只要可能的话，减少存货）
8见斯坦迪什团队论文你的要求是什么？Standish Group International, Inc., 2003, Standish Group (based on 2002 CHAOS Report).
9系统要求通常会导致时间表停顿的关键的一个原因是它们没有被整合到整个项目中，在项目时间表的开始也没有进行过计算。当详细描述且对我们的项目进程进行整合时，我们只关注客户特征，但却不在意所有需要支持的任务（见小提示#2：制作出一个详细的任务清单）
10要寻找更多的小提示以快速做出决策，见 ：http：//www.liraz.com/tdecision.htm
11见斯蒂芬 卡维高效能人士的七个习惯Simon and Schuster, New York: 1989
12举例而言，如果我们试图将十英磅放在只能装五英磅的袋子里，难道那是袋子的错？
13许多高水平的项目经理喜欢形式上在房间里走一走，对早期的时间表框架进行口头上的委托事项。他的目的是对单个项目参与者进行口头事项委托，并对工作保持一定的责任。即使他的目的是好的，时间却未必恰当。我们也许不知道也不能理解这个项目在这个时间点是是否与我们的时间表相符合。
COPYRIGHT©2008,HTTP://ZEROBUG.CNBLOGS.COM .ALL RIGHTS RESERVED.
