`
flymy23
  • 浏览: 3444 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
最近访客 更多访客>>
文章分类
社区版块
存档分类
最新评论

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

 
阅读更多

http://www.infoq.com/cn/articles/tencent-team

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 公司的吕毅和滕振宇在问题设计上提供协助



分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics