我们经常会听到颠覆性创新、微创新这样的词语。但实际上创新非常难做。尤其对于初创小团队，创新实在太难。
在CTO俱乐部第96期《 产品创新之路及DevOps实践分享 》活动上，速评网联合创始人王立杰给我们分享了他在产品创新路上的实践经验。本次分享的内容跟创新有关，但又不是告诉大家通过什么方式或方法去做创新，而是从另外一个思路讲。希望通过这次的分享，能够在如下几个方面给大家以启示：如何决定产品的路线图，如何快速验证核心用户需求，如何快速反馈、随需而变，如何为客户带来最大价值的服务。
速评网联合创始人 王立杰
以下为王立杰本次分享内容精华摘选：
逃离项目管理百慕大三角
百慕大三角的事情大家都很熟悉，我遇到过很多项目，经常会陷入到这种百慕大三角。在我们传统的项目管理里，有个项目管理三角形，也就是：时间、资源以及功能需求。这个三角经常会导致很多问题，以致很多项目在实际操作过程中失败了。
我们创业团队做项目的时候，首先想到的是怎么顺利的把产品做出来，也就是怎么从项目管理百慕大三角中逃出来。
2009-2010 Standish Chaos的研究报告显示，通常真正能够成功的项目其实很少，软件项目成功率约为30%左右，大多数项目其实都是有问题的，要么失败，要么Challenged。
曾经有两个犹太人，一个老人，一个年轻人，他们口渴要喝水，老人让年轻人去烧水。年轻人灌满一壶水开始烧，最后因为柴火不够水没有烧开。年轻人很郁闷，老者就问，在柴火有限的情况下，你觉得怎么才能将水烧开？大家一定知道，在没有那么多柴火的情况下，不要烧满满的一壶水，少烧点就可以。
我们在项目管理三角形中，在有限时间和资源的情况下，不太可能把所有的需求都做出来，这时候需要有选择的去做最有意义的事情，而不是去烧满满的一壶水。
颠覆传统的项目管理三角形
从这个角度来讲，我们需要把传统的项目管理三角形打翻。传统项目管理三角形里，通常来讲功能需求是确定的，然后根据功能去做分析，算出来所需要的时间和资源。而在敏捷开发里面，我们把这个给推翻，叫倒立三角形，就像前面讲的烧水的例子，并不去做所有的事情，而是根据现有资源，有限的时间里有选择的去做一部分事情。
敏捷开发模式中的80-20准则
那该选择做哪些事情？根据80-20准则，客户真正关心的东西只有20%，把这20%做好、做精，可能就足够了，另外的80%大多数时候是锦上添花。所以，我们要选择对客户最有价值的一部分去做。只有这样，才能摆脱项目管理三角形的束缚。
我们在学校里面学到了瀑布开发模式，分阶段的需求，设计，分析，设计，详细设计，编码，测试，交付，维护，这个流程周期很长。
假如我们利用这种模式做为期一年的一个项目，从年初计划到年底交付，这里面会有一些指标。比如开发费用。从年初到年底，开发费用支出是固定的，一直在支出。只有年底把软件做出来，并卖给客户，现金流才转正。通常情况下，在此期间这个项目的净现金流一直都是负的。这是传统模式。
而在敏捷开发模式中，我们把所有要做的功能划分成小块，先选择做最重要的20%。假设在三到四个月内把这20%先做出来推向市场，由于这20%的功能可以满足客户80%的需求，客户有可能因此就买单了。这时候，现金流会是另外一种情况，从三到四个月后就可以开始有收入，到五个月、半年左右，如果做得好，可能会收支平衡。除了资金，这段时间的成果还能够帮助团队验证做的东西、方向对不对。
除此之外，还能获得另一种成功。就是还有一种可能，项目做到一半，证明这条路是错的，不做了，就是半路夭折。敏捷可以做到，可以让你更好的项目很容易成功，你做错的项目很容易失败，其实失败是另外一种成功。
这是敏捷开发模式里面打破传统项目管理三角形的好处。在这里，很重要的一点就是我们需要对所有要做的功能有一个很好的梳理，就是划分优先级，我们需要知道哪些是20%，把最重要的东西找出来，逐步的去做。
我们传统会做需求分析，做调研，通常来讲所有的项目一条一条不分彼此，都分析得很透彻。在敏捷里面，因为我们划分了优先级，不是所有的东西都分析得很透，我只把最重要的地方分析透了。
需求分析：将用户实例化抽象化虚拟化
我之前接触的大多数公司做需求分析经常是这样一种文档：系统应该支持什么什么、系统应该做到什么什么……通常都是这么一种描述。开发人员如果对这个领域有点熟悉，可能还会建议说能干什么不能干什么。如果是初来乍到的，看了以后，可能惟一能记住的就是系统应该做什么。但实际上，说不出一二三。
在敏捷里面，这样做事的方式就是要变化一下。比如我们会分析几种典型的用户：
第一个类叫委托人，就是所谓真正掏钱买软件的人，买软件和用软件是两类人，采购拍板的是老板，他的需求是一种需求，我们通常叫委托人。
第二类叫终端用户，就是实际上经常用你的软件和产品的人。
第三类叫合作方。如果说你做传统ERP软件，不可能一个人做，有服务器，有合作方，合作方又是另外一类。
还有一类是内部客户，我们提供客户的管理员，还有写文档的人。
我们从这四个角度去划分用户，然后再针对每种用户进行实例化。比如做招聘相关产品的，抽象出一个招聘主管，叫杜拉拉。我们会定义它的用户属性，它到底怎么做。这最主要的是帮助大家建立起真实的虚拟用户的情形，帮我们去理解他这种用户会在什么情况下怎么使用你的系统。
刚才讲我们传统的需求是系统应该做什么，在这里面我们在描述需求的时候不是这样描述的，我们经常说，对于杜拉拉她想要做什么事情，达到什么目的，首先定位角色，他属于哪类用户，然后他要做什么事，做这个事的最终结果是什么，这个结果代表了什么，是价值。就是说我们做这个产品功能有没有价值，在敏捷里面我们讲是价值驱动，真正对客户有用的东西我们才去做，没用的东西我们就不做。所以我们会讲价值最大化。
从上下文的描述，能够帮助大家快速的去理解一个软件，一个系统到底该做什么，应该做什么，更好的去把握需求。我们再把所有的需求做细分之后，我们把最重要的20%找出来然后开始做。
利用MVP理论找出最重要的20%需求
按照上面的思路，创业团队已经能够较好的完成第一步的工作，可以把产品做出来、推向市场并接受客户的买单。但也还是会遇到一些问题，比如在敏捷开发中通常会提倡客户沟通，但当客户多了的时候，就会发现需求也越来越多，有时候团队就会被客户趋势，做的东西也越来越多。最后，东西多了，用户也有提升，但是转化率反而会下降。这是因为客户的需求其实一直保持在20%，但后来客户发现新增的许多东西并不是他所需要的，就会不想掏钱。
这是因为我们在做这些事的时候，走了一个偏方，离我们最初的目标越来越远，不是我们真正想要做的事情。所以，我们要清楚：要做就做最重要的20%！
那这如何找出最重要的20%需求呢？或者说我认为20%是重要的，我怎么去验证它？这里就需要用到MVP理论了。MVP，讲的是最小可行产品。如图所示，有两个圈，一边表示小的产品，一边讲可行的产品。
对于创业公司、小团队，就应该做MVP。再次一定要把最小产品区分出来，最小产品它不代表是可行的，什么是可行的，就是你这个东西是对客户有价值的，真的能够卖给客户的。我们这里面讲MVP，最小可行的真正卖给客户，客户愿意买单的这么一个产品。
为什么我们要做MVP？MVP有两个假设，第一个叫价值假设。最小可行，它是有价值的。我们衡量客户对我们的产品愿不愿意买单就是价值假设，这是有意义的。第二个叫增长假设。本来客户会认为你这个产品很有价值，也愿意买单，但是你能不能够快速的增长，是个普遍性的需求，客户能不能很快的累积。
MVP就是想帮我们去快速了验证这两个需求、两个假设。我们把最重要的20%选出来，把其中的某些功能做成MVP，用MVP去验证这两个假设，一个是价值假设，一个是增长假设。
如何验证？这时候我们基于MVP的开发模式会变化。在传统的测试驱动开发中，通常的方式是说功能，分析，写代码，写对应的单元测试，然后去验证。但现在，不是写代码，会先写对应的测试利用率，然后再去写相应的代码，去验证我的测试利用率可以通过，是这种开发模式。
基于MVP的开发模式，我们叫验证假设驱动开发。MVP基于两个假设，第一是价值，第二个是增长，有价值的情况下规模快速增长。我们首先提出两个假设，然后为了验证这个假设，需要相应的收集数据指标，用指标去说明这两个假设是正确的。最后开发一个最小可行产品，即MVP，也就是最重要的那部分，然后推向市场，看客户的反应，收集数据，继续验证两个假设，是不是真的有价值，是不是能够快速增长，这叫验证假设驱动开发。如果你验证对了，你就继续走，如果错了，你可以赶快停掉。
所以我们希望通过MVP去更快的验证你的思想。这是我最想跟大家分享的事情，我经过这次之后我发现，如何更快速的找到客户的痛点，更快速的去验证它，是非常非常重要的。
MVP到底该怎么做？质量不可商量！
我是做最小可行产品，即对客户有价值的产品出来的，到底怎么做？该做到什么程度？是不是要很高的指标？是不是零缺陷？真正去做的时候会发现有很多的问题。那该如何做？
首先我们着重强调一点，质量不可商量！ MVP一定是要高质的。比如做移动互联网，如果做了一个APP，功能好像还不错，但界面不好，用户很可能因此就抛掉，再下次他根本就不安装。第一印象可能会把客户赶走，所以质量要求很高。
如果关注质量，那长期来看质量会提升，成本会降低。如果关注成本，那长期来看成本会提升，质量会降低。—— 爱德华兹 · 戴明
质量到底是什么？通常我们有两个定义，一个叫外部质量，一个叫内部质量，外部质量很简单和需求保持一致。内部质量跟你的源代码需求一致。
外部质量其实就是功能，客户能够见到的东西，内部质量是代表代码，通常来讲内部质量决定了外部质量。质量应该是内建的。就是在写完代码的那一刹那，质量应该基本定型了，再多的测试也只是帮它去改善质量，不能够真正的改变质量。所以说质量是内建的，一定要从一开始就去关注，保持源代码的质量。
同样做代码也是这个道理，从根本上注重质量，保证代码质量才能够真正交付出高质量的产品。
质量到底该做到什么程度？喜马拉雅山高8848米，8848是基于海平面来的，它是相对海拔的高度。对于质量来讲，同样应该有一个基准，用这个基准去设计目标。对于MVP来讲，就要根据那两个假设，价值假设和增长假设，基于这两个假设去制定质量目标。MVP虽然是最小可行产品，但这不代表它质量低，质量要求实际是很高的。
还有这样才能够更好的验证思想，验证是不是抓住客户的痛点的需求，同时又不需要浪费很多的财力物力。
另外，商业目标决定质量目标。质量不是越高越好，比如动车、飞机肯定是要百分之百的。但大多数商业软件是有商业目标的，也就是既能够验证两个MVP的假设，又不会因此付出过高的代价。验证MVP就是想省时省力，如果因此要付出更多就没有意义了。应该就是在这个尺度内，客户满意，目标又得到很好的验证。
破窗理论：项目需要保质保量 需要真正把事情做完
一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙地被人打破；一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一个很干净的地方，人们不好意思丢垃圾，但是一旦地上有垃圾出现之后，人就会毫不犹疑地抛，丝毫不觉羞愧。
破窗理论对软件研发来讲非常非常重要。如果说我们在写软件的时候，里面的代码有不好的味道，坏味道，比如不重构、不复用或者代码不整洁，一旦有人开始这样做，团队里面其他人因为看到的代码本身就不是整洁的，那么接下来也不会让自己的代码变得更加整洁。就是你有坏的东西，会引出更多破坏性的东西。
后来我们在做事情的时候就特别注意这一点，一开始就把这个代码的质量抓得很紧。除了代码以外，我们还经常强调一点就是小流程，我们有个做事的小规则，这个规则需要维护得很好，一旦有人去打破规则，你不及时修补的话，慢慢的更多的人去违反。如果大家公司有开发流程的话可以去看一下。
需要把真正的把事情做完。破窗里面还有重要的一点，是我们经常强调的，把事情真正的做完。
我们划分阶段去做事，希望在整个计划内真正把所有的事情做出来。在此基础上，就需要在每一个要做的功能里面，真正的把事情做完，不要留小尾巴。如果留了，就会出现项目无法收尾的情况。为什么说经常遇到项目收尾收不完，好像工作做了90%了，就差一点点收尾。恰恰这一点经常花一个月甚至更长时间还收不完。因为之前没有把事情真正的做完，里面都留个小尾巴造成要收的东西很多。所以说我们需要真正的把事情做完。
《跨越鸿沟》：新摩尔定律
最后讲一点，有本书叫《跨越鸿沟》，讲的是新摩尔定律，讲客户获取成本。MVP只是帮我们验证最早的用户，在《跨越鸿沟》里面，用户被划分成几类：第一类是创新者，第二类叫早其尝鲜者。MVP就是帮我们去验证这两部分人，就是喜欢尝试新鲜东西的人。把这部分人吸引过来，来证明产品是有价值的，是能够快速增长的。
但产品真正的要成功，还需要占领后面两个市场，一部分人叫早期的大多数，这拨人有一定的先见性，愿意购买产品。后期大多数是受早期大多数人的影响，因为别人用了产品，后面这波人也愿意用。
所以从通过MVP把早期尝鲜者吸引过来，真正过渡到最后一拨人是一个很大的挑战。是一个鸿沟，是很难跨越的一个鸿沟。其实我也没搞明白怎么跨过去。余下的，是运营的问题了，做出产品可能走了90%，运营是10%，运营做不好也一样跨不过去。
王立杰，速评网联合创始人，敏捷爱好者、实践者，独立培训师，有超过10年的软件研发经验、超过5年的敏捷实施经验。