阿里新零售战役项目如何实现持续价值交付

白凡

分享：洪永潮 董小华
编辑：白凡

讲师介绍：
洪永潮：阿里敏捷教练。我们有一个专门的敏捷教练的团队，我做天猫、淘宝，新零售，现在在这个项目是在天猫事业部的项目里面。
董小华：阿里巴巴天猫新零售技术部的PMO项目经理，我其实是开发出身的，转型做项目经理，最近是在带天猫新零售的一个比较大的战役项目，在这个项目当中跟永潮两个人合作。

洪永潮：我会先讲方法论跟理论这一部分。
今天大概分四部分：

• 背景
• 如何驱动持续价值交付
• 实施过程
• 小结

1. 背景

阿里巴巴马云从2016年提出新零售这个概念以后，现在国内新零售的风气是很足的，我们做的这个项目之前没有提过，在6月24日钉钉有一个发布会，提到智能打call的项目，大家可以看到在蛮多的网站上面阿里出了一个王炸，其实也就是这个项目，是同一个项目，这个项目是腾讯跟京东都有布局，这里面竞争是很激烈的。

第二个这个新零售之争提出来之后，像盒马这样的模式出来以后，我们真的不确定，接下来做成什么样子我们真的没有办法去预测、感知的，我们只能比竞争对手想办法更快以更低的价格来交付价值，这是一个业务的诉求，大家看到现在很多研发方式里面会涉及到瀑布流，这个对持续价值交付是反利，瀑布流在开发的时候尤其在前面分析的时候是埋坑的，是埋bug的过程，在后面的测试过程当中持续把bug逐渐消掉，前面的开发过程bug很多是很难交付出去的，我们希望我们产品的缺陷是持续有一个降低水位的过程，希望我们能够做到缺陷量持续保证低水位，这样我们就更容易接近持续发布这个状态。我们希望建立持续交付的管道，怎么样快速交付价值。

2. 驱动持续价值交付

第二个部分怎么样来驱动持续价值交付，我们会通过三个维度来讲。

首先希望我们的产品探索这一块做的更快，更快得到反馈。

第二部分希望我们的产品交付过程建立一个管道能够快速的交付出来我们的需求。

第三部分希望我们的团队也能够更快的响应这样的文化，来为我们上面两个产品探索和产品交付做支撑，其实这三个是在一起需要持续协作、改进，我今天主要讲产品探索跟产品交付。

2.1 产品探索-双钻模型⾼高效规划需求

产品探索会讲到一个双钻模型，我们这个项目是2B的项目，会有一些跟2B项目不一样的地方，我们提这个产品的时候希望去解决一个问题，我们已经定义了问题，这个问题用什么方法去解，跟谁来讨论，最后的方案是什么样子的对我们都不确定的，我们需要找到一个方法把我们的问题跟方案能够澄清，我们有哪些方法？

一开始会有产品的大图，一般产品立项我们都会有一个产品的目标，这个产品是怎么样的走向，作为公司产品经理这一层会去定我们产品的路径跟业务的流程，我们会根据某一个主题或者是某一个领域给他提一个问题，定专门的专项去奔这个主题去做。

我们会根据这个主题去画出我们这个主题相关的需求交付，这个交付画出来以后怎么办？是不是就开发，是不是就让我们的开发同学就把这个需求开发出来，这是一个方法，这个方法就会有问题，如果开发完了，交付给客户，客户说这不是我想要的怎么办？有两个问题，第一个我浪费了我的工作量，浪费了我开发同学的精力。

第二个对业务方来说他的反馈偏慢，我们会拿着交付稿直接到客户那边去，我们是2B的项目，所以会找天使用户，他会来跟我们一起共创，来交付的时候，他会跟我反馈这个就是我想要的，那个是我不想要的，这个是对我们第一次有这个快速的反馈，这是第一部分。

第二部分会跟我们的客户访谈调研，完全从客户的角度来，解决客户的问题。

这两个做完以后，我们的产品同学会收集到很多的反馈，这里面会做抽象，会根据我们的主题去确定我们这个主题里面的小目标，根据小目标再来看我们需要做什么，这个时候会拎出来我们要做的问题跟功能点，这个时候会重新回到我这些问题跟功能点能不能解决我客户的问题，或者是我们在做共创时候的问题。

