敏捷大会 II 敏捷助力产品创新(上)

李国柱-京东精益敏捷教练

导语：

一般我们想到产品创新，会觉得这个是产品经理的事，是产品经理应该关心的，我们研发团队好像一般关注比较少。根据我自己的经验我发现在创新上面非常强的团队，通常研发团队有非常深的参与度，而且对整个创新过程的支撑是非常强。

敏捷思维在创新过程其实也能够扮演很关键的角色，接下来我结合自己的工作经历跟大家分享一下，在产品创新过程当中如何做到敏捷思想和敏捷实践起到助推产品创新的效果。

*一、产品创新面临的挑战  *

首先我们在企业里工作中会做各种各样的创新尝试，大到产品的全新业务模式的建立或者旧有业务模式的重构，小到用户体验的提升，非常非常的多。产品经理可能有一些不错的想法抛出来，我们研发团队来帮助实现，这个过程会投入到很多的人力或者很多的金钱，最后结果如何呢？相当多的结果是非常不确定，很有可能达不到我们需要的这种效果。也就是说其实是非常不确定性，有非常多的不确定性，或者是成功的机会其实并不是非常的高。

​

根据我自己的经验做过一些统计，互联网行业新产品成功率，我自己的经验不会超过5%。之前一家公司我参与产品的创新和孵化工作，当时有39个项目进入孵化阶段，两年以后还活着的只有3个， 这个成功率是非常低。即使是小的创新，比如说用户体验提升的工作，至少有一半以上是不成功，也就是说我们上线以后，发现用户并没有期望那样喜欢我们的产品，或者更多的用户流入。这个取决于做用户体验的目的，你是拉新还是促活，还是保证留存等等诸如此类。所以创新成功的领域非常低。

另外，我们在这个过程当中不得不依靠一些老司机，比较资深的，对用户，对行业有比较深洞察的产品经理，可能他们提出来的想法是靠谱一些。我们需要这样的人，这样也是在我们的行业当中是不可或缺。但是问题是这是可遇而不可求，你也许有机会跟一个靠谱的资深产品经理一起工作，但是也许不是这样的。而且即使有这样的人在团队当中，这么长时间下来我发现他不可能一直对下去，这次可能是OK，但是过一段时间在另外一个功能点，他的洞察力不一定靠谱了。这个其实是我们的现状决定的。

现在互联网行业基本红利期结束了，好摘的果子基本摘掉了，剩下都是难啃的工作，剩下都是比较难的工作，有很多不确定性，到底有哪些路可以走通，其实谁都说不清楚，这个也是我们面临的很大挑战。

我们经常听到VUCA时代，说的就是这个，我们这个时代瞬息万变，不确定性非常强，不管是在各个业务领域，基本上都是这样：

V（Volatility）、U（Uncertainty）、C（Complexity）、A（Ambiguity）

创新面临最大的挑战就是不确定性，我们面临很多路，但是没有办法搞清楚哪一路真的可以走通，这个创新面临的最大不确定性，但是好消息是敏捷最大的长处就是应对不确定性。

二、产品需要敏捷思维

敏捷应对不确定性的方式

我们工作中两种不同的思维方式或者工作方式，一种是预测式的过程，另外一种是经验式的过程。

预测式过程就是传统的这种做事模式。我们觉得要把这件事情做成，就意味着一开始什么都要做对，什么都要想对，这种工作模式一开始花大量的时间和精力希望在一开始什么都做对，什么都要靠谱，常常事与愿违，就是这种不确定性。这个会导致团队以为快接近目标的时候，才发现这个不是我们去的方向，赶紧换方向，可能是另外一个目标。这个时候你调整方向会花大量的代价。可能接近调整目标了以后，其实发现目标还在另外的地方，又要再做调整。很多团队死在调整路上，你根本没有为不确定性做准备。

敏捷方式就经验式的过程，它的方式是什么？假定没有办法在一开始就得到所有需要的信息，从而没有办法什么都做对，这种前提下就不指望我们一开始做的是最正确的决定，我们先基于现有的信息先做靠谱的决定，然后往前走两步，走两步以后，这个时候有新的信息进来，我再基于新的信息做更加靠谱的决定，再往前走两一步。这样不断往前走，新的信息不断进来，不断修正方向，反而更好，更快达到我们的目标，这个是敏捷应对不确定性的方式。
​

