京东精益敏捷教练分享：敏捷助力产品创新

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

导语：

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

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

一、产品创新面临的挑战

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

​

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

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

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

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

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

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

二、产品需要敏捷思维

敏捷应对不确定性的方式

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

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

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

打破确定性思维

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

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

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

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

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

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

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

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

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

举个例子：

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

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

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

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

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

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

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

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

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

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

探索创新方式的学习循环

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

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

三、建立低成本快速试错的工程能力

如果要支撑之前的以最小成本快速试错，我们必须建立低成本快速试错的工程能力，这个实现不了，我们很难实现最小成本快速试错。

例如

“团队一” 可以做到一周快速有五六次上线，

“团队二” 可能一个月就试一两次

“团队二”一个月做的尝试试错数量都比不上“团队一”一周做的，如果我们竞争对手能做的这么快，我们的危机就来了。他一个月尝试试错次数是我们一年的量，这个意味着他可以比你更早找到正确的方向，我们的生存危机就很大了，所以我们必须建立低成本快速试错的能力。

让创新置换快速运转

我们有想法、快速实现上线，基于数据分析，然后形成新的想法，不断来进行循环。这个过程要做很多的事情，我们要让创新的环快速运作，大家看各种各样的事情要做。这个需要很多人紧密配合，才能让环转起来。

在你的团队里面，转一圈要多久？通常之前参与比较好的团队，如果一个想法比如说一天开发，一天测试的想法，转一圈非常快，基本一天半就转完了，你有一个想法，产品同学有一个想法马上要验一下，这个非常重要，一天开发一天测试，两天半就够了，这个是非常快的。

如果把这个创新环比做成齿轮，我们想让齿轮快速转起来，就需要加入润滑油，这个润滑油就是精益的实践。

跨职能自管理团队

我们要把我们的这种创新团队组织起来，这个创新团队跟之前不一样，它必须是跨职能自管理团队，首先我们要坚持的是围绕价值流组织跨职能团队，下图是电商业务价值流，所谓价值流就是通过一系列的过程能够提供用户有价值的产品。这个过程是企业的命脉，如果这个过程出问题，那么企业就有了问题。围绕这个过程顺利进行，我们必须下面有很多的系统支持，就是有系统群。每一个系统群有相应的研发价值，研发团队确保这个系统正常运作，如果有新的需求快速迭代，快速上线做尝试，这是首先要做到的。

在团队划分的时候不要对抗康威定律。康威定律说的是软件系统组织和架构有一一对应的关系，如果没有对应就意味着有更高的沟通协作成本。

团队边界和系统的边界重合是沟通成本最小，我的团队需要按照这种方式来组织。这个意味着我们的系统要经过比较合理的划分，使得系统间高度结耦，只保留最小程度的依赖，消除不必要的依赖，这种情况下每个系统可能对应相应的团队。这种情况下团队之间的跨团队沟通协作成本最低，沟通协作的成本在这个过程会消除很多。

我们需要打破巨石架构，采用微服务的形式。

微服务是高度类聚,我们希望加强交付为主的跨职能团队。

还有宽组织沟通协作机制，确保团队可以高效的运作。

管理风格是非常关键一点，这里面象征了两种管理风格，一种是牧羊犬，另外一种是领头羊。

牧羊犬 的模式：走偏了赶回来，模式寿命比较短。

领头羊 的模式：把领头羊管好就可以，领头羊走到哪里，其他羊就走到哪里。

这两种模式区别非常明显，我们希望团队可以高效进行产品创新，我的经验是下面的方式有利于团队创新。

原因其实挺简单:

牧羊犬的方式 要想运作起来，必须制定复杂的流程，各种检查机制，各种文档，确保整个团队能够运作起来。但是问题是，对于需要创造力和反复试错的任务，无法通过简单的遵循一套规则来实现。