这一块我们的同事会做很多的工作，他会去做分析、讨论，最后我们会有一个收敛和定义的过程。

我们会有四个小组，我们会有一个会，这个会里面会有一些需求，这个需求必须要跟客户共创过的，必须要有交付稿跟客户共创。输出，关于这一块也是我们产品的输入。输出，这是一个表格，看起来是需求的列表，这个列表看到有些需求会被踢掉，你这个需求是不能做到的，没有把你的需求说明白，我们通过这个表格，把关注点放到了客户身上。

接下来就相对简单了，一旦确定你的需求要做什么事情，就来把这个方案给定下来，这个方案对我们阿里同学相对简单，我们有很明确的业务场景，也有很明确的业务流程，也有明确的交付过程。

这个会涉及到淘宝和钉钉之间的协作，这里需要去明确我们这个流转的过程是怎么样流转的，我相信在座的公司里边大家做这个很容易，把这个定下来是不难的。

这个定下来以后，我们的方案已经出来了，我们的需求已经细化了，接下来把这个需求交给我们的开发同学去交付。

2.2 产品交付-建⽴立持续交付价值的管道

这个图不知道有没有人看到过。

最近看世界杯的时候比较多，到了晚上到酒吧里面喝酒，看世界杯，这个人他喝完酒以后，发现这个人的钥匙掉了，他就找，他就在这边去找，这个人看了好久，说你在这里找什么，已经看你找了很久，他说我在找我的钥匙，那个朋友说你找到了吗，他说没有，那你为什么在这里找，他说这里有光，我看得到，黑的地方我看不到，是不是这样子，如果亮的地方我们就能看到问题，黑的地方我们是看不到的，我们希望用光照亮问题所在，希望把我们所有的事情都能够完全可视化出来，让我们能够看到我们的现状、看到我们的交付过程。

在建立交付稿的时候，会把价值流可视化，上一位嘉宾讲到所有项目在开始的时候，第一个事情就是建立看板，把所有的价值可视化出来，我们再根据这个看板去度量，去拿反馈，去建立我们的文化，让看板里面每个流每一段能够很清晰的表明出来，这个是需求卡片，红色的是缺陷，这个是任务卡片，这个是我们的开发中心。

我们会定下来明确的流转规则，我们从设计到开发有规则，发布也有规则，设计也有规则，这个设计会说我这个卡片怎么样移到下一个阶段来，这个是很明确的，我们做这个目标是为了让价值更快的交付出来，我们希望价值能够顺畅的流动起来，怎么流动？在看板时间里面去讲到我们限制WIP来让我们的内行量减少，也就是我们的多任务能够减少，这样对我们每一个价值来说可以保证它尽快的完成，而不是有很多在过程中的需求不断的进来，这里边会有一个说法，我们希望能够关注快完成的需求，我们在看板里面是从右往左还是从左往右看？

我们需要从右往左看，我们关注的是让我们的价值更快的完成，我在前边被block，需要去看什么被block住了，我们希望在测试中只有一个需求被测试，不管怎么样这个需求被block，我们会停下来把这个稿定下来，我觉得这样的例子可能适合丰田这样的公司，在很多的企业比较有困难，可以根据实际情况限制我们的viper。

前面有了看板，那我们需要有一些工程的实践，比如说CRCD去驱动我们让我们更好的交付，今天只是一个Devops的专场，Devops阿里还做了很多的实践，我们专注是在交付价值。

2.3 团队支撑

我们的产品开发完我们还会做一轮产品共创，前面提到有一个原型一共创，我们把交付稿给到客户去看，这个是产品做好了以后，上线以后，我们会选择不低于三家企业去做实验，这里面有一个原则，很多的APP在用的时候，如果我是产品经理会去现场指导，告诉客户怎么用，我们希望的是在现场不要去引导他怎么做，这个反馈拿过来以后我们就可以看，前面用户说的国能是不是他很需要或者他是不是已经用了，我们要去做第二轮共创，这个对我们蛮重要的，决定了我们这个需求，这个产品做了以后能不能真正的规模化上线，这是第二次反馈。

