敏捷的好未来-百人团队的实战攻略

彭小阳

作者简介：赵兰兰，是好未来的项目管理PMO，目前在家长帮。

今天主要讲的这几块有四个方面，第一个，敏捷转型拦路虎，基本上大家都会遇到。第二个是找支点撬动转型，第三个是百人大战战绩，大家关心的到底效果什么样，第四个是靴子落地，工具方面可以能够帮助大家在工作当中应用到一些工具和方法。

一、敏捷转型拦路虎

敏捷转型拦路虎，这个实际上是我在我们这边总结和整理出来的，但是基于不同公司、不同业务场景、不同企业文化的冲突下，我总结出来的只是基于我们公司做出来的东西。

第一个管理，我们在敏捷转型的时候，其实做敏捷这件事情，大家都有一个共同的认知，必须是自组织，大家非常认可。

但是为什么在中国敏捷转型或者我们推进，原因就是在中国文化的情况下，组织是最困难的，组织结构的障碍是最困难的，因为你刚刚说了，开发团队是个领导者，好的产品是个领导者，怎么去打，这个成本相当高。所以我们如何组织成自己的事情，对于来说是非常大的挑战。

另外一个沟通挑战，团队内部的信息不对称，刚刚有老师提到，不同的产品要对不同的研发，不同研发要对不同的产品，等于是一个网状式的结构，很有可能这种信息的确实成本也特别高。

第三个挑战是缺乏高效的管理工具，比如刚刚提到过的阿里说现在很好的人效，但是这仅仅是基于我们中国的比较优秀的、研发团队比较强的公司来说，但是对于小企业，或者一些基础能力建设不强的公司，它的提效工具是很匮乏的。

第四个挑战，人的问题，大家在面对转型的时候都不愿意走出舒适区，我到任何一个团队，基本上大家都说我挺好的，你为什么要来，你一个CMO到我这来要准备干什么，因为你给我的压力是很大的，你改变了我原来的工作风格。
所以，这几个难度是我们要去解决的。

二、找支点撬动转型

那我们怎么去解决呢？找支点撬动转型，支点是什么？刚才我们提到了有管理类，有一些组织信息，包括人员的冲突，我们要找到支点，能够让你在团队支撑你转型，能够让你从上而下的支撑、支持来干这件事情。

最痛苦的是，我们到这个团队了，大家都认为你没有价值，但是我们能做的很多，所以我们需要找支点，这个支点是什么，我这边找到的，老板经常会说，你们为什么上线时间这么长，还有什么东西？

我给到我们整个其他团队做培训的时候，另外一个事业部的伙伴问我，你怎么做到的让他们不延期，首先这个问题其实是非常普遍的，所以我们为了解决拦路虎，那我们就要找到支撑我们的点，这个点有可能是这样的，有可能是其他的。
所以，你要拿出你的论据和论证，在这个团队里立足，所以你要找到这个撬点，能够撬动你干这件事儿，那我们后续就要在这两个撬点上给到业务一个肉眼可见的成绩，不然你来的时候说的好好的，要帮我减少bug，提高我们的交付效率，最后什么也没干，那不就白搭了嘛。

三、百人大战战绩

所以，你的撬动要跟后面的数据一些信息对应起来，说一下实际上在团队里面实践的一些途径，整个团队大概我用了半年左右的时间，100人左右团队，实际上这是一部分效果，因为这个效果比较明显，有些定性的，包括一些小的10%的数据。

所以大家可以看到，版本延期，原来版本延期率是27%，基本上10几个版本，两三个都会延期，延期率比较高，bug的日峰值下降了40%，日峰值大家能理解吗，比方说在每个版本里面的最高的那一点的bug数。

刚才可能我跟老师说，你的数据到底是怎么衡量的，这是其中的一部分指标，你的日峰值，我肉眼可见的，当在一个很高的数降到一个很低的数的时候，这意味着什么？对于团队来说叫风险可控。

在一个迭代的周期里面，一个比例降到40%，到最后不断每天持续的降低，到最后的收敛，这是一个统计，这是你可以给团队带来的风险降低，同时能够保证在最后的时候，是一个紧密关联的情况。

还有研发测试比提升50%，什么意思呢？原来的团队是集中一侧，我也不管你，我们就写代码，我也不管写的对不对，反正从研究的角度，我是来写bug的，这是什么问题，请测试一下。

所以，在这个时候引入了一些产品思维，用户story拆分的方式，从史诗级的用户拆分到小的MVP，然后进行分批分次的测试，能够提前进入，这样的研发测试直接缩短了，因为测试什么都做不了，只能测试然后等待，然后假装验证一下以前的有没有问题。

