产品探索驱动的敏捷开发

Posted 2021-04-25 守破离的轮回

注：本文内容曾经在“2018敏捷之旅杭州站”上做过公开分享，由于数据安全的原因，部分内容有删减

在VUCA时代，产品的需求变得越来越难以明确，竞争的激烈导致行业细分越来越专业化，客户对产品体验的要求也越来越苛刻。在常见的产品研发管理实践中，不论使用的scrum还是kanban，往往关注的是产品研发和交付的敏捷，而忽视了产品需求来源这个关键的问题。只有把需求产出的过程融合到整个产品开发的框架里，完成产品需求探索敏捷和产品研发交付敏捷的结合才能形成完整的价值生产闭环，以让组织获得更大的竞争优势。

这里主要是介绍阿里新零售业务场景下产品探索驱动的敏捷开发实践，从问题出发，结合产品共创的理论模型和完整的共创性项目管理框架，让大家对阿里新零售的敏捷项目管理有一个全貌的了解，供大家参考。

敏捷开发的特点

说到“产品探索驱动的敏捷开发”，那我们先想想什么是敏捷开发、敏捷开发有什么特点。敏捷开发这个说法是相对于传统的“瀑布”开发模式来说的，那敏捷开发和瀑布式的开发最主要的不同是什么呢？

敏捷和瀑布

有一个最常见的观点就是，敏捷开发比传统开发速度更快，开发的节奏更快了，产品的交付上线更快了，这样我们对外界环境变化的反应也就更快了。就像中国武功里常说的：“天下武功唯快不破”。为什么我们希望软件开发能变得更快呢？因为人类的社会正在进入VUCA时代，我们的社会环境正在变得越来越多变、不确定、复杂和模糊，我们的产品正式要适应VUCA时代的这些挑战，所以必须要具备更快的反应速度，提高敏捷性。那么我的问题又来了，是不是我们的研发变得更快了，我们就一定能取得业务上的成功呢？

显然不是，我们的开发变得更快了并不一定能帮我们取得业务上的成功。有一句话叫做“一开始就错了方向，跑得越快离终点越远”。谷歌的google+，阿里的来往，在我们行业有太多这样的例子。

为什么要做产品探索

我们可以这样画一个象限图，纵坐标是正确的方法，横坐标是正确的产品。如果方法和产品都不对，那结果就一定是垃圾；如果方法正确，产品选错了，那结果一定是业务上的失败；如果产品选对了，但是方法有问题，有可能你最终还是交付了价值，但是你会陷入维护的噩梦，这个事情是不可持续的；当只有方法和产品方向都对了，最终你才可能得到成功的产品。

我们常见的敏捷框架，不管是Scrum还是Kanban，更多的都是关注在更快更早的交付产品，也就是聚焦在正确的方法上，但至于怎么样找到正确的产品方向，却一直是被忽视的领域。

所以我们说敏捷，我们认为就是要建立两种能力，一种是“更快更早交付产品的能力”，我们称之为开发交付的敏捷，还有一种能力就是“更灵活响应变化，找对产品方向的能力”，我们称之为产品探索的敏捷，只有具备了这两种敏捷的能力，才能说我们达到了全链路的敏捷。而其中产品探索的敏捷是经常被我们忽视的。

说到产品探索的工作容易被忽视，我们就不得不提到PO这个角色（在有的组织里叫产品经理或PD）。PO主要的职责有两个部分的工作，一个是产品交付相关的，比如给开发团队澄清需求、拆分需求、规划和跟进迭代的计划；第二个部分是产品探索的，比如规划产品方向、澄清产品价值、收集客户反馈等等（在需求源头的事）。产品交付类的工作属于HOW的部分，产品探索的部分属于WHAT。我们经常发现在一些组织里，PO花在产品交付上的时间比例非常高，很多PO花在交付上的时间往往有80%左右，甚至有些技术转PO的会高达90%以上。这个其实是非常不健康的情况，按照我们对PO的期望，他应该把80%的时间花费在产品探索上，产品交付只需要花20%的时间，产品交付的责任PO可以让开发团队一起来分担。

