Project management 如何管理争夺有限资源的多个客户端需求

所以我为一个内部开发团队管理项目。也就是说，我们所有的客户都是企业内部的

我试图找出整理请求和分配资源的最佳方法。不幸的是，企业对开发人员没有无止境的预算，但他们仍然希望一切都能完成

我想做一些积压工作和功能规划，但我如何跨多个客户机和多个产品做到这一点

---

最后但并非最不重要的是紧急请求。有人说我们明天需要这个，你怎么处理。我似乎每周都有一个，我们可以做到这一点，但我们永远不会吃到功能待办事项。

根据子项目的合作程度，您可以按照单一的优先顺序管理功能和待办事项。因此，组织最重要的任务首先是透明的，但是，决策者必须能够在优先级上达成一致，或者划分时间/团队，然后在分配给客户的时间或资源片内与每个客户一起管理优先级。在整个组织范围内，这并不是最有效的方法，但一旦做出这个艰难的决定，您就可以自由地独立管理每个项目

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

---

看起来你有很多变化。如果你还没有使用敏捷过程，比如XP，你应该尝试——至少是管理需求/特性和交付部分。随着任务之间的进展变得越来越明显，经常交付更改也可以减轻您的一些压力。

我同意MaxVT的观点，即您可能希望看到类似XP的东西，因为即使您交付的程序功能有限，它们仍然可以得到一些帮助

您可能还希望根据积压工作列表中已有的内容，开始为提出需求的人设定期望值

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

通过敏捷，您可以了解应用程序必须实现哪些功能才能发挥作用，然后让应用程序达到这一点。然后，您可以以某种优先级的方式跟踪要添加的功能，这样您就可以首先实现最重要的功能，然后在有时间时向其中添加更多功能

---

了解每个功能必须做什么以及需要多长时间才能更好地帮助您进行项目管理，并为您的上级生成报告。

当您的资源有限且紧急情况占用了您的大部分时间时，除了处理紧急情况之外，您能做的最好的事情之一是，是为了使效果可见，以便您有数据与利益相关者进行更高级别的讨论，例如，这真的是紧急情况吗？有什么办法可以避免这件事成为紧急事件

在考虑按优先级排序的积压工作时，您走上了正确的轨道，部分原因是关于优先级的讨论是您可以或可能能够回击内部客户的讨论

紧急情况请不要排队！工作，我见过的一件工作就是使用红牌，要么跳过那些排在队伍最前面的牌，要么限制它们一次只进行一张，这样你就可以和其他没有处理紧急情况的团队一起在非紧急工作中取得进展

---

无论您采取何种方法，其中一个关键部分就是收集足够的数据，以支持与客户进行数据驱动的讨论。以最简单的形式，让团队粗略估计待办事项中每个项目的大小，这样您就可以跟踪每周完成的工作量以及待办事项中的工作量。几周后，您将有支持性数据提交给您的上司，以支持我们90%的时间都在处理紧急情况。我们该怎么办？讨论。

一切都在日程安排和资源中，请稍后再谈资源。对于你的问题，还有一个改变控制的方面

日程安排

我使用谷歌电子表格是因为它简单，每个人都对它感到舒适/熟悉，每个人都可以免费访问它

如果你看下面的图片，你可以看到有一个'Assigned To'列，这是 程序员。您将有多个这样的计划，每个项目一个

在第二幅图中，您可以看到一些摘要。包括程序员在项目中分配的总小时数。这可以让你计划他们何时可以在另一个项目上工作

文章的其余部分在这里->

资源

---

您可能已经有了项目时间表，但是如果您的所有内部程序员都在忙于项目，您会怎么做？你实际上是资源不足。这是外包承包商可以提供帮助的地方。如果你没有这方面的预算，那么人们只需等到程序员从分配给他们的项目中走出来，例如对不起，老板，但是格雷格在接下来的两周内不会完成他当前的项目。如果你想让他完成这个项目，我们可以，但是如果是为外部客户开发的项目，那么这个项目将延迟交付，我想说你需要对紧急请求收取多一点费用。然而，除了改变组织的内部收费模式和F&A分支机构的运作之外，你在这方面无能为力

您有很好的理由再引入一名开发人员，但当然$$$总是很紧

坦白地说，我喜欢FogBUGZ，公平地说，还有其他的案件/事件追踪者，FB是我的最爱。无论项目/客户如何，我都可以快速查看队列中的内容及其优先级

我给你的其他建议是：

公布工作队列的大小。可能需要一些内部保密，但也许你可以在墙上/网站上发布你正在进行的所有项目

