【腾讯敏捷转型No.8】你爱上手机QQ了么？

上一篇文章《QQ邮箱如何利用敏捷做到中国第一》，“QQ邮箱之母”马化腾带领QQ邮箱团队，从流量思维向产品思维转变，“QQ邮箱之父”张小龙也是在这个敏捷转型过程中，剔除固有的成见，激发对优秀产品的追求，从而有“微信”这个神话诞生。

接下来这篇文章，将会讲述腾讯手机QQ是如何进行敏捷转型的。

你爱上手机QQ了么？不管你现在是否还在使用手机QQ，也不曾改变它“辉煌的历史”。

在2010年以前，绝大多数的中国人都依赖手机QQ进行沟通，国内所有手机出厂都会内置手机QQ客户端，不然没有办法卖出去。

手机QQ第一个版本是2002年，率先在索爱一款T618手机上线，这款手机开始支持GPRS网络和安装Kjava软件（如图一）。

（图一：手机QQ1.0版本界面）

这是最早期的手机QQ，功能肯定称不上强大，不过已经具备基本功能，能够在与好友聊天时发送文字和表情，在手机端进行随时随地聊天，修改在线状态。

2007年，腾讯在内部推行敏捷的时候，手机QQ团队已经做了B1的手机QQ业务五年了。如表一，手机QQ敏捷转型做出了以下改变。

（表一：手机QQ团队敏捷转型前后）

很多团队向敏捷转型，几乎都是在站立晨会中开始，手机QQ团队也不例外。晨会主要给手机QQ团队带来的两点改变，一是每天都准时开晨会，二是开会方式是站立的。

在当时的腾讯，想知道哪个团队是否要敏捷，看他们开会是否站立就一清二楚了。在当时的手机QQ团队也是如此，一堆人围着一个圈，絮絮叨叨给领导汇报工作。

手机QQ团队就这样开晨会并且持续了一段时间，然后敏捷教练就告诉大家：很开心能看到大家坚持站立晨会，但是晨会并不是成员给领导汇报工作、听领导训话的报告会。

（图二：领导在会议上教训员工）

相信很多团队在敏捷转型过程都有类似的经历（如图二），领导在晨会上对团队一顿臭骂，团队集体做一个热身操，拍照留念，齐声大喊“我不能左右客户，但是能转变心情”，然后就开始一天的工作。

这样子的敏捷晨会肯定是错误的，晨会的本意是加强内部沟通。而有效的沟通必须建立在团队成员平等的基础上，需要每个团队成员都发言，互相沟通，了解进度，针对团队关心的问题进行交流。

手机QQ团队刚开始站立晨会的时候，有些团队成员会不适应，不知道要说些什么，然后就设定一个模板来说：

1、我昨天做了什么？

2、我今天计划要做什么？

3、我觉得有什么问题和挑战？

按照这个模板进行一段时间的站立晨会，慢慢会发现，一个15个人左右的站立晨会大概需要30分钟，有点冗长，而且团队成员注意力只有在自己发言的时候，其它成员发言并没有认真听，这样的晨会效率也是会很低的。

为了提高晨会效率和质量，缩短晨会时间，在引入“故事墙”之后，手机QQ团队的晨会模板再做出了以下改变：

1、昨天的工作发现了什么问题？

2、今天我需要什么帮助？

3、如果没有以上相关内容就“过”。

晨会通过以上调整，大大缩短了开会时间，提升开会的效率和质量。大家每日工作的具体内容都在“故事墙”上体现，工作流程、进展一目了然，所以晨会不需要重复具体的内容，把重心放在“发现问题和帮助协作”上，晨会时间能够缩短在15分钟以内。

即使在开会的过程中，很多成员会说“过”，证明他们的工作进展顺利，暂时不需要帮助。团队经历这样一个过程，他们会明白团队每个人都是平等的，每个人的发言都是有价值的，每个人都值得被尊重的，这样的晨会“含金量”会更高。

而在晨会中暴露的问题，并不是在晨会上进行讨论，而是完成认领。例如，有成员暴露了某个问题后，与这个问题相关的团队成员举手示意后，等到晨会结束，问题的相关成员聚在白板前进行讨论，最后把讨论结果拍照发给全员即可，并不需要整理成文稿，只需要问题相关人员看得懂即可。

（图三：Kjava手机QQ团队开晨会）

在没有引入敏捷之前，手机QQ团队基本上是一年一个大版本，在每年头三个月，产品经理团队讨论需求三个月，然后和开发团队一起“PK”三个月，架构设计研发三个月，测试修改Bug三个月，版本上线，就这样一年就过去了。

随着手机QQ用户不断增加，产品经理也积攒了不少需求，希望可以大干一个版本。与此同时，整个团队不断在赶版本，技术债务不断累积。

当产品经理团队经过激烈的讨论，提出了一个宏大的产品需求构想后，技术团队认为需求是美好的，但是在实现在原来的架构上是不现实，并且提出三个月的时间进行架构重构，然后全力开发新产品。读到这里，如果你是一个产品经理，你觉得技术团队的话可信吗？而当时的手机QQ产品经理团队愉快地答应了。

三个月约定时间到了，技术团队没有完成，再申请提出三个月时间，产品经理团队等不及，决定进行双线开战，一部分技术团队成员在旧版本下开发新功能，一部分同学进行架构重构，等两边完成后合入开发的新功能，结果发现了更多的问题，等修正了Bug之后，最终全新的版本耗费了很长时间才能上线。

重构本来是一个代码优化的过程，例如，修改变量命名，抽象类的方法等。很多开发团队在现实中容易把重构的定义混淆，重构是一边开发新需求，一边修改Bug，代码质量一点一滴提升，重构就是在这样一个过程汇总逐步完善实施的。

千万要注意的是，不要Hold住全世界。很多开发人员懒得去理解，就试图利用干净的代码替写，这样的悲剧经常会在不同的产品团队中上演，这样会酿成大祸。值得吸取经验教训的是，重构是每一天的事情，不能停版来进行重构。

如果延误新版本上线时间，错过了最佳的市场时机，被竞争对手占尽先机，容易酿成大错。所幸手机QQ团队在当时竞争对手不多，并没有造成很大的问题。

经过这次的经验教训，手机QQ团队发现开发流程存在很大的问题，明白再宏大的需求，都必须渐次完成开发过程，并且决定通过引入敏捷来解决问题。

手机QQ团队通过引入敏捷Scrum模型，开始尝试迭代式开发，利用刚性交付和迭代模型图，无论如何确保每个月发布一个版本（在《腾讯敏捷转型系列第五篇文章：需求没有做完可以发布嘛》中提到），经过不断的摸索和努力，最终手机QQ2008版本成功上线，并且取得不俗的成绩，手机QQ同时在线用户达到500万。