艾永亮谈腾讯的自运转团队

InfoQ：永亮您好，谢谢您接受访问，可以请先和大家做一个简短的自我介绍。

Aland：艾永亮 (Aland Ai)，腾讯公司敏捷教练 & 高级项目经理，曾参与 QQ 农牧场，Qzone 商城，SOSO，无线应用、网络游戏等业务的项目管理与教练工作。曾任著名敏捷咨询公司 ThoughtWorks 资深敏捷顾问。可通过腾讯微博、新浪微博与他交流。

InfoQ：很高兴在上海 Scrum Gathering 中看到你的分享，当中有些还是腾讯公司的创新实践，可以先介绍一下 “自运转团队” 是如何的概念？跟一般自我管理团队 (Self-managing team) 有什么分别？

Aland：实际上“自运转团队”也可以称作“准自组织团队”，他是通向“自组织团队”的中间阶段。 “自运转”是通过一系列预定义的流程来将团队成员串联起来，但它在我们通常定义的工作流程上加上了三项重要内容：1. 当前环节负责人要对其工作的进度和质量负责；2. 当前环节负责人要跟进上一环节负责人的交付时间和质量； 3. 当前环节负责人要推动下一环节负责人的工作尽快开展。这样在单纯的事务流程上加入了“人”的内容，任何一个环节都有 “当前”、“上游”、“下游” 三名团队成员关注和推进（始末端均为项目经理），这就在让团队成员通过流程连接在一起，使得大家不只关心自己手头的工作，还需要关心上下游的工作，团队推动远胜于项目经理一人推动。

然而，“自运转团队”却缺乏“自组织团队”的自我管理，持续改进的内容，因为它的任务计划和分工还是有 PM 统一规划的。不过虽然它与“自组织团队”还有一定距离，但是由于团队成员彼此紧密联系，相互关注，这将促使团队向自管理的方向发展。因此我们认为这是通往“自组织”的一个中间阶段，同时由于它更容易实现，因此它实际提供了一个向“自组织”转型的切实可行的方法。

InfoQ：可以介绍一下 ”自运转团队” 是公司在什么背景下想出来的？

Aland：它出现原因其实很自然，指令型团队让所有人都很痛苦，自组织又难于实现，所以才有了“自运转团队”。大家都知道腾讯为了适应互联网的快速变化和满足用户的需求，产品发布速度都非常快，这使得大家压力都很大，在这种情况下多数项目经理都会想方设法提升效率，一个很自然的想法是让每个角色都能更加专心在自己的工作上，全力提升自己的效率，而由项目经理承担起来大量沟通和推进的工作。这种情况下，每个人确实更专注了，团队都在项目经理的指令下工作，但是大家却忽视了团队其他成员的工作，再加上缺乏充分的直接沟通，在配合中就产生了大量问题，比如实现偏差、接口不一致等。经过一段时间，问题频发，大家感觉更累了，这时作为敏捷教练的我们自然会建议转换团队管理方式，但是要打破大家的工作习惯，特别是已有很久的思维模式，是件非常困难的事，因此我们就尝试先借助一些工具让大家的工作透明出来，适度增加成员之间工作联系，经过一段时候的摸索和尝试，找了利用流程和责任来驱动工作进展的方法，也就是“自运转团队”。

InfoQ：在敏捷宣言背后的原则当中提到 “最好的架构、需求和设计出自自组织团队。”，在你们实践中，”自运转团队” 又如何做出最好的架构、需求和设计呢？

Aland：是的，这一点“自运转团队”做的也还不错。由于大家的工作联系，在“自运转”过程中不断加强，彼此之间越来越紧密，客观上使得大家会越来越关注相关成员的工作质量，因此开发人员会主动帮助产品经理完善需求细节，测试人员也会从用户使用的角度提出优化建议，架构设计也会在开发经理的带领下组织大家经常性的讨论、评审、优化，同时每个迭代我们都会固定的安排一些技术需求，以避免技术债务的累积。不仅如此每个人对团队问题也会越来越警觉（这一点有点贴近自组织了，呵呵），有一次，素材多次出现问题，产品经理就主动拉开发同学讨论解决方案，最后决定由开发同学写一个检查工具，其间项目经理都没有参加。

