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

Question

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

我正在尝试找出整理请求并分配我们现有资源的最佳方法。(不幸的是，业务没有为开发人员提供无穷无尽的预算，但他们仍然希望完成所有工作)

我想做一些积压和功能规划，但是我如何跨多个客户端和多个产品做到这一点呢？

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

Answer 1

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

紧急请求也是如此。一个开明的组织将能够跨不同的部门对此进行优先级排序-即紧急安全修复将任何功能排序，而不考虑所有权，但更有可能的是，“紧急”内容要么作为分配给客户端的“切片”的一部分完成，要么根据“紧急请求者”可能产生的压力来完成。

看起来你有很多变化。如果您还没有使用敏捷流程，例如XP，您应该尝试-至少在管理需求/功能和交付经常部件方面。随着任务之间的进展变得更加明显，经常交付更改也可以减轻您的一些压力。

Answer 2

我同意MaxVT的观点，你可能想看看像XP这样的东西，因为即使你正在交付功能有限的程序，他们仍然会得到一些可以帮助你的东西。

您可能还想开始根据积压列表中已有的内容来设置对那些提出需求的人的期望。

这意味着您应该与开发人员一起检查您的积压工作，确定需要完成的任务，并为每个任务分配时间。这将提供一种方式来声明项目A有x个小时，因此您可以告诉某人您可能能够到达它。

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

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

Answer 3

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

在考虑优先级积压时，您是在正确的轨道上，部分原因是关于优先级的讨论是您可以(或者可能能够)推动您的内部客户的讨论。

紧急情况下，“跳过队列！”工作，我见过的一件事是使用“红卡”，或者跳过那些直接排在队头的人，或者限制他们一次只有一个正在进行中，这样你就可以与其他不在紧急情况下工作的团队一起在非紧急情况下取得进展。

无论采用哪种方法，关键部分都是收集足够的数据，以支持与客户进行数据驱动的讨论。以最简单的形式，让团队粗略地估计积压中每个项目的大小，这样您就可以跟踪每周完成了多少工作，以及积压中有多少工作。几周后，你将有支持数据带给你的老板，以支持“我们90%的时间都在处理紧急情况。我们该怎么办？”讨论。