论文部分内容阅读
近日，张小龙在微信内部年会上发表演讲，以过往实例阐述了自己对产品与管理的思考。一方面，他重申了效率至上的价值观；另一方面，他也打破了外界对其产品之神的人物设定。因为神不会犯错，而只有不断思考和修正才能让产品保持活力。
如今微信团队膨胀得越来越快，有1 500多人之多。对此，大家都有一个担心，就是当一个团队规模特别大的时候，很多行为方式一定会进入一种“组织化”的模板中去，要想保持自己的特色就变得特别不容易。
《人类简史》这本书提到，我们的记忆里面只适合处理150人以内的人际关系，一旦超过150人，它就变成一个社会化的组织。这时候对个体来说是不太舒适的，因为已经超过了他的舒适区。
我担忧的是，微信团队作为一个上千人的组织，如果把它当成10个150人的团队的话，我认为它会有非常高的创造力；如果把它当成整体1 500人，我特别担心它在创造力上会不会反而有一些衰退。
做什么取舍是有意义的？
在QQ邮箱开始快速发展的时候，我在内部做过一次分享，当时我说了一句话，叫“我们达到了KPI是我们产品的副产品”。所谓副产品就是，我们真的把这个东西做好以后KPI自然就达到了。早期的微信团队也一直是围绕这个思路在工作。
但是，当我们的团队变大以后，这个思路其实是被动地慢慢发生了变化。很多同事跟我讨论一些产品或者业务方向的时候，往往会给出一些证据，这些证据是用数字证明——这个对我是有冲击的。我说的冲击是说大家在思考问题的出发点上有一些驱动力，不是来自是不是在做有价值的事情， 而是来自于我们能做到一个多高的数据。
我举几个小的例子，首先是一个好的。
去年在春晚的红包大战里面，我们并没有把竞争当成一个大战来看待，但是竞争对手会把这当成一个大战来看待，对方PR说一定要在数据上超过我们。我们团队当时在开会时说，我们今年的策略是什么。我很高兴大家最终定下来一个策略——我们今年的目标是怎么样帮助用户更高效地抢到红包，而不是最终体现为一个数字非常大，这是完全不同的一个思考点。
如果我们是为了让数字变得很大、更多人抢更多次数、花更多时间，那我们整个产品逻辑里面就会围绕这个目标去做，我们会让用户抢100次才抢到一个红包，这样参与的人数次数最多。如果让用户高效地抢红包，我们的产品逻辑就变成废除了所有的多余过程，让用户尽可能少地花时间在微信里面。
这两个产生的结果也是不一样的。对用户来说，花尽可能少的时间抢到红包，他是最愉快的，但是数字上相比而言不是最大的。在这样的情况下，我们采用这样一种对用户有价值的做法，最后获得的口碑和数据都非常好。
这里反映了一个点，就是你用一个不同的目标驱动的话，产生的方法完全不同。我们从来没有给公司领导反映说我们的KPI有问题了，反而是聚焦在数据的目标上，这点值得大家反思。我跟技术团队讨论问题时也说，不要太关注用户的增长，因为这是一个很自然的增长，我们更应该关注我们给用户做了什么事情，是否满足了他们某一种使用的需要、愉悦的需要。
我再举一个微信内部不好的例子。
比如城市服务。城市服务作为微信里面的一个入口功能很重要。去年制定年度目标的时候，团队给我抛出一个年度目标，让我大吃一惊，因为我没有看到这样的年度数据。什么目标呢？列出明年要达到的年访问量、年PV达到多少……我说怎么会有年PV这个说法，我只听过日PV，最多听过周PV。团队解释说如果说日PV，那个数据太小了，不好看，我当时有点哑口无言了。
这看起来是一个技巧，但是我希望同事少用这样的技巧。我们应该看到我们的日PV、日UV在增长，也不愿意看到一个很大的年PV数据；我们应该看到城市服务里面每一项服务它的质量、可操作性越来越好，也不想看到这里面进来的次数有多少——就像前面提到的，因为当我们提出一个目标方向，我们努力的方向一定会随着这个目标改变，当提出一个纯数据目标，努力的方向可能会围绕这个去做。
微信有一个特别大的优点，就是商业模式建立得比较干净，不是在透支流量状态下建立的。之前我一直没有想过这一点，我觉得这不是应该的吗？后来大家发现我们在微信流量方面其实是非常保守、非常谨慎的。我们所有业务不管是商业还是非商业的，我们首先去衡量它对用户具体带来的价值是不是真的很大，然后再决定要不要使用这个流量。
就像大家看到微信广告的表现一样。有人说微信里广告的空间特别大，原因是这里的流量根本没有完全释放出来。事实上，大家会看到从微信广告上线到现在，没有一个平台广告产品能够像微信朋友圈广告这样做到几乎没有什么用户的抵触，甚至到目前为止还有很多用户说为什么我看不到一些广告，别人能看到——这是一个特别好的效果。并不是我们刻意要达到这样一个效果，而是说即使我们在考虑像广告这样非常商业化的东西的时候，我们首先考虑的是用户是不是把它当成一个很友善、很好的一个功能在使用，而不是说我们去测试一下用户的忍耐力下限、一直到击穿它为止。
所以对于这一点建议其实很有意思，你会发现任何时候都有一个分支道路让你去选择，只是看你用什么样的方法去做选择。
敏捷性和小团队密不可分
我想分享的第二点是关于敏捷性的问题。
2005年当我们接手QQ邮箱的时候，QQ邮箱在中国排名在靠后，没有人重视，可以说接手过来是一个烂摊子。但当时并没有意识到这是一个烂摊子，毕竟排名十来名从数据上看也是挺大的。于是，我们组织了团队做这个事情，目标是把QQ邮箱做好。
我们在第一年用的是最“正统”的方法。比如，我们会去研究竞争对手的产品、研究世界上最领先的同类产品，并且尝试去学习它，把功能做得很复杂。当时这一块领先的产品是微软的 hotmail，我们就想做中国的hotmail。怎么做呢？当时公司有非常科学的流程管理，有非常科学的研发，于是我们就用这个方法论来做……最后的结果却非常失败。因为用户进来发现产品非常慢，每一个操作又很烦琐，所有功能看起来都没有什么亮点，因此用户很快就流失了。 但是，每次公司内部汇报，我们都有很多东西可以说——我们这个月又做了什么新的东西，整个技术水平又往前迈进多少步等。
现在回想起来那一年我们做的所有事情，用一句话来概括就是“一个非常平庸的团队用了一些非常平庸的方法去做出来一个非常平庸的产品”，而且是不知不觉的。
2006年的时候，邮箱团队开始思考这个危机，认为再按照现在的方式推进已经过时。要不让它死掉，要不重新找到一条出路。当时我们放手一搏，成立了一个大概10个人的小团队，有几个后台开发，有几个前端的人员，人员非常精简，跟我们微信起步时非常类似。人员精简到什么地步呢？除了后台以外，我们把这些人聚到一起也就十来个座位，大概2、3个web的开发，2、3个产品，1、2 个UI，还有1、2 个测试，他们组成了我们定义为的敏捷团队。
实际上，就这么小的一个团队在后面几年做的事情远远超过之前几十人的努力，这个小团队当时用了一个方法，叫敏捷项目管理。
所谓的敏捷是真的非常快。例如当我头一天晚上发现我们这里有一个东西要改一下，我发一个邮件出去，有的第二天上班的时候就发现这个东西改过来了，并且已经上线，大多数一个星期上线是不夸张的，这无疑是一种很酣畅的感觉。
敏捷带来一个最好的心理感受是什么呢？ 我们今天可以想一些与众不同的点子，然后很快就看到效果：因为我们可以很快把它上线，然后去验证；如果不对就下线，如果还有改进余地，下个星期再去改它。如果改了还不行，那继续下线，如果改了行，说明它一定很好……这是一个能够持续实现你想法的过程。
在邮箱从2007年开始进入一种敏捷项目的推进方法以后，后面几乎每年都是一个非常高速的往上发展过程。这个过程就像一辆汽车有了发动机、有了足够汽油就会自己一直跑下去。后面几年，我们一直保持这样快速迭代、快速上线、快速验证想法这样的流程，团队运转也非常顺畅。
所以，关于敏捷开发我特别希望大家能够多去做一些尝试，其实这个尝试并不是需要大家一定要把项目剥离出来几个人来做才行。它更多是一种方法论，而不是具体的一种形态。
实施人才轮岗机制
最后，我想讲一下对于人才、对于组织的一些思考。
微信事业群做了一个活水计划，HR在这块一直花了很多精力来推进。当我们人数很多的时候，其实多一些轮岗是有好处的。之前大家认为在一个岗位，就一直这么做，如果没有特别的事情，可能做这个事情好几年、十几年都有可能。
但是，这可能不太利于组织活跃度，也不太利于个人自我成长。最近一年我跟HR说，我们有没有一些新的机制能够帮助组织里面的人员流动得更加顺畅。从我的角度看，反而觉得大家在团队里面经受的锻炼或者锤炼是不够多而不是说太多了。这里如果有一些方式让大家用同样的时间，但是经历更多、思考更多，确实是没有坏处只有好处。
所以对于微信事业群的同事，大家用活水计划去让一些想要转换岗位的人让他没有后顾之忧可以非常自由地转，同时我们也上升到总监这个级别，制定出一个微信事业群内部的措施——微信事业群的总监如果没有经过轮岗是不能往上晋升的，必须要有轮岗的经历。
可能有些同事会觉得这样会不太舒服。当然不能太舒服，必须要走出一个人的舒适区域，面对新的挑战。但是以后回头来看，这样的结果其实是有好处的，通过一种轮岗的方式可以让自己接触更多的锻炼。
总结一下，我想要分享的主要有两点：第一，关于对我们产品、我们业务思考方向是不是真的从用户角度来出发来考虑；第二，关于敏捷性。即使对微信来说，我们的前期迭代很快，后面迭代速度确实变得越来越慢，所以这也是需要大家思考的。
如今微信团队膨胀得越来越快，有1 500多人之多。对此，大家都有一个担心，就是当一个团队规模特别大的时候，很多行为方式一定会进入一种“组织化”的模板中去，要想保持自己的特色就变得特别不容易。
《人类简史》这本书提到，我们的记忆里面只适合处理150人以内的人际关系，一旦超过150人，它就变成一个社会化的组织。这时候对个体来说是不太舒适的，因为已经超过了他的舒适区。
我担忧的是，微信团队作为一个上千人的组织，如果把它当成10个150人的团队的话，我认为它会有非常高的创造力；如果把它当成整体1 500人，我特别担心它在创造力上会不会反而有一些衰退。
做什么取舍是有意义的？
在QQ邮箱开始快速发展的时候，我在内部做过一次分享，当时我说了一句话，叫“我们达到了KPI是我们产品的副产品”。所谓副产品就是，我们真的把这个东西做好以后KPI自然就达到了。早期的微信团队也一直是围绕这个思路在工作。
但是，当我们的团队变大以后，这个思路其实是被动地慢慢发生了变化。很多同事跟我讨论一些产品或者业务方向的时候，往往会给出一些证据，这些证据是用数字证明——这个对我是有冲击的。我说的冲击是说大家在思考问题的出发点上有一些驱动力，不是来自是不是在做有价值的事情， 而是来自于我们能做到一个多高的数据。
我举几个小的例子，首先是一个好的。
去年在春晚的红包大战里面，我们并没有把竞争当成一个大战来看待，但是竞争对手会把这当成一个大战来看待，对方PR说一定要在数据上超过我们。我们团队当时在开会时说，我们今年的策略是什么。我很高兴大家最终定下来一个策略——我们今年的目标是怎么样帮助用户更高效地抢到红包，而不是最终体现为一个数字非常大，这是完全不同的一个思考点。
如果我们是为了让数字变得很大、更多人抢更多次数、花更多时间，那我们整个产品逻辑里面就会围绕这个目标去做，我们会让用户抢100次才抢到一个红包，这样参与的人数次数最多。如果让用户高效地抢红包，我们的产品逻辑就变成废除了所有的多余过程，让用户尽可能少地花时间在微信里面。
这两个产生的结果也是不一样的。对用户来说，花尽可能少的时间抢到红包，他是最愉快的，但是数字上相比而言不是最大的。在这样的情况下，我们采用这样一种对用户有价值的做法，最后获得的口碑和数据都非常好。
这里反映了一个点，就是你用一个不同的目标驱动的话，产生的方法完全不同。我们从来没有给公司领导反映说我们的KPI有问题了，反而是聚焦在数据的目标上，这点值得大家反思。我跟技术团队讨论问题时也说，不要太关注用户的增长，因为这是一个很自然的增长，我们更应该关注我们给用户做了什么事情，是否满足了他们某一种使用的需要、愉悦的需要。
我再举一个微信内部不好的例子。
比如城市服务。城市服务作为微信里面的一个入口功能很重要。去年制定年度目标的时候，团队给我抛出一个年度目标，让我大吃一惊，因为我没有看到这样的年度数据。什么目标呢？列出明年要达到的年访问量、年PV达到多少……我说怎么会有年PV这个说法，我只听过日PV，最多听过周PV。团队解释说如果说日PV，那个数据太小了，不好看，我当时有点哑口无言了。
这看起来是一个技巧，但是我希望同事少用这样的技巧。我们应该看到我们的日PV、日UV在增长，也不愿意看到一个很大的年PV数据；我们应该看到城市服务里面每一项服务它的质量、可操作性越来越好，也不想看到这里面进来的次数有多少——就像前面提到的，因为当我们提出一个目标方向，我们努力的方向一定会随着这个目标改变，当提出一个纯数据目标，努力的方向可能会围绕这个去做。
微信有一个特别大的优点，就是商业模式建立得比较干净，不是在透支流量状态下建立的。之前我一直没有想过这一点，我觉得这不是应该的吗？后来大家发现我们在微信流量方面其实是非常保守、非常谨慎的。我们所有业务不管是商业还是非商业的，我们首先去衡量它对用户具体带来的价值是不是真的很大，然后再决定要不要使用这个流量。
就像大家看到微信广告的表现一样。有人说微信里广告的空间特别大，原因是这里的流量根本没有完全释放出来。事实上，大家会看到从微信广告上线到现在，没有一个平台广告产品能够像微信朋友圈广告这样做到几乎没有什么用户的抵触，甚至到目前为止还有很多用户说为什么我看不到一些广告，别人能看到——这是一个特别好的效果。并不是我们刻意要达到这样一个效果，而是说即使我们在考虑像广告这样非常商业化的东西的时候，我们首先考虑的是用户是不是把它当成一个很友善、很好的一个功能在使用，而不是说我们去测试一下用户的忍耐力下限、一直到击穿它为止。
所以对于这一点建议其实很有意思，你会发现任何时候都有一个分支道路让你去选择，只是看你用什么样的方法去做选择。
敏捷性和小团队密不可分
我想分享的第二点是关于敏捷性的问题。
2005年当我们接手QQ邮箱的时候，QQ邮箱在中国排名在靠后，没有人重视，可以说接手过来是一个烂摊子。但当时并没有意识到这是一个烂摊子，毕竟排名十来名从数据上看也是挺大的。于是，我们组织了团队做这个事情，目标是把QQ邮箱做好。
我们在第一年用的是最“正统”的方法。比如，我们会去研究竞争对手的产品、研究世界上最领先的同类产品，并且尝试去学习它，把功能做得很复杂。当时这一块领先的产品是微软的 hotmail，我们就想做中国的hotmail。怎么做呢？当时公司有非常科学的流程管理，有非常科学的研发，于是我们就用这个方法论来做……最后的结果却非常失败。因为用户进来发现产品非常慢，每一个操作又很烦琐，所有功能看起来都没有什么亮点，因此用户很快就流失了。 但是，每次公司内部汇报，我们都有很多东西可以说——我们这个月又做了什么新的东西，整个技术水平又往前迈进多少步等。
现在回想起来那一年我们做的所有事情，用一句话来概括就是“一个非常平庸的团队用了一些非常平庸的方法去做出来一个非常平庸的产品”，而且是不知不觉的。
2006年的时候，邮箱团队开始思考这个危机，认为再按照现在的方式推进已经过时。要不让它死掉，要不重新找到一条出路。当时我们放手一搏，成立了一个大概10个人的小团队，有几个后台开发，有几个前端的人员，人员非常精简，跟我们微信起步时非常类似。人员精简到什么地步呢？除了后台以外，我们把这些人聚到一起也就十来个座位，大概2、3个web的开发，2、3个产品，1、2 个UI，还有1、2 个测试，他们组成了我们定义为的敏捷团队。
实际上，就这么小的一个团队在后面几年做的事情远远超过之前几十人的努力，这个小团队当时用了一个方法，叫敏捷项目管理。
所谓的敏捷是真的非常快。例如当我头一天晚上发现我们这里有一个东西要改一下，我发一个邮件出去，有的第二天上班的时候就发现这个东西改过来了，并且已经上线，大多数一个星期上线是不夸张的，这无疑是一种很酣畅的感觉。
敏捷带来一个最好的心理感受是什么呢？ 我们今天可以想一些与众不同的点子，然后很快就看到效果：因为我们可以很快把它上线，然后去验证；如果不对就下线，如果还有改进余地，下个星期再去改它。如果改了还不行，那继续下线，如果改了行，说明它一定很好……这是一个能够持续实现你想法的过程。
在邮箱从2007年开始进入一种敏捷项目的推进方法以后，后面几乎每年都是一个非常高速的往上发展过程。这个过程就像一辆汽车有了发动机、有了足够汽油就会自己一直跑下去。后面几年，我们一直保持这样快速迭代、快速上线、快速验证想法这样的流程，团队运转也非常顺畅。
所以，关于敏捷开发我特别希望大家能够多去做一些尝试，其实这个尝试并不是需要大家一定要把项目剥离出来几个人来做才行。它更多是一种方法论，而不是具体的一种形态。
实施人才轮岗机制
最后，我想讲一下对于人才、对于组织的一些思考。
微信事业群做了一个活水计划，HR在这块一直花了很多精力来推进。当我们人数很多的时候，其实多一些轮岗是有好处的。之前大家认为在一个岗位，就一直这么做，如果没有特别的事情，可能做这个事情好几年、十几年都有可能。
但是，这可能不太利于组织活跃度，也不太利于个人自我成长。最近一年我跟HR说，我们有没有一些新的机制能够帮助组织里面的人员流动得更加顺畅。从我的角度看，反而觉得大家在团队里面经受的锻炼或者锤炼是不够多而不是说太多了。这里如果有一些方式让大家用同样的时间，但是经历更多、思考更多，确实是没有坏处只有好处。
所以对于微信事业群的同事，大家用活水计划去让一些想要转换岗位的人让他没有后顾之忧可以非常自由地转，同时我们也上升到总监这个级别，制定出一个微信事业群内部的措施——微信事业群的总监如果没有经过轮岗是不能往上晋升的，必须要有轮岗的经历。
可能有些同事会觉得这样会不太舒服。当然不能太舒服，必须要走出一个人的舒适区域，面对新的挑战。但是以后回头来看，这样的结果其实是有好处的，通过一种轮岗的方式可以让自己接触更多的锻炼。
总结一下，我想要分享的主要有两点：第一，关于对我们产品、我们业务思考方向是不是真的从用户角度来出发来考虑；第二，关于敏捷性。即使对微信来说，我们的前期迭代很快，后面迭代速度确实变得越来越慢，所以这也是需要大家思考的。