微信团队如此强大，张小龙是用什么方法管理的？

---

作者 DS

8亿用户的微信是中国历史上最成功的互联网产品，没有之一。

除了张小龙带领的微信团队在产品上极度尊重用户的需求，保持克制和优雅的产品理念。

最重要的就是微信团队在成立初期就坚定的使用「敏捷」方法，时刻关注组织的「敏捷」性。

「敏捷」到底是什么？

先从字面上理解，顾名思义，「敏捷」一词包含了两层含义：

一是「灵活」——检查调整，游刃有余；

二是「快速」——天下武功，唯快不破。

什么意思？

张小龙在微信领导力大会上谈到：

关于敏捷开发，我特别希望大家能够多去做一些尝试，我们今天可以想一些与众不同的点子，我们很快把它上线了，然后可以去验证。

如果不对就下线，如果还有改进余地，下个星期再去改它。这是一个能够持续实现你的想法的过程。

这其实就是「敏捷」的原理，既满足产品开发过程中需求的动态变化，又能通过短迭代管理监控项目的实时效果。

究其本质而言，敏捷管理方法很简单：就是“检查与调整”循环。

每过一小段时间就停一停手头的工作，检查已经取得了哪些成果，看看这些成果是不是自己期待的，想想有没有更好的方法。

这一点看似容易，做起来并非易事，需要企业愿意改变固有方式，接受敏捷管理方法。

为什么优秀的公司都在做「敏捷」？

优秀的公司或者说团队，之所以迫切需要「敏捷」这种新的工作方式。像是微信、京东、华为、通用电气、Twitter 会一致采用「敏捷」。

原因就在于当前不少公司的开发项目都会延期超支，而且最后交付的成果还不能用。这明显是工作方法不得当。

很多项目坚持采用「瀑布法」，坚持每件事都要事先规划好，甚至还坚持要求在长达数年的项目执行期之内不能做出任何改变，这是非常荒谬的。

一个组织由小变大的过程中通常会出现一些问题，比如：

执行力下降；发布频率降低；不尊重用户体验；片面追求KPI；制造虚荣指标来获取公司资源；团队满意度降低；团队的能力和创造力受到限；

这一系列大公司病，早期通常被公司管理者忽视而造成极其恶劣的后果。

一些公司的高管更重视营销，商务合作，文化洗脑而忽视用户和团队管理，等到积重难返，后悔不已，但是很难改变，优秀人才流失，企业增长乏力，进入恶性循环。

「敏捷」方法充分考虑到了可能出现的不确定性因素，同时具有鲜明的创造性。

科普延伸：

《图解敏捷教练和 ScrumMaster》

《赋能：打造不确定性的敏捷团队》

这几句话看起来像是口号，但贯彻得到实践当中后，确实带来了和在传统瀑布模型下开发软件截然不同的局面。

它的结构是围绕着学习过程建立的，这样一来，团队既可以评估已经取得的成果，同样重要的是，也可以评估取得这些成果的方法。

这种架构能够为团队提供更加高效的工作方式，帮助他们更好地自我组织，提高工作速度，改进工作质量。

当下竞争超级激烈，如果不采用一种全新的、能够更好地回应客户需求的工作模式，团队未来可能会经营不下去。

这时，只有两个选择：要么改变，要么解散。

如何实施「敏捷」？

无论你们的员工多优秀，作为领导者，你们都必须确保在员工的能力范围之内，努力改善产品的质量和一致性。

因此，第一步就是管理层必须让员工知道，你们非常热衷于改善产品的质量和一致性，对产品的质量具有深刻的责任感。

如果只说不做，那么一切改善都不会出现。行动是最重要的。

1. 聚焦团队，实现高水平业绩：
提升团队业绩比提升个人业绩重要得多，卓越团队的目标远远超越了个体的目标，你们的团队必须拥有完成一个项目所需的全部技能，并且要把项目团队拆解为一个个小团队，团队人数宜少不宜多。

2. 进行周期性项目管理
把你们项目的工作分解开，看看在一个固定的、短暂的时间段内能完成多少工作量。最好以1—4周为一个周期，这个周期称为冲刺。

冲刺后必须展示成果，让每个人知悉一切，再做下一个冲刺循环。

3. 把快乐转化为更高的绩效
提升团队运作的透明度，让下属获得自主感、掌控感和目标感；

在每个「冲刺」阶段结束时，让每位员工找出一个有待改善的地方，在下一阶段予以解决，使团队成员拥有成就感。

员工是否快乐，是预测公司未来业绩的指标，工作原本可以让人愉悦。

4. 80%的价值来自20%的功能
敏捷的魔力在于能帮你把价值最高、风险最低的的事项优先解决。

你需要拟定待办事项清单，确定优先顺序，在战略上着眼于全局，策略上迅速行动。

进行「观察—导向—决定—行动循环」。

以上观点来自，《敏捷宣言》的起草人之一、「Scrum 之父」的 Jeff Sutherland。

工作原本也可以不让人垂头丧气，可以以非常流畅、令人愉悦的方式进行，最大限度的发挥自由和创造力，获得高收益的成果。

「敏捷」在 IT 技术部门的延伸是？

众所周知，「敏捷」延伸到IT部门后，产生了一个从「开发」到「运维」的跨领域问题，就是这两年很热门的「DevOps」

DevOps 的「一个中心，两个基本点」——以业务敏捷为中心，构造适应快速发布软件的工具（Tools）和文化（Culture）。

《凤凰项目》，一个关于 DevOps 的故事，一本关于讲述 IT人的从普通码农历练成为 COO 的非励志小说，一个非虚构的「敏捷」转型故事。

· 如何让一个几乎失败的项目死灰复燃？

· 如何挽救濒临拆分抛售的公司？

· 如何化腐朽为神奇？

关于 DevOps 更深度的讲解：

《DevOps 转型实践》

在玩偶实验室的「开发运维报告说明」中，为了更好地理解企业在采用开发运维各阶段的情况和习惯，我们用基准问题测试了 4039 家 IT 企业。

第一点出人意料的是，在敏捷性性指标（agility metric）和可靠性指标（reliability metric）方面，运用开发运维的高绩效公司远远胜过表现平平的同行：

代码部署频率快 30 倍；

代码部署交付期快 8000 倍；

变更成功率高 2 倍；

MTTR（ Mean Time To Repair，平均修复时间 ）快 12 倍；

换言之，他们更为敏捷。他们的部署代码的频率快 30 倍，从「代码提交」到「成功投产运行」的速度快了 8000 倍。

表现突出企业的交付期以分钟或小时计算，而表现较差企业的交付期以周、月甚至季度计算，如此发展，这些表现差的企业终究会被淘汰。

当一个团队在进行「敏捷」变革时，也在颠覆IT人现有的传统认知，如何让自己和团队更加高效？

该文章在 2018/5/8 23:09:13 编辑过