说说最小可行产品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模块优化(四期)按照迭代时间窗口打包的需求，而是根据时间窗口收集到的原始需求而进行的打包处理，无视需求内部联系，无视内部优先级差异，无视颗粒度大小。