mvp必备的三大模块

1.反馈渠道:请尽可能为你的MVP用户提供产品内部的反馈机制(如网站顶部的留言板入口、移动应用中的提交反馈页面)，而不仅是在产品体外设置独立的反馈渠道(如微博、微信、QO用户希望在遇到问题的那一刻尽快将自己的疑惑、惊诧与愤懑传递给开发团队。这些最终采取了行动的少数派用户，极有可能出于两种初衷:第一，他们的确遇到了棘手的麻烦;第二，他们真的是你产品的忠实粉丝，以苛求的狠光审视任何一个不完美的细节，热忱地为团队带来改善意见。无论遇到哪一种，都决不能令其失望，倘若反馈渠道的门槛过高，会令他们望而生畏，提反馈的冲动也随之烟消云散。

2.官方公告:包括群体公告和针对单个用户的定向消息通道。公告看板的目的是向用户传递来自产品官方的声音，包括团队动态、运营公示、反馈回复，以及应对突发情况的紧急通知和危机公关等。对于网站而言，公告看板的具体实现形式可以是首页的一条醒目的横幅、个人中心的系统消息或是群发的邮件，而客户端及移动应用内的公告则可能更加醒目，如能够轻易占据用户注意力的推送通知(PushNotification)并非每个用户都有看公告的习惯，然而对于试图主动了解官方信息的用户而言，找到入口的方式必须简单易行。

3.自动升级:网站的优势是随时部署，用户打开浏览器看到的永远是最新的内容相比之下，客户端和移动应用的用户是经过漫长的链条转化而来的。如果用户每次获取新版本都要再一次经历手动搜索、下载和安装的过程，许多偷懒的用户宁愿选择继续维持在老版本，而最终看不到我们呕心沥血迭代出的升级版。这与我们快速迭代的开发策略背道而驰。最佳策略是在产品启动时提示用户有可用的新版本，当用户确认升级后，通过内置的下载模块在后台完成更新，整个过程无需用户介入，而是“傻瓜式”地完成。笔者曾参与开发“云诺网盘”的OS客户端任务。当时我们的团队过于专注于产品核心功能的实现，而忽略了加入用户反馈的收集模块、推送通知提醒和自动升级提示。这一疏漏对日后新版本的推广造成了麻烦:当jOS客户端配合网站改版完成一次重大迭代后，我们几乎无法告知这批iOS用户前去升级，只能眼巴巴地盼着他们上门来发现更新的消息。无奈之下，我们尝试向所有填写了联系邮箱的用户发送邮件，但到达率有限，后台数据显示的升级率依然非常低。这个前期隐患导致的后续影响是，在相当长的一段时间内，我们不得不维持旧版的应用接口，向下兼容用户的数据格式，并耗费大量额外经历保证新老用户体验的一致性

之后在参与动漫阅读应用“高能贩”的开发中，我们吸取了教训，在最小化可用产品阶段就植入了这三大模块:在“关于”页面加入了“意见反馈”的入口;在代码里接入了友盟的推送通知和自动升级组件。于是在产品以周为单位快速迭代的早期阶段，新版本分发到大部分活跃用户手中通常只需要两到三天。这有助于让我们极早判断新版本是否稳定可靠，以及不同版本改动对用户行为数据的影响

除了上述提到的模块之外，针对不同用户设置不同的后台功能开关，进行新功能的灰度发布，也是避免失败的一种方式。腾讯微信有一套动态运营的完整方法论，设计有大量的后台开关，每次完成新功能时，总是先让一小部分用户先使用，待效果好再放大受众范围，效果不好则折叠甚至删除。运行下来发现，大约有70%的想法最终未能通过市场的检验，真正让所有用户看到的功能可能不到30%。同样地，后台开关设计还能运用于提交市场审核时避免不必要的意外挫折，如暂时屏蔽掉可能带来审核麻烦的敏感版块。