打破确定性思维

平时我们怎么把洗澡水调到合适的温度？水头没有刻度，我没有办法去调，怎么办？难道就没有办法洗澡，我们就试，我们先拧开再说，要不断的调整，不了多久就调到合适的温度这就是所谓经验式的过程，敏捷应对不确定性的方式。

我们必须打破不确定性思维，我们希望从确定性思维向右边转变。这个过程当中，很多团队不敢轻易尝试，因为失败了就要背锅，这种环境是不可能有什么创新动力在，我们必须转变以最小成本快速试错。

关键在于，不确定性环境下要试错，但是要想成功有两个关键词儿，第一是最小成本，第二是快速，这两个缺一不可。

①-所以我们需要从不愿意轻易尝试，极力避免失败，转变为以最小成本快速试错。

②-追求大而详尽的计划转变为迭代式小规模计划。

大而详尽计划没有意义，没有过不了多久情况变得不一样，你原来想跑的东西没有办法试用。

③-追求完整、详细的需求文档转变为需求渐进明晰，切分小粒度。

在这个过程中，你花大量时间到写需求文档，很多时间都浪费掉了。我们期望方式是需求渐进明细，远的需求按照优先级来排好，很快马上要做的需求，最近一两周做的需求把它仔细细化可以开始开发，更加远的需求允许一定程度的模糊性或者是粗粒度，这样更加容易应对变化。

④-对范围、时间、质量毫无差别的坚守转变为坚守时间、质量、范围可协商。

举个例子：

老板把你叫到办公室跟你说，这些需求某一天全都要，保质保量。这个意味着范围、时间、质量全部限死了，你在这个过程没有什么调整余地，这些需求在那个时间点要保质保量全部上，实际当中我们发现在不确定环境下，这个其实相当难做到，大家都会硬头皮做。这个时候问开发能不能实现，开发说压力太大了，但是不行，老板要，你必须做到，996、247你随便选。

开发同学面临这种状况会怎么选，可见都弄上去，你要的功能，要的界面这些都弄上，但是不好见的地方不好意思要做很多的妥协，各种临时的解决方案都在里面了，代码看上去一团糟，接手的时候很难在这个基础做开发。因为你已经把时间卡在那儿了，我们真的要这样吗？

我们回过来看一下：时间、质量、范围。

时间能不能妥协？通常不能妥协。因为毕竟很多东西是要时效性，比如说双十一活动和6.18活动，时间不妥协。

质量能不能妥协？质量当然不能妥协了。这个是我们的责任，我们有责任有义务保证质量把我们的产品功能奉献给客户，服务奉献给客户。

我们的范围能不能妥协？实际上是可以的。我们再把老板交过来一大包需求拿过来，仔细切小看看，你会发现他们优先级度是不一样，有些东西可以往后放一放，这个时候会发现很多协调、讨价还价的余地。

也就是说范围应该可以接受，这个是天然决定，你要切开小粒度，必须切下，切开，然后再说这个重要，还是那个重要，这个先做，那个先做，这个时候才有讨论余地。

⑤—精确的进度把控及对任何便利的追究，到接受意外变化并以最小的代价快响应。

“构建-衡量-学习”循环

在精益创业里面，所有构建、衡量、学习就是来自于精益创业，一开始有想法，然后快速形成开发，形成上线，然后可以收集到用户的反馈，基于用户的反馈，用户的数据分析出来得到和验证我们的路子，这个路子是不是走的通，是不是用户需要，然后形成新的想法再进一步实现，这个过程就是“构建—衡量—学习”我们以快速试错成本的一个方法。

探索创新方式的学习循环

产品方向搞清楚了，我们在后面需要持续推动产品的增长，我们在局部不断做这种优化，所以后面优化的思路完全是一样，它来自于增长黑客的思路。

可以在团队成立专门增长团队，有了新的想法开始排优先级，觉得靠谱就赶快做出来，上线验证。我们只做验证我们想法需求最小集，只要验证我们的想法，甚至不开发都可以，很多时候不开发，做一个假的界面，背后是人工在弄，就没有开发现成的系统，只要验证我们的想法就足够了。快速评估、学习里面的验证思路，然后形成新的想法。

未完，下期继续
to be continue......