刚才还提到了一个指标衡量，我这里面用线上和线下bug，线上bug指的是我们提交这个版本预测之后，实际上在线上发生的情况，保证的是我的开发质量，等于我的开发质量提高了，这是通过研发的注册，为什么我没有在这里写，但我得口述一下，因为有好多内部的信息，大家如果感兴趣可以看一下。

测试要提前写，所以我要求整个团队的测试团队把测试提前准备，并且在研发、研讨期间提供给P1级，首先能够保证研发自己把P1级给过完之后流程是通的，第二如果有P2、P3的话，当形成一个周期之后，慢慢的知道测试会关注哪些点，研发不光是自己去写功能的时候，他就会知道考虑正向、逆向各种情况，他自己真的会去跑case，去跑开发场景，而不是光光写代码，所以最终的结论大概下降了50%。

60%的指标，最大交付周期缩短了60%，可以想象吗，原来最大的交付周期是8.4周，我在极限的时候要求他们做到了每两周一次迭代，后来因为业务的调整，因为需要跟别的团队进行整合交互，等会儿在我后面的部分可以看一下迭代日历。

还有一个，有一句话是屋子里的大象，经常看到一个问题，需求评审很正常，我管它是多少个小时，我们是做项目的，我有没有考虑到部分的成本、时间、效率，我最开始进入团队，帮团队转型的时候特别可怕，第一次评审在8月份，在一个会议室里开了4个小时，导致第二天我就高烧了，因为通宵实在太累了，拖的时间太久了。

我第一件事情就是告诉你，你们这个评审会议绝对有问题，为什么？因为我之前做过产品，所以我知道它的产品方案是什么样的，所以如果我们在里面转型的时候，假设我们之前有过产品经验的话，那你就从产品的角度切入，告诉他你的问题。

我们原来是研发出身的，我们可以看研发的角度去解决问题，我们要找到这样的一个撬点，因为我本身不是研发出身的，所以最开始的分支建设慢慢学，但是总有一点，你进行转型，而且能够切入整个转型的团队。

所以，评审的周期、时长也很重要，你首先要保证产品需求的完整性，很简单，你要看它的价值有没有，不一定本身不是产品出身，不一定能够了解到，但是他有没有想这件事情，有没有呈现这件事情。

那如果框架本身有问题的话，那基本上不需要，评审的原因是产品需求不完整，在我这有记录，所以大家比较担心的是，放到一个团队，不跟团队配合，有一句话叫做温柔的天使是不对的，不对的原因你会影响别人的时间，别人的时间就是钱。

如果他不认的话，你找他的老板，我当时在那个团队很有趣，也比较尴尬，因为理论上一个团队有一个总负责人和产品的一个研发，我过去之后跟产品的负责人聊一聊，跟研发的负责人再聊一聊，把两边的价值观要对齐，让他们两个人同时支持我这件事情，所以付出了双倍的努力。

我们在前三个里面提到的一些关于其他方面的数据指标，包括像我们刚刚说的持续交付里面，到底你的度量衡是什么，我不知道有没有大家参加过上一次，2018年的大会，里面杨老师持续交付2.0的书里面，包括上次课应该也提到过。

不同的阶段有不同的交付市场，首先这是一个，交付周期是一个度量衡，我们经常讨论的代码数，但是代码数可能不能百分百的保证，可能每个代码的逻辑不一样，所以只是一个侧面的回答，包括一些研发角度是不是也做一些衡量。
在我们的团队里面，我还会同时衡量几个数值，一个是bug数，包括每个人的bug数，还有简单bug，刚刚老师提到过，简单的bug，比如你的UI问题就是属于粗心，所以这种人，我单独会跟他的负责人沟通，我不管你面对多少，因为我来这的很多事情，你们之前的交情好就好我不知道，我给你一次机会，对不起，你不给我机会，那我就要把你挂下去。

包括刚才提到的QA标准，线上bug要求多长时间之内必须解决，我们这边的规定，两个小时之内线上bug，一级bug两个小时之内、半个小时之内没有解决的话，我们是可以开除员工的，但是没有说一定，看影响范围。

所以对于质量，线上和线下的标准，跟它的绩效、员工直接考核，我作为一个项目经理，我有权利直接从后台看到数据的，我必须从数据客观的表达的表达这个东西。

刚才提到的老板如果经常改变需求怎么办，老板改变需求，不管谁改变需求，到我这都要走规律。还有一个，我们在日常工作中，研发小伙伴们、产品小伙伴们，如果关系好的话，经常会有一个小问题，接私活，导致你的年薪，所以你要找到另外一个制衡的人，比方说测试，告诉他俩商量好的接私活，到你这你不能同意。