新零售怎么做产品探索

在阿里新零售我们的产品探索实践叫“产品共创”。

产品共创

实际工作中，我们经常会看到PO去走访客户，那走访一趟客户回来就算完成了共创吗？显然没有那么简单。我们把和客户在一起的活动分成了三个层次：

• 最常见的一个层次就是“客户访谈”，访谈很好理解，就是听取客户声音，就是听听客户是怎么看、怎么想的、有什么反馈，客户访谈之后我们能得到一个信息的总结，比如客户对什么满意，什么不满意，有什么痛点等等；

• 往上一个层次是“客户调研”，客户调研和客户访谈有一个比较大的区别是访谈是不设引导方向的，调研其实是有一个预设的方向的，调研一般是带着一个特定的疑问，希望客户在一个问题上提供更多的信息。调研的结果是我们能得到我们的工作方向，就是说调研之后我们就形成一个结论，什么该做，什么不该做，找到我们的产品方向；

• 那共创就是在访谈、调研的基础上再前进一大步，共创的结果是要直接形成我们的产品方案，或者也可以理解是要直接得到需求。

产品共创模型

为了把产品共创说明白，来我们一起看一下这个产品共创的理论模型，我们把产品共创的过程分解为5个步骤。

• 第一个步骤叫“感同身受”，这个意思就是我们要真正进入到客户的实际场景中去，去体验在实际场景中客户真正的痛点是什么，真正在意的是什么，你不去体验，你就永远没有感觉，比如说设计一个功能让线下门店的导购打开钉钉就有一个二维码，就可以让到店的顾客扫码加会员，但你到了客户现场才发现，很多门店里是不允许导购在上班时间用手机的。

• 第二步叫“定义问题”，在第一步里我们体会到了客户的痛点我们是不是就马上去要给他一个东西去解决他的问题呢？不是这样的，这个时候我们要开始独立思考了，我们首先要定义这个问题，这个问题的本质是什么？不能简单的按照客户的要求直接给出产品。举个大家非常熟悉的例子，比如客户说我要一匹跑得更快的马，那我们真的要去找一匹汗血宝马给他吗？当然不行，这个时候我们要独立思考一下，重新定义一下问题，客户的问题应该是是希望更快的出行方式，这样问题从找马到了出行方式了，那这样我们的思维就一下子打开了，也不会被客户带到死胡同里了。

• 第三步是“形成概念”，有了重新定义的问题，这个时候就能对问题开始构建解决方案的模型了，在一个什么边界的范围内，通过什么手段，解决客户的什么问题，这个阶段，基本的产品方案就形成了。

• 第四步是“制作原型”，到了这个阶段才是真正设计产品原型了，需要把上一步的产品方案给具化出来，设计产品原型是PO最基本的工作了，这里就不赘述了。

• 第五步是“验证效果”，这步就很重要了，原型出来后不是马上投入开发，而是要把原型拿到客户现场来，和客户一起检验这个产品是否是能真的解决客户的问题，是否能产生真正的价值。这里需要再补充一个小环，在使用产品原型图和客户完成了共创之后，产品可能就进入了开发，在开发完成之后不能着急着上线，这时候需要把可用的产品再拿到客户这里来，再次让客户来验证一下，看看真实的产品是否还是能得到客户的认同。

在这样一个环的共创模型中，可以看到第1步和第5步是一定需要和我们的客户在一起的，2、3、4这三步是需要我们的独立思考的。

共创三部曲

模型可能比较枯燥，我们来看看在实际的工作中，我们是怎么样来操作产品共创的。在新零售产品线上，我们把共创分成三个阶段，简称为共创3步曲。第一步是“原型共创”，第二步是“产品共创”，第三步是“T+14反馈”。

我们按照这三个阶段，一个一个来看我们是怎么做的。

1. 原型共创