获取现有项目的组织优先级。组织中的某个人必须知道什么时候需要什么，什么是最重要的——无论是经理、首席执行官还是董事会。 . 其他的都排在队列的末尾。 . 如果鲍勃有紧急请求，而你正在处理吉姆和玛丽的请求；让Bob先通过Mary和Jim，获得允许在队列中跳过他们，或者在必要时越过他们的头顶。 或者，Bob可以选择将队列中较高的一个或多个项目向下推，并将其替换为他的紧急请求。无论哪种方式，它都会给紧急请求带来固有的额外成本。不是真正紧急情况的事情往往不再被称为紧急情况。它有点像ER线，将每个实验室的请求标记为STAT，即使你现在不需要它

e、 g

记住，如果一切都是头等大事，没有什么是头等大事

编辑： 除了你问过的FogBUGZ之外，这不仅仅是问题/错误跟踪。您也有功能请求、查询和日程安排项目，您可能需要升级到最新版本才能利用这些功能。充分利用它

确保您在FB中包含您的功能请求。你往FB里倒的越多，它给你的图片就越好。记住使用过滤器和栅格视图

---

FB有一个维基。将您的团队高级工作列表张贴在那里，让所有人都能看到。

这有两个方面，一个是实际的，一个是政治的。第一个是直截了当的，第二个是一团糟

其中一些是可怕的管理/营销胡说八道，所以我提前道歉，但这是好的

为了在实践层面上理清优先顺序，我首先对努力和效益进行了高水平的评估，每项评估的范围为1到10，然后将其绘制在X轴上的努力矩阵上，Y轴上的效益矩阵上。业务部门必须评估效益并证明其合理性，it团队和业务部门共同评估工作。业务团队不会干扰it部门的评估，但他们可能需要自己增加时间

从广义上讲，右下角高努力低效益象限中的任何东西都会立即被杀死——以太多的代价换取太少的代价。在高努力、高收益的右上角的任何项目都会被归类为一个主要项目，需要进一步调查，因为这些通常是您会发现一个或其他评估的地方。左上角的任何高收益低努力都是快速的胜利，并跃居榜首。最后，左下角低努力低效益的东西是问号。与大型项目一样，这些项目需要进一步检查，尽管在这种情况下，您试图将其转化为快速成功，您可能能够修改范围以增加效益或减少工作量，或者表明它们实际上比人们想象的要多，应该被杀

但一般来说，越靠近左上角，低努力、高效益的事情就应该越早完成

一个关键的问题是——所有的信息和整个矩阵都是公开的——如果存在分歧，开发人员只是管理流程，而不是对其进行裁决。每周发布最新矩阵和生成的时间表，并在 所有相关方确保每个人都同意

这涉及到政治方面——你知道有些事情是在浪费时间，但它是由一个非常重要的人提出的。理想情况下，这是您的经理获得其保留的地方，但通常情况下，如果您有一个透明的流程，即收益/努力得分和矩阵都是公开的，一个追求不值得的东西的人要么因为其他人的反对而挣扎，指出他的改变是垃圾，根本不应该发生，更不用说优先考虑了，要么b有足够的影响力，这无关紧要，但至少你被其他人所覆盖，他们会给你施加压力，你明白这一点

透明的流程是如何处理最后一分钟的请求。如果每个有请求的人都知道他们在队列中的位置，那么对其他人来说，在没有通知的情况下把东西放进去会变得更加困难，因为他们不仅仅是在和开发人员捣乱，他们也在和他们的同事捣乱，并推后他们的项目

一般来说，这样做的人要么有足够的影响力，你无论如何都无法阻止，要么会激怒其他人，要求他们做出改变，迫使他们将不良行为最小化

这些最后一分钟的问题中有一个有趣的子集是依赖时间的项目，也就是说，如果在本周完成，比等待六个月带来的好处更大的项目。一个例子可能是，在立法税收变更之前有三个月的窗口期，该项目将允许公司利用这一点

在这种情况下，项目将根据其最大可行效益进行评估，然后在其列入进度表时重新进行评估-因此，如果有了最大效益，项目将在明天进行，那就太好了，但是，如果即使它的最大收益在两个月内无法实现，你也必须根据它在那个时间点上所能提供的收益，放弃收益，并重新评估，这通常会扼杀它

简言之：

良好的效益/努力评估允许您选择那些对业务产生积极影响最大的项目 透明的、定义良好的过程，由开发人员管理而不是裁决。

---

我们实际上使用Fogbugz进行问题跟踪，我问这个问题的主要原因是想弄清楚如何让它作为一个管理工具更好地工作。你能给我一些提示吗？

[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