点晴MIS内部交流教程加入收藏
新手上路
教程搜索
 您的位置:点晴MIS系统问题答疑『 微信好文 』浏览当前帖子  
教程帮助  

  教程搜索
  搜索范围: 搜索方式: 关键词(可用空格分开)  

  作者及文章信息: 本文热度:2474 % 
admin

积分:81500
等级:网站管理员
文数:8928
注册:2004-7-20

  信 息   主 页       

楼 顶 

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


作者 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 编辑过

  离 线  2018-5-8 23:09:02 
  本文章共有 0 页, 0 张回文,每页有 10 张回文 >> [ ]
页码:
Copyright 2003-2018 ClickSun All Rights Reserved