MVP与用户故事地图运用

这一式，看名字就没啥悬念，肯定是讲MVP（Most Valuable Player）了。

我是个篮球迷，篮球也是我最喜欢的运动，职业生涯投篮命中率从未低于千分之30。跑位风骚，经常能找到空位出手的位置，然后投出另对手胆寒的三不沾。视野开阔，传球诡异，时常为对手传出手术刀似的精准传球。我最厉害的一招，是持球突破，利用自己的爆发力，能把对手和己方队友一起突个干净，然后飞身上篮，为篮筐舒舒服服的送上一个盖帽。乔丹，邓肯和库里，是我最喜欢的3个球员，他们也都是MVP，有机会在自己的文章里给他们打个call，也是极好的。

好了，瞎扯淡到此结束。这一式要讲的其实是Minimum Viable Product （MVP，最小可行产品），即如何通过用户故事地图的实践去定义最小可行产品。

延续上几式用的那个例子，我们通过凤翼天翔，得到了一张影响地图，影响地图的WHAT，就是这一式的输入。在上面的例子中，我们把WHAT分成了2个层级，那么在这里，我们第一步就是把第一层做为需求骨干，横向展开：

（由于绘图空间受限，我无法在一个图里把影响地图全部描绘出来，其实最好能有足够的空间把整个地图在同一个空间里展开，并且通过标签，连线的手段标注那些相互有关系的需求单元）

完成了需求骨干之后，我们接下来要做的是第二步，把每个骨干下的需求竖向排列：

第三步，逐列的去排列优先级，需求的分解和优先级的排列方法在这里不做介绍，同学们可以参考这两个文章去深入的学习如何去分解需求和排列优先级：

《8-useful-strategies-for-splitting-large-user-stories》(外部链接贴不进来，自己搜索吧）

《产品经理：需求排序大法》

第四步，就是找出MVP了，一句话概括寻找MVP的过程就是做减法，一直到再减就不能用了。找MVP的过程，其实就是制定产品规划的过程，产品经理和团队共同探索，最终由产品经理决定MVP包括哪些需求。

MVP不仅仅是指最小的功能集，也隐含了最小的用户群体，最小的数据需求的含义。一个发布到市场上的产品，并不需要一开始就满足所有的用户和提供所有的内容。在上一式 凤翼天翔里就已经提到过这一点，在上述的例子中，我们可以考虑一开始只对内部员工开放这些售后配件购买的功能，也仅仅提供超过5年才需要更换的零件的在线预定和优惠的功能。

在划分MVP的过程中，也可能会涉及到需求优先级的调整，比如说第三方登录功能，从单纯的业务价值来说，或许价值很高，但是如果说这个时候第三方平台的登录接口因为各种各样的原因无法及时就绪，那很自然我们可以考虑降低这个需求的优先级。

使用同样的方法，我们也可以制作出经销商和总部相关用户故事地图：

上面这个图就体现了“最小的数据需求”的思想，我们不需要一开始提供所有的数据和内容，所以我们把所有的零配件明细数据导入的需求分成3部分，第一批只要导入MVP需要的数据就可以了。

看过上一式的同学应该还记得，在制作影响地图的时候，我们需要识别运营需求和数据需求，在上一式识别出运营需求和数据需求对这一式排列优先级会很有帮助。也可以看出来，对于2C的的产品而言，很多时候数据的需求会比运营的需求更重要。

到了这一步，我们就得到了一个最初始的产品规划，接下来，就需要把这些需求，或者叫用户故事，导入到Product Backlog里，摩拳擦掌的准备开始启动项目，进行开发了。当然，这里在MVP里的需求，需要符合INVEST原则，INVEST原则这里就不介绍了，不知道的同学可以从网上的资料自行去了解一下。总结一下第三式的内容：

第一步：横向展开需求骨干

第二步：竖向列出所有想到的需求/用户故事，需要满足INVEST要求

第三步：调整每一列需求的优先级

第四步：找到MVP，注意MVP也隐含了最小用户群体和最小的数据/内容的含义

坦率的说，这一式我觉得内容上并没什么新意，用户故事地图的方法很多组织和团队都已经在使用，并且已经运用的非常熟练了，比我这里介绍的内容更丰富更生动的干货在网上多了去了。

上一式的影响地图和这一式讲的用户故事地图这两个方法都不难，易于理解，易于上手。我对这两个地图最深的感触是：需要坚持。简单并不等于容易（simple <> easy），要使用这两个方法，需要团队投入时间，空间持续的去沟通，探索和描绘。我的经历告诉我，一开始业务团队和IT部门都会有很大的热情去做这两个地图，当经历了几次沟通，探索，得到了初步的地图之后，新鲜感会逐渐的褪去，团队会出现嫌麻烦，想当然的情绪，然后一点点的脱离这两个方法。想办法坚持下去，这两个方法的收益是持续性的。

我们再看一下MVP的概念和理解，比较活跃的几个敏捷微信群里，好几次都出现对于MVP概念上的解读，沟通，争论。各种各样的理解层出不穷，有自己理解的，有引用别人文章的，也有自己再引申概念的。但是，没有一个是基于具体的实践的。

我们实际操作下来的感受是，不要让那么多概念和理解来干扰我们的行动，更不要让它们变成阻止我们行动的理由。让事情变得简单一点，就按照字面上的意思去操作就好。MVP不就是最小可行产品么？根据产品的特性和所处环境，找到最小的，能真正运行的产品不就行了么？

这里可以给出两个我们具体的例子，第一个例子就是我们这个APP，如果同学们从起手式读到这里，应该可以看得出来，这个APP的MVP是非常小的，仅仅是针对很小部分的用户（内部用户），推出很小一部分的零配件（5年以上需更换的零配件），拿掉几乎所有的运营功能，这就构成我们的MVP了。这个MVP可能只占所有规划功能集的5%左右。

第二个例子是我们之前对于一个老的工作流系统的改造，我们也尝试使用用户故事地图的方法，同学们可以想象，对于一个老系统的改造，我们或许可以控制一下MVP的用户群体，但是不可能去缩小功能需求和数据需求，否则对用户来说就是功能的倒退，是不能接受的。所以这个项目的MVP就占据了整体功能的70%以上，虽然MVP的体量和占比都大了，但是对于这个项目本身而言，它还是一个MVP，因为我们已经是把第一次发布的功能集精简到再减就不能用的地步了。

根据这两个例子，看起来都不需要去的纠结MVP到底是用于验证，还是用于发布，到底是面向最终客户，还是面向内部用户。群里面也看到过这样一个例子，提问者来于一家做金融IT产品的公司，他的问题是：如果他们的竞争对手产品的功能是10个，那他们就不能用MVP的思路去只提供3个或者5个功能的产品去发布。

这里可能他对于MVP的理解就存在误区了，MVP应该是由产品本身的特性和它所处的环境决定，Minimun 和 Viable是两个并存的关键字，显然在这个例子里，3个或者5个功能在这个产品所处的环境里，就不满足viable的要求，所以它就不是个MVP。

到这里，《葵花宝典》的起手式和前三式都讲完了，前三式都是关于一个软件项目的价值识别和需求分析。很多公司对于启动一个软件项目有非常严格和正规的流程来控制，在我们这里，这个过程叫做潜项。一个敏捷项目当然也需要潜项，而且在我看来，前三式都需要在潜项中完成，而不应该把这些工作放到项目里面去做。换言之，完成了用户故事地图，MVP和后续的产品规划之后，才能正式的去启动这个项目，因为只有得到了这些信息之后，我们才知道我们为什么要做这个项目（价值目标），这个项目需要完成哪些功能需求（影响地图），我们又是如何规划这些功能的发布顺序的（用户故事地图）。

需要注意的是，在潜项中要完成这三式，并不代表在项目中就不需要再做这些工作，上面已经讲过，影响地图和用户故事地图应该是持续性的实践。第一，影响地图和用户故事地图都不是一次成型的，随着项目的推进，会有越来越多的信息被接受，各种细节也会越来越丰满，这个时候我们需要继续在这两个地图上去细化。第二，在项目过程中，也会出现各种各样的变数。我们也需要回到这两个地图上，把这些变数和项目的价值目标连接起来，再根据变数来调整产品的发布规划。

接下来，我们就可以开始开发了么？且慢，先看看 第四式 别忙打，先磨下剑。

本文由@合气大蒜 原创发布于管理圈，未经许可禁止转载。