如何管理竞争有限资源的多个客户需求

Question

所以我为内部开发团队管理项目。这就是我们所有的客户都是业务的内部人员。

我正在试图找出整理请求并分配我们拥有的资源的最佳方法。 （不幸的是，对于开发人员而言，业务并没有无穷无尽的预算，但他们仍然希望一切都完成）

我想做一些积压和功能规划，但我如何在多个客户端和多个产品上做到这一点。

最后但并非最不重要的紧急请求。有人说明天我们需要这个，你怎么处理这个问题。我似乎每周都有一个，我们可以做，我们只是从不吃功能积压。

Answer 1

根据子项目的合作程度，您可以在一个优先级顺序中管理功能和积压（因此，组织最重要的任务首先是透明的，但决策者必须能够收集优先级），或者分配时间/团队，然后在分配给客户端的时间或资源切片内管理每个客户端的优先级。在整个组织范围内，这不是最有效的方法，但一旦做出这个艰难的决定，您就可以自由地独立管理每个项目。

紧急请求完全相同。一个开明的组织将能够在不同的部门中对此进行优先级排序 - 即紧急安全修复程序对任何功能进行排名，而不管所有权如何，但“紧急”事件更有可能作为分配给客户的“切片”的一部分完成，或者根据“紧急请求者”可以产生的压力。

看起来你有很多变化。如果您尚未使用敏捷流程（如XP），则应尝试 - 至少管理要求/功能并经常提供部件。随着任务的进展变得更加明显，提供变更通常也可以缓解一些压力。

Answer 2

我同意MaxVT你可能想看看像XP这样的东西，因为即使你提供功能有限的程序，它们仍然可以得到一些有用的东西。

您可能还希望根据您在待办事项列表中已有的内容，开始设定提出要求的人的期望。

这意味着您应该与开发人员一起完成积压工作，并确定需要完成哪些任务，并为每项任务分配时间。这将提供一种方式来声明对于项目A有x小时，所以你可以告诉别人什么时候你可以到达它。

通过敏捷，您可以查看必须实现哪些功能才能让应用程序变得有用，然后让应用程序到达那一点。然后，您可以以某种优先级方式跟踪要添加的功能，以便首先实现最重要的功能，然后在您有时间添加更多功能时。

了解每项功能必须采取的措施以及应采取的措施将更好地帮助您完成项目管理，并为您生成报告。

Answer 3

当你的资源有限且紧急情况占用大部分时间时，你可以做的最好的事情之一（除了处理紧急情况），就是让效果可见，这样你就可以获得更高级别的数据与利益相关者的讨论（例如，“这真的是一个紧急情况吗？可以做些什么来防止它变成紧急情况？”等等。）

在考虑优先顺序时，您处于正确的轨道上，部分原因是对优先级的讨论是您可以（或可能）推翻内部客户的讨论。

紧急情况“跳过队列！”工作，我看到工作的一件事是使用“红牌”，要么跳过那些权利到队列的头部，要么限制他们只有一个正在进行中，所以你可以取得进展非紧急工作与未处理紧急情况的其他团队合作。

您采取的任何方法的关键部分是收集足够的数据，以支持与客户进行数据驱动的讨论。在最简单的形式中，让团队粗略估计积压中每个项目的大小，这样您就可以跟踪每周完成的工作量，以及积压工作量。几个星期后，你将获得支持数据，以便你的老板支持“我们90％的时间用于处理紧急情况。我们将采取什么措施？”讨论

Answer 4

全部在调度和资源中（稍后将详细介绍资源）。还有一个方面是对你的问题进行变更控制。

计划

我使用谷歌电子表格，因为它简单，每个人都很舒服/熟悉它，每个人都可以访问它simaltanious（它也免费！）。

如果你看下面的图片，你可以看到有一个'Assigned To'列 - 这就是程序员的初衷。你会有这样的多个时间表，每个项目一个。

在第二张图片中，您可以看到一些摘要。包括程序员在项目中分配的总小时数。这使您可以计划何时可以使用其他项目。

本文的其余部分在这里 - ＆gt; Project Schedules with Google Spreadsheets

<强>资源

你可能有你的项目时间表，但如果所有内部程序员都忙于项目，你会怎么做？你实际上没有资源。这是外包承包商可以提供帮助的地方。如果你没有这方面的预算，那么人们只需要等到程序员离开他们被分配到的项目（例如“对不起老板，但greg不会再完成他当前的项目2周。如果你想把他拉下来那么项目，我们可以，但那时该项目将提供“＆lt; - 祝你好运：”

错误管理＆amp;改变控制

还有进行错误管理和变更控制的方法，但是我不想深入其中，然后每周2-3小时对每个程序员的前台日历进行调试。具有运行的功能，聚集在一起5-10并记录它们，然后再将它们交给程序员编写代码（从v1.1中创建一个包）。

Answer 5

这有两个方面，即实践和政治。第一个是直接的，第二个是一团糟。

其中一些是糟糕的管理/营销方式，所以我提前道歉，但它很好。

为了在实际水平上对优先次序进行分类，我首先对工作和效益进行高级评估，每个评分为1到10，然后将它们绘制在矩阵上（在X轴上作出努力，在Y轴上获益） ）。企业必须评估利益（并证明其合理性），IT团队和企业共同评估工作（业务团队不会弄乱IT的估算，但他们可能需要在自己的时间内添加）。