InfoQ：在 ”自运转团队” 中，迭代的工作估计、任务分拆、申领任务是如何进行呢？

Aland：迭代的工作估计是由团队在 IPM 上集体评估的，但是由于受制于各个成员所熟悉的领域不同，所以只能做到由部分成员估计，但至少不是一个人估计。任务拆分也由相关产品、开发、测试一起讨论决定的。任务认领不会那么自组织，主要是由项目经理安排，不过这里也会充分考虑每个成员的兴趣和意愿。

InfoQ：在 ”自运转团队” 中，迭代结束的回顾会议会不会有什么不同呢？会按照职能分别作回顾还是按团队或是按项目作回顾呢？

Aland：回顾会议并没有什么不同，因为自运转团队也必须要是一个完整的特性团队，至少要包括产品、开发、测试等成员，这样才能自己“运转”的起来，因此回顾会议上也会要求所有成员都参与，共同为团队改进出谋划策。

InfoQ：在 Tencent，回顾会议的频度和形式是如何的呢？

Aland：腾讯的 Retro 一般会安排在重要版本发布之后，有时也会选择一些关键迭代结束的时候。形式上主要采用的是 WELL/LESS WELL 的经典方式进行。

InfoQ：在 ”自运转团队” 中，Scrum Master 角式会有不一样嘛？

Aland：自运转团队中，Scrum Master 实际由项目经理担任，由于团队成员尚未达到自组织，因此项目经理除了承担原有 Scrum Master 的工作之外，还需要承担更多的工作，比如迭代计划、发布计划、组织发布等。

InfoQ：项目经理职能和责任在敏捷转形中有什么变化？

Aland：关于项目经理的角色的职责，我们一直在不断探索，过去项目经理更多是负责计划、跟进、沟通等以过程为主的工作，现在公司对项目经理提出了更多的要求，特别是在产品方面，要求项目经理不只能管好过程，更要为产品交付负责，要能组织团队保质保量的完成特性开发，而且还要在过程中平衡业务需求与技术需求的优先级，不能盲目的赶进度赶需求，做最有价值的事和控制节奏都很重要。

InfoQ：如果让你从新作团队组织安排的话，你认为会不会有什么不同的地方呢？还有，有没有打算让团队朝向更自我组织的想法和计划呢？会是如何做法呢？

Aland：一定会往自组织的方向继续发展的，而且我相信这是团队自身发展的必然结果，因为团队一旦步入正轨，只要方向保持不变（这个需要项目经理坚持把控），团队的自组织性会自然产生，但是这有一个前提，团队和业务要相对稳定。

除此之外，还要不断加强团队的产品意识建设，让团队所有成员都能持续关注做最有价值的特性，从用户的角度不断优化产品功能和体验。不但要建设优秀的团队，更要产出优秀的产品。

InfoQ：对于成立组织团队方面，有没有什么心得能分享给读者呢？

Aland：我之前总结过一个《建设融洽主动的项目团队》的心得，在公司内部做过几次分享，主要是谈从“融洽”和“主动”两个方面来建设团队，内容比较多，其中有一点是大家感到比较有启发的。团队内部角色之间有些许矛盾是难免的，比如产品同学对需求如果考虑不周，开发同学就有可能产生抱怨，这时很多团队采用的方法是加强评审环节。但是这样并不能完全解决问题，原因有两个，一是评审费时费力，二是评审也不能查出所有问题，开发过程中还会遇到问题。我认为这不是根本的解决之道，因为人非圣贤，总有考虑不到的时候，评审就像壁垒一样只能屏蔽一部分问题，然而如果一个优秀的团队是可以让这些问题变得不是问题。我向大家推荐的办法其实很简单，就是“相互帮助”，我会去和开发同学解释产品同学的难处与局限性，请他作为伙伴帮助他，如果有考虑不到的地方和产品同学一起来解决，这样开发同学对产品同学的看法就发生 180°的逆转，对不周不再认为是问题，而是想办法帮助他，这样产品同学就在开发同学的帮助下不断进步，他们两个的关系也会越来越好。这是也是一个化解团队矛盾的技巧。

InfoQ：非常感谢 Aland 能接受我们的采访，谢谢您。

另外，笔者亦希望在此感谢 Odd-e 公司的吕毅和滕振宇在问题设计上提供协助

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。