It seems to me that this decision often comes down to office politics. One business group doesn't want to feel any less important than another, especially with identical priorities set at the top. Regardless as to how many different ways you explain why doing both at the same time is a bad idea, it seems as though the politics get in the way.
To get the best product to the users, you need to prevent developer thrashing. When the developers are thrashing, the risk of defects and length of delivery times begin to increase exponentially.
Also, if you can put your business hat on, you can try to explain to them that right now, nobody is getting any value from what the completed products will deliver. It makes more sense for the business to get the best ROI product out the door first to begin recouping the investment ASAP, while the other project will start as soon as the first is finished.
Sometimes you need to just step away from the code you have been writing for 11 hours in order to stay maximally productive. After you have been staring at the minutiae of a system you have been implementing for a long time it can become difficult to see the forest for the trees, and that is when you start to make mistakes that are hard to un-make.
I think it is best to have 2-3 current projects; one main one and 1-2 other projects that aren't on such a strict timeline.
If both projects have the same priority for the company, one obvious reason is for project managers to give higher management the illusion that both of the projects are taken care of.
Consider that the two projects could belong to different customers (or be requested by different people from higher management).
No customer wants to be told to wait while a different customer's project is given priority.
"We'll leave the other one for later" is, a lot of times, not an acceptable answer, even though this leads to delays for both projects.
I believe this is related to the notion of "Perceived Responsiveness" in a software program. Even if something takes more time to do, it looks faster when it appears to be doing something, instead of idly waiting for some other stuff to complete.
It depends on the dependencies involved. If you have another dependency upon the project that can be fulfilled when the project is not 100% complete, then it may make sense to split the developer's time. For example, if your task is large, it may make sense to have the primary developer do a design, then move on to a second task while a teammember reviews the design the primary developer came up with.
Furthermore, deserializing developers from a single task can help to alleviate boredom. Yes, there is potentially significant loss in the context switch, but if it helps keep the dev sharp, it's worth it.
if you go by whats in the great and holy book 'peopleware', you should keep your programmer on one project at a time.
the main reason for this is that divided attention will reduce productivity.
unfortunately, because so many operational managements are good businessman rather then good managers, they may think that multitasking or working on both projects somehow means more things are getting done (which is impossible, a person can only physically exists in one stream of the space-time continuum at one time).
I think the number 1 reason from a management standpoint is for perceived progress. If you work on more than one project at the same time stakeholders are able to see progress immediately. If you hold one project off then the stakeholders of that project may not like that nothing is being worked on.
Working on more than 1 project also minimizes risks somewhat. For example if you work on one project first and that project takes longer than expected you could run into issues with the second project. Stakeholder also most likely want their project done now. Holding one off due to another project can make them reconsider going ahead with the project.
Depending on what the projects are you might be able to leverage work done in one for the other. If they are similar then doing both at the same time could be of benefit. If you do them in sequence only the subsequent projects can benefit from the previous ones.
Most often projects are not a constant stream of work. Sometimes developers are busy and sometimes not. If you only work on 1 project at a time a developer and other team members would likely be doing nothing while the more 'administrative' tasks are taking place. Managing the time over more than one project allows teams to get more done in a shorter timeframe.
As a developer I prefer working on multiple projects as long as the timelines are reasonable. As long as I'm not being asked to do both at the same time with no change in the schedule I am fine. Often if I'm stuck on one project I can work on the other. It depends on the projects though.
I'd personally prefer the former but management might want to see progress in both projects. You might also recognise inaccurate estimates earlier if you are doing some work on both, enabling you to inform the customer earlier.
So from a development perspective 1 is the best option but from a customer service point of view 2 is probably better.
It's managing your clients expectations; if you can tell both clients you are working on their project but it will take a little longer due to other projects then to say we are putting your project off till we finish this other project the client is going to jump ship and find someone that can start working on their project now.
It's a plaecbo effect - splitting a developer between two projects in the manner you've described gives people/"the business" the impression that work is being completed on both projects (at the same rate/cost/time), whilst in reality it's probably a lot more inefficient, since context switching and other considerations carries a cost (in time and effort).
On one hand, it can get the ball rolling on things like requirement clarifications and similar tasks (so the developer can switch to the alternate project when they are blocked) and it can also lead to early input from other business units/stakeholders etc.
Ultimately though, if you have one resource then you have a natural bottleneck.
The best thing you can do for that lone developer is to intercept people( from distracting that person), and try to carry some of the burdon around requirements, chasing clarifications and handling user feedback etc.
The only time I'd ever purposely pull a developer off their main project is if they would be an asset to the second project, and the second project was stalled for some reason. If allowing a developer to split a portion of their time could help jump-start a stalled project, I'd do that. This has happened to me with "expert" developers - the ones who have a lot more experience/specialized skills/etc.
That being said, I would try to keep the developer on two projects for as little time as possible, and bring them back to their "main" project. I prefer to allow people to focus on one task at a time. I feel that my job as a manager is to balance and shift people's priorities and focus - and developers should just develop as much as possible.
There are three real-life advantages of splitting developers' time between projects that cannot be ignored:
Specialisation: doing or consulting on work that requires similar specialised knowledge in both projects.
Consistency and knowledge sharing: bringing consistency into the way two separate products are built and work, spreading knowledge accross the company.
Better team utilisation: on a rare occasion when one of the projects is temporarily on hold waiting for some further input.
Splitting time between several projects is beneficial when it does not involve a significant change in context.
Having a developer to work single-handedly on multiple software development projects negates the benefit of specialisation (there isn't any in the case), consistency and knowledge sharing.
It leaves just the advantage of time utilisation, however if contexts differ significantly and there is no considerable overlap between projects the overhead of switching will very likely exceed any time saved.
Context switching is a very interesting beast: contrary to its name implying a discreet change the process is always gradual. There are various degrees of having context information in one’s head: 10% context (shallow), 90% (deep). It takes less time to shallow-switch as opposed to fully-switch; however there is a direct correlation between the amount of context loaded (concentration on the task) and output quality.
It’s possible to fill your time entirely working on multiple distinct projects relying on shallow-switching (to reduce the lead time), but the output quality will inevitably suffer. At some point it’s not only “non-functional” aspects of quality (system security, usability, performance) that will degrade, but also functional (system failing to accomplish its job, functional failures).
By splitting the time between two projects, you can reduce the risk of delaying one project because of another.
Let's assume the estimate for both projects is 3 months each. By doing it serially, one after the other, you should be able to deliver the first project after 3 months, the second project 3 months later (i.e. after 6 months). But, as things go in software development, chances are that the first project encounters some problems so it takes 12 months instead. Or, even worse, goes into the "in use, but never quite finished" purgatory. The second project starts late or even never!
By splitting resources, you avoid this problem. If everything goes well with the second project, you are able to deliver it after 6 months, no matter how well the first project does.
The real life situations where working on multiple projects can be an advantage is in the case where the spec is unclear (every time) and the customer is often unavailable for clarification. In those cases you can just switch to the other project. This will cause some task switching and should be avoided in a perfect world, but then again...
This is basically my professional life in a nutshell :-)
发布评论
评论（13）
在我看来，这个决定常常归结为办公室政治。 一个业务团队不希望感觉自己比另一个业务团队更不重要，尤其是在高层设定了相同的优先事项的情况下。 不管你用多少种不同的方式来解释为什么同时做这两件事是一个坏主意，似乎政治都会成为障碍。
为了向用户提供最好的产品，您需要防止开发人员的混乱。 当开发人员陷入困境时，缺陷风险和交付时间开始呈指数级增加。
此外，如果您可以戴上您的商业帽子，您可以尝试向他们解释，目前没有人从已完成的产品将提供的内容中获得任何价值。 对于企业来说，首先推出最佳投资回报率产品以尽快收回投资更有意义，而其他项目将在第一个项目完成后立即启动。
It seems to me that this decision often comes down to office politics. One business group doesn't want to feel any less important than another, especially with identical priorities set at the top. Regardless as to how many different ways you explain why doing both at the same time is a bad idea, it seems as though the politics get in the way.
To get the best product to the users, you need to prevent developer thrashing. When the developers are thrashing, the risk of defects and length of delivery times begin to increase exponentially.
Also, if you can put your business hat on, you can try to explain to them that right now, nobody is getting any value from what the completed products will deliver. It makes more sense for the business to get the best ROI product out the door first to begin recouping the investment ASAP, while the other project will start as soon as the first is finished.
有时，您需要暂时离开已经编写了 11 个小时的代码，以保持最大的工作效率。 当你长时间盯着所实施的系统的细节之后，你可能会变得只见树木、不见森林，这就是你开始犯下难以挽回的错误的时候。
我认为最好有2-3个当前项目； 一个主要项目和 1-2 个其他项目没有如此严格的时间表。
Sometimes you need to just step away from the code you have been writing for 11 hours in order to stay maximally productive. After you have been staring at the minutiae of a system you have been implementing for a long time it can become difficult to see the forest for the trees, and that is when you start to make mistakes that are hard to un-make.
I think it is best to have 2-3 current projects; one main one and 1-2 other projects that aren't on such a strict timeline.
如果两个项目对公司具有相同的优先级，一个明显的原因是项目经理会给高层管理人员一种错觉，即这两个项目都得到了照顾。
考虑到这两个项目可能属于不同的客户（或者由更高管理层的不同人员要求）。
没有客户希望在其他客户的项目获得优先权时被告知等待。
很多时候，“我们将另一个项目留到以后”并不是一个可接受的答案，尽管这会导致两个项目的延误。
我相信这与软件程序中的“感知响应性”的概念有关。 即使某件事需要更多时间来做，当它看起来正在做某事时，它看起来会更快，而不是无所事事地等待其他事情完成。
If both projects have the same priority for the company, one obvious reason is for project managers to give higher management the illusion that both of the projects are taken care of.
Consider that the two projects could belong to different customers (or be requested by different people from higher management).
No customer wants to be told to wait while a different customer's project is given priority.
"We'll leave the other one for later" is, a lot of times, not an acceptable answer, even though this leads to delays for both projects.
I believe this is related to the notion of "Perceived Responsiveness" in a software program. Even if something takes more time to do, it looks faster when it appears to be doing something, instead of idly waiting for some other stuff to complete.
这取决于所涉及的依赖关系。 如果您对项目有另一个依赖项，并且可以在项目未 100% 完成时完成，那么分割开发人员的时间可能是有意义的。 例如，如果您的任务很大，那么让主要开发人员进行设计，然后继续执行第二项任务，同时由团队成员审查主要开发人员提出的设计，这可能是有意义的。
此外，将开发人员从单个任务中反序列化可以帮助减轻无聊感。 是的，上下文切换可能会带来重大损失，但如果它有助于保持开发的敏捷性，那么这是值得的。
It depends on the dependencies involved. If you have another dependency upon the project that can be fulfilled when the project is not 100% complete, then it may make sense to split the developer's time. For example, if your task is large, it may make sense to have the primary developer do a design, then move on to a second task while a teammember reviews the design the primary developer came up with.
Furthermore, deserializing developers from a single task can help to alleviate boredom. Yes, there is potentially significant loss in the context switch, but if it helps keep the dev sharp, it's worth it.
如果你遵循伟大而神圣的书“peopleware”中的内容，你应该让你的程序员一次专注于一个项目。
这样做的主要原因是分散的注意力会降低生产力。
不幸的是，由于许多运营管理人员都是优秀的商人，而不是优秀的经理，他们可能认为同时处理多项任务或同时处理两个项目意味着可以完成更多的事情（这是不可能的） ，一个人在某一时刻只能物理存在于时空连续体的一条流中）。
希望有帮助:)
if you go by whats in the great and holy book 'peopleware', you should keep your programmer on one project at a time.
the main reason for this is that divided attention will reduce productivity.
unfortunately, because so many operational managements are good businessman rather then good managers, they may think that multitasking or working on both projects somehow means more things are getting done (which is impossible, a person can only physically exists in one stream of the space-time continuum at one time).
hope that helps :)
我认为从管理的角度来看，第一个原因是感知进步。 如果您同时从事多个项目，利益相关者能够立即看到进展。 如果你推迟一个项目，那么该项目的利益相关者可能会不喜欢没有任何进展。
从事多个项目也可以在一定程度上最大限度地降低风险。 例如，如果您首先处理一个项目，并且该项目花费的时间比预期长，那么您可能会在第二个项目中遇到问题。 利益相关者也很可能希望他们的项目现在就完成。 由于另一个项目而推迟一个项目可能会让他们重新考虑是否继续该项目。
根据项目的内容，您也许可以将一个项目中完成的工作用于另一个项目。 如果它们相似，那么同时进行这两项操作可能会有所裨益。 如果您按顺序执行它们，则只有后续项目才能从之前的项目中受益。
大多数情况下，项目并不是持续不断的工作。 有时开发人员很忙，有时则不忙。 如果您一次只处理 1 个项目，则开发人员和其他团队成员可能会在执行更多“管理”任务时无所事事。 管理多个项目的时间可以让团队在更短的时间内完成更多的工作。
作为一名开发人员，只要时间安排合理，我更喜欢同时处理多个项目。 只要我不被要求同时做这两件事，并且日程安排没有改变，我就可以了。 通常，如果我被困在一个项目上，我可以做另一个项目。 但这取决于项目。
I think the number 1 reason from a management standpoint is for perceived progress. If you work on more than one project at the same time stakeholders are able to see progress immediately. If you hold one project off then the stakeholders of that project may not like that nothing is being worked on.
Working on more than 1 project also minimizes risks somewhat. For example if you work on one project first and that project takes longer than expected you could run into issues with the second project. Stakeholder also most likely want their project done now. Holding one off due to another project can make them reconsider going ahead with the project.
Depending on what the projects are you might be able to leverage work done in one for the other. If they are similar then doing both at the same time could be of benefit. If you do them in sequence only the subsequent projects can benefit from the previous ones.
Most often projects are not a constant stream of work. Sometimes developers are busy and sometimes not. If you only work on 1 project at a time a developer and other team members would likely be doing nothing while the more 'administrative' tasks are taking place. Managing the time over more than one project allows teams to get more done in a shorter timeframe.
As a developer I prefer working on multiple projects as long as the timelines are reasonable. As long as I'm not being asked to do both at the same time with no change in the schedule I am fine. Often if I'm stuck on one project I can work on the other. It depends on the projects though.
我个人更喜欢前者，但管理层可能希望看到这两个项目都取得进展。 如果您同时对这两方面进行一些工作，您也可能会更早地发现不准确的估计，从而能够更早地通知客户。
因此，从开发角度来看，1 是最佳选择，但从客户服务角度来看，2 可能更好。
I'd personally prefer the former but management might want to see progress in both projects. You might also recognise inaccurate estimates earlier if you are doing some work on both, enabling you to inform the customer earlier.
So from a development perspective 1 is the best option but from a customer service point of view 2 is probably better.
它正在管理客户的期望； 如果你可以告诉两个客户你正在从事他们的项目，但由于其他项目而需要更长的时间，那么如果你说我们将推迟你的项目直到我们完成另一个项目，那么客户就会跳槽并找到可以的人现在就开始他们的项目。
It's managing your clients expectations; if you can tell both clients you are working on their project but it will take a little longer due to other projects then to say we are putting your project off till we finish this other project the client is going to jump ship and find someone that can start working on their project now.
这是一种普拉克波效应 - 按照您所描述的方式将开发人员分配到两个项目会给人们/“企业”留下两个项目都完成工作的印象（以相同的速度/成本/时间），而实际上它是可能效率低得多，因为上下文切换和其他考虑因素会带来成本（时间和精力）。
，它可以推动诸如需求澄清和类似任务之类的事情（因此开发人员可以在受阻时切换到备用项目），并且还可以导致其他业务部门/利益相关者等的早期输入。
一方面 但是，如果你只有一种资源，那么你就会遇到自然的瓶颈。
你能为那个孤独的开发人员做的最好的事情就是拦截人们（以免分散那个人的注意力），并尝试承担一些围绕需求的负担，追逐澄清和处理用户反馈等。
It's a plaecbo effect - splitting a developer between two projects in the manner you've described gives people/"the business" the impression that work is being completed on both projects (at the same rate/cost/time), whilst in reality it's probably a lot more inefficient, since context switching and other considerations carries a cost (in time and effort).
On one hand, it can get the ball rolling on things like requirement clarifications and similar tasks (so the developer can switch to the alternate project when they are blocked) and it can also lead to early input from other business units/stakeholders etc.
Ultimately though, if you have one resource then you have a natural bottleneck.
The best thing you can do for that lone developer is to intercept people( from distracting that person), and try to carry some of the burdon around requirements, chasing clarifications and handling user feedback etc.
我唯一一次故意让开发人员退出他们的主要项目是如果他们是第二个项目的资产，而第二个项目由于某种原因陷入停滞。 如果允许开发人员分配一部分时间可以帮助启动一个停滞的项目，我会这样做。 这种情况发生在我的“专家”开发人员身上——那些拥有更多经验/专业技能/等等的人。
话虽这么说，我会尽量让开发人员在两个项目上停留尽可能短的时间，然后将他们带回他们的“主要”项目。 我更喜欢让人们一次专注于一项任务。 我觉得作为一名经理，我的工作就是平衡和转移人们的优先事项和焦点——而开发人员应该尽可能地发展。
The only time I'd ever purposely pull a developer off their main project is if they would be an asset to the second project, and the second project was stalled for some reason. If allowing a developer to split a portion of their time could help jump-start a stalled project, I'd do that. This has happened to me with "expert" developers - the ones who have a lot more experience/specialized skills/etc.
That being said, I would try to keep the developer on two projects for as little time as possible, and bring them back to their "main" project. I prefer to allow people to focus on one task at a time. I feel that my job as a manager is to balance and shift people's priorities and focus - and developers should just develop as much as possible.
在现实生活中，在项目之间分配开发人员的时间具有三个不容忽视的优势：
一致性和知识共享：使两个独立产品的构建和工作方式保持一致，在整个公司传播知识。
一致性和知识共享
更好的团队利用率：在极少数情况下，其中一个项目暂时搁置，等待进一步的输入。
更好的团队利用率：在极少数情况下，其中
当不涉及环境的重大变化时，在多个项目之间分配时间是有益的。
让一名开发人员单独处理多个软件开发项目会抵消专业化（在这种情况下没有任何专业化）、一致性和知识共享的好处。
它只留下了时间利用的优势，但是，如果上下文显着不同并且项目之间没有相当大的重叠，则切换的开销很可能会超过节省的任何时间。
上下文切换是一个非常有趣的野兽：与它的名称相反，它意味着谨慎的更改，该过程始终是渐进的。 一个人头脑中的上下文信息有不同的程度：10% 上下文（浅），90%（深）。 与完全切换相比，浅切换所需的时间更少； 然而，加载的上下文量（任务的集中度）和输出质量之间存在直接相关性。
依靠浅层切换（以减少交付时间），您可以完全将时间花在多个不同的项目上，但输出质量将不可避免地受到影响。 在某些时候，不仅质量的“非功能”方面（系统安全性、可用性、性能）会降低，而且功能方面（系统无法完成其工作、功能故障）也会降低。
There are three real-life advantages of splitting developers' time between projects that cannot be ignored:
Specialisation: doing or consulting on work that requires similar specialised knowledge in both projects.
Consistency and knowledge sharing: bringing consistency into the way two separate products are built and work, spreading knowledge accross the company.
Better team utilisation: on a rare occasion when one of the projects is temporarily on hold waiting for some further input.
Splitting time between several projects is beneficial when it does not involve a significant change in context.
Having a developer to work single-handedly on multiple software development projects negates the benefit of specialisation (there isn't any in the case), consistency and knowledge sharing.
It leaves just the advantage of time utilisation, however if contexts differ significantly and there is no considerable overlap between projects the overhead of switching will very likely exceed any time saved.
Context switching is a very interesting beast: contrary to its name implying a discreet change the process is always gradual. There are various degrees of having context information in one’s head: 10% context (shallow), 90% (deep). It takes less time to shallow-switch as opposed to fully-switch; however there is a direct correlation between the amount of context loaded (concentration on the task) and output quality.
It’s possible to fill your time entirely working on multiple distinct projects relying on shallow-switching (to reduce the lead time), but the output quality will inevitably suffer. At some point it’s not only “non-functional” aspects of quality (system security, usability, performance) that will degrade, but also functional (system failing to accomplish its job, functional failures).
通过在两个项目之间分配时间，您可以降低因一个项目而延迟另一个项目的风险。
我们假设这两个项目的预计各为 3 个月。 通过依次进行，您应该能够在 3 个月后交付第一个项目，在 3 个月后（即 6 个月后）交付第二个项目。 但是，随着软件开发的发展，第一个项目很可能会遇到一些问题，因此需要 12 个月的时间。 或者，更糟糕的是，进入“正在使用，但从未完全完成”的炼狱。 第二个项目开始得很晚，甚至永远！
通过分割资源，可以避免这个问题。 如果第二个项目一切顺利，无论第一个项目做得有多好，您都可以在 6 个月后交付它。
By splitting the time between two projects, you can reduce the risk of delaying one project because of another.
Let's assume the estimate for both projects is 3 months each. By doing it serially, one after the other, you should be able to deliver the first project after 3 months, the second project 3 months later (i.e. after 6 months). But, as things go in software development, chances are that the first project encounters some problems so it takes 12 months instead. Or, even worse, goes into the "in use, but never quite finished" purgatory. The second project starts late or even never!
By splitting resources, you avoid this problem. If everything goes well with the second project, you are able to deliver it after 6 months, no matter how well the first project does.
在现实生活中，在规范不明确（每次）并且客户经常无法澄清的情况下，处理多个项目可能是一种优势。 在这种情况下，您可以切换到其他项目。
这将导致一些任务切换，在完美的世界中应该避免，但话又说回来......
简而言之，这基本上就是我的职业生涯:-)
The real life situations where working on multiple projects can be an advantage is in the case where the spec is unclear (every time) and the customer is often unavailable for clarification. In those cases you can just switch to the other project.
This will cause some task switching and should be avoided in a perfect world, but then again...
This is basically my professional life in a nutshell :-)