在两个项目之间分配开发人员的时间有哪些优势？

Question

我有两个项目，具有相同的优先级和工作时间需求，以及一个开发人员。两种可能的方法：

1. 首先交付一个项目。
2. 分开开发人员的时间并稍后交付。

我看不出人们会选择第二种方法的任何理由。但他们这样做。你能解释一下为什么吗？

Answer 1

在我看来，这个决定通常归结为 办公室政治 。一个企业集团不希望感受到任何重要性，尤其是在顶部设置相同的优先级。无论你用多少种不同的方式解释为什么同时做这两件事都是一个坏主意，似乎政治方式就会受到阻碍。

要向用户提供最好的产品，您需要防止开发人员捶打。当开发人员发生颠簸时，缺陷风险和交付时间开始呈指数级增长。

此外，如果您可以放置​​您的业务，您可以尝试向他们解释，现在，没有人从已完成的产品将提供任何价值。对于业务而言，首先要获得最佳投资回报率产品以便尽快开始收回投资更有意义，而另一个项目将在第一个项目完成后立即启动。

Answer 2

有时候你需要离开你写的代码11个小时才能保持最高效率。在你盯着你已经实施了很长一段时间的系统的细节之后，很难看到森林中的树木，那就是当你开始犯下难以制造的错误时。

我认为目前最好有2-3个项目;一个主要的项目和1-2个其他没有严格时间表的项目。

Answer 3

如果两个项目对公司具有相同的优先级，那么一个明显的原因是项目经理要让高级管理层认识到两个项目都得到了照顾。

考虑这两个项目可能属于不同的客户（或者由来自高层管理人员的不同人员请求）。

当一个不同客户的项目获得优先权时，没有客户希望被告知等待。

“我们会留下另一个以后”，很多时候，这不是一个可接受的答案，即使这会导致两个项目的延迟。

我认为这与软件程序中“感知响应”的概念有关。即使某些事情需要花费更多时间，但当它似乎在做某事时看起来更快，而不是无所事事地等待其他一些事情来完成。

Answer 4

这取决于所涉及的依赖性。如果项目在项目未完全完成时可以满足项目的另一个依赖关系，那么分割开发人员的时间可能是有意义的。例如，如果您的任务很大，让主要开发人员进行设计可能是有意义的，然后在团队成员审查主要开发人员提出的设计时继续执行第二项任务。

此外，从单个任务反序列化开发人员可以帮助减轻无聊。是的，在上下文切换中可能存在重大损失，但如果它有助于保持开发者的利益，则值得。

Answer 5

如果你在伟大而神圣的“人物软件”中找到了什么，那么你应该让你的程序员一次完成一个项目。

主要原因是分散注意力会降低生产力。

不幸的是，因为很多运营管理人员都是优秀的商人而不是优秀的经理，他们可能会认为多任务处理或在这两个项目上工作意味着更多的事情要完成（这是不可能的，一个人一次只能存在于时空连续体的一个流中。）

希望有所帮助：）

• LM

Answer 6

我认为从管理角度来看，第一个原因是感知进步。如果您同时处理多个项目，利益相关者可以立即看到进度。如果你关闭一个项目，那么该项目的利益相关者可能不喜欢没有任何工作。

开展一个以上的项目也可以在一定程度上降低风险。例如，如果您首先处理一个项目并且该项目花费的时间比预期的长，那么您可能会遇到第二个项目的问题。利益相关者也很可能希望他们的项目现在完成。由于另一个项目而关闭一个可能会让他们重新考虑继续该项目。

根据项目的不同，您可以将一项工作完成另一项工作。如果他们相似，那么同时做两件事可能会有好处。如果按顺序执行，只有后续项目可以从之前的项目中受益。

大多数情况下，项目不是一个持续不断的工作。有时候开发人员很忙，有时也不忙。如果您一次只处理1个项目，那么开发人员和其他团队成员可能会在执行更多“管理”任务时无所事事。通过管理多个项目的时间，团队可以在更短的时间内完成更多工作。

作为开发人员，只要时间表合理，我更喜欢在多个项目上工作。只要我没有被要求同时做两件事而没有改变时间表我就没事了。通常，如果我坚持一个项目，我可以在另一个项目上工作。这取决于项目。

Answer 7