这一轮是我们的产品同学会跟客户在一起到现场去验证，去用他的核心流程和前面提到的价值和场景，让用户给反馈，从易用性、易懂性、解决问题来做反馈，会根据这个反馈去做调整，这个项目需不需要做规模化推广，这个是我们项目上线前做用户的第二次反馈。

第三次反馈，在我们的需求上线以后，规模化以后，我们这边讲到T+14的业务反馈，一个场景有需求我们会有一个小目标，这个小目标会通过我们业务数据的反馈，某个页面访问了多少，流失率有多少会去定一个指标，这个指标定下来以后会在我们的需求上线14天以后来看数据，看情况到底怎么样子，这个图是我们某一个团队他会先去看我的数据，这个是整个大团队看我这个数据，我们可以看到产品同学对我们这一块的业务需要很熟悉。第二个，他对业务数据的反馈要很清晰，这里面也会看到对他的下一轮有支撑作用，如果他看到这个数据有被下载了，他会看一下为什么会这样，如果上去了，他也会去分析为什么会上去。

产品上线会有三次反馈，第一个是原型共创。第二个是产品共创。第三次是业务反馈。
我们还会建立一个持续价值管道，会去度量我们的效能目标，显示时间也好，质量也好，这些数据我们都会有一个完整度量体系来度量。
接下来会由董小华来讲关于这一块如何在团队里面怎么实施的，谢谢大家。

3. 持续价值交付的实施过程

董小华：大家可以看到我们分了三步第一个是做技术提效，第二个是组织提效，第三个是产品提效。

基于我们自己的基础和特点，技术提效的方法非常多，我们一直要用的方法研究，而且结合以前的成功方法，第一个我们选择先做技术提效，当我们的技术提效达到一定程度以后做组织提效，我们在做完技术提效完了以后，技术已经做的很好了，已经很快了，但是大家都在追求发布时间点，看着这个日子，大家都在加班加点完成这个日期，但是完成这个日期又怎么样，我们的目标达到了吗，大家不知道我们的目标到底在哪儿，基于这个点，把我们的形式变一变，希望大家去打破职能边界建立更好的团队向心力、凝聚力，让大家都关心业务目标，而不仅仅只是关注发布时间点。

做完这个以后，我们就做了第三步，第三步希望我们的需求是真正有价值的，而不是说PD坐在家里闭门造车，这样他们想出来的需求是YY，并不是解决用户的痛点，因为新零售是很新的领域，如何比对手跑的更快，这个需求是非常重要的，甚至决定你整个团队生死，这个是我们最重要的地方，基于这个点我们就做了一些尝试，在产品领域的探索，我们希望改变产品团队工作习惯，当时我们进行了共创，希望在我们的工作流程当中引入共创这个机制，使我们的产品探索快速从output到outcome的转变，什么叫autocode？我们以前的团队PD把产品给我们，技术开发团队上线，但实际上这样，你上线的功能不一定能够解决客户的痛点和需求，我们希望真正解决的是解决他的问题，给他带来了价值，产生了他的效果，这样才是真正的outcome，所以说我们希望有一个这样的转变。

3.1 技术提效：建⽴立持续价值交付管道

建立这个管道首先得有一个价值流转规则及度量规则，我们把每个需求拆成状态，默认的状态是待处理，这个状态你有了这个点，你就可以录入我们的系统，它就是待处理的状态，当我们开始迭代，我们会选择价值明确优先级更高的需求，这些需求会变成已选择的需求。第三个是设计中的状态，因为PD和UED交付设计和视觉设计师他们是需要进行交互和视觉设计的，当他们有了资源之后他们开始交互视觉设计的时候就把这个需求改成设计中的状态。

第四步，当开发同学有资源的时候，就把这个需求改成待开发的状态，这里还有前后端的区别，对于后端来说，可能我的需求明确了，交互以后就可以进行后端的开发设计工作，对于前端来说很多还是要依赖视觉稿的，我们的标准前端的视觉同学是把评审完成以后，才把这个需求做成待开发的状态。

