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

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

导语：

通常咱们想到产品创新，会以为这个是产品经理的事，是产品经理应该关心的，咱们研发团队好像通常关注比较少。根据我本身的经验我发如今创新上面很是强的团队，一般研发团队有很是深的参与度，并且对整个创新过程的支撑是很是强。

敏捷思惟在创新过程其实也可以扮演很关键的角色，接下来我结合本身的工做经历跟你们分享一下，在产品创新过程中如何作到敏捷思想和敏捷实践起到助推产品创新的效果。

1、产品创新面临的挑战

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

​

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

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

如今互联网行业基本红利期结束了，好摘的果子基本摘掉了，剩下都是难啃的工做，剩下都是比较难的工做，有不少不肯定性，到底有哪些路能够走通，其实谁都说不清楚，这个也是咱们面临的很大挑战。

咱们常常听到VUCA时代，说的就是这个，咱们这个时代瞬息万变，不肯定性很是强，无论是在各个业务领域，基本上都是这样：

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

创新面临最大的挑战就是不肯定性，咱们面临不少路，可是没有办法搞清楚哪一路真的能够走通，这个创新面临的最大不肯定性，可是好消息是敏捷最大的长处就是应对不肯定性。

2、产品须要敏捷思惟

敏捷应对不肯定性的方式

咱们工做中两种不一样的思惟方式或者工做方式，一种是预测式的过程，另一种是经验式的过程。

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

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

打破肯定性思惟

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

咱们必须打破不肯定性思惟，咱们但愿从肯定性思惟向右边转变。这个过程中，不少团队不敢轻易尝试，由于失败了就要背锅，这种环境是不可能有什么创新动力在，咱们必须转变以最小成本快速试错。

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

①-因此咱们须要从不肯意轻易尝试，极力避免失败，转变为以最小成本快速试错。

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

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

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

在这个过程当中，你花大量时间到写需求文档，不少时间都浪费掉了。咱们指望方式是需求渐进明细，远的需求按照优先级来排好，很快立刻要作的需求，最近一两周作的需求把它仔细细化能够开始开发，更加远的需求容许必定程度的模糊性或者是粗粒度，这样更加容易应对变化。

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

举个例子：

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

开发同窗面临这种情况会怎么选，可见都弄上去，你要的功能，要的界面这些都弄上，可是很差见的地方很差意思要作不少的妥协，各类临时的解决方案都在里面了，代码看上去一团糟，接手的时候很难在这个基础作开发。由于你已经把时间卡在那儿了，咱们真的要这样吗？

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

时间能不能妥协？一般不能妥协。由于毕竟不少东西是要时效性，好比说双十一活动和6.18活动，时间不妥协。

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

咱们的范围能不能妥协？其实是能够的。咱们再把老板交过来一大包需求拿过来，仔细切小看看，你会发现他们优先级度是不同，有些东西能够日后放一放，这个时候会发现不少协调、讨价还价的余地。

也就是说范围应该能够接受，这个是自然决定，你要切开小粒度，必须切下，切开，而后再说这个重要，仍是那个重要，这个先作，那个先作，这个时候才有讨论余地。

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

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

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

探索创新方式的学习循环

产品方向搞清楚了，咱们在后面须要持续推进产品的增加，咱们在局部不断作这种优化，因此后面优化的思路彻底是同样，它来自于增加黑客的思路。

能够在团队成立专门增加团队，有了新的想法开始排优先级，以为靠谱就赶快作出来，上线验证。咱们只作验证咱们想法需求最小集，只要验证咱们的想法，甚至不开发均可以，不少时候不开发，作一个假的界面，背后是人工在弄，就没有开发现成的系统，只要验证咱们的想法就足够了。快速评估、学习里面的验证思路，而后造成新的想法。

3、创建低成本快速试错的工程能力

若是要支撑以前的以最小成本快速试错，咱们必须创建低成本快速试错的工程能力，这个实现不了，咱们很难实现最小成本快速试错。

例如

“团队一” 能够作到一周快速有五六次上线，

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

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

让创新置换快速运转

咱们有想法、快速实现上线，基于数据分析，而后造成新的想法，不断来进行循环。这个过程要作不少的事情，咱们要让创新的环快速运做，你们看各类各样的事情要作。这个须要不少人紧密配合，才能让环转起来。

在你的团队里面，转一圈要多久？一般以前参与比较好的团队，若是一个想法好比说一天开发，一天测试的想法，转一圈很是快，基本一天半就转完了，你有一个想法，产品同窗有一个想法立刻要验一下，这个很是重要，一天开发一天测试，两天半就够了，这个是很是快的。

若是把这个创新环比作成齿轮，咱们想让齿轮快速转起来，就须要加入润滑油，这个润滑油就是精益的实践。

跨职能自管理团队

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

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

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

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

微服务是高度类聚,咱们但愿增强交付为主的跨职能团队。

还有宽组织沟通协做机制，确保团队能够高效的运做。

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

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

领头羊 的模式：把领头羊管好就能够，领头羊走到哪里，其余羊就走到哪里。

这两种模式区别很是明显，咱们但愿团队能够高效进行产品创新，个人经验是下面的方式有利于团队创新。

缘由其实挺简单:

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

领头羊的方式 对指望高效创新的团队来说是很是须要的，咱们就是但愿有人站起来引领你们往前走，而不是拿着鞭子赶着你们往前走。

咱们须要激发和引领团队内在驱动力，但愿团队有掌控感、成就感，同时有明确的目标和知足感。若是但愿这个团队有这种感觉，咱们让团队本身来造成这种组织，制定团队运做的规则来推进团队的运行，让他们来管理。

透明和信任也是很重要，咱们把信息透明起来，有透明才有机会带来信任。没有透明信任就无从谈起。一旦没有信任，团队间协做成本很是高，由于你们都忙着自我保护。

小批量快速反馈跟交付

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

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

快速需求探索和规划

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

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

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

② 整个过程是可视化 ，一旦可视化沟通效率就增长了不少。

工做透明化

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

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

持续交付流水线

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

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

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

持续改进

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

4、总结

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

文章来源：Worktile敏捷博客

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

文章转载请注明出处。