第一个阶段是“原型共创”，原型共创，按名字就可以理解，就是和客户一起基于产品原型的共创，这个共创的结果就是要得到一个客户认可的产品原型，在模拟的情况下证明产品的价值。这个阶段，PO需要拿着产品原型设计稿，和客户一起讨论并确认产品方案。

在原型共创的时候有一个点非常关键，这个是我们来判断共创的产品需求是否靠谱的一个判断依据，就是“超出预期”。超出预期的意思就是我们在原型共创的产品原型必须要能带给客户超出预期的感觉。如果不能给客户带来超出预期的感觉，这个就要小心了，这个产品方案很可能就是不靠谱的。

2. 产品共创

第二个阶段是“产品共创”，产品共创就是在产品开发完成之后，正式上线之前，我们拿产品到客户这里让他在正式产品上来验证业务价值的过程。在一般敏捷的做法里，开发完成的东西，我们就会希望能尽快能交付到客户的手里收集反馈，但有没有想过，会有两个问题：一个是远离客户，你能拿到的只能是一些冷冰冰的数据反馈，你很难得到有体感的用户直接反馈；二个其实线上数据的反馈还是太慢，等你收集到足够让你分析的数据的时候可能都过了好几天了，这个时候如果有问题，其实已经实际的伤害了我们的客户了。所以，我们需要在产品规模化上线之前要来到我们的客户这里，邀请共创客户来体验我们的产品，看是不是能在真实场景里解决实际问题。

在产品共创的过程中有几个点需要注意的：一个是选择共创的客户，之前的原型共创的客户是需要安排产品共创的，但是也需要找一些没有参加原型共创的客户，看看第一次看到这个新功能的客户是怎么反应的。二个就是人在现场，但是不对客户的使用做引导，不要讲这个新功能该怎么操作，让他自己直接去试用，看看凭直观的理解，客户会怎么操作，这个和功能设计的易用性关系非常大，你的一个新功能，到了客户手上，很有可能就不是按照你设想的那样去操作的，怎么提供最直观傻瓜式的操作体验，就是衡量你产品好坏的一个标准之一了。

3. T+14反馈

通过了第二阶段的“产品共创”，没有问题的话，那你就能正式批量上线了。第三阶段就是“T+14反馈”了。T+14反馈的意思是在正式上线14天之后需要一个这个功能的线上数据报告，这个报告基本就是用来证明你的功能是否取得成功的一个证明了，这个报告是一个以数据展示为主的报告，需要有目标和现状数据的对比，比如UV、PV、转化率、跳出率等等。或者从数据中发现了什么关键的结论，或者新的需求需要加在后续的迭代中完成的。

产品探索驱动的敏捷开发

现在我们一起捋一捋在整个研发流程中共创三部曲的位置：在新零售产品线，一个完整的迭代是先从主题输入开始，主题就是我们的产品方向或叫目标方向。有了这个主题的输入，PO同学就要去到客户那边寻找产品机会，并且完成产品原型共创；原型共创完成之后会有一个需求准入评审，这个需求准入评审主要就是评审原型共创的质量，并且达成各个敏捷团队之间的需求拉通；然后就正式进入了研发阶段；在下一步是灰度上线；灰度上线了之后就进入了共创三部曲的第二步：产品共创；通过白名单选择共创客户，完成了产品共创后又会有一个发布评审，发布评审的目的就是验证产品共创的质量，评估收集到的反馈，决定产品是否可以全量发布；最后是14天之后的一个T+14反馈报告。

这是一个完整迭代的整个流程，可以看到，在整个流程中，共创三部曲的位置是非常重要的，可以说是整个迭代流程的主心骨。开发的前提是共创（原型共创），开发的产出是为了做产品共创，产品开发的价值是靠T+14的数据来证明。这个模型我们就称之为产品探索驱动的敏捷开发。

可以看到，我们一般称之为开发迭代（或sprint）的阶段是整个流程中的一个部分，在我们部门，中间的这个开发的迭代一般是两周的时间，但是整个产品周期大概需要7-8周的时间。