从广义上讲，高效率低效益象限（右下角）中的任何东西都会立即被杀死 - 太多太少。高努力，高效益（右上）的任何东西都被归类为一个重大项目，需要进一步调查，因为这些通常是你会发现一个或其他评估结果。任何高效益低成本（左上角）都是快速获胜并跳到列表的顶部。最后，低功耗低效益（左下角）的问题是问号。与主要项目一样，这些需要进一步检查，但在这种情况下，您试图将它们变成快速获胜（您可以修改范围以增加收益或减少工作量）或显示它们'实际上会比人们想象的更多的工作，应该被杀死。

但总的来说，越接近左上角（努力程度低，效益高），事情就越早完成。

一个关键的事情 - 所有信息和整个矩阵都是公开的 - 如果存在分歧，开发人员只是管理流程，而不是对其进行裁决。每周发布最新的矩阵（以及由此产生的时间表），并在所有相关方之间定期打电话，以确保每个人都同意。

这涉及政治方面 - 你知道某些东西是浪费时间但是某些人非常重要。理想情况下，这是你的经理获得保留的地方，但一般来说，如果你有一个透明的过程（即利益/努力分数和矩阵都是公开的），推动一些不值得的东西的人要么（a）因为其他人而斗争回过头来指出他的改变是垃圾，不应该发生，更不用说优先考虑了，或者（b）有足够的影响力，这无关紧要，但至少你会像其他人那样压迫你理解这一点。

透明的流程是您处理最后一分钟请求的方式。如果每个有请求的人都知道他们在队列中的哪个位置，那么人们在不注意的情况下放弃内容会变得更加困难，因为他们不仅仅是在搞乱开发人员，而是在与同行搞混并推回他们的项目。

一般来说，那些做到这一点的人要么具有足够的影响力，要么无论如何都无法阻止它，或者激怒其他人要求做出足够的改变，以致他们将被迫最大限度地减少他们的不良行为。

这些最后一分钟问题的一个有趣的子集是依赖于时间的项目，即如果在本周完成比在等待六个月时获益更大的项目。一个例子可能是在立法税改变进入之前有三个月的窗口，项目将允许公司利用它。

在这种情况下，项目会根据它的最大可行效益进行评估，然后在计划中进行重新评估 - 因此，如果它具有最大利益，那么它明天就会发生很好，但即使有了它的最大利益，它也不会发生在两个几个月你必须根据它在那个时间点传送的内容并重新评估（通常会杀死它）来降低利益。

简而言之：

• 良好的福利/努力评估可以让您选择那些对商业最有影响的人
• 开发人员管理的透明定义良好的流程，而不是裁决。

Answer 6

如果是外部客户的开发，我会说您需要为“紧急”请求收取更多费用。但是，如果没有改变组织的内部收费模式（以及你的F＆amp; A分支机构的滴答声），那么你就无法做到这一点。

你有一个很好的例子可以引进一个开发者，但当然$$$总是很紧张。

坦率地说，我喜欢FogBUGZ（并且公平地说还有其他案例/事件跟踪器，FB是我最喜欢的）。我可以快速看到队列中的内容及其优先级（无论项目/客户端如何）。

我给你的其他建议是：

1. 宣传工作队列的大小。可能需要一些内部保密，但也许您可以在墙上/网站上发布您在旅途中的所有项目。

2. 获取现有项目的组织优先级。您组织中的某个人必须知道什么时候需要什么，什么是最重要的 - 无论是经理，CEO还是BOD。 。
   其他一切都在队列的末尾 。
   如果Bob有紧急请求，而你正在处理Jim和Mary的请求;让鲍勃首先通过玛丽和吉姆获得许可，让他们在队列中跳跃（或者如果有必要，请高过头）。
   或者，Bob可以选择推送队列中较高的一个或多个项目，并将其替换为紧急请求。无论哪种方式，它都会在紧急请求中产生固有的额外成本。不是真正紧急事件的事情往往不再被称为。它有点像ER系列“即使你不需要它也能将每个实验室请求标记为STAT”

如，

[Jim1] <- [Mary1] <- [Bob1] <- [Jim2] <- [Jim3]
[Jim1] <- [Mary1] <- [Bob1] <- [Jim2] <- [Jim3] <- [Bob2]
                       |-------------swap-------------|
[Jim1] <- [Mary1] <- [Bob2] <- [Jim2] <- [Jim3] <- [Bob1]

您的内部（和外部）客户的答案几乎总是肯定的（有时由于技术原因没有）。但是，“是”总是后面跟着“但是”。

You - Yes bob, we can work on that project for you, but we can't start until 
around X months from now.

bob - That's not good enough

You - OK, you have a couple options. If you want to shift some of your other 
requests around we can push it to the start of your queue, that would get it 
started in Y months. 

Bob - Still not good enough

You - Well, you can negotiate with Jim and Mary to leapfrog their projects.

Bob - They won't budge

You - Then go over their heads, and talk to Mr. Dithers`

[some time later]

You - Yes Mr. Dithers, we can work on Jim's requests. You are aware that will 
push back Jim and Mary's requests.

Mr. Dithers - Yup.

You - Aye-Aye Capt'n.

[some time later]

Jim - Why the $%#$%#$5 aren't you working on my request

You - Talk to Mr. Dithers

请记住，如果一切都是重中之重，那么NOTHING是首要任务。

修改
继FogBUGZ之后（自从你问过），它不仅仅是问题/错误跟踪。您也有功能请求，查询和计划项目（您可能必须升级到最新版本才能利用这些功能）。充分利用它。

确保您在FB中包含功能请求。你转入FB越多，它给你的画面就越好。请记住使用过滤器和网格视图。

FB有一个wiki。在那里发布你的小组高级工作清单供所有人查看。