在考虑支持问题的同时，我们如何切实可行地计划项目？

我们在工作中遇到了问题：我们正在尝试安排工作时间，以便我们可以评估时间范围并获取截止日期。

问题在于，在不知道将要发生的所有事情的情况下很难计划一个项目。

例如，现在我们已经计划了到12月初的所有项目，但是到那时，我们将进行各种内部和外部会议，电话会议和额外的工作。最好说一个项目需要三个星期，但是如果这段时间有一个星期值得中断，那么完成日期将推迟一周。

问题是三折：

1. 当我们计划项目时，时间尺度是按字面意义计算的。如果告诉我们，如果我们估计三个星期，则将截止日期定为三个星期的时间，并且没有延期的余地。

2. 临时工作等意味着我们在项目上浪费了生产时间。

3. 有时客户没有我们需要的时间去做工作，所以有时他们会来找我们，说他们需要在月底之前完成一个项目，即使我们认为工作需要两个月-更不用说我们已经有工作要做。

我们有一个甘特图，我们试图将其包含在我们拥有的所有项目中，并填写了时间表，但它们根本没有与甘特图进行比较。这很难说“嗯，我们为这个项目计划了3个星期，但是我们在这里已经损失了一个星期，所以截止日期必须推迟一周。”

错过我们与客户沟通的最后期限也是不专业的。

其他人如何处理这种情况？您如何管理项目计划？您将多少“额外”时间安排到一个项目中，以说明在项目期间发生的非项目工作？您如何处理支持问题以及错误和问题？您在计划期间无法解释的事情？

更新

很多好的答案，谢谢。

问题是尽管在不知道将要发生的所有事情的情况下很难计划一个项目。

这就是风险管理的重点。您不可能一无所知，因此您需要根据自己的知识进行计划，并确定哪些因素可能会对您的计划产生最大的影响以及发生的可能性。通过说如果X发生，也将评估进度表的潜在影响，这将使进度表滑移估计的Y天或几周（关键字-估计）。

很好，说一个项目要花3个星期，

永远不要给出这样的具体估计。给出一个范围或量化达到该估计值的概率。例如，说“该项目将需要2-5周”或“此项目在3周内完成的可能性为85％，在4周内完成的可能性为95％”。

对客户而言，一直说我们错过了最后期限也并不专业。

真正。但是，您正在混合使用“估计”，“计划”和“期限”的概念。您的估计是完成给定任务或项目将花费多长时间以及达到目标的可能性的近似值。截止日期是客户施加的日期，必须在该日期完成项目才能增加价值。日程安排是您使用可用资源来满足截止日期的方式。

有时候，根本不可能在最后期限内完成分配的工作，并且世界上的所有估算和计划都不会有所作为。

所以我的问题是……其他人如何做到这一点？您如何管理项目计划？您计划将多少“额外”时间安排到一个项目中，以解决在此期间发生的任何事情？

我建议您阅读两本书，分别由史蒂夫·麦康奈尔（Steve McConnell）撰写：软件评估：揭开妖术的神秘面纱和快速开发：驯服野性软件时间表。软件估计就是要提出您的估计，将其提供给客户，以及谈判和处理不切实际的期望的某些方面。快速开发是常规项目管理，处理开发生命周期，进度，资源分配，以及如何最好地计划和预算项目以满足您的估计和期限。

我建议深入研究Scrum开发过程的细节。它涵盖了按focus factor度量标准进行的此类旁听活动。基本上，您必须进行2-3个冲刺/迭代，然后测量团队的关注因子（对于每个成员，这也会有所帮助）。之后，您将能够提供涵盖日常活动的更准确的估算。

看看这篇文章- “焦点因素”

如果您中的任何一个熟悉敏捷开发，您可能已经听说过焦点因素（或生产率因素）。它用于计划以帮助确定您必须处理多少“实际时间”。这是“真实时间”与“理想时间”之间的区别。

关于中断的事情是，对于给定的个人或团队，他们倾向于在相对较小的概率范围内发生。例如，您每周大约有相同数量的会议，或者每个月用于紧急错误修复的时间大约相同，或者为在办公桌旁的人回答问题所花费的时间相同，尤其是在平均很长一段时间。

许多现代调度技术都将这一点考虑在内。Scrum将其分解为速度。基于证据的调度还对任何给定的估计使用具有置信区间的速度。当您决定在任何给定的一周内可以完成多少个“番茄”时，番茄会考虑打扰。所有这些都取决于跟踪中断的历史测量值，并将它们以某种方式纳入您的估计中。我建议您看看所有这些内容，并设计出一种适用于您的团队的技术。

到处都是好的建议。

可能对解决支持问题有帮助的另一件事是，让人们在固定的“循环”基础上给予支持。

例如，如果您有5个开发人员，则将其分配给一周的每一天。当天到来时，指定的开发人员仅在支持下工作。第二天，另一位开发人员接管了支持。这样，每个人都有机会停留在自己的“流程”中，每个人都可以品尝到狗食。

你怎么ACTUALLY选择瓜分支持定时工作没有真正的问题（该天的周循环只是一个例子）。重要的是将支持时间限制为固定的固定间隔。通过权衡取舍，可以使开发时间更加可预测，因为您无法“每个人都放弃”来处理支持问题。

这是一种真正伴随经验的技能，通常人们在被要求能够准确判断出这种事情之前就会被问到。我一直在一个非正式的风格下，在一个紧密联系的团队中工作，但是我们制定了一些经验法则，似乎很合适。

首先，任何任务都不会少于一周。即使一个任务似乎只需要几天的时间，也要花费数周的时间。出于某些原因，本周结束前将无法完成。

第二，尽最大努力估计任务将花费的时间，包括中断，客户支持问题，通过测试完成任务等。现在，将这个数字加倍。那是您的估计（以周为单位）。

第三，确保您的经理尚未在估算中添加一些填充。我们的团队中有一位经理抱怨我们的估计。事实证明，他已经准备将其乘以2.1（根据经验得出的填充估算值），在告诉他之前，我们已经将其加倍了。

它不是一个花哨的工具，并且可能不是一个完美的方法，但是效果很好。

人们在做估计要明白，没有哪支球队是以往任何时候都 100％的项目。您有请病假，休假，陪审义务，丧亲假，所需的人力资源会议（这是节省时间！），与项目无关的团队会议，不可避免的延误，洗手间休息，对已经生产的物品的支持工作，处理电子邮件， ，在旧计算机死后配置新计算机，回答有关未来工作的问题并为该工作做估算，指导初级人员等。估算员在8个小时内承担6个小时以上是不负责任的每天可用。这是无法满足截止日期的保证。如果您保证不能按时完成任务，则可以保证客户不满意。

您是完全正确的-在不知道将要发生的所有事情的情况下很难计划项目。但是，跟踪规范的事情以及您要完成的任务非常重要。计划管理在这里发挥作用。我一直在使用Microsoft项目管理（标准版），该项目还包括项目管理计划软件中的功能。

您可以访问http://www.microsoft.com/project/en/us/schedule-management.aspx了解更多信息。

您的项目团队似乎有很多隐藏的工作，使您失去了重点和速度。实际分离处理任务可能是有益的

..support问题，错误和资料？

特定人群，以便其他团队成员可以专注于新的开发任务。通过这种方式，他们的整体产量可能会下降，但是由于分散注意力的减少，质量将会提高。作为回报，这将减少错误的数量，因此，一项特殊的工作使它可以进入您的项目。

至于计划部分，我完全同意托马斯·欧文斯的回答。