确定功能请求优先级
确定不同请求的优先级有时会很困难且令人胆怯。 遵循相对可量化的方法，不仅可以帮助您确定正确功能的优先级，还可以帮助您向要求功能的人员解释您的决定。
确定功能优先级的第一步是确保记录每个请求，即使您可能觉得该请求不重要。 当您完成第一个版本的应用开始着手新版本时，这将帮助您创建要改进的积压事项。
提示
使用项目目标作为优先处理哪些功能的指南。
下表显示了如何记录每个功能的示例。
| 要求的功能 | 绝对必要吗？ | 实施难度 | 业务影响 |
|---|---|---|---|
| 查看审批请求列表 | 是 | ||
| 收到审批请求时，通过手机向用户实时推送通知 | 否 | 简单 | 高 |
| 尚未提交的支出报表的草稿保存功能 | 否 | 硬 | 中 |
| 与 ERP 系统集成 | 否 | 硬 | 非常高 |
提示
避免将必需品与有更好混在一起。 问问自己（或您的用户）：“如果添加此功能需要四周时间，是否值得将发布推迟四周？”
优先级象限图
列出所有功能请求后，应将请求分类到如下图所示的象限中。
快速致胜
此象限中的要求应该优先处理。 快速致胜是对业务有重大影响但易于实现的要求。
大型投资
这些要求会对业务产生重大影响，但由于以下一个或多个原因而难以实现：
需要额外投资（如新服务）
需要由专业开发人员或外部业务合作伙伴进行开发
需要很长时间（一周以上）来创建功能
涉及不同部门的多个利益干系人
小满足感
此类请求可能易于实现，但对业务的影响有限。 开始着手“小满足感”之前，您应该首先优先处理“快速致胜”和“大型投资”。 注意不要太沉迷于这些“小满足感”；一次处理太多将使它们成为一笔“大型投资”。
时间消费者
“时间消费者”将占用大量时间，但却没有什么影响。 它们可能来自不直接使用应用的高层管理人员。 面对这些情况时，您可以共享“优先级象限”图来说明是如何作出决定的。 您可能会帮助他们理解，或者可能会发现某些方面比您想象的更具影响力。
提示
让要求功能的用户查看（甚至创建！）优先级象限，以帮助相互理解。