我每次在那个时候都强调，我会去听，只要接私活的该点就点，该说就说。所以这不一定说是每一次都是负责人去管，但是杀鸡给猴看，你总要杀几只鸡的，我们在说转型给团队带来什么样的感受，持续近10个月的反馈。

其他的小伙伴，比方说从我们公司到VIPKID，到其他的公司，最开始的时候他们觉得很累、很痛苦，到了另外一个公司，离职之后到另外一个公司2、3个月之后过来给我发微信，确实提高了我的效率，在团队里面跟别人相比，觉得我对自己的要求都比别人高，而且有趋势成为领导者。

本身他自己感觉到他自己的效率高了，刚才我说的，测试最开始可能是给你一轮你的用力，慢慢走几圈之后会自己形成自己的概念，因为你不跑你不做，就有人逼着你去跑、去做，就会形成一个条件反射。

包括像从不同的维度，产品研发和老板层面对我那半年持续的转型非常认可，包括小伙伴们在内部和外部出去之后都有比较大的收获，比如调整到别的部门发现，兰兰老师你赶紧把你那个什么什么发给我吧，我用一下，我们这边就是一个作坊。

四、靴子落地

因为我做的所有的东西很俗、很接地气，直接拿过去就可以用，当这些东西没有底层的支撑，这些东西没有用起来的时候，其他大型的转型或者其他的上层建筑的东西不太现实，你底层的东西地基先要打好。

我刚才已经说了一部分的工具和方法，在这里面给大家细分一下，具体有哪些我认为比较好用的方法、法宝。

第一个落地剪裁的敏捷管理体系，其实每天都在做项目管理或者转型，但是大家有没有想过，你自己的团队适用于什么样的项目管理方式。

包括我现在到了家长帮，它的管理方式和原来的管理方式也不一样，原来的管理方式是纯产业的，现在的部分是要直接对接业务方，包括业务方的需求怎么输入，怎么做优先级管理，包括我们中心的项目，甚至法务这些东西都需要我来凑。

你要帮助他们打造他们的体系，所以怎么剪裁这件事情，对于个人转型很重要，你个人有这种理念，你才能在团队里面推行，而不是生搬硬套。

第二个，一些可践行的工具和方法，这些工具和方法大家可以拿过去直接用，但是用的过程中也要不断地调整，我这个里面是我自己这部分的一些项目管理体系，底层的基础建设就是你的流程梳理，流程梳理其实大家都简单。

比方说我们立项、启动、评审，这是一个流程，但是这个流程可能是在不同的团队里面角色不一样，比方说在有的团队里边可能项目子集里边产品经理就是项目经理，有的团队里边可能技术负责人是这个项目经理，所以你的流程的角色包括结点也不一样，需要去调整，自然梳理。

那大家基本上不太去考虑我手里有多少人，我手里就可以用多少人。我每次都会在这个团队里做资源梳理，为什么？老板说你这个东西不能延期。然后项目经理战战兢兢地说好，我不延期就去找技术负责人去了，但是你根本就没有考虑到他真正的资源是不是够。

所以我每次到一个团队里边，我首先去谈他的人，看是不是可控而且可以支撑的，如果人不够，我第一件事就是去找老板，你给我这个任务是不合理的，我告诉你合理的是什么样。

还有一个，问题和痛点的梳理，问题和痛点不就那几个吗？其实并不是，我每次带团队都会做很细很细的访谈。这是到一个敏捷团队里边去做的一个最基础的事情。烦琐但是非常非常有效。你要去听Words，你家的每个客户是谁，有一些研发，有一些测试。

从表面上看起来大真的是很和谐，真正你去跟他谈的时候你会发现这么多深坑。所以你要去解决他们的痛点，比方说谁经常延期，谁的需求经常写不清楚。我就遇到过研发经常吐槽一个产品说需求不清楚，但还是说“兰姐你别去找他说了，反正他都那样。”那这个事我们能成吗？肯定不能成，对吧？但是我肯定不会说某某研发吐槽了你产品需求有问题，我会一起办。

产品标准是什么？所有的产品@到，然后去一个一个过，有问题的把这个人单独拎出来，这是方式和方法的问题。你其实已经知道问题和解决方案了，但是你要给他一个过渡，了解业务这个不用说了，不了解业务的项目或者是PMO我觉得没有办法很容易的帮助他去转型。

实现的路径，敏捷实践咱们不用说了，你检查就好了。干系人的管理、××的管理刚才说了，你的资源梳理之后你要定期地去复盘，因为人有进有出、有借有还，我们就经常会跟别的团队去借人和出人。

访谈、站会、看板、复盘一会儿我们去细说，业务的学习是真正地去使用产品，然后你沉淀产出哪些东西？流程规范、流程图这个东西不用说，这个是标准的。

