说说最小可行产品MVP和最小可上市功能MMF

MVP/MMF原理

这里的MVP并不是最有价值人员,而是Minimum Viable Product,对于已经上线的产品而言,可以把MVP等同理解为Minumum Marketable Feature(MMF),下文就是居于已经上线的产品分析,可以按MMF来理解MVP。

MVP参见https://en.wikipedia.org/wiki/Minimum_viable_product

MMF参见https://www.agilealliance.org/glossary/mmf/

根据原子业务需要来识别需求,单个需求上线就能发挥业务效果,也能够对上线效果进行回顾。最极端的例子是界面文案修改。

识别MVP不复杂,参见如下问题来帮助识别

该需求对应的业务部门是不是涉及超过1个,相应功能并没有关系

该需求如果上线,就能让业务部门(包括运营,除了IT研发的其它部门)使用起来,不再需要等待其它功能齐备了才能用

该需求是否能够独立的对应到需求价值(也即是业务价值),最好能关联到相关KPI,也即是可以判断对KPI有定性的正面影响

MVP/MMF好处

颗粒度小,便于快速识别,也便于独立的判断优先级

有利于快速书写PRD,有利用快速澄清理解PRD,甚至不再需要开会来澄清

有利于开发安排,就像在木桶里面装石头一样,装大石头会留下许多缝隙,装小石头能够减小缝隙,处理更多容量

MVP/MMF坏处

针对同一个系统的小修改每个都有独立的业务意义,区分MVP识别后,需求数量显得很多,要分别澄清,反而浪费时间

解决方案:合并针对同一个系统同时上线的琐碎MVP,这里与前面指导有冲突,需要平衡

MVP/MMF的反面例子

按时间作为需求打包依据

好处

明确上线时间

坏处

首批功能需求要等待后面的需求一起,不能尽早交流,高优先功能需求混杂在里面,不能尽快处理

需求打包包括10+个MVP,实际上线时,往往只能完成部分,导致需求前面澄清,又不断分拆延后,后面要再澄清,里面存在工作量的浪费

例子

XXXXXX模块优化(四期)按照迭代时间窗口打包的需求,而是根据时间窗口收集到的原始需求而进行的打包处理,无视需求内部联系,无视内部优先级差异,无视颗粒度大小。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180908G08PXQ00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券