需求管理不是堆功能，是在做产品生命力的加减法。本周分享下moscow排序法。这是个在需求管理中常用的排序方法。游戏项目开发的过程中，都会有远超开发量级的需求和诸多构想，要确保重要的需求得以优先满足，可以用这个方法来让团队成员对于每个需求交付的重要性达成共识。
这个方法是把需求成must（必须有），should(应该有)，could（可以有），won't（不会有）这四个类型。权重排序上，必须有>应该有>可以有>>不会有。这个分类方法，除了共识外避免冲突和误解外，主要还在帮助团队在产品开发过程中有更好的管理风险，以及在有限的时间资源下来达成更好的更有价值的功能交付。
- 必须有，是产品的生命线，是产品在市场中立足的 生存基因，决定产品是否成立。常说的硬装底层，如核心玩法循环的完整性，缺失的话游戏无法正常运行体验。
- 应该有，是产品的体验线，是支撑体验的骨骼系统，虽然权重低于必须有，但基本上都直接影响玩家留存。如任务指引的流畅度，决定了玩家能走多远，虽然缺失时可以用硬核等来定义用户的筛选，但面向用户时还是应该要有。
- 可以有，是产品的吸引线，就像是产品的肌肉线条，是锦上添花的加分项，非必需能提升质感。例如某些动态变化系统、角色动作细节，有则惊艳，无也无妨。如果资源紧张下，通常是安排到下阶段才做。在游戏体验愈加同质和成熟的行业趋势下，变得更加重要。
- 不会有，是产品的边界线，在交付更好价值功能的前提下，不会有是明确拒绝非核心需求。如为小部分玩家添加冷门功能等，避免资源分散。另一个角度来说，不会有，也存在是未来迭代预留的类型，如跨平台功能，等待产品后续的生态成熟再激活
个人理解，这个分类本质上是在做产品的基因测序，从而让团队在需求风暴中始终能紧盯为何而做的核心目标。而陷入功能膨胀，所有需求都重要，什么都需要是游戏开发中最危险的大坑了，用moscow方法是会要求团队进行三重的跃迁。
- 从加法思维转向减法逻辑。时间，人、技术底层，这三个资源恒定是铁律。必须有的清单就必须精简到很残酷，若删掉某功能后游戏仍可运行，则它不属于必须有。
- 服务核心用户的权重大于满足所有人。玩家群体需求必然分化，即便在追求做泛用户，走玩法融合的项目中，主次之分也是需求管理的超级挑战。我们时刻需要回答一个问题，游戏到底是谁的“必须有”。以清晰的定位来让需求有更明确的优先级。
- 以动态校准替代单次性决策。我们测试前预判的需求分类，可能在测试数中被颠覆认知，预判的应该有的功能，可能数据表现低迷；而预判中可以有的，反而可能大放异彩。需求的优先级是需随版本迭代来动态刷新，也需要紧随用户的实际表现来更迭。
需求管理的长期目标，是在训练团队的战略延迟满足能力，让团队能有价值溯源的思考逻辑，最终让团队会为长期价值放弃短期诱惑。当把需求列为必须有时，去回答它如果缺了就无法成立么。列为应该有的，去回答它能带来竞争力么。归为不会有时，也去回答它现在不做会影响产品生命线么。如今行业卷到发紫，剔除需求杂质，聚焦核心体验是赢得竞争的关键。需求管理也已不是堆功能，是在做产品生命力的加减法，是证明每个功能都在为产品核心价值做增量。