规划最小可发布版本（MMR）
在很多企业里，公司流程规定每个产品需要制定3~5年的长期战略规划，以及长达1年的产品路线图。对于创新产品而言，如果一个版本都还没有发布，就说明团队没有验证产品是否真正有客户，这时候做的任何长期规划都是臆想。虽然在制作商业模式的阶段已经用MVP验证过想法，但是客户还没有见到真正的产品。当用MVP验证出客户“愿意买单”的时候，并不代表客户见了产品后真的会买单。因此，团队需要从第一份产品Backlog里精心筛选出最有价值的特性并做出一个成本最小的产品版本发布到市场上，而不是畅想未来。
最小可发布版本（MinimumMarketableRelease，简称MMR）是将为客户提供的最小、最有价值的特性集合构成一个产品发布出来，目标是抢占市场窗口，及早获取用户真实的反馈，用真实的产品验证商业模式。最小可发布版本，即第一个版本的市场反馈可以为产品的迭代演进提供参考信息，从而使团队减少不必要的需求开发，减少浪费。MMR与MVP有所区别，MVP是验证假设的试验，MMR是真的可以被用户购买的产品。
团队需要铭记的是：永远都不要期望在第一个版本里做出尽可能多的需求特性，而是要以最少的特性先发布MMR，这个版本要体现产品的独特的价值主张。那么如何决定哪些特性应在第一版MMR里出现呢？
第一，依据核心价值主张和卡诺模型，那些不属于核心价值主张的特性一定不要出现在MMR里；那些不属于产品必备属性的特性，也不应被纳入第一版MMR。
第二，团队对产品的每个特性只需要问一个问题：如果没有它会怎么样？如果没有它并不影响用户的使用需求，那它就不该出现。
腾讯于2011年1月发布了基于安卓平台的微信1.0测试版，当时微信的核心价值主张是“极速轻快的楼层式对话，带给您飞一般的聊天体验”。那时微信的功能仅仅是即时收发消息与拍照分享，而其他功能都是在后续的版本中不断地增量式添加的。
对于产品的每个特性，其最小的、必不可少的、有价值的部分都要被拆分出来。拆分出最小特性的要诀是：将每个特性拆分出子特性，一直拆到不能再拆为止（如果再继续拆，就无法为用户提供独立的价值），然后采用MoSCoW[方法来识别每个子特性的优先级。
[*]MustHave：必须有的特性。如果没有这个特性即无法实现版本发布的目标。比如，对刚才介绍的微信案例来说，由于第一个版本需要向用户体现产品的核心价值主张，因此收发消息是MustHave特性，否则用户就无法使用产品的核心功能。
[*]ShouldHave：不是关键的基本特性，但是对用户仍有较高的价值。在产品具备MustHave特性的前提下，团队可以提供增强功能。
[*]CouldHave：在MustHave和ShouldHave特性都具备的前提下，团队可以考虑那些添枝加叶的功能，当然，要在其成本和代价不大的情况下才考虑做。在有风险的情况下，团队应首先考虑删掉CouldHave特性。
[*]Won’tHave：在这个版本里不会发布的特性。
对于第一版MMR来说，团队一般只交付MustHave的特性，即完成核心价值主张的最基本的功能，如图8-11所示。
图8-11规划MMR
在创建了我的看板工具产品的第一份Backlog后，我和团队讨论后确定的第一版MMR只包括下面几个必备属性。
[*]项目成员和权限管理。
[*]项目维护：创建、删除、更改、查询、归档。
[*]看板的基本功能：列、工作项。
[*]浏览器的支持：IE8及以上版本。
其他属性一概没有被纳入第一版MMR。而即使有些特性属于必备属性，我们也将每个需求进行了拆分、细化，因为其可能隐含一些不是团队必须要做的子特性，如表8-2所示。
表8-2MMR示例
比如拿“项目维护”来说，实际包含了5个功能，我们对每个功能用MoSCoW方法识别了其优先级。对于第一版MMR来说，“创建项目”“删除项目”“更改项目”属于MustHave，因为没有这些特性用户便无法使用该产品；而“归档项目”和“查询项目”属于ShouldHave，因为即使不做这些特性也不影响用户的基本使用流程。因此，在制作第一版MMR过程中，我们没有将“归档项目”和“查询项目”纳入其中。
再比如“删除项目”这个特性，每个子特性的优先级不尽相同，其中只有“删除单个项目”是必备属性，其他都不是，因此我们只做了删除单个项目。
团队在发布第一版MMR后，要积极获取用户的反馈，并将采纳的反馈纳入产品的Backlog中。团队对产品需求的认知是随着时间以及市场和用户的反馈而变化的，因此，团队在第一个版本中没有做的ShouldHave特性，在后续版本中可能会将其升级为MustHave，或者降级为CouldHave，甚至放弃不做。因此，团队在第一个版本后的每个版本制作过程中，也需要用MMR的思想来重新审视每个特性的优先级，将每个特性拆分到最小单位，并从当前的Backlog里取优先级最高的那些特性。
页:
[1]