Project management 如何确定未来功能的优先级（企业web开发）

假设您是一个拥有2000名用户和7名开发人员的内部企业web应用程序的产品经理。您有一个350个未来特性的列表，每个特性的工作时间从5天到150天不等

您如何选择要使用的功能，以及如何运行发布过程

以下是我的想法：（如果无聊就跳过）

• 发布过程。一次处理多个功能，准备好后分别发布。另一种选择（到目前为止我们一直在做的事情）是选择一组特定的功能，将它们指定为“发布”，然后一次发布所有功能（通过大量电子邮件发布）
  较短的发布过程的优点是，我们可以在完成开发后立即发布特性。更大流程的优点是更容易组织

• 功能优先级。将所有未来功能放在一个电子表格中，其中包含功能、描述、评论、评估、好处、（您的）评估、（您的）好处列。将副本交给两名高级工程师、另一名高级项目经理和您自己
  工程师们估计了所有的特征（精确到什么程度？互相咨询？）。为了确定效益，每个人在未来功能中分配分数（总计=10*[未来功能的数量]）（不相互咨询？），比较分数和平均值（？）
  这里的另一个潜在策略是仅以绝对（比如）1-100分对每个功能进行排名。拥有一个绝对排名是很好的，因为它使我们的功能列表更改时的优先级更容易（我们不希望每次有人提出一个新功能时都要重新分配点）

---

你的策略是什么？有没有任何书籍/网站在这个细节层次上攻击这个问题？

迈克·科恩（Mike Cohn）写的一本很棒的书，叫做《敏捷评估与规划》（Agile Estimating and Planning）。它有一些很好的方法来估计和计划发布。包括一个名为“规划扑克”的规划游戏，在该游戏中，工程团队用卡片聚在一起建立用户故事。每个工程师正面朝下打一张牌1、2、3、5、8、13。高低卡解释，你再做一次。在重复1或2次之后，通常会在相同的估计上收敛

还有软件架构之外的内容：由Luke Hohmann创建并维护成功的解决方案，这可能有助于解决一些与产品管理相关的问题，以及用于确定优先级的推理。我还没有读过这本书，但我参加了卢克·霍曼的一次演讲，他谈到了他的书的主题，我迫不及待地想读它

此外，我还建议阅读有关各种敏捷开发过程的书籍，如Scrum、Crystal Clear和XP。还有Ken Schwaber的Scrum和Alistair Cockburn的Crystal Clear:一种针对小型团队的人力方法论。极限编程也解释了：拥抱变化（第二版）由肯特·贝克和辛西娅·安德烈斯

对于特性优先级，这通常由涉众完成。您需要开发满足涉众需求的特性，正如Luke Hohmann指出的，这些特性包括系统架构

然而，最重要的事情之一是确保您与团队就软件开发过程达成一致。如果您强制执行一个流程，而团队不相信，那么它将不起作用。

当然您没有350个独立的功能，有些功能必须依赖于其他功能。

---

把它们都放进一些任务管理软件中，让你定义哪些任务依赖于哪些其他任务，你可能很快就会发现你有了一个更简单的决策过程…

至于发布过程，您可以在功能准备就绪时介绍这些功能，并通过公司博客通知用户，该博客在完成新功能时更新。这样的博客文章应该简要介绍该功能、在哪里找到它、如何使用它等。
这不仅能让你的用户保持好奇，而且还能让潜在客户了解你产品的进展情况

至于未来实施的优先顺序：让那里的客户也参与进来如何？看看uservoice（它用于跟踪此站点的请求/错误）。它提供了一种很好的方式，让用户对最想要的东西进行投票，并显示正在进行的工作和计划的内容。

“以绝对（比如）1-100的比例对每个功能进行排名”

按顺序建造它们

当你得到（a）重要价值或（b）小东西的临界质量时，释放它们

---

始终按优先顺序工作。首先构建最重要的东西。尽可能快地交付价值

这里的一些人已经说过了——让最终用户参与进来什么和等待什么的决策过程。毕竟，这不是关于什么对你有用，而是什么对你的最终用户有用

也就是说，我不会让“所有用户自行决定”；用户组中应有一名与您共事的代表（即高级用户角色）

即使这样，你也不会对用户说“你想要什么功能？”你会问他们下一步想看到什么功能。为什么你这样对他们说，而不是让他们挑选一个庞大的单个功能的电子表格，原因有两个：1）他们不知道依赖性，2）你想收集一个逻辑版本的功能包

因此，用户代表可能会说“我们需要让照片库下一步工作”。他们可能不知道PhotoGalery实际上与文件上传模块相同（它只接受不同的文件类型）

所以，在下一个版本中，你将照片库和文件上传打包在一起——考虑到文件上传的75%是因为