那现在我们再回到我们的敏捷框架中来，scrum和kanban，如果我们在scrum和看板的基础上增加产品共创三部曲就相当于增加了三个产品共创的反馈节点，目的是通过直面客户，以得到更快更直接的用户反馈，进而实现产品探索的敏捷。在看板的框架上也是类似的，通过增加产品反馈节点，以得到更快更多的反馈，从而达到产品探索的敏捷。

新零售项目管理框架

这个就是我们新零售的整个项目管理大图，上面相对内容比较多，简单来看，这个框架分为上下两层，上面可以理解是产品级别的层面，下一层是特性团队的层面，在多个敏捷团队上，我们拉齐了各个团队的需求准入和需求验收评审的节奏，并在需求准入评审和需求验收评审的会议上完成了对产品共创质量的把控，也就是说我们把整个产品共创和产品共创的质量检查融入到了整个产品线的运作机制中来，从而保证了产品共创机制能够持续有效的执行下去。

产品共创要点总结

• 第一个是产品共创方法适用的领域，目前我们还是觉得这个方法在2B的业务领域里是比较适用的。首先2B的业务领域往往是非常复杂的，我们的PO其实往往并不是这个领域产品的真正用户，比如我们做零售行业的产品，但我们自己却没有在线下店里卖过货，我们怎么敢说我们已经比客户更了解他们的需求呢？比如电信产品，我们也没有在运营商的公司里真正运营过这么大的网络，我们真的比运营商更了解他们需要什么吗？而且2B的商家他们在有自己的痛点，他们更愿意花时间、投精力陪你一起来共创，C端的用户往往就很难；但是C端的产品怎么做类似的产品探索，这个以后有机会也可以和大家一起探索；

• 第二个是要实现产品探索的敏捷开发一定要建立真正意义上的特性团队，或者叫feature team。这里有一个误区，有的时候我们觉得把开发、测试、产品等跨职能的人组织在一起，好像就形成了一个特性团队，其实这里往往有很大的问题。把这些不同职能的人聚在一起就一定是feature team了吗？还有一个概念叫做项目组，这样的一个team和项目组有什么区别？这里就不展开讲项目组和特性团队的区别了，但有一点，一般项目组里不同角色的人的目标是不一致的，比如产品的目标一般是业务导向的，但是开发的目标很可能是交付导向的，这个时候大家对产品探索这个事情的理解就不一样了，开发同学这个时候就会希望需求早点订好了就不要再动了，这样开发效率才最高，但是产品探索的方式很容易带来需求的频繁变动，这样就不可避免带来团队内的冲突。所以，建立真正意义上的特性团队，团队里所有的角色都统一到业务目标上来，就非常必要了；

• 第三个对待产品探索的态度，拒绝拍脑袋需求，因为拍脑袋来的需求最容易，坐在办公室里，几个人一合计，一天可以产出一个月都做不完的需求，这样产出的东西可能最终有价值很少。我们有一个口头禅就是，“无共创、不产品”；

• 第四个是“最小闭环”，也称为MVP，一个新的功能，我们只从最小闭环开始做，产品探索不就是尝试嘛，哪有尝试时就下大注的？这个时候不要担心功能不全客户会不满意，只要是真的对客户有价值的功能，就算不完整，客户也是会非常兴奋的，如果真的是痛的厉害的地方，你的药就算只能治好一部分，那对客户来说也是灵丹妙药；

• 第五个要“数据说话”，产品探索的目的还是实现业务价值，以终为始，用数据说话才是最有效的检验产品探索效果的方法。每个新特性启动开发前都必须有目标，每个特性上线后都必须检查目标是否达成；

• 最后一个是“机制保障”，共创其实不是一个轻流程，这个流程对PO提出了巨大的挑战，怎么保障这个流程能够有效的运作下去，这个就需要可行的机制保障。我们建立了一套需求准入和需求验收的评审机制，这个是业务和产品老板直接主持的评审，通过这个方式保障共创机制的可靠运转；

---