最后开发中，当开发有资源介入的时候，才会进入开发中，待测试，当我们开发完成以后，我们那边有一个冒烟，一个需求开发完成以后需要有一个最基本的主流测试，这个就叫冒烟，冒烟通过，而且给整个团队演示你最好的产品，这个演示完成以后可以进行测试，测试以后就进行测试中，待发布，当我们的测试工作也完成了，项目组的验收也完成的时候，会叫待发布，为什么不能发布？就看PD的决策，当PD认为这个时机到了，可以发布了，就把这个状态改成已发布。

开发状态待开发和待发布，第二个就是统一选择和已发布，这两个度量标准主要是讲度量两个维度，开发周期时长是想度量开发的效率。交付周期时长，是我们团队的交付能力，整个流转规则是从左到右一直流转过去的，这个度量只是说看效能，你要跑得快，质量也是不可缺的，必须要保证你的质量是不断提升的。

看一个具体的物理看板设计，这个跟刚才永潮讲的看板是差不多的，刚开始是有一个需求池，待处理的需求就放在这个频道里面，后面就是设计中，待开发，有开发中甬道，开发中甬道根据具体的业务情况，有的是前后端，需求端，大家可以根据自己的实际情况来加实际甬道。还有一些对别的部门有一些依赖可以放在这里，这是需求卡片，这是任务卡片，当每个任务卡片完成以后，可以放到完成的甬道里面，当这个需求拆解出来，所有的团队都移到完成甬道以后，这个需求可以移到待测试，整个的需求或者是价值的流转，就是从左到右的。

这是电子看板，阿里的营销平台，黄色的部分就是刚才显示的状态，这里是需求卡片，需求卡片可以拆成任务卡片，这里还有一个缺陷卡片，我们在执行过程当中有一些bug，有一些线上的问题，对于这些问题我们也会纳入迭代中，去跟进，去解决，不是说快速跑就不管线上问题了，线上的问题也会一直来跟进。

这个是晨会，我相信很多人都在用这个时间，这个时间真的是很好的推荐，每天花10到15分钟就可以暴露你项目当中的问题，通过判断透明化。通过物理判断进行透明化，是一个很好的时间，通过物理判断来进行透明化大家都聚焦在这里，关注每一个任务完成的情况。

还有一个点就是按照优先级来拉动需求流转，不同的需求优先级是不同的，我们需要聚焦在价值更高的需求上面，希望让价值更高优先级更高的需求如何尽快到这个看板，而且这个看板的人，我相信大家都知道是拉动的机制，不是出一个才能进进来。看板还有一个原则，会限制数量，每一个甬道会限制你的数量，开发甬道是根据开发人员的数量，为什么要限制这个WIP？让整个队伍不会出现跟杂乱的问题，你这个甬道比如说限制2，当这个地方太多了，也是不能进来的，通过看板能够快速的发现你这个过程当中里面的问题快速改进。

交付周期、开发周期都是在不断的变短，有效bug数也是在不断的减少。
这是一个内建质量对比，蓝色线是存量bug，红色线是每天新建出来的bug，绿色是每天解决掉的bug数量，这有一个分界线，大家可以看到，从这个点就是项目评测的时间点，每天大量爆发bug，这个持续的时间非常长，项目周期以及结果大家心里都是没有底的，当执行敏捷以后，这个跟永潮前面讲的是差不多的，小批量产生bug，小批量的快速解决，这个存量bug是一个比较平稳的线，这里还是有一个小量的高峰，这是因为当时我们第一次测试，有些需求还是出现了需求比较高的bug，但还是比以前有改进的。

3.2 组织提效：构建全功能的特性团队

最上面是一个项目总体目标，根据这个目标进行团队的拆分，每个团队会有它自己的目标，有些团队竖向的团队，有些横向支撑的团队，这些都是不可避免的，不可能做到全部都是竖向的，横向的支撑也是必要的，需要有一个项目的总体规划，需要结合你的总体目标和你项目的总体规划来推你各个小团队具体的实践过程。

根据业务目标来组建全功能团队是怎么组建的。
针对目标1，我们有各个角色，产品运营、测试等等各个角色，我们在阿里巴巴BU是一个很大的部门，这个团队有的角色，比如说产品来自一个第一个BU，交付可能来自于第二个BU，真正的是跨BU、跨角色全功能的团队。

