交付MVP而不偷工减料：第一周检查清单
「最小可行产品」这个说法已被滥用得伤痕累累。它常常沦为交付半成品的遮羞布，把缺口称作「第二阶段」。但它最初的含义更加犀利、也更有用：MVP是你能够构建的、用来弄清自己是否在解决真实问题的最小事物。「最小」关乎范围，「可行」则不容妥协。
用Scrum的话来说，这一点很重要，因为每个Sprint都应产出一个可用且有价值、符合团队「完成的定义」的增量。在《Scrum指南》中，「完成」并非可选项。一个为了赶上某个日期而牺牲质量、可访问性或安全性的MVP，并不是更小的产品——它是一项带着发布派对的负债。
把「最小」和「粗制」区分开
负责任的MVP，其纪律在于削减范围的同时让质量保持恒定。你交付的是更少的功能，而不是更脆弱的功能。2022年的环境奖励这种做法：在预算收紧、时间表不确定的情况下，那些靠小而扎实的发布快速学习的团队，胜过了那些为已然变化的市场精雕一场豪赌的团队。
最小意味着更少的功能、更窄的用户群、幕后的人工步骤——而不是省略测试。
可行意味着真实的用户能够完成一项真实的任务，并从头到尾获得真实的价值。
你的「完成的定义」依然适用——MVP增量与任何其他增量遵循同样的标准。
确定范围那一周的检查清单
陈述假设。 写下你要检验的那一条信念，以及能够证实或推翻它的信号。如果写不出来，你手上的是一张功能愿望清单，而不是MVP。
削减到一条核心流程。 找出真正交付价值的那一条路径，把所有仅仅支撑或扩展它的东西都推迟。
守住「完成的定义」。 质量、可访问性、安全性和数据处理仍在范围之内。它们不是可以拿来交换的功能。
为学习而规划，而不仅仅为发布。 提前决定你要衡量什么、由谁来看，这样发布才能真正让你学到东西。
把人工部分讲明白。 早期用人工介入来「假装」后端是可以的——只要在内部诚实地承认这是临时的，并记录下这笔债务。
在投入之前有个实用的直觉检验：如果真实客户只用这个版本，你愿意在上面署上自己的名字吗？如果诚实的答案是「不」，那你削减的是可行性，而非范围；你应当收窄所构建的内容，而不是降低构建的用心程度。
把MVP当作经验性循环的第一圈，正如Scrum的本意——构建一个小而「完成」的增量，把它摆在用户面前，检视所发生的一切，然后做出调整。其目的从来不是交付更少的用心，而是交付更少的臆测。
如果你的团队正在打磨一个MVP，并希望它真正做到最小、又不沦为未来的负债，XNM的项目集与项目交付咨询服务 可以帮助你确定其范围，使它既能让你快速学习，又依然站得住脚。