问当你必须对多个人项目进行多任务处理时，如何管理/组织？

EN

有许多因素需要考虑，比如项目的到期日、管理层的能见度、对业务的影响等等。

不过，通常情况下，我有效地使用了一些我使用的规则：

• 按特性/bug分解，我们将称它们为任务。这意味着您正在使用某种任务跟踪机制，这是由于从一个项目跳到另一个项目的结果。您需要知道您所在的位置以及您在项目中的去向，以便尽可能减少上下文切换的开销。
• 显然，按照每个项目的优先级顺序完成任务.
• 完成一项任务。即使项目A的优先级1任务通常比您分配的每个项目花费的时间更长，无论如何也要这样做。如果你早点离开的话，你就得重新弄清楚当你回到这个项目的时候你想要做什么。
• 如果管理层交给您任务，请创建一个优先级队列，并使其可用。如果它只是一个白板，告诉管理层，所有的任务，你被赋予的是最底层的。如果他们想把它放在最上面，他们必须看到他们正在抢先/中断的任务。
• 为每个项目分配一般的时间.如果是一天，半天，一周，任何对你的环境都有意义的事情，试着坚持下去(上面提到的完成任务除外)。如果你可以在一个早上为A项目安排2个任务，那就去做吧。不要把项目分拆得太多。和以前一样，如果你被赋予了B项目的任务，而你现在在A项目中，你可以这样说：“太好了，我明天早上就在B项目上，我会在早上第一件事看它。”
• 即使你背对背地做同一个项目，你也要记住，你有两个工作会议(在一个项目上工作的时间)，你为一个项目分配了两个工作。
• 使用有效的分离器分割会议:一天结束时，午餐，咖啡休息。任何你的大脑停止工作的东西都是100%的。上下文切换将是很自然的，即使您没有切换项目，您也必须这样做。

目标是有一个明确的时间表来管理古怪的工作量/项目。如果你坚持这样的时间表：

        Mon Tues Wed Thurs Fri
Morn    A   B    A   B     A
Aft     A   C    C   C     C

..。然后，您的度量将更加准确和可预测。如果您在开发/交付日期使用刻录图表，它们将更加准确和可预测。创建一个计划可能需要时间来考虑到某些经理、QA、其他开发人员、软件/硬件资源等的可用性，但是一旦您将其关闭，就会像往常一样，您不会那么慌张。

如果你遵守纪律，SnOrfus的建议将很好地适用于较小的、定义良好的项目。对于更大、更探索性的项目，程序员多任务处理在很大程度上是一个管理神话。乔尔·斯波斯基说，不要让人们一次只做一件事。。转换项目的频率越高，完成的任务就越少。

我有个老板坚持我要“多任务”。我的策略始终是优先处理各个项目，并首先做最优先的事情，尽可能长时间地坚持单个项目。有时，我会在一件事上延迟报告进度，这样我就可以错开进度报告，使之看起来像是在来回切换。然后我会撒谎说“是的”--我是在做多项工作。有时候，你可以先做所有非常快速的项目，这样你就可以专注于一个更长的项目(每天报告一个较短的项目，而你则专注于较长的项目)。这样我总是很有效率，我的老板也很高兴(如果有一点不正确的话)。说句公道话，我先试着和他说理，只是在失败的时候才撒谎。

这个规则的一个例外是处理技术支持请求的中断。对程序员来说，没有什么比深入了解客户的需求更重要了。这种理解的好处值得打破注意力的成本(在合理的范围内)。

祝好运!