如何管理功能请求和软件更改？

Question

我是一名软件工程师，在过去的几年里，我成为了事实上的软件项目经理，仅仅因为没有一个。因此，为了保持我们在研发/工程部门的理智，客户已经习惯了带着他们的要求来找我。我没有这个领域的经验，所以这是我第一次担任软件项目的项目经理。我管理过其他东西，但没有管理软件。

那么，您如何管理软件项目并标记优先级呢？请求以不频繁的间隔出现，所以我们很可能正在为其他人做一些事情，然后另一个人带着一份需要处理的“匆忙”工作而来。说“先到先得”还是说“先到先得”，还是说是钱最多的人？

Answer 1

我们最终得出的结论是，我们现在将每两个月举行一次销售/工程会议，讨论当前的项目和即将到来的或未来的功能要求。销售工程师将成为项目经理，至少他们将与最新的产品产品相一致。在过去，把它传递给工程部并忘记它是很容易的。这可能会减轻软件工程师必须做的工作，并使销售和管理部门有责任明智地利用我们的时间。

Answer 2

我发现，客户越抱怨他们的请求有多紧急，除非他们本身也是一个开发人员，这通常是一个好的迹象，表明这个请求根本不紧急。我在大学时的一位教授总是告诉我们不要让紧急打扰到重要的事情。

我通常按以下顺序对请求进行分类：

1. 与最近的升级或迁移有关的问题(最重要)。
2. 安全修复。
3. 现有系统的功能中断。
4. 坏的功能在RC和测试版功能。
5. 付费功能请求。
6. R&D特性请求来自大部分用户。
7. 只有一两个用户的研发功能请求。

最后一个问题实际上需要更多的时间，因为它们往往是那些“我昨天就需要它”的请求。实际上，用户很少完全考虑他们实际需要什么，以及它将如何支持他们的业务模型。最常见的情况是，这些紧急请求一旦送达，就会被使用一两次而被遗忘。一旦被遗忘，它们就会成为一个无穷无尽的安全漏洞和意外后果的头痛。

Answer 3

我喜欢

其原则：

1. 气急
2. QII -重要但不紧急
3. QIII -不重要，但紧迫
4. QIV -不重要也不紧急