领头羊的方式 对期望高效创新的团队来讲是非常需要的，我们就是希望有人站起来引领大家往前走，而不是拿着鞭子赶着大家往前走。

我们需要激发和引领团队内在驱动力，希望团队有掌控感、成就感，同时有明确的目标和满足感。如果希望这个团队有这种感受，我们让团队自己来形成这种组织，制定团队运作的规则来推动团队的运行，让他们来管理。

透明和信任也是很重要，我们把信息透明起来，有透明才有机会带来信任。没有透明信任就无从谈起。一旦没有信任，团队间协作成本非常高，因为大家都忙着自我保护。

小批量快速反馈跟交付

刚才提了研发的价值，我们从需求一直到有价值功能，整个过程就是研发价值流，这个过程就是价值实现的过程。这个过程中我们一般都是小计划，短迭代，小批量的方式来运作。我们不做大的计划，我们可以有长期路线图，但是只聚焦在短期要做的事情上，批量切小，把需求切小，每一次聚焦我们在做事情，快速完成再做下面的事情。

小批量就是快速得反馈，这个事情一个月才能做完，如果作为一个月的需求来看，你靠近一个月才有可见的东西出来，才有测试介入，才能告诉开发，这个地方没有作对。如果切小就有机会分析上线，本来一个月要上线，我们切了四批，第一周结束的时候就可以上线，第二批在第二周结束就可以上线了，有些时候有些功能早上线一天，生存机率就大很多。还有如果是大包东西没有拆开，要做就是一开始一批全部开始做，把需求切小了很重要的一点，就是减少浪费了。

快速需求探索和规划

其实需求跟规划、探索是挺花时间的一个过程，而且你会发现这个过程当中，如何充分发挥团队的这种智慧，其实是很大的挑战。我们知道有很多人有不错的想法，如果把大家合到一起来就会发现讨论的过程，大家做出来的决策趋于平庸化，我们采用了一些群策群力头脑风暴的方式，我们叫做需求探索工作坊，模式就是大家群体一起头脑风暴。

但是为了让大家充分发挥每个人聪明才智，这个里面有一些方法和技巧：

① 引导的技巧，保证团队能够在过程进行高效的讨论，不跑题，不被某些人主导而压制其他人，主持人角色很重要。

② 整个过程是可视化 ，一旦可视化沟通效率就增加了很多。

工作透明化

这是我们办公场所，其实放眼望去，这么团队在忙，他们是一个团队，他们做一些重要的事情，但是没有可视化是搞不清楚。也许每个人专注于自己那一块，到底卡在什么地方？哪些地方需要大家一起协商讨论介入，这个过程是看不出来。没有过程的可视化就没有办法做优化的工作，或者是协调共同的工作，就不会发生了。所以我们需要把价值流动过程可视化出来，我们就有机会做更多的事情。

可视化什么？就是价值流动过程，包括我们整个待开发的队列，工作项和各种各样问题和阻碍，甚至是人力资源分配都是可视化。

持续交付流水线

流水线包括两部分，一部分是持续集成，另外一部分是持续部署。

持续集成有一些规则，比如说尽可能频繁集成，及时提交代码等等

持续部署有一些要求，让整个过程高效运作起来，从代码的集成，编译打包、测试，单元测试，功能测试和接口测试到最后部署等等都自动化起来，减少尽量人工干预。

持续改进

我所经历过的高效创新团队里面，没有一个团队是一步成功的，都是经过常年不断的改进才实现快速高效的交付能力。回顾会是个好东西，就是定期开回顾会，认真落实大家的想法，落实一些改进的项。时间长了肯定有效果。

四、总结

最后想说，这整个过程我最有感触，我们想要团队不断提升，根本聚焦是对人的改变。我们发现不管是对敏捷而言，还是精益也好，本质就是思维的转变，人的思维转变，做事方式的转变。一旦人变了，做事方式和态度有所变化，做事就不一样了。

文章来源：Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。