小步快跑、敢于试错、快速迭代
在我们开发一款产品的过程中，关于产品的开发周期上，有一个被广泛认可的原则叫小步快跑，有一本书叫《精益创业》，说的就是这方面的内容，这一点也非常符合当下的互联网创业文化，在过去我们绝大多数人的想法是，当我们有一个好的想法的时候，在屋里弄一帮人，闭关三年，然后产品就横空出世，但是这种情况下，当你做出来的时候，就算你的产品符合当年的需求，但是计划往往赶不上变化，市场还有用户的需求早就已经不一样了，再说了，万一当初没有赌对呢，因此在现在的互联网上，讲究的就是用最低的成本、最小的规模、最快的速度去尝试一个粗糙的东西，然后快速的拿到市场上去尝试，如果好，就趁热打铁，继续做下去，并把它做大做强。如果不好，就赶快转换方向。
现实中我们遇到的很多的创新，一些很不起眼的小功能，都是在不断的改进中做起来的，因此，当你产生一个想法时，速度是最重要的，不是要把产品做的多么完美，而是要尽快把他做出来，不管在刚出来的有多么粗糙，只要具备基本的核心功能，就尽快把他做出来，让用户去用，去骂，让后要做的就是经常看看用户的使用反馈，亲自在论坛上回复用户的帖子，与用户通过QQ等软件去交流，在微博上紧盯用户的反馈，这也是每一款产品必然要经历的过程。
如果我们做了一个新的功能，是不是会受到用户的欢迎，这一点我们在前期往往不得而知。很多人的心态往往是这样，反正领导说了，这个产品要能支持一亿的用户，为了支持一亿的用户我们要先采购5000台的服务器，然后又招了很多人，做了很多的工作，花了一年多的时间搭建起了一个能够支持一亿用户的平台，但是到了最后却发现用户并不买账。
因此当我们实际做一款产品时，即使未来会有一亿的用户使用，开始的时候还是先让100个用户来试试，看看他们的反应，如果反馈很好，就再拿1000个用户来试，然后再多买两台服务器，用10000个用户测试。这个时候，如果反馈依然很好，那就可以考虑批量采购服务器了，所以按照这个小步快跑的原则，很多企业的研发方法，产品的发布方法以及迭代更新的速度都应该相应的做出改变。
关于产品，我这里提了两个数字概念，第一，产品刚出来的时候最不重要，哪怕第一天只有1000个用户，第二天就有2000个，往后可能会更多。然后照着这个趋势做一条曲线出来，因此在这个过程中不要在乎绝对的用户数量，而是要关注相对的增长趋势。第二个数字，指的是产品有很多的环节，如果满分是1分，但是每个环节我们都只做了0，8分，最后的产品的分绝对不是想当然的0.8分，而是0.8乘以0.8后的0.64分。因此功能越多，数字就越小，产品失败的就越快。因此，功能贵在于精，而不在于多。要在每一个点上都做到极致。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点“小步快跑、快速迭代” 可用于工作的好方法 - 简书
“小步快跑、快速迭代” 可用于工作的好方法
互联网行业推出产品有个基本的做法“小步快跑，快速迭代”，就是不要想着一次性发出好的产品，而要通过快速迭代的方式进行更新，保证每一小步都跑得很快。
有三种现象阻碍创新：面面俱到谋布局；尽善尽美求完美；吝惜资源不主动。这三种现象，由人们的一种狭隘意识所致。若从宇宙观出发就不这样看了。宇宙的平衡是随时建立的。一个点出现，一个平衡跟上。这个点不断突破，就不断有新的平衡。每个时点上漂流着一定的磁场，一定的磁场聚合在一定的点周边。
快速迭代首先是一种产品研发理念。
在快速迭代理念支持下的产品研发是“上线-反馈-修改-上线”这样反复更新内容的过程，形式非常适合互联网产品或者移动端，通过收集数据或用户反馈迅速知道改进的结果，用快速迭代的方式可以立即在用户之间找到平衡点。
“小步快跑，快速迭代”。为了实现单点突破就要允许不完美，但要快速迭代向完美逼近。每天都能发现修正一两个小问题，不到一年产品就打磨出来了。
这种方式可以借用到我们的写作之中，以及任何需要写文稿的地方。
当我们需要写一篇文稿的时候，首先是确定这篇文稿要表达的是什么，再去收集素材，然后把这些素材组合起来写成一篇文稿。
如果我们一定要等到所有的素材都收集齐了再写，那不知道要收集到什么时候了，因为如果不是提前已经收集了素材，临时收集还不知道从什么地方去收集，怎么可能收集得齐呢？而且在素材的汪洋大海里又怎么知道哪些是最合适的呢。
因此，我们接到写文稿的任务后，如果头脑中有现成的素材就可以构思好后直接开写，这是一个初稿，初稿完成后就放在一边。这时我们就会知道文稿有哪些地方不足，还需要什么东西来填充等等。当我们在后来的阅读或者生活中看到有用的素材，就自然想到可以用到什么地方。
第二天或者过几小时就要对文稿初稿进行修改，如果自己拿不准，还可以请教前辈高手，让他们伸出援救之手。这个过程就是“快速迭代”的过程，这个过程要经过很多次，不断地迭代。
也许最终呈现的文稿只有八十分，但是比没有要强多了。因为那些想着尽善尽美的人，总是要在大脑里形成一个完美的文稿才动手，可能还没有动手，时间就已经过去了。甚至有的想象得很完美，结果出来的东西只有三四十分，这就不是我们想要的结果了。
这里有一个原则就是，我们的大方向一定要正确，也就是过去说的“做正确的事比把事情做正确重要。”那么这种“小步快跑，快速迭代”方法就可以运用到平常的任何工作中去，特别是对那些需要创意的工作，更需要采用这种方法。
关注个人学习与成长，与大家共同进步！
得到品控手册 总则 这本手册是干什么的？ 是为我们自己赋能的。 为自己赋能是什么意思？ 当你忘记手册上的内容，但是具备了以下三种能力的时候，你已经能力附体，成为得到的一 员了： o你可以定义自己的工作目标，并完成它； o如果需要选择，你可以自己找到判断的标准； o如果目标一...
小步快跑，快速试错 什么是最简可行产品？ 最简可行产品（Minimum Viable Product，即MVP）是指以最低成本尽可能展现核心概念的产品策略，即是指用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出自己产品最终想要的效果，然后通过迭代来完善细节。一个...
总则 这本手册是干什么的 ? 是为我们自己赋能的。 为自己赋能是什么意思 ? 当你忘记手册上的内容，但是具备了以下三种能力的时候，你已经能力附体，成为得到的一 员了: ●你可以定义自己的工作目标， 并完成它; ●如果需要选择， 你可以自己找到判断的标准; ●如果目标一个人不...
当你想表达什么的时候，总被告诫，“三思而后行”，甚至有人告诉你一个方法，把舌头在嘴里转三圈以后，再考虑要不要说。好吧，那你是不是又成了一个貌似“优柔寡断”的人？我们常说，某人是性情中人，就意味着，这个人的言行带有更多的直觉的色彩。或者说，某个人，快人快语。 好像我们都争着表...
有一天，蓝蓝的天空里有好多好多的棉花糖，很美，给我温暖。 总会有美好的温暖，鼓励你坚持走下去。
后台语句： 前端语句： MySQL数据： 注册成功截图： 登录成功截图： 今天为大家分享了用Node.js和MySQL编写网页中的注册登录页面，不足之处望大家多多指正，谢谢大家，持续更新中......
众里寻芳千百度， 浅溪幽涧翠娥眉。 蝶身玉尾黄金蕊， 比翼双飞恋舞姿。
林安喜欢一个人，喜欢了很久很久。 那一年，林安12岁，刚上初中。那会儿，初一已经不叫初一了，而是改叫七年级。就好像现在的高考已经没了北京卷、湖北卷……取而代之的是统一的全国卷。这些年，好像什么东西都变了。 今天，是林安初中兼高中同学小李的婚礼，而小李是高禹学生时代最好的哥们...译者注： 本文译自： https://dzone.com/articles/learn-drools-part-1-1 其中有几个想法跟原作者认识不一， 这个也明确标出， 也烦请读者指正。 & & 在实现复杂业务软件系统时， 经常需要维护一组业务规则。在运行时， 这些业务规则针对业务数据，触发新的动作。 推广来看， 我们称之为规则引擎。如果咱们的业务规则比较少时，我们可以自已搞一个规则引擎，来维护业务规则，针对业务数据触发合适的处理逻辑，或对数据分类。 使用自研的规则引擎的话，一个好处是，我们可以完全控制引擎的执行算法。这样，我们可以方便地调整算法，期间不需要依赖第三方实现的规则匹配实现。 另一方面，如果规则经常需要调整或规则很多时， 使用自研引擎的话，开发成本会很高。这个梗怎么破？ 针对上述问题， 现在业界已经有这样成熟的实现， 这些第三方实现已经通过充分测试和业界验证。这样我们可以很方便地分离业务数据和规则。 第三方组织维护规则引擎， 我们只需要把业务规则定义成策略。使用声明式（而非入侵实现式），业务分析人员可以方便地理解这样的逻辑。 Drools是个啥？ Drools是开源的业务规则整合平台（BLiP， Business Logic integration Platform ），Java实现，现在Red Hat和JBoss维护。 Drools有两个核心功能： 规则编写。借助编写功能，我们可以创建规则文件，这样的业务文件后续名是drl。在这样的规则文件里， 以声明方式，定义业务规则。此文件中，可以包含多个业务规则。业务开发人员将收集到的业务规则编译成drl格式的内容。 运行时执行环境。运行时环境中， 逻辑上有一个工作内存空间，它在概念上跟Hibernate的session很像。跟规则文件中包含着多个规则类似，运行时环境里创建内存空间。在运行时环境里，定义好的业务规则作用到业务数据。Drools语境里，我们称输入的业务数据为Facts。 规则：规则也就是逻辑单元，运行时作用于业务数据。它有两总分内容：when和then。 When：确定业务条件，以触发事先定义好的业务规则。 Then：业务动作。如果业务规则满足后，这里定义的动作将被执行。 总体语法如下：
Rule &规则名称&
&触发条件&
&业务动作&
Rule &规则名称&When&触发条件&Then&业务动作&End
& 下面的例子中， [&]
本文译自： https://www.gremlin.com/community/tutorials/chaos-engineering-the-history-principles-and-practice/ 有感于公司的年中大促备战。集中备战开始时，跟同事聊天， 提到，现在一切风平浪静，是问题正在憋大招么？逗完闷了后， 顺着这个思路想， 在问题憋大招的时候，咱能不能主动出击，化风险于无形？Google一把后，发现业界已经”捣蛋工程”做到很是精致，已经形成很大的文化圈子。于是，从修补自身知识体系的角度出发， 粗翻了这篇文章。抛砖引玉，如有讨论，荣幸至极。 随着微服务和分布式架构的兴起， 现在的Web系统变得越来越复杂。相比于以往，我们现在对这些Web系统的依赖越来越强， 另一方面这些复杂系统中可能的功能失效也更难于预测。 这些复杂系统中的功能失效造成公司业务的中断， 且修复成本居高不下。 系统问题影响客户下单和事务办理。即便是一个很小的IT系统问题， 也很可以会把公司的业务一下子拉到解放前，造成业务停摆， 基于此，公司内部的IT团队的重要考核指标里加进了IT宕机成本（cost of downtime）。 比如， 2017年， 98%的公司表示，单单一小时的IT宕机会造成公司业务损失10万美元。例如， British航空公司CEO表示， 2017年一次系统问题致使British Airways (BA)数万乘客滞留， 结果造成公司财务损失一1.02亿美元。 为了避免财务损失， 问题面前必须给出方案， 毕竟问题出现后， 在那干等着也显得咱不专业。 为了应对脑瓜盯上的这个达摩克利斯之剑， 越来越多的公司转向Chaos Engineering。 Chaos工程是个预防针 Chaos工程采用组织协作且整体可控的方式， 在IT系统宕机之前发现可能的坏点。 特意制造一定的系统压力， 观测系统是否可用，
我们可以做到及时发现并修复问题， 从而避免被恶意地上头条。 借助Chaos [&]
译者注： 1. 本文译自： https://medium.com/@cramirez92/s-o-l-i-d-the-first-5-priciples-of-object-oriented-design-with-javascript-790f6ac9b9fa 2. SOLID代表了软件设计原则， 本身又有坚硬稳固之意。 结合中文语境稍微引申下， 是不是跟中文里的坚如磐石比较贴近？正是因为软件设计中使用了SOLID原则， 软件系统稳定的坚如磐石， 而不是弱不禁风不吹就倒。 前段时间发现一篇SOLID原则方面很不错的文章， 如果你对PHP熟悉的话， 可以直接读这篇: S.O.L.I.D: The First 5 Principles of Object Oriented Design。 不过， 咱是一个JavaScript码农， 就把原文章的实例改成Javascript的了。 JavaScript是一个弱类型的语言， 有些人认为它是一个函数式语言， 也有一些人认为它是一个面向对象的语言， 也有一些人认为前面两个特性都有， 也还有一些人认为在JavaScript中支持类机制就是不知所云。
— Dor Tzur 本篇文章是SOLID的入门指导，其中简要地描述了什么是SOLID原则。 SOLID是下面五个原则英文单词的单字母缩写： S — Single responsibility principle 单一职责原则 O — Open closed [&]
译者注： 本文译自https://williamdurand.fr//from-stupid-to-solid-code/ STUPID是啥来着， 该不是秋天的菠菜吧？ 上周在Michelin公司， 我做了一个名为”面向对象编程”的演讲，其中，讨论到了怎么才写出更好的代码，也即from STUPID to SOLID code。这里，STUPID和SOLID一样都是首字母缩写词，代表了软件业已有过多讨论的问题和针对问题的设计原则。 本文中， 我将介绍STUPID和SOLID。也请留意下，这些是原则，而不是定律。 不过，对那些想提升自己设计能力的同学来说，将STUPID和SOLID视为原则的话，将很有帮助。不过考虑到现在STUPID和SOLID所透露的信息并没有引起足够多的重视，也很有必要再要出来念叨念叨。 STUPID的代码？没开玩笑吧？ 初听这个说法， 你可能会有些小受伤， 不过，十有八九， 你已经写了很多STUPID的代码。我也是这样的。等下，这个STUPID是什么意思呢？该不会是秋天的菠菜吧。拆开来看， 代码下面6个问题： 单例 Singleton 高耦合 Tight Coupling 测试困难 Untestability 过早优化 Premature Optimization 词不达意的命名 Indescriptive Naming 重复 Duplication 下面， 我将按个解释下这些软件设计中常见的问题点，期间会有不少细节讨论。整个内容也是我演讲稿的再整理。 单例 单例设计估计是最为大家所知一个设计模式，不过同时也是最被误解的设计模式之一。单例模式有什么问题呢？如果你经常使用单例模式的话， 就很有必要听我来聊聊了。 单例模式使用起来很有问题， [&]
译者注： 本文译自： https://dzone.com/articles/object-oriented-analysis-and-design-part-1 本文也是本博客里OOAP方面的第一篇。 一共2300个字，阅读大概需要15分钟。 下面是正文。 这件事谁来做？ 做这个事有什么好处？ 如果我做的话， 老板会不会觉得我在浪费时间或在找借口而不愿意做这个事？在很想设计下一个软件前， 咱是不是考虑过上面的这些问题？ 以前你也很有可能试着设计过一些软件，设计中， 会发现很耗时又没有什么回报。不过， 在长时间的软件工作过程中，你也应该想到这些问题：应该再深入地学习设计模式，努力做到设计出来的软件可复用、模块化且易读。 在这个系列文章中， 我将介绍如何合理地设计下一个软件。 你将学到什么？ 以前尝试的设计咋失败了？ 设计过程中， 怎么跟老板聊设计问题？ 一个成功的设计都需要哪些要素？ 软件开发流程 什么是面向对象分析？ 什么是面向对象设计？ 什么是设计模式？ 将学不到这些内容 Java,C#或C++的语法。 函数和变量有什么区别 不会被一大堆设计模式淹没。 学不到面向对象编程。 “什么?” 在看到最后一句话时, 你可能有这样的疑问。 “没有面向对象编程,那我还在这浪费什么时间?” 这个系列文章是关于面向对象设计的, 而不是面向对象编程。 我们都知道怎么面向对象编程,如在C#中写一个类。 不过, 正如一句谚语所说,”知道怎么拿锤子, 并不意味着你是一个建筑架构师”。 [&]
& 译者注： 本文译自https://piotrminkowski.wordpress.com//quick-guide-to-microservices-with-spring-boot-2-0-eureka-and-spring-cloud/。 笔者使用翻译的方式， 咬文嚼字地理解原文， 把翻译的结果也贴出来， 请大家指正。 本文内容13942个字， 阅读完大概需要30分钟。 本文内容假定读者已经对maven和Spring有一定的使用经验。 & 我博客中， 有不少文章是关于Spring Boot和Spring Cloud的。现在这篇文章，主要是想总览地介绍地下Spring Boot和Spring Cloud框架提供的核心组件， 期间使用了一个实际可运行的例子来帮助我们更直观的理解怎么使用Spring创建微服务。 本文包含如下话题：
cloud-native开发环境中使用Spring Boot2.0。 使用Spring Cloud Netflix Eureka， 完成微服务的发现功能。 使用Spring Cloud Config服务提供分页式配置服务。 使用Spring Cloud Sleuth整合日志 开始撕代码之前， 咱们先看看下面的图。这个图展示了我们实例的整体构架。这里，有三个独立的微服务，它们在服务发现模块里注册，从配置服务里取配置信息，并在业务上相互通信。整个业务系统隐藏在API Gateway的后面。 目前， 最新版本的Spring Cloud是Finchley.M9。 这里， 为了管理依赖的方便， 直接使用spring-cloud-dependencies， [&]
Titanic: Getting Started With R – Part 2: The Gender-Class Model 上一节中， 我们串讲了怎么利用R语言来预览数据， 在最后在只是针对目标变量做了粗略的预测。本节中， 我们开始加上数据集中的其它变量来更好的预测。 泰坦尼克号沉了的拯救中，”妇女和儿童优先”的原则很是引人注意。这样， 我们先看下性别和年龄这两个变量是不是最后的生还有很大的影响。我们从乘客的性别开始。导入数据后，利用summary命令观察下性别这个变量： & summary(train$Sex) female male 314 577 从上面的数据看， 我们看到大多数的乘客都是男性。现在再使用上节中提到的prop.table命令，看下性别和是否生还这两个变量组合起来结果怎样？ & prop.table(table(train$Sex, train$Survived)) 0 1 female 0.. male 0.. 呃，也不是很明确。prop.table命令默认情况下，计算百分比时分母是所有乘客的个数，这时我们看到四个分数的总和是1。 我们实际上是想要行维度的百分比，即，针对每一组性别单独看，生还结果的百分比。这时， 我们可以给prop.table命令再传一个参数，让它统计百分比时使用第一维度。 & [&]
欢迎来到第一部分， 本节中， 我们将使用R语言来加载数据并粗略了看看浏览下这些数据。 关于怎么安装R语言和RStudio，请移步这这里（如果是Linux环境的话， 直接运行命令”sudo apt-get install r-base“安装）和这里。 现在回到Kaggle，注册后 下载数据！这里我们需要下载train.csv和test.csv两份数据，并保存下来。在下载页面里， 可以顺便往下滑滑鼠标，对数据有个大致的了解。后续学习中， 我们将时不常地翻看这个数据描述页。 打开RStudio后， 将看到三个pane。左边的是控制台，这里我们输入命令并执行。 右上角， 是当前环境中打开对象的列表。 右下角，有多个Tab， 可以看到Help页和数据可视化输出的图表等。 在控制台，我们可以在函数前加上问号， 这样回车后看这个函数相关的文档描述，如输入?table后， 将在右下角的Help Tab里 看到table命令的描述。 打开RStudio后， 第一个需要做的是设置工作目录。设置工作目录后， 我们可以设置后的路径下加载文件，只在输出文件到指定路径。在RStudio中， 这个操作很方便，点菜单“Session”，选”Set Working Directory“后， 通过”Choose Directory…“，刚才下载了训练数据和测试数据文件的路径，就设置了工作目录。设置默认工作目录过程中， 在控制台留意可以发现，这里自动输入了跟界面操作等价的命令，我们可以趁此机会了解到这些界面操作背后的命令都有哪些。 RStudio虽然支持直接使用命令行模式地简短输入命令，我们还是建议你创建一个文本来保存脚本。这样，我们可以方便地重现以前的结果，并不需要全部重新输入情况下做细小的调整。点击左上角的”new document“按钮，选择“R Script”后， 第四个Pane会在左上角出来。从控制台中复制setwd命令（这个命令是前面设置默认工作路径时RStudio时自动生成的），复制到前面创建的脚本里。现在保存这个脚本到前面设置好的工作路径下。 在RStudio中，有些快捷键可以让操作执行更方便些。鼠标放在某一行后，按下Ctrl-Enter，可以执行当前行的命令。在控制台里， 我们可以使用键盘上的上下键来找到最近执行过的命令，Tab键会触发自动补全。 好了， 下面我们加载数据，在RStudio中看下数据的内容。RStudio右上角找到并点击“Import Dataset”，选定train.csv文件。导入过程中， [&]
Categories注册 | 登录
杭州市某高逼格UPUP之地
报名已结束
收藏已收藏 | 21
1.3万 人浏览
扫码分享给好友
天下武功，唯快不破。大道至简的道理人人都懂，但是具体落地时很多人收不住，甚至把简单的事情复杂化。
做产品要快，但有些误区需绕开：不必等一切想明白再动手。产品并不是设计出来的，而是“改”出来的。一件产品，只有不断改进，才能把竞争者甩开；只有快速迭代，才能创造需求的赢家。
需求辣么多，要如何确定产品迭代的需求？要如何制定合理的版本迭代计划？又该如何通过市场和用户的反馈数据决策下一步的迭代方向？
5月28日（周六），起点学院线下公开课携手腾讯众创空间特邀四位产品大牛，为你分享他们多年工作中实战得到的经验，告诉你产品迭代的秘密，赶快来报名参加吧！
活动主题：小步快跑 快速迭代—产品大牛教你迭代的秘密
活动主办方：起点学院、腾讯众创空间、人人都是产品经理
活动协办方：杭州智慧产业创业园
活动规模：200人（按入场时间就坐，迟到无座敬请谅解）
活动时间：5月28日周六下午14:00-17:30 （13:00入场签到，14:00活动正式开始，请勿迟到）
活动地点：杭州市西湖区文一西路857号杭州智慧产业创业园B座109报告厅
活动费用：30元/位（费用用于茶歇，会务安排等）
1，产品经理、运营人员、设计师、程序员、创业者优先；
2，起点学院学员优先；
3，人人都是产品经理粉丝优先；
4，腾讯众创空间粉丝优先
点击底部“我要报名”立即报名或复制报名链接到浏览器中根据提示即可完成报名，链接：
活动门票说明
本次活动门票，分两轮发放（请提前抢票哦）
第一轮：5月24日19:00
第二轮：5月26日8:00
本期活动分享嘉宾：（排名不分先后）
都说产品经理是离CEO最近的职位，也许今天坐在你身旁的这位小伙伴，就是未来身价百亿的CEO。请珍惜今天这个短暂的相聚，珍惜你身边的这群朋友（这是一个“人脉=资源”的时代），一定要加个微信！！
活动议程：（以现场为准）
金牌合作伙伴
收藏已收藏 | 21赞已赞 | 5产品鹅说 | 你真的理解“小步快跑、敏捷迭代”吗？
什么是最小可行性产品
最小可行性产品（Minimum Viable Product，MVP）最早出现在Eric Rise的《精益创业》一书中，刊载于哈佛商业评论，它提出“在市场和风险尚不明确的情况下，贸然倾尽公司所有全力投入是不太明智的。所谓的最小可行性产品，是让开发团队用最小的代价实现一个产品，以此最大程度上了解和验证对用户问题的解决程度。”
Dropbox在项目初期，仅用了一个3分钟视频、一个简洁的登录页面，便获得了大量用户注册，且清楚地告诉了用户“我是谁”。这种以极小的成本获得了对用户的需求验证，这就是一个很好的最小可行性产品例子。
图 1 图片为Dropbox官网登录页面
形象点解释一下这个名词，“试”这个概念大家一定不陌生，在生活中，有很多和“试”密切相关的事情。比如，在开发完一个新版本后，通常的做法不是立刻全量上线，这样做有极大的风险，较为可行的方式是采用一定比例的“灰度上线”亦叫做“小流量”上线，这样既可以满足最快速度触达目标用户，收集他们的使用体验和反馈，同时也不会面临全量上线出现意外事故导致负面影响的风险，这个“灰度上线”或者“小流量”上线的过程，就是一个新版本的“最小可行性产品”的过程。
同样，一部鸿篇巨制的大片在具体开始拍摄之前，工作人员会事先针对每个镜头绘制电影的分镜头脚本，以确保镜头的连贯、降低拍摄成本，同时在开始拍摄之前，工作人员还会对于分镜头的脚本进行多次讨论和修改，这里的分镜头脚本对于最终成型的电影来说，就是一个“最小可行性产品”。
假如你立项做一个创业项目，打算设计一款高科技活性炭材质的纯棉内裤，你的产品核心诉求点是“活性炭材质”吸附有毒有害物质，那么为了快速打造你的“最小可行性产品”验证市场反应，你预约了一家加工制造厂为你定做这款内裤，在这个时候你应该重点突出最核心特质，即吸附活性炭功能上，快速让加工厂加工生产一个样品拿到市场去验证，而不是精雕细琢讲究不同花色和样式把精力放到工艺上。
因此“最小可行性产品”主要强调在产品项目的初期，作为产品从业者要学会“克制”，聚焦场景和需求，提炼一款产品最核心的功能特性，去掉所有锦上添花的其他功能，并且快速找到验证路径，锁定目标用户，收集体验并尽快迭代修复的过程。通过几个例子更好地理解这个概念。
人人湘米粉
人人湘是一家米粉店，是一家开在北京，没有收银员，卖出150000碗米粉，获得2700万融资的米粉店。是的，你没有看错，这是一家互联网化思维的米粉店，也是巧妙运营了MVP思路在立项初期快速探索产品可行性的米粉店。人人湘的创始人希望在北京开一家能够吃到家乡口味米粉的米粉店，可是，面对众人连锁品牌、巨额的租金、对人群口味的不确定性等未知因素考虑，他们采用先快速搭建一个粉店雏形，即人人湘的MVP，这一家粉店叫做“无名米粉店”，它开在中关村，就在3W咖啡的旁边，是人人湘用来测试自己产品可行性的雏形。为了摸准用户心智，来自家乡以及其他外地的白领中午就餐是否会选择他们的米粉，还是米饭类更能带来流量，提高翻台率，他们便从湖南米粉中选出了20几种，全部放在测试店“无名米粉店”里面进行销售，然后纪录每一种类型的粉的销售情况和用户食用后的反馈情况。
不光如此，他们还适当地添加了一些米饭，比如牛肉盖饭、宫保鸡丁盖饭等。经过了3个月的测试之后，证实了他们原先的设想，即选择鱼粉的用户是最多的。于是在这样快速、简洁上线的测试店里，他们完成了假设的佐证，于是最终确定店内的5款主打米粉，即老馋粉、辛太急、炒粉、至尊鲜鱼粉、椒无双。
图 2人人湘米粉产品宣传图
从2010年上线0个用户，到2013年上百万的用户量。而纵观Instagram的发展历程，也是在产品立项的初期巧妙地运营了MVP理论，首先他们用h5制作了一个简单的原型，叫做Burbn，然后拿着这个原型给周围的朋友使用，收集意见和反馈。Burbn的定位和设计理念和现在的Instagram有很大的区别，它的主场景为特定的地点，核心功能锁定在签到上，并且还支持游戏、社交媒体、图片分享等功能。当Instagram的联合创始人Kevin 和 Krieger拿着他们的MVP Burbn收集第一批种子用户的反馈和建议，竟意外地发现用户并不是拿Burbn来签到的，而是用它发布、分享图片，跟他们最初设想的用法完全不一样。于是他们砍掉了原来的游戏、签到等功能，只留下了和发布照片相关的功能，正式将产品定位为图片社交分享社区。于是，Instagram应运而生，上线后几个月就获得了破万的用户量。
图 3 图片来源于Quora kevin systrom
Craigslist
界面极其简洁干净，载入和响应速度极快，而且除了用户上传的之外几乎没有其他任何图片，只提供用户最需要的服务，没有广告位，没有一丝一毫的垃圾，操作简单，安全性高。网站虽界面简单但其服务能力相当强大，所有的功能都是对准用户需求的，例如信息发布一段时间会被自动删除，但在账号里可以看到过去所有发布过的信息，只要一个按钮便可以repost；而沉下去的帖子可以通过renew顶上去。
图 4 图片为Craigslist官网
界面简洁清爽，没有多余冗杂的设计，是汇集各大年龄阶层的大型论坛，每个论坛有子版块，子版块的话题各不相同，广受用户喜爱。对Reddit而言，他们的工作优先级排序一定层面反应了用户需求，他们的工作优先级按照内容运营、管理员工具、商业化、移动端研发与优化顺序排序的，因此即便前端页面功能并不十分丰富情况下，也有相当大的用户使用。
图 5 图为Reddit官网
“最小产品”与“可行产品”
Eric Rise在《精益创业》中提出最小可行性产品的概念后，被不少创业圈的人误解为“最小可行性产品”就是用最小的成本快速上线迭代，甚至有时在并未想清楚业务形态和产品逻辑的情况下就贸然立项。这种只看到“最小”而忽略“可行”的做法是本末倒置的。“最小可行性产品”的核心是解决两个问题：核心功能、种子用户。因此“最小”和“可行”是一个并列的概念，两者相辅相成、缺一不可。
图 6 MVP模式关系图
“最小可行性产品”的核心要义不在于寻找“最小产品”，而在于“佐证假设”，因此“最小可行性产品”不是一个产品，它是一个求证的过程。很多公司和项目初期，会常常犯这样的错误，“我们要快速迭代，快速迭代，小步快跑，先上线看市场反馈，我们再做升级调整。”这样做的一个思维路径是用市场反应来找答案，而不是用市场反应来验证答案。显然不是最小可行性产品所提倡的概念。
“最小”是一个相对概念，不是绝对限定值。不能轻易地认为“最小可行性”产品中的“最小”就是最精简的功能、最简陋的流程、最易于上线的路径，这样就可以快速迭代、小步快跑了。不同的产品，定位与所需要解决的关键痛点不同，其涉及的“小”的概念和范畴也是不同的。探索“最小”的过程，需要你回答并且精准地提炼出你想要验证的产品的“功能特性”、“卖点”、“构成要素”、“关系链”，这个过程就是提出“假设”的过程，当你完成了假设之后，需要用“做减法”的方式提炼选出最核心的功能卖点，然后拿此卖点到市场上去验证，这个过程就是进行“佐证”的过程。
一、假设：
假设是你基于现有市场的需求情况，结合你的调研和深度研究，主观加工制造出来的一个“联系”，即受众需求和产品功能的联系，这个假设其实就是针对于你打算投入市场的产品的定性，回答一个问题“它是什么”。
比如，通过观察，发现大量的用户在办公中会使用一些常用社交软件进行文件传输和共享，基于这个观察你们提出疑问，是不是用户在用社交软件办公、聊天过程中，也存在部分处理文件、比如文件的存储、转存、回转的需求，基于这个疑问你们提出假设，建立在社交关系链基础上的文件传输和共享是成立的，于是你们打算扩展产品功能，设计一款基于社交产品的文件管理功能。那么，这时提出文件管理功能模块的过程，其实就是一个提出假设的过程。
基于一个场景或者潜在市场，可以提出的假设千差万别。但是对于一个初期产品、一个独立的feature，你的假设一定要聚焦，同一时间只解决最痛的一件事情。因此你的假设一定是可定量的，即你最希望用一个什么样的feature或者解决方式去帮助用户解决痛点。在美国好莱坞电影编剧选择剧本时，一般最希望看到的是一个可以用一句话看到的剧本，这样才可能第一时间让编剧以及受众留下印象，同理也作用于一个产品的假设提出。这也和最小可行性产品中的“最小”不谋而合。
在平时的工作中，可能运用到“假设”的方法有：
· 头脑风暴，找关键词，并将关键词聚类
· 想象如果若干个功能中只能保留一个功能，那它会是哪一个
· 回归生活场景，把自己当成用户，寻找需求的原始根因
· 同比其他产品，面对一个需求，市场上最好的产品解决方式是什么，最差的产品解决方式是什么
· “变废为宝，”尝试颠覆已有“不合理”的假设，对其进行打磨和改革，尝试思考，加上什么、或者减去什么它更合理
· 自我设问，不断问自己“为什么”，如果缺少了一些功能，产品是否还有意义
二、佐证：
“佐证”是将你事先假设的产品feature和卖点拿到市场验证的过程，以确定之前的“假设”是否可行。因此“佐证”的目的是验证需求，并且用“可行”的标准来衡量“假设”。
佐证的过程是需要对标“可行”的标准，“可行”从字面意思来理解，绝不是简简单单让一个产品模子从0到1。从无到有的过程回答的是“可能”的问题，不是“可行”的问题。“可行”一定是发生在多维度环境下，多向度的交互动作，即一定是产品、概念、受众、环境等发生碰撞，才能判断是否“可行”。因此，可行可以理解为“假设可行”、“验证可行”、“市场可行”、“用户可行”。“可行性”的过程是在解决整体性、关联性、共鸣性、情感连接，做减法，找到潜在种子用户。
图 7 可行性模型
1）假设可行：
假设可行也即就是功能可行，做产品的时候，你会有很多假设。你假设自己知道用户的需求是什么，他们喜欢什么样的设计，应该采取什么样的市场策略，用什么架构最有效，如何持续地盈利，哪些法律和规定是必须遵守的。但不管是一个多么资深的产品设计者，总会有一些假设是错的。
比如你看到现在宠物市场很火，尤其是大城市，于是你做出假设，认为你可以在北京这样的一线城市做一个提供高端的宠物护理项目。这是你基于身边看到、听到和观察到的现象得出来的假设。但是基于此假设是否可行，这里会有这样一些问题，宠物护理对于跨区域的要求并不高，通常是锁定在小区附近居住人群密集的地方，所以你的选址和跨区域规模化需要再多加考虑；另外，你的护理服务是上门的，还是直接到店的？如果是上门服务，那么主人家中的设备设施是否满足需求？如果是到店的，是否支持在线预约，让宠物护理业务＋互联网，基于此假设，如果锁定了一个高端住宅区，那么如何更高效地实现线上、线下对接，简单来说即怎么高效地接送宠物。
虽然搞清楚是否有人需要你的产品的唯一方法，就是把你的产品尽快推向市场。但是在假设的初期，你需要结合基于产品卖点、环境、情景做多方面求证。
2）验证可行：
验证可行也即验证方法可行，完成了假设的设定之后，你需要开始构思一个有效的验证假设的防范。如果你想做一款基于本地商户线上下单、接单的产品，你预设了这些功能，比如可以接单、查看流水、收入分析、各大接入第三方平台效果监控、直接对接地图、团购网站、自定义优惠券金额、产品类别、上传图片并修改美化图片功能，甚至还有一些辅助小工具比如计算器、账本等，那么验证这个假设有以下几种方法，你拿着你的设想和理念去跟投资人喝喝咖啡，融一笔钱，然后召集来一个初始团队，用几个月时间打造这样一款实体产品，接着带着你的产品去实体商店一一推广，在各大渠道发布造势，然后等候市场和用户验证是否需要你这款产品。
其实，除了这种方法以外，你还可以有别的方式在更早的时候验证你的想法是否可行了。初期MVP就是移动应用的原型，你可以用手绘方式简单地勾勒出你产品的核心功能路径，然直接拿着它就可以去和你的目标用户聊了，可以问问如果现在有这样一款产品提供给他们用，他们是否有兴趣，他们是否已经有在使用同类的产品了，叫什么，使用频率有多高，是刚需吗，是否还存在其他可替代的产品。
我曾经参与过一款面向医生用户群体的产品立项，在立项初期团队是采用了这样的一种方式，先是明确出产品核心feature和主流程交互，然后让设计师设计了几个关键路径的交互稿件，我们就拿着这个去跟医生用户沟通，让他们模拟使用的场景，其结果是这样的方法行之有效且成本非常低。
3） 市场可行：
经济学中对于有效市场假说，将市场分为三类，弱有效市场，半强有效市场，强有效市场。这里所提及的市场可行，和对应的目标用户有很大的关系。还是以刚才的宠物护理项目为例，在构思这样一个项目的初期，出于资金、人员等因素的限制，对于初创团队、公司很难一开始就有那么多的人力、物力在全国范围内铺开，因此通常会聚焦到一个有限市场内去对需求的可行性进行验证，比如选择一个人流量较大、入住率较高的高端住宅区，这时候其他区域就不再是你做此次产品可能性验证的市场范围了。同理，你设计一款针对二三线城市本地商家投放推广广告的产品，那么你的目标可行市场就一定不能是北上广这样的区域。市场与定位的目标用户群体是相辅相成的，因此在选择市场的过程中需要时刻比对目标用户进行阶梯式筛选。
4） 用户可行：
人总是对新鲜事物包含激情的，所以，当你的新产品上线后，所有人都可能成为你的潜在用户，但并不代表所有人都是你的有效用户。也即就是说，当你做出了一款新的产品，在产品刚推广出去时，会有一批用于尝试新鲜事物的用户率先使用你的产品，他们可能会针对自己的使用场景和体验给你提出一些意见或建议，然后他们并不是你的忠诚用户，对你的产品也没有那么高的粘性。
一段时间过后，可能因为被其他新的产品吸引过去了。因此，一定要注意对用户进行甄别，对用户的反馈反复求证。Geoffrey A. Moore 在其经典著作“Crossing the Chasm” 里，也提出了类似的观点。“技术产品的生命周期定律，在天使用户和早期大众用户之间有一条很难跨越的鸿沟。”所以，找准你的天使用户，找准对象说，然后快速修正迭代，最后改进成适合早期大众用户的真正产品。最小可行性产品需要用户选择的可行。
图 8 图片来自Geoffrey A. Moor在其经典著作“Crossing the Chasm”
记得曾经在用户访谈日就一款社交软件采访用户时，当问及到“你们觉得现在的产品是否好用，如果不好用那么希望它还有哪些功能？”这类问题时，用户总能给出五花八门各种答案，比如“希望可以用它手写文字”、“希望还可以支持看一些视频、新闻之类的”、“希望可以有个日程提示”等。其实时间一长你就不难发现，这类用户并不是针对你所提出的产品本身在提供意见，而是在回答他生活中的一些痛点，这些痛点有些跟这个产品相关，有些跟这个产品毫无关系。
在平时的工作中，可能运用到“佐证”的方法有：
· 巧用“六顶思考帽”方式进行内部讨论，变换思维角度验证需求
· 部门内不同成员进行可用性测试、可以是访谈、简单沟通，观察目标对象使用反应
· 快速产出原型图，用幻灯片、flash等方式观察目标用户使用体验
· 抓大放小，找准种子用户，让他们看到产品的潜力和未来发展方向。
打磨产品的过程是讲好一个故事的过程
俗话说“罗马不是一天建成的”、保尔柯察金也用他的毅力回答了“钢铁是怎样炼成的”。所以“最小可行性产品”并一个可量化的产品，而是一个需要断试错、迭代、大量验证、求证的过程。
最小可行性产品提倡两个方面核心点：找到核心功能、找准种子用户。在产品设计的初期阶段，核心功能的选取就类似于故事主线的梳理。一个故事创作会经历“背景”、“类型”、“结构”、“要素”、“爽点”的层层漏斗式提炼，对应到产品设计过程中，也即“场景”、“类别”、“架构”、“元素”、“feature”。因此打磨产品的过程是一个讲故事的过程，我们可以借用讲故事的一些技巧到最小可行性产品的设计中去。
图 9 故事漏斗法抓取你的产品“爽点”
你去看一部电影、或者读一本小说，如果这个内容足够吸引人并且可以第一时间吸引你的共鸣，那么尽管看完时隔几天或者几个月，你仍然可以用一句话将这个电影、或者是故事的主要情节梗概概括出来，哪怕这个时候故事里的其他一些细节你已经记不清楚了。
这就是故事的爽点，一个写作者在编译自己的故事时，首先会为故事设定一个大致背景，接着会有一个大概的方向，自己即将讲一个什么类型的故事，比如是爱情故事、武侠、悬疑故事、荒诞故事、侦探、喜剧、警匪还是什么。这就类似于你在构思一个产品项目时想做一个什么方向的产品，是社交、云、工具、生态服务平台还是什么。
紧接着，故事作者会基于特定的方向开始收集资料和素材，比如所讲的是一个武侠类型故事，我们都可以预期的元素有，绝顶高手，传奇的武功，各门各派，鱼龙混杂的酒楼，群英荟萃的武林大会。还要有师徒，师兄弟，师妹，凶徒，好友，魔教余孽，知名美女等各类角色。故事的创作者会基于这些元素进行素材收集和有的放矢地排列组合。
收集完素材之后，紧接着，你需要为你的故事构思一个“爽点”（也可以理解为high点），即在一个产品中你主打的一个核心feature，除了这个主要的feature外可能它还会有一些其他的功能点，但是这一个feature是你们主要想传达给用户的，让用户记住你的，类似于一个用户一天使用几十个产品之后，回过头说起你的产品来还能记住的那个点。
当你燥热口渴时，你想要的就是一听冰可乐；当你想要刺激恐怖，你就会去找一部恐怖电影。写作中比如创作一个女性宅斗文，你的“爽点”就是要是复仇，需要传递出来“吃了我的给我吐出来，拿了我的给我还回来”，甚至最好是“踩过我的给我跪下来”。
在设计一款类型产品时就是这样直接满足用户某一方面的渴求，因此，在进行产品核心feature构思的阶段就尤其要先搞清楚这个类别的“爽点”在哪里。而爽点的选取思路就同比最小可行性产品中“最小”中对于“功能特性”、“卖点”、“构成要素”、“关系链”等的提炼。
比如，你想做一款K歌APP，调研了一下现有市场上的产品，发现大部分都是在一个独立app产品中进行K歌，然后再将歌曲转出到其他平台。比如唱吧的定位是“陌生人K歌”，因此提供的主要功能是录歌、直播唱歌、陌生人录音等。
图 10 为K歌类产品现状分析
基于此你想做一个能主要聚焦于微信好友，并且可以邀请熟人朋友一起K歌的产品。你的核心feature便是能直接邀请并和微信好友进行在线K歌。在前期阶段，在微信发起邀请且如何利用微信关系链进行K歌将作为你这款产品设计的要点，像其他附属功能比如直播、打赏、在线KTV等将不作为主要的关注点。甚至在前期可以基于如何自然地在微信中发起邀请、接受邀请、打开K歌房间等流程设计对应的交互页面，然后拿着你的交互Demo找到身边朋友、或者用户听听他们的意见和反馈。
· “最小”和“可行”是一个并列的概念，两者相辅相成、缺一不可。
· “最小”是一个相对概念，不是绝对限定值。探索“最小”的过程，需要你回答并且精准地提炼出你想要验证的产品的“功能特性”、“卖点”、“构成要素”、“关系链”，从而以做减法的方式精确地找准核心功能卖点。
· 从无到有的过程回答的是“可能”的问题，不是“可行”的问题。“可行性”的过程是在解决整体性、关联性、共鸣性、情感连接，做减法，找到潜在种子用户。
· “最小可行性产品”的落脚点不在“产品”，在于“佐证假设”，因此“最小可行性产品”不是一个产品，它是一个求证的过程。
· 因此MVP绝不是一个可量化的产品，通过你不断试错、迭代的试验品，它是一个过程，而且不是一个一蹴而就的过程，它是一个需要大量验证、求证的过程。
· 最小可行性产品提倡两个方面核心点：找到核心功能、找准种子用户。
· 打磨产品的过程是一个讲故事的过程，我们可以借用讲故事的一些技巧到最小可行性产品的设计中去。一个故事创作会经历“背景”、“类型”、“结构”、“要素”、“爽点”的层层漏斗式提炼，对应到产品设计过程中，也即“场景”、“类别”、“架构”、“元素”、“feature”。
本文作者：
舒文，腾讯产品经理、专栏作者；知乎：舒文；微博：舒文Aqua；微信：aquasays
点击图片回顾上集
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点}