需求规范、研发规范、测试规范，刚才提到了，说我们在每一个环节里边是有一些标准的，那这些标准哪来，你先把这个杆立起来，你没有杆是说你这个不合理，那抱歉，你告诉我怎么才是合理的？

比如说我在现在新的团队里边开会，大家都不会开。我直接让我的实习生写个会议管理规范，迟到的罚钱，老板迟到的罚100块钱，员工迟到的罚50块钱。
然后开站会是怎么开？钉钉有二维码去发会议邀请，直接二维码放在那扫，我不点你，我自己不会得罪人，我得罪你没有意义。直接通报，谁到那个点迟到了，别人写上谁迟到，迟到了发红包。不是说钱这件事情，就挂名这一件事情就够让他受不了了。

还有一些实践方法，按需提测，刚才提到了用户故事，用户故事拆分之后就是按需提测，按story来提测，这是产品的一个工作方法。包括我们在敏捷里面是必须要践行的。

站会、看板、复盘方法，双管道制和班车制。双管道制我解释一下，什么是双管道？就是你的团队里边可能存在不同的产品方式，比方说小程序，比方说PC端和暗端。它可能适用的迭代的中心和方式都不一样。

所以你要用不同的管道去管，这就是扣了我刚才说的那个主题，为什么我要做资源梳理，有的时候可能APP端的人很多，但是小程序的人很少。然后老板会问，为什么APP的迭代的速度和小程序的迭代速度一样？难道不应该是小程序更快吗？他肯定会找到你问，但是当你之前没有盘这个资源的时候，你是回答不出来为什么的，对吧？

随意不同的通道，这只是一个举例双管道的时候我们比方说是有两个渠道，我们是有APP和小程序的，你有其他的方式的话你就要去剪裁。

比如我现在的团队里边，之前的团队是APP里边有教学管理××度033500和基础服务。三块儿组成一个APP就是业务模块还有三个，但它们之间有交互，所以我们把它们分成了三个××033515去做连接迭代。

但是在现在新的团队里边，有小程序，有后台的，有PC端和APP的，那我就要拆分。当然，他们之间有相互关系的，比方说APP和小程序之间的互推，互相的拉新、留存这种。包括像我们最近微信干的一些事，比如说是一个××033542的收口。这个我们做项目，同时要了解行业。

除了这个项目和这个体系之外，我们具体有哪些工具和实操方法？

第一个：需求管理。

需求管理主要分三块：需求通道管理、需求优先级管理和用户故事方法。

第二个：信息可视化。

看板、站会、透明资源池和复盘实践。

我现在讲需求通道，这是一个Logo，那是一个Logo。之前我们刚才说了业务给了研发的需求很多，我们需要用工单。其实它是同样类似的一种思维，你的需求如果进来是发散的。好像贴反了，应该需求是发散着进来，进行收敛。

因为你的需求很多，但你的接口只有一个的话，那你就很容易去分清，当你的需求很少，你接口的人很多的时候，你就可以去优先分配，这是一个需求通道的问题。另外一个，需求管理的节奏刚才提到了小程序、APP后台、PC和H5都是不一样的。

第二个：需求优先级管理。我不知道你们是怎么在做需求优先级管理的，P0、P1、P2，你们会管吗？产品经理管？那产品经理告诉你这几个需求都紧急呢？那就没法管了是？那我就在这等着是吗？所以在我这，之前他们是怎么管？
要么就是一头，我这头放弃，我就今天必须全都得上，为什么？因为好多个产品经理都要找我。那都安排光了我怎么给他安排？我怎么给他立项？抱歉，不好使。

所有的需求都在一个地方去维护，必须到从1开始给我列。有一个专门的一个人，比如说这次的需求谁是主打的，谁的需求比较多或者比较重要，那你就做主负责人去给我列，不给我列这个东西，你什么时候列清楚了什么时候咱们做产品需求的内审。你内审的时候如果没有这个东西，抱歉，你内审就不通过，别想往下走。

然后我会在这个时候，刚才提到说他们做一个月左右的规划，我会跟业务方说这个版本的上线时间是什么时间，我的下一个版本需求收集时间是什么时间。业务方不仅仅是产品经理，产品经理在一个群里，我会很标准地告诉业务方，你6月20号提交的是V780版本的需求，然后我V780需求大概上线时间是7月中旬，如果业务方没有在6月20号提交给产品经理的话，那是业务方的问题。

然后在另外一个产品群里我告诉他们，我要求在6月30号的时候你能做产品的需求初审，也就是说你必须要达到80%以上的需求的完整性和优先级的排序。你没有的，抱歉，需求初审没有，轮到下一波去，下一个版本再见。所以必须得给我排序。