我个人更喜欢前者，但管理层可能希望看到两个项目的进展。如果您正在对两者进行一些工作，您可能也会更早地识别出不准确的估算值，从而使您能够更早地通知客户。

因此，从发展的角度来看，1是最佳选择，但从客户服务的角度来看，2可能更好。

Answer 8

它正在管理您的客户期望;如果你可以告诉两个客户你正在处理他们的项目，但由于其他项目需要更长的时间，然后说我们正在关闭你的项目，直到我们完成这个项目，客户端将跳槽并找到一个可以现在开始研究他们的项目。

Answer 9

这是一种愚蠢的效果 - 以你所描述的方式将开发人员分成两个项目给人们/“业务”给人的印象是两个项目的工作都在完成（同样的速度/成本/时间），同时实际上它可能效率低得多，因为上下文切换和其他考虑需要花费成本（时间和精力）。

一方面，它可以在需求澄清和类似任务之类的事情上滚动（因此开发人员可以在被阻止时切换到备用项目）并且还可以导致其他业务部门/利益相关者的早期输入等

最终，如果你有一个资源，那么你就有一个天然的瓶颈。

你可以为那个单独的开发人员做的最好的事情就是拦截人们（分散注意力的人），并尝试围绕要求，追逐澄清和处理用户反馈等方面进行一些操作。

Answer 10

我唯一一次故意将开发人员从他们的主要项目中拉出来是因为他们是第二个项目的资产，第二个项目由于某种原因而停滞不前。如果允许开发人员分割他们的一部分时间可能有助于启动一个停滞不前的项目，我会这样做。这种情况发生在我身上的“专家”开发人员 - 那些拥有更多经验/专业技能等的人。

话虽这么说，我会尽可能在最短的时间内让开发人员参与两个项目，并将他们带回他们的“主要”项目。我更愿意让人们一次专注于一项任务。我觉得我作为经理的工作是平衡和改变人们的优先事项和重点 - 开发人员应该尽可能地发展。

Answer 11

在不可忽视的项目之间分配开发人员的时间有三个现实优势：

1. 专业化：在两个项目中进行或咨询需要类似专业知识的工作。

2. 一致性和知识共享：使两个独立产品的构建和工作方式保持一致，在公司内传播知识。

3. 更好的团队利用率：在其中一个项目暂时搁置等待进一步投入的极少数情况下。

如果不涉及上下文的重大变化，则几个项目之间的分割时间是有益的。

让开发人员在多个软件开发项目上单独工作，否定了专业化的好处（在这种情况下没有），一致性和知识共享。

它只留下时间利用的优势，但是如果上下文显着不同并且项目之间没有相当大的重叠，则切换的开销很可能超过任何节省的时间。

上下文切换是一个非常有趣的野兽：与其名称相反，暗示一个谨慎的变化，这个过程总是渐进的。在一个人的头脑中有不同程度的上下文信息：10％上下文（浅），90％（深）。与全开关相比，浅开关需要更少的时间;然而，加载的上下文量（任务集中度）与输出质量之间存在直接关联。

有可能完全依靠浅切换（缩短交付时间）来完成多个不同项目的工作，但输出质量将不可避免地受到影响。在某些时候，不仅质量（系统安全性，可用性，性能）的“非功能”方面会降级，而且还会起作用（系统无法完成其工作，功能故障）。

Answer 12

通过分割两个项目之间的时间，可以降低因另一个项目而推迟一个项目的风险。

我们假设这两个项目的估算值分别为3个月。通过一个接一个地连续进行，您应该能够在3个月后交付第一个项目，第二个项目在3个月后（即6个月后）交付。但是，随着软件开发的进展，第一个项目可能会遇到一些问题，因此需要12个月。或者，更糟糕的是，进入“使用中，但从未完全”炼狱。第二个项目开始得很晚，甚至从不！

通过拆分资源，可以避免此问题。如果第二个项目一切顺利，无论第一个项目做得多好，您都可以在6个月后交付。

Answer 13

在多个项目上工作的现实生活情况可以成为优势的情况是规范不清楚（每次）并且客户通常无法澄清。在这些情况下，您可以切换到另一个项目。 这将导致一些任务切换，应该在完美的世界中避免，但是再次......

这基本上是我的职业生涯，简而言之： - ）