逃离项目管理百慕大三角

百慕大三角的事情大家都很熟悉，我遇到过很多项目，经常会陷入到这种百慕大三角。在我们传统的项目管理里，有个项目管理三角形，也就是：时间、资源以及功能需求。这个三角经常会导致很多问题，以致很多项目在实际操作过程中失败了。

我们创业团队做项目的时候，首先想到的是怎么顺利的把产品做出来，也就是怎么从项目管理百慕大三角中逃出来。

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%，运营做不好也一样跨不过去。