“最小可用产品(MVP,Minimum Viable Product)”来自于Eric Ries所写的著名书籍《精益创业》,MVP是精益产品开发的核心思想之一。MVP可以理解为是用最快的方式建立一个最小的可用产品,这个产品表达出最终产品想达到的主要效果,然后快速接触用户通过用户反馈不断迭代完善产品。
MVP方法论有如下几个要点:
第一,MVP的产品观是开发团队不可能掌握所有的用户需求,无论开发团队在需求阶段多么努力,开发团队都不可能掌握全部信息。对于重大软件产品,这一点总是正确的,因为在绝大部分情况下,用户自己都不可能完全说清楚自己的所有需求,要理解这一点很容易,iPhone给了你非常好的用户体验,但没有见过iPhone之前,你能否清楚地说明白你希望要一部什么样的手机?
第二,MVP的一个要点是“最小”,为什么要“最小”,因为要“最快”。MVP是一个不断重复迭代的过程,要做到重复迭代,迭代速度需要快,这和敏捷的道理是一样的。
第三,MVP的另一个要点是“可用”,MVP不是原型、不是demo,MVP是满足用户主要预期的可交付产品,是要让用户能够用起来的产品。如果用户的最终需求是一辆满意的汽车,那么MVP不能是一堆汽车零件,MVP应该是一辆能动的车,MVP最低要求也是一辆能开的助动车,MVP要让用户能够用起来。
第四,MVP是局部和阶段的,但项目负责人必须始终关注全局与最终,要能思考“最小”和“可用”,必须具备全局视野和对最终产品的思考。MVP者都是全局思维者,MVP者已经从全局层面考虑到了用户需求的不确定性,才能考虑到通过MVP的手段,快速接触用户,提前把用户牵引入产品开发过程。
对于软件研发,MVP方法论是具有普适性的,MVP思维是产品经理和项目经理必须具备的思维,凡是不具备MVP思维的产品经理和项目经理,负责重大软件项目必然失败。为什么这么说?
传统产品和简单软件的项目管理,一般总是能分解为“正确”和“效率”两个问题,前者解决“做正确的事”的问题,后者解决“正确地做事”的问题。比如传统软件开发,需求阶段试图把“做正确的事”的问题解决掉,开发阶段则专注于解决“正确地做事”的问题。
但是,重大软件项目的项目管理不一样,重大软件项目的产出不是代码,产出的是整合的知识。复杂软件产品要整合哪些知识?用户所在体系对于所要解决问题的知识、用户对于用户体验偏好的知识、设计者对于系统可用性可靠性可扩展性的知识、开发工程师对于软件工程各个专业环节的知识、开发方关于开发资源约束的知识,等等等等。
这种知识产品的性质使得重大软件项目的生产过程具有两个特点:
第一,知识产品的“正确”和“效率”不可分割。知识产品,只有通过知识消费场景的检验,被用户接受,生产才有价值;没有经过知识消费场景的检验,不被用户接受,生产过程没有价值。因此,知识产品的生产,正确——即产品“是被用户接受的”,始终是最重要的目标,为了保证知识产品生产的正确,最好的办法就是让每个阶段产品都快速接触用户、通过用户检验。
第二,知识交流,必须具有合适的载体;没有合适的载体,知识交流效率极低。产品经理和客户在会议室开一天会,客户也不一定能说明白“什么手机是好手机”这个问题,但是产品经理把几款手机放在客户面前,客户只需很短的时间就能回答哪部手机比较好并说明原因;同样,在开发团队内部,产品经理统一开发目标、项目经理掌握开发情况,都需要信息沟通载体,没有合适的信息载体,再开会、再出差、再加班也没用,开发团队还是无法达成一致的知识理解。这是因为,重大软件项目管理本质上是一种知识管理活动,重大软件项目的失控本质上都是知识管理的失控。
从上述软件产品生产的特点,就可以看到为什么MVP方法论是普适的,因为最好的阶段性产品开发目标就是MVP、最好的产品知识交流载体就是MVP。以知识管理作为重大软件项目管理的核心,是MVP方法论的实质,也是敏捷的实质,MVP就是产品级的敏捷,敏捷就是在开发全程规范性贯彻MVP。
这里值得一提的是,从乔布斯的iPhone开始,产品领域兴起了一种“超预期”方法论,这种方法论指出了一个重要的产品法则——符合用户预期的产品只是平庸产品、超用户预期的产品才是成功产品。一些产品经理把这种方法理解为“闭门开发、放大招”,这种理解完全是误解:第一,乔布斯是最懂得MVP的,苹果第一款iPhone确实在放大招,但大家都忽视了iPhone的MVP就是iPod与iTunes,乔布斯通过产品节奏把MVP上升到了产品战略的级别;第二,要让广大用户超预期,就更要做好局部的MVP,比如通过A/B测试落实全程MVP、通过度量和监控落实自动化MVP,不做MVP准备而“放大招”是重大项目管理的大忌。
MVP是一种普适的知识管理思维,重大项目的产品经理和项目经理必须具备这种快速“开发-度量-改进”迭代的思维。最后,列出重大项目的产品经理和项目经理需要关注的MVP检查列表:
- 以MVP交付作为项目早期里程碑;
- 以MVP统一开发团队的产品理解与开发目标;
- 以MVP的交付情况、系统监控和用户反馈来考核开发团队;
- 以MVP用户反馈和系统监控决定下一步产品定义与开发计划;
- 以MVP方法论持续迭代产品。
本文经授权发布,不代表增长黑客立场,如若转载,请注明出处:https://www.growthhk.cn/cgo/product/64211.html