第4章用户故事地图

4、用户故事地图：史诗故事拆分、用户旅程绘制、MVP范围界定

好，咱们进入第四讲。这一讲，我要跟你聊聊用户故事地图。

说实话，我见过太多团队一上来就埋头写用户故事，写了几百条，结果发现根本不知道从哪开始开发。为什么会这样？因为缺少一张「地图」。

用户故事地图，说白了就是一张可视化的需求全景图。它能帮你把大需求拆成小块，看清用户完整的旅程，然后精准地圈出MVP的范围。我个人习惯在项目启动的第一周就拉团队做这件事，效果特别好。

先说说史诗故事（Epic）。

什么是史诗故事？就是那些太大、太模糊、没法直接开发的需求。比如「用户能下单购物」——这听起来像一句话，但背后涉及商品浏览、购物车、地址填写、支付、订单确认……一堆事。

我在项目中遇到过团队把「用户管理」写成一个史诗故事，结果开发了两个月还没做完。嗯，这里要注意：史诗故事必须拆分。

史诗故事拆分的黄金法则：

举个例子，把「用户能下单购物」拆成：

你看，这样拆完，每个故事都清晰了。我曾经犯过一个错，把「用户能搜索商品」当成一个普通故事，结果发现它涉及搜索框、搜索结果页、筛选、排序……最后不得不重新拆分。所以，别怕拆得细，拆得越细，后面越省心。

故事拆完了，接下来要画用户旅程。

用户旅程，就是用户从开始到结束，经历的所有步骤。你想想看，用户不是上来就点「购买」的，他得先知道你的产品，然后注册、登录、浏览、比较、下单……每一步都是旅程的一部分。

我的习惯做法：

拿一沓便利贴，或者用Miro这样的在线白板。把用户从「发现产品」到「完成目标」的每一步都写下来，贴在墙上。别管顺序对不对，先贴出来再说。

举个例子，一个在线教育SaaS的用户旅程可能是：

画完旅程后，你会发现很多之前没注意到的细节。比如，用户可能在「试听课程」这一步就流失了，那你的MVP是不是应该优先优化试听体验？

我记得有一次帮一个电商SaaS团队画旅程，画到「用户退货」这一步时，大家才发现退货流程里有个「填写退货原因」的步骤，用户经常填错。后来我们把这个步骤简化成了选择题，退货率直接降了30%。你看，旅程图就是这么有用。

好，现在你有了一张完整的用户旅程图，上面贴满了故事。接下来就是最考验功力的一步：圈出MVP的范围。

MVP不是把功能做少，而是把核心价值做透。说白了，你要回答一个问题：用户用你的产品，最想解决的那个问题是什么？

我曾经踩过的坑：

有一次做MVP，我觉得「用户头像上传」功能很重要，花了两天时间做。结果上线后发现，用户根本不在乎头像，他们只关心能不能快速下单。从那以后，我每次圈MVP范围时都会问自己：这个功能砍掉，用户还能用吗？

界定MVP范围，我推荐用「MoSCoW法则」：

实际操作时，我会把用户旅程图上的每个故事都贴上标签：M、S、C、W。然后只保留所有M，再加上少量S。C和W直接砍掉，别心疼。

MVP范围界定的三个原则：

举个例子，一个在线课程平台的MVP，我圈定的范围是：

你看，这样圈完，MVP只有5个故事。团队两周就能做完，然后快速上线验证。如果用户反馈好，再迭代加功能。如果反馈不好，调整方向也来得及。

嗯，这里要特别提醒：MVP不是终点，是起点。你圈定的范围只是第一版，后面要根据用户反馈不断调整。我见过太多团队把MVP做成了「全功能精简版」，结果开发周期拉长到三个月，错过了市场窗口。

最后总结一下：

下一讲，我们会聊聊如何把这些故事变成可执行的开发任务。到时候见。