为什么第一个版本要是MVP？为啥要梳理MVP？书里（《精益创业》）告诉你，你需要用一个最小可行性的模型去验证需求。用最小的代价去验证用户是否买账，就算是验证出来是伪需求，也方便及时调整方向或止损。
但是在我的实际经验中，MVP，实际通常是为了保证上线时间，被砍的光秃秃只被保留最核心功能的产物，为什么？
因为人手永远不够，老板要求上线的时间永远都紧迫。
开始设计一款新产品的时候，作为一个逻辑完整思路清晰目光长远牛逼哄哄的PM,可能通常会把整个产品设计的大而全，脑中有宏图心中有草原，但是如果一股脑都开发了是不太好的，因为功能越多，涉及到的交互细节越多，你花时间去设计这些大大小小的逻辑的时间越多，越有可能在一些不重要的细节、交互上浪费时间来回纠结。如果不确定这个产品的技术成本，那还有可能需要花时间和开发人员扯皮，权衡开发时间和收益。碰到好脾气的开发，可能自己悄悄花很多时间做了，碰到脾气不好的，可能就会指着鼻子骂你，做的产品没有意义。
那么如何避免这种情况呢？
一个字：砍
其实砍需求是不太容易的，这不是打脸吗？！那怎么办? emm，那就给自己一个台阶下吧：你需要列优先级，先列大的功能点，再列小的。优先级靠后的往后面的版本去排，具体到版本号，大概排期1-4个大版本，第一个小版本里可以放4-5个小版本。
这样列完MVP就差不多可以做到心中有数了。
举个栗子，我们来看下抖音的mvp。
第一个版本的抖音，做了3件事，看视频、简单的录视频和关注。没有现在的发现页卡，没有美颜、贴纸、也没有热门话题，精选视频的标记，也没有私信，简简单单，只有最最核心的录视频和看视频功能，这就是它的MVP。
因为功能足够少，产品在后续迭代就有无数种可能和方向，业务重点也可以灵活的调整。
你自己梳理完就结束了吗？并不是的，靠你自己，可能只能完成50~70%的样子。why？请接着往下看。
初步的mvp梳理完，接下去就交给交互设计了，完成后开评审会。
第一次评审会非常关键，它会让你对MVP有更清晰的认识。因为这个会上，一定会被开发质问和喷。这次会上需要尽可能讲的细，尤其是你感觉不太好做的功能（需要对开发有一定了解），会上沟通，确认好大概的开发时间，如果开发告诉你某个功能耗时非常长不想做的时候，你就需要注意了，先记录下来，然后思考这个功能能否再拆分的细一些，把一些功能往后面的版本放。会议结束后，及时整理笔记，拆分耗时长的功能，重新梳理优先级，把最重要的保留，其他的往后面的版本放。
做完这一步，MVP基本就90%成型了。
接下来就是开发阶段，开发阶段，依旧还是会和开发有沟通，协商和调优先级的情况（简称撕逼），和之前的套路一样，碰到开发耗时长的功能，重要功能的做拆分，选出高优先级的，不重要的功能，就往后放吧。
就这样，等开发全部提交测试的时候，MVP就定了（如果没有被硬插新需求）。
从上面的过程来看，MVP的梳理过程中，开发哥哥们帮了很大的忙， 有句话说的好，君子性非异也善假于物也。不要拍被喷，因为比起你的成长收获和产品推进来说不值得一提，只要最后的需求都是合理的，他们还是会按时去完成的，而且，他们不做也得做呀（滑稽˃ꌂ˂）
砍需求看上去是件不容易的事情，但是它的意义还是很大的，在这过程中，你会一遍遍反复的去思考一件事：
什么才是我这个产品最重要的功能，我们的思路和主线会一步步的清晰，也会更关注产品本身的核心功能和产品定位。
——推荐阅读——
扫一扫
491
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
