我有两个项目，具有相同的优先级和工作时间需求，以及一个开发人员。两种可能的方法：
- 先交付一个项目。
- 拆分开发人员的时间并在以后交付。
我看不出人们为什么会选择第二种方法。但他们确实如此。你能解释一下为什么吗？
1414 次
13 回答
12
在我看来，这个决定往往归结为办公室政治。一个业务组不希望感觉比另一个不重要，尤其是在最高优先级设置的情况下。不管你有多少种不同的方式来解释为什么同时做这两件事是一个坏主意，似乎政治阻碍了。
为了向用户提供最好的产品，您需要防止开发人员崩溃。当开发人员陷入困境时，缺陷的风险和交付时间的长度开始成倍增加。
另外，如果你能戴上你的商业帽子，你可以试着向他们解释，现在没有人从完成的产品所提供的东西中获得任何价值。对于企业来说，首先获得最佳 ROI 产品以开始尽快收回投资更有意义，而其他项目将在第一个项目完成后立即开始。
于 2009-04-20T23:34:30.457 回答
7
有时你需要离开你已经编写了 11 个小时的代码，以保持最大的生产力。在你一直盯着一个你已经实施了很长时间的系统的细节之后，可能会变得很难只见树木不见森林，这就是你开始犯难以消除的错误的时候。
我认为最好有2-3个当前项目；一个主要项目和 1-2 个其他项目不在如此严格的时间表上。
于 2009-04-20T23:34:34.217 回答
5
如果这两个项目对公司来说具有相同的优先级，一个明显的原因是项目经理给上级管理层一个假象，即这两个项目都得到了照顾。
考虑这两个项目可能属于不同的客户（或由更高管理层的不同人员提出要求）。
当其他客户的项目被优先考虑时，没有客户希望被告知等待。
很多时候，“我们将把另一个留到以后”是不可接受的答案，即使这会导致两个项目的延迟。
我相信这与软件程序中的“感知响应”概念有关。即使某件事需要更多时间来完成，当它似乎在做某事时它看起来会更快，而不是无所事事地等待其他一些事情完成。
于 2009-04-20T23:36:07.770 回答
2
这取决于所涉及的依赖项。如果您在项目未 100% 完成时对项目有另一个可以实现的依赖项，那么分配开发人员的时间可能是有意义的。例如，如果您的任务很大，让主要开发人员进行设计，然后在团队成员审查主要开发人员提出的设计时继续执行第二项任务可能是有意义的。
此外，从单个任务中反序列化开发人员可以帮助减轻无聊。是的，上下文切换可能会造成重大损失，但如果它有助于保持开发人员的敏锐度，那就值得了。
于 2009-04-20T23:29:01.530 回答
2
如果你按照伟大而神圣的书“peopleware”中的内容，你应该让你的程序员一次只做一个项目。
主要原因是注意力分散会降低生产力。
不幸的是，因为很多运营管理人员都是优秀的商人而不是优秀的管理者，他们可能认为多任务处理或同时处理两个项目意味着更多的事情正在完成（这是不可能的，一个人只能物理地存在于空间的一个流中——一次时间连续体）。
希望有帮助:)
- LM
于 2009-04-21T00:19:28.243 回答
2
我认为从管理的角度来看，第一个原因是感知进步。如果您同时处理多个项目，利益相关者能够立即看到进展。如果你推迟了一个项目，那么该项目的利益相关者可能不喜欢什么都没有做。
从事一个以上的项目也可以在一定程度上降低风险。例如，如果您首先从事一个项目，而该项目花费的时间比预期的要长，那么您可能会遇到第二个项目的问题。利益相关者也很可能希望他们的项目现在完成。由于另一个项目而推迟一个项目会使他们重新考虑是否继续该项目。
根据项目是什么，您可能能够将一个完成的工作用于另一个。如果它们相似，那么同时进行两者可能会有所帮助。如果您按顺序执行它们，则只有后续项目才能从以前的项目中受益。
大多数情况下，项目并不是一个固定的工作流。有时开发人员很忙，有时不忙。如果您一次只处理一个项目，则开发人员和其他团队成员可能会在执行更多“管理”任务时什么都不做。管理多个项目的时间可以让团队在更短的时间内完成更多工作。
作为一名开发人员，只要时间表合理，我更喜欢从事多个项目。只要我没有被要求同时做这两件事而不改变日程安排，我就很好。通常，如果我被困在一个项目上，我可以在另一个项目上工作。但这取决于项目。
于 2009-04-21T02:02:36.577 回答
1
我个人更喜欢前者，但管理层可能希望看到这两个项目的进展。如果您对两者都进行了一些工作，您可能还会更早地识别出不准确的估计，从而使您能够更早地通知客户。
因此，从开发的角度来看，1 是最好的选择，但从客户服务的角度来看，2 可能更好。
于 2009-04-20T23:29:05.913 回答
1
它正在管理您的客户期望；如果您可以告诉两个客户您正在从事他们的项目，但由于其他项目需要更长的时间，然后说我们将您的项目推迟到我们完成另一个项目，客户将跳船并找到可以现在开始着手他们的项目。
于 2009-04-20T23:34:32.423 回答
1
这是一种 plaecbo 效应 - 以您所描述的方式将开发人员分成两个项目会给人们/“企业”这样的印象，即两个项目的工作正在完成（以相同的速率/成本/时间），而实际上它是可能效率低得多，因为上下文切换和其他考虑会带来成本（时间和精力）。
一方面，它可以在需求澄清和类似任务等事情上取得进展（因此开发人员可以在它们被阻止时切换到备用项目），它还可以导致其他业务部门/利益相关者等的早期投入。
但最终，如果您拥有一种资源，那么您就会遇到自然瓶颈。
你能为那个孤独的开发者做的最好的事情就是拦截人们（以免分散那个人的注意力），并尝试在需求方面承担一些负担，寻求澄清和处理用户反馈等。
于 2009-04-21T00:36:12.680 回答
1
我唯一一次故意将开发人员从他们的主要项目中拉出来是他们是否会成为第二个项目的资产，而第二个项目由于某种原因而停滞不前。如果允许开发人员分配一部分时间可以帮助启动一个停滞的项目，我会这样做。这发生在“专家”开发人员身上——那些拥有更多经验/专业技能/等的开发人员。
话虽如此，我会尽量让开发人员在两个项目上停留的时间尽可能短，然后让他们回到他们的“主要”项目。我更喜欢让人们一次专注于一项任务。我觉得我作为经理的工作是平衡和转移人们的优先事项和重点——开发人员应该尽可能地发展。
于 2009-04-21T01:14:46.643 回答
0
在项目之间分配开发人员的时间具有三个不容忽视的现实优势：
专业化：在两个项目中从事或咨询需要类似专业知识的工作。
一致性和知识共享：将一致性引入两个独立产品的构建和工作方式，在整个公司传播知识。
更好地利用团队：在极少数情况下，其中一个项目暂时搁置等待进一步的输入。
当不涉及上下文的重大变化时，在多个项目之间分配时间是有益的。
让开发人员单枪匹马地处理多个软件开发项目会否定专业化（没有任何专业化）、一致性和知识共享的好处。
它只保留了时间利用的优势，但是如果上下文差异很大并且项目之间没有大量重叠，则切换的开销很可能会超过节省的任何时间。
上下文切换是一种非常有趣的野兽：与它的名字相反，它暗示着一种谨慎的变化，这个过程总是渐进的。一个人的头脑中有不同程度的上下文信息：10% 上下文（浅），90%（深）。与完全切换相比，浅切换所需的时间更少；然而，加载的上下文量（专注于任务）和输出质量之间存在直接相关性。
依靠浅切换（以减少前置时间）可以将您的时间完全用于多个不同的项目，但输出质量将不可避免地受到影响。在某些时候，不仅质量的“非功能性”方面（系统安全性、可用性、性能）会降低，而且功能性（系统无法完成其工作、功能故障）也会降低。
于 2009-04-21T10:10:47.900 回答
0
通过在两个项目之间分配时间，您可以降低因另一个项目而延迟一个项目的风险。
让我们假设这两个项目的估计都是 3 个月。通过一个接一个地依次进行，您应该能够在 3 个月后交付第一个项目，在 3 个月后（即 6 个月后）交付第二个项目。但是，随着软件开发的发展，第一个项目很可能会遇到一些问题，因此需要 12 个月。或者，更糟糕的是，进入“使用中，但从未完全完成”的炼狱。第二个项目开始晚了，甚至从来没有！
通过拆分资源，您可以避免此问题。如果第二个项目一切顺利，你可以在 6 个月后交付它，无论第一个项目做得如何。
于 2009-04-21T10:24:08.400 回答
0
在现实生活中，在多个项目上工作可能是一个优势的情况是规范不清楚（每次）并且客户经常无法澄清。在这些情况下，您可以切换到另一个项目。这会导致一些任务切换，在完美的世界中应该避免，但话又说回来......
简而言之，这基本上就是我的职业生涯:-)
于 2009-04-25T21:44:56.517 回答