企业应用 MVP:从小处起步,在真实使用中成长
一家分销企业的老板脑中有一个清晰的应用构想:客户可以自行下单,销售可以实时查看库存,仓库自动接收发货指令,所有交易直接进入财务报表。每次和团队讨论时,功能清单都在不断变长。当他终于去询价时,预估的时间和费用让他犹豫是否还要开始。
这种情况非常普遍。企业应用的构想往往越来越大,因为公司里每个人看到的问题都不一样,都希望一次性全部解决。然而,一次性构建所有功能,恰恰是验证一个应用是否真正有用的最昂贵、风险最高的方式。有一种合理得多的做法:从能够带来真实价值的最小版本开始,再根据实际使用情况逐步完善。
这种方法被称为 MVP,即最小可行产品(minimum viable product)。这个术语来自创业圈,但其原则对于打算构建内部应用或面向客户应用的企业同样适用。本文将介绍 MVP 在企业语境下的含义、如何确定范围、常见的错误,以及如何从第一个版本走向完整的系统。
要点摘要
- MVP 是应用的最简版本,它已经能解决一个真实问题,并且可以每天使用
- MVP 不是随便做做的原型——它的技术质量必须足以在其上继续开发,而不是被丢弃
- MVP 的范围由最重要的一条工作流程决定,而不是由最长的功能清单决定
- 上线头几周来自真实用户的反馈,远比规划阶段的假设更有价值
- 分阶段的方式能降低成本风险,更快带来收益,也让团队更容易适应
MVP 对企业而言到底意味着什么
在创业圈,MVP 常被用来测试市场是否需要某个产品。而对于已经在运营的企业,目标略有不同。你通常已经知道问题是真实存在的——订单遗漏、库存不同步、报表延迟。你还不知道的是:解决方案最合适的形态是什么,哪些功能真正会被使用,以及团队将如何适应新的工作方式。
企业应用的 MVP,是能够完整处理一条核心工作流程、足够稳定可供日常使用,并且建立在可扩展技术基础上的第一个版本。关键词是可行:能够真正投入使用。一个只能演示、却无法在实际运营中使用的应用不是 MVP,而是原型。原型适合用来测试界面构想,但无法提供真实使用情况的数据。
为什么一次性构建全部功能风险很高
把完整的应用作为一个大项目一次性构建,在纸面上看起来很高效:一次规划、一次开发、一次上线。但在实践中,这种方式带有一些往往到项目后期才显现的风险。
- 漫长的开发过程中需求发生变化,应用完成时部分功能已经不再适用
- 关于用户工作方式的假设被证明是错的,而这要等到所有功能都建立在这些假设之上后才会暴露
- 由于大范围难以准确估算,成本和时间往往超支
- 上线时团队需要一次学习大量新东西,对系统的抵触情绪随之增加
- 收益要等整个项目完成后才能体现,而成本从一开始就在支出
MVP 把这个顺序颠倒过来。第一批收益在几周或几个月内就能体现,而不是等漫长的项目结束之后。之后的每个阶段都建立在已被证明有用的基础之上,因此开发出无人使用的功能的风险大大降低。
如何确定 MVP 的范围
MVP 最难的部分不是构建,而是决定哪些内容不放进去。每位利益相关者都有自己偏爱的功能,而且听起来都很重要。以下几个问题可以帮助你更客观地进行取舍。
当前哪个问题代价最高?
从消耗时间、金钱或机会最多的问题入手。如果手工记录的订单经常出错并导致重新发货,那么下单流程很可能就是 MVP 的候选。如果最大的问题是报表延迟,那么 MVP 也许是一个从现有数据源提取数据的简单仪表盘。
主要用户是谁?
好的 MVP 通常把一个主要用户群体服务得非常好,而不是对所有群体都敷衍了事。这个应用主要是给外勤销售、仓库管理员,还是客户使用?选定一个,深入了解他们的工作方式,设计出对他们来说最简单的流程。
从头到尾最精简的流程是什么?
把核心工作流程从开始到结束的步骤写下来。例如:销售创建订单,管理员审核,仓库备货,记录已发货状态。这条路径上的每一步都必须包含在 MVP 中,哪怕只是简单形式。不在这条路径上的功能——比如深入的分析报表、与其他系统的集成,或者复杂的权限设置——都可以留到后续阶段。
经验法则
如果某个功能在几个月内可以暂时用合理的手工流程替代,那它很可能不需要放进 MVP。把它记为后续阶段的候选,再观察这个需求是否真的出现。
MVP 不等于低质量
关于 MVP 最危险的误解之一,是把它当作草率开发的借口。MVP 削减的是功能的数量,而不是现有功能的质量。所构建的流程必须稳定、安全、好用,因为用户会根据第一印象来评判整个系统。一个在第一周就频繁出错的应用,无论下一个版本多好,都很难重新赢得信任。
技术基础同样需要从一开始就考虑清楚。数据库结构、应用架构、数据安全,以及应用今后如何扩展,都应该在设计时考虑到后续阶段,即使那些功能尚未开发。建立在脆弱基础上的 MVP 往往最终需要重建,反而抵消了原本想要节省的成本。
健康的 MVP 范围是什么样的
回到本文开头那家分销企业。在长长的愿望清单中,代价最高的问题其实是:外勤销售通过聊天发送订单,再由管理员重新录入——经常延迟,有时数量还会出错。因此,合理的 MVP 范围是一个给销售使用的下单应用:选择客户,从产品目录中挑选商品,查看大致库存,提交订单,管理员则收到一份整齐的待处理订单列表。
客户自助下单门户、与会计系统的自动集成以及销售佣金计算都没有放进去。它们依然重要,但可以等到基础下单流程被证明可行、团队也已适应之后再做。按这样的范围,第一个收益——更快、更准确的订单——可以更早体现,而沿途积累的订单数据也会成为下一阶段的宝贵基础。
构建 MVP 时的常见错误
- 01开发过程中范围不断扩大,直到 MVP 变成一个换了名字的大项目
- 02按照谁的声音最大来选择功能,而不是按照哪个问题代价最高
- 03没有从设计阶段就让真实用户参与,导致上线时流程让人感到陌生
- 04上线 MVP 时没有收集反馈的计划,下一阶段就缺乏依据
- 05把 MVP 当作最终产品,第一个版本运行后就停止开发
最后一个错误相当常见。MVP 上线、最紧迫的问题解决之后,公司的注意力就转向了别处。应用仍在使用,但周围堆满了临时办法——额外的电子表格、手工记录,或者为系统尚未处理的事情建立的聊天群。集中化系统的优势就这样慢慢被侵蚀。MVP 应该是开发路线图的起点,而不是终点。
从 MVP 到完整系统
MVP 使用几周之后,你将拥有规划阶段所没有的东西:证据。哪些功能使用最多,用户在哪些地方经常困惑,哪些手工流程仍在系统之外运行,哪些需求被提出得最多。这些信息应当成为决定下一阶段的基础。
把路线图拆分为多个小阶段,每个阶段都带来可感知的收益。第二阶段也许加入与会计系统的集成;第三阶段也许向客户开放访问;第四阶段也许为管理层增加仪表盘。顺序由业务价值和反馈决定,而不是由在任何人使用应用之前写下的初始清单决定。
- 从第一天起就确定收集反馈的方式:简短表单、定期答疑会或直接观察
- 监测使用数据,了解哪些功能真正被使用
- 把每一个仍在系统外运行的手工流程记录为开发候选
- 定期与用户代表和管理层一起复盘优先级
- 以短周期发布更新,让用户看到他们的意见得到了落实
为分阶段开发选择合适的合作伙伴
并非所有开发方都习惯采用 MVP 的方式。有些更习惯一开始就锁定范围的单阶段项目。选择合作伙伴时,留意他们是在帮你精简范围,还是在不断增加功能。好的合作伙伴会询问每个功能背后的业务问题,建议合理的开发顺序,并解释 MVP 的技术基础将如何支撑后续阶段。
同样要注意合同和付款的结构。分阶段的方式最适合同样分阶段的合作模式,每个阶段都有明确的范围、交付成果和费用。这样,你就可以在承诺下一阶段之前,先评估每个阶段的成果。
结语
成功的企业应用很少在第一天就以完美的形态诞生。大多数都是从一个能很好解决某个问题的简单版本成长起来,再根据人们的实际使用方式一点点扩展。如果你的应用构想看起来大得无从下手,问题也许不在构想本身,而在于第一步迈得太大。找到最重要的那一条流程,把它做好,让真实的使用情况告诉你下一步该往哪里走。
