MVP 的开发周期都在哪儿变长

问周期之前要先定的一件事

来问 MVP 开发，最先关心周期很正常。可同一份功能清单发给几家，回来的预估周期各不相同。功能的条数定不了周期。MVP 不是正式产品缩小一号的版本，而是用来验证一个假设的工具。“有没有人愿意为这件事付钱”所需要的最小产品，和“正式对外也拿得出手的第一版”，工作量差得很远。

要定的只有一件事：这一版想确认什么。确认的对象清楚了，做的一方才能把范围收窄，告诉你就这个目的而言，有这几个页面和这几个功能就够。假设是空的，功能清单只会越列越长，周期跟着清单走。

先挑出第一版不做的东西

清单再看一遍，现在不用做的条目其实不少。管理后台最典型。初期的订单也好、报名也好，用在线表格接住、人工处理，服务照样转。三种第三方登录不如先留一个邮箱注册；多语言、消息推送、对账自动化，在用户涨上来之前都可以由人顶着。

砍功能不等于做得糙。用户直接碰到的页面和流程一旦松垮，假设根本验不出来。要减的是运营侧的便利功能和为万一准备的功能。人手能处理的事先别急着自动化，省下的时间放到用户看得见的那一面。

开工之后，回复的速度就是进度

活儿转起来之后，把进度往后推的通常不是代码。设计稿发出去等确认的那几天，文案定不下来的那几天，攒到一起就是按周计的延误。做的一方拿不到决定就进不了下一个页面，这段等待原封不动加在开发周期上。

把确认的节奏定下来，把拍板的人收到一个，这种延误会明显减少。每周固定一天看这一周做出来的东西，当场拍板，反馈就不会堆积。拍板的人一多，光是把互相矛盾的意见对齐就要额外花时间。这个阶段，快的决定比完美的决定更影响周期。

商店审核和支付签约走的是别人的日历

开发做完了，服务却开不了张，这种事常有。App 要过应用商店审核，被拒了改完重新排队；国内安卓渠道还要一家家分别提交，软件著作权登记证书通常是前置条件。要收款，微信支付和支付宝的商户号申请、审核是另一条线，主体资质材料也得备齐。

这些日程做的一方拉不动。把它们算进开发周期里，上线那天就会对不上。

所以这类流程放在开发第一周一起挂起来。商户号申请、开发者账号注册、资料准备，和页面开发并排推进。外部服务对接同理，要接什么已经定了，报价阶段就把名字一起写上。文档单薄或者自带一轮审批的服务，本身就是一个日程变量。

上线日期已经定死了也可以先说

日子已经定在那儿了，直接把日子告诉我们也行。想验证的假设还没缩成一句话，也不影响开聊。Weple 的 MVP 开发是这个顺序：先把这一版要确认的事对齐，再把周期固定下来，最后排这个周期里装得下的范围。功能清单已经有了，我们陪你一起挑出第一版可以不做的条目。计价的依据写在价格说明，商店审核、支付签约这些跑在外面的日程，也一起画进第一版排期表。