看板演进也是有一个过程的，新增加了两部分，第一个是产品运营。第二个是待跟进事项，为什么要增加这一部分？当我们组建了全功能团队以后，我们的团队里面是融合了所有的角色，之前的团队都是技术团队，技术的角色，现在也包括了运营，所以我们希望把他们运营的工作也在看板上进行透出，这样给大家带来的影响是什么？我们不仅关注交付链路，也关注产品的运营情况，我们希望把运营结果的数据作为复盘的出路，全链路能够看到真正产品的效果。

待跟进，我们希望明确团队里面各个角色他需要跟进的事情，每个事情的责任人是谁，完成时间是什么，都把它透明化出来，这样每天开晨会的时候，很快就可以推动事情的解决。
我们拆了团队，我们其实也是一个大的项目或者是大兵团，小团队可以为你的小目标快速去跑，但是大军团作战还是要有一个节奏感，我们根据各个决策去有一个时间板，什么时候做主题输入，什么时候做产品设计，什么时候做产品对焦，各个时间各司其职。

3.3 产品提效：建立可持续的价值交付

我们希望引入共创这个机制来达到我们的目的，如何引入共创。

第一步，希望大家一起去到客户那边跟客户进行需求调研，根据客户的诉求进行产品的抽象设计，我们不希望产品同学用户说什么，我们就做什么，他需要做思考，基于用户的痛点有一个想法设计出产品，当他设计出来以后，在我们这边是一个交付稿，有了交付稿之后去进行原型共创，拿着这个交付稿去跟客户商量看这个交付稿能不能实现你当时的痛点和问题，如果客户说没有达到我的理想功能，可能就会现场提出问题，这样我们的同学可以快速进行改，当天就能改好，当天可以进行确认，快速修改，快速确认，确认好了以后，这一个就可以完成了，不像以前你想出来直接做，要经过半天的开发过程，这个时候已经很晚了，我们希望通过原型共创的过程得到反馈。当原型共创完成以后，会拿着上线功能进行产品共创，不告诉客户怎么用的情况下看看客户怎么用，如果不会用，说明我们的设计有问题，如果客户用了觉得也不过如此，也是有问题的，如果客户用了以后，客户很兴奋，出钱我也要用，那你是真的做到比较满意了，经过这些以后，能够带来什么好处？

第一个我们所有的需求都是来自于客户痛点的，杜绝YY。
第二个，在这个过程当中两步共创能够快速验证和快速改进，是一个短反馈的过程，让我们可以匹配更快，更快的改进。
第三步，共创过程是所有角色都参加的，可以更直观的理解用户理解为什么做，当他理解为什么这样做，当他参与进来了，增加参与感和成就感。我们希望通过这个来提升团队的凝聚力和产品的有效性。
在推共创的过程当中，验证流程与工具，我们刚开始会有一个原型共创，在共创完成以后会有一个需求准入评审，这个是项目级最大的老板来把控的，他会看你的共创是不是足够有价值，是不是解决你的用户痛点，如果真的有价值才会进入产品开发阶段，如果真的是YY，如果你的设计共创得不到认可的，是不会进入到产品开发过程的。当产品开发完以后会有一个持续发展的过程中，这个我就不赘述了，发布完以后，在上线的过程当中跟用户进行产品共创，共创完了以后也需要共创报告，这个共创报告结合T+14，这个功能上线14天左右会有一个线上数据的测试过程，除了看用户现场的反馈之外，我们还要看大量的线上数据，来看这个需求是不是解决问题，如果验收评审不通过，有些做的不好是不会得到规模推广的，包括各个需求可视化，哪个步骤会有阻塞，都可以很明显的看到。

4. 总结

我们为什么要引入持续价值交付？我们要在巨大的不确定下要快速拿到业务结果。

我们如何去做，我们通过建立以端到端的持续价值交付管道的方式来达到的。
建立管到以后如何去持续改进？我们是通过建立有效的度量机制。
有了度量机制以后我们如何形成更有战斗力的团队完成这个目标？是通过建立全功能特性团队。
最后一个我们如何有效验证产品的价值，我们通过基于共创的价值验证闭环来做的。