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模块优化(四期)按照迭代时间窗口打包的需求,而是根据时间窗口收集到的原始需求而进行的打包处理,无视需求内部联系,无视内部优先级差异,无视颗粒度大小。
领取专属 10元无门槛券
私享最新 技术干货