【录音稿】导入创业精神--专治大公司病—

敏捷全球之旅2012 中国 @深圳敏捷部落

主题：导入创业精神-专治大公司病

讲师：王晓明（敏思特咨询首席合伙人，腾讯高级管理顾问，组织转型导师，创新工场特聘导师，华为首位敏捷组织转型咨询师）

时间：2012年11月17日9:00-10:00；

地点：深圳市高新科技园科技中一路腾讯大厦2楼多功能厅

记录：白恩鹏

演讲简介：

王晓明导师从一个真实的案例，介绍了腾讯内部某游戏研发梦之队的敏捷实践。他们在开始的敏捷转型里要么非常的痛苦，要么自我感觉良好。受部门总经理的委托，他们深入细致的分析了该团队出现的问题，通过组织架构调整和成员开放心态调整，在短短四个月的时间里，将如此优秀团队的工作效率提高了一倍。他们将创业精神注入到团队里，让团队从被动接受任务的状态变为主动追求产品极致的心态。王晓明导师本次分享非常适合正在敏捷转型中的游戏研发团队。如何调整好游戏团队中美术，策划，程序成员之间的协作与沟通方式，如何提高团队成员的主动性，本文绝对是游戏从业人员难得一遇的干货。

关键词：组织改革产品极致开放心态轻敏捷

开始：

(主持人)欢迎大家加入敏捷深圳之旅，通过本次大会，来打造深圳的敏捷社区，为大家创建一个可以互相交流的圈子，促进深圳IT精英们的成长。那本次活动也得到了@平安科技（深圳）有限公司的大力支持，在此表示感谢。同时感谢@图灵图书为大会的互动提供了奖品。那么话不多说，就有请我们的第一位讲师，来自敏思特咨询的首席合伙人，腾讯高级管理顾问——@王晓明。其实他还有很多的Title和经历哈，接下来就让我们欢迎他来为大家一一介绍。

（王晓明）非常感谢大家能在周末一大早来参加这样的一个活动，这上面也讲了我们这个活动（@深圳敏捷之旅）也举办了三期。没一起都会获得大家很多的支持，有很多的都是老朋友，老面孔了，有些是新朋友。那么希望今天这个活动，大家能够开心的度过。

OK那么今天我分享的这个主题《导入创业精神》。这个听起来是一个很虚的主题哈。那么我们在虚一点。那么我是一个咨询师，同时还有各种title：敏思特的首席创始人，合伙人，现在是腾讯的高级管理顾问组织转型的导师，同时帮助腾讯的进行了多次的大规模的组织转型，另一个头衔是@创新工场的创业导师，曾经是@华为的首位敏捷转型咨询师。非常幸运的成为了今年商业评论的管理开发者的撰稿人。如果大家有兴趣的话可以看一下，第九期，关于敏捷管理的文章，这也是在中国首次在这样的刊物上发表于敏捷相关的文章。

首先今天我想通过一个一个非常真实的，惊心动魄的故事，今天与会的一些同学也经历了这个项目。在去年末的时候很幸运的与腾讯合作，接受这个部门团队的邀请，和这个团队合作，帮助这个团队去解决它的一些问题，或者帮助发现有没有要解决的地方。

那么首先我介绍这个团队的时候，这个团队几乎是整个部门里最优秀的三十几个人组成的。无论是在产品设计方面，还是在技术方面都是非常优秀的，尤其是在美术方面，他们部分人甚至是在@暴雪工作过。这个团队有着非常高远的志向：打造一款面向全球的高品质竞技游戏。这个在我看来，简直是我心目当中的一个梦之队。

继而我发现这个团队非常的优秀，但是这个部门的总经理希望我能和团队合作，发现团队的一些问题。我就和团队的一些核心的成员进行了一些访谈，那么首先我问了一下他们的总经理和产品总监，他们给我的一个反馈就是：团队的效率还不是特别高。有么有可能帮助团队提高些效率。我个人认为这么优秀的团队，效率不应该低，对吧。然后我就再问一些更深入的问题，发现他们不是想说明的特别的透彻。

然后我又进一步询问了其他的团队成员，这位（产品策划）成员说，在做这种大型的游戏，对工具引擎要求非常的高，非常的严格。我们的工具引擎还不是很完备，所以导致我们很难提高这样的效率。

【评论】：游戏研发的过程中，程序员除了设计架构，实现需求，版本控制，修复缺陷以外，还要开发大量的编辑器给策划和美术用。如：关卡编辑器，地图编辑器，任务编辑器，动画编辑器，特效编辑器，UI编辑器等，调试编辑器，内挂编辑器。如果是在做游戏的同学，在做研发的时候，要重视工具的研发，游戏的灵魂一定在于策划，品质一定在于美术，稳定在于技术。对于技术出生的产品经理，要重视编辑器开发，别把所有事（苦逼的对齐UI坐标，手动添加关卡）都弄给程序员，反而让策划无事可做，或者无法高效的编辑游戏。

接下来又问了美术的负责人，我们希望产品（经理）不要再改方向了，我们之前已经改过几个方向，团队很痛苦。

【注释】：这里的方向一般是指美术风格，比如角色的性格，背景。一般的，美术绘制要保证游戏角色，场景在剧情，历史，故事的条件下保持一致。画风，色彩，细节，纹理等细节都要保持高度的一致。美术出图，一般要经过原画，审核，定稿，上色，细化等复杂的工艺过程才能提交。一旦在最后要求修改性格，内容，故事背景，那么只能从原画开始从新定义，修改，然后又是重复漫长的工艺过程。所以修改产品方向，容易影响到美术风格，修改的代价是非常巨大的，也不是一般人承受得住的。英国的敏捷教练Jez Humble曾在清华大学深圳研究院做过一个@持续交付的分享，他举了一个宝马和吉普的例子：如果宝马坏了，要修缮，代价是非常昂贵的。这么多艺术家的美术成果一旦要改方向，要改动的代价很大。

问了技术部的人，我们的问题是，我们缺人！如果你再给我更多的人，我们一定能够提高效率。

【解读】为什么技术部会要人，因为事多，而且很杂！举个简单的例子：假如没有UI编辑器，那么控件的摆放一定是由程序员来实现。一个做架构的程序员，让他改UI控件的坐标，外发光，内发光，对于他来说这是很蛋疼的事情。这种事情对于程序员来说，简直就是毫无技术含量，毫无价值的东西。但是对于产品经理来说，界面交互体验又很总要，但是确实缺少工具，所以程序员希望有个打杂的人员来做这种琐事。对于创业型的游戏公司，他们的游戏引擎普遍缺少各种编辑器，于是程序员设计完游戏架构之后，他们要苦逼的去对齐各种控件，做与游戏架构无关的事情。在移动互联，大部分手机游戏的UI交互和操作的实现占据了程序员大部分的时间。这些和游戏无关的内容可以由脚本策划，或者一些编辑器工具来辅助实现，但是开发编辑器的代价很大，所以他们宁愿加人。建议程序员再做游戏研发的之前，先实现核心功能，然后开发编辑器，配置文件，或者让脚本策划来辅助实现一些在程序员看来比较次要，但修改频繁的工作。人固然很重要，但是如果要加人，是否有必要。

我又问了项目经理（Project Manager），项目经理说：“感觉我们团队比较缺乏经验”。这给了我一个很大的问号，这是不是这个部门应该有的风格。这个缺乏经验应该是指对敏捷不是很熟悉，也不是很了解，并且不愿意遵守一些相关的敏捷流程。部分成员感觉自组织性不高，对产品也不是很重视，对产品出现的细节也不是很在乎。然后我们看一下，这个团队工作了差不多一年多的时间，但是还是没有产生一个可以给投资人看的一个Demo。而我们希望6-9个月可以出一个高品质的demo，但还是没有。

和整个团队的核心同学沟通，整体感觉团队的心态都还不是很开放！但是我还没有发现很多问题的细节，或者说没有抓住这个问题的点。所以当时也具体不知道怎么去帮助他们，所以我就做了另外一件事情。那么我的一些同事对这个团队进行了一个x-Ray的扫描。看项目的各个环节，哪些的地方做得好，我们可以保持，哪些地方做的不好，我们可以帮助他们去改进的。

首先我们来看看这个项目的需求管理环节。我做事一般喜欢抓住源头，一般你发现末端出现的问题，很可能在源头就有比较大的问题。需求管理环节，我发现一个比较奇怪的现象：我个人理解一个产品的需求，一个产品的需求只需要由一个资深的产品经理去管理就好了。但是在这个项目当中并不是这样的，我们队整个核心组的了解，大家似乎不是很敢尝试去沟通。对需求的理解是一种多重管理。即，这个需求来自不同方，就是同一个需求的细节来自于产品经理，产品总监，项目经理甚至是小组里的 PO（Product Owner）。这样导致了一个什么样的结果呢？开发人员和美术人员觉得：这个人告诉我A，那个人告诉我B，一会儿又改成C，我不知道该听谁的？所以我很痛苦，我改来改去，也无法改到让大家都满意的程度，所以他们就非常的纠结。

继而我观察了一下整个项目管理的情况：这个团队是1-2周一个迭代。比如他们跑一周的一个迭代，他们整个周一几乎一天的时间，都用来做这样一周的项目计划（Scrum Meeting）。为什么要这样呢？他们说是借鉴了一些国外公司的做法。我发现这样一个细节，要用很长的时间来做项目计划（Project Schedule），所以通常情况下，每个周一晚上，或者周二早上才能拿到这个迭代的迭代计划。这样大家一算，一天（星期一）就过去了。这样一周 5 天的时间就变成了 4 天的时间。那么在这个环节里面，这个团队就浪费了 64.5 人·日的工作量。如果说这个事情，1小时可以搞掂。那么就可以节省了 64.5 人·日的工作量。

【注释】粗略估算 30人× 0.5个星期一 × 4.3个星期 = 64.5 人·日；计划会议一般集体开半天即可，因此 30 人多开了半天。而一个月有 4.3个星期一，所以整体会浪费了 64.5 个人·日的时间。

那么进而我又关注了项目的其他的项目管理活动，比如晨会（Scrum Meeting）。晨会的效果让整个团队觉得非常的失望和不满。晨会大家站成一圈，然后大家说来说去都没什么感觉。很多同学说这个晨会和故事墙（Dashboard / Dash wall/ Kan ban）效果都不好，形式做起来了，但是感觉没有实效。最要命的是做得很痛苦，还不如不要这个。因为这样一些效果不好的实践，导致了每个月又浪费了10.75个人·天的工作量。当时的策略我们先把一些功能做出来，有Bug，没关系。我们放到后面去修理。当时我去体验了一下这个产品，这个产品的潜质非常好，但是bug非常多，还有性能方面的问题也比较多，有的比较严重。有的成员很在乎，提议可否早点去修理。但是有的成员，甚至是当时的项目管理者，这个不着急，放到后面去修理。大家都知道，bug早一天修和晚两个礼拜修成几何级数增长。你今天修和一个月以后修，你花费的时间是远远不同的。不但是工作量的不同，甚至痛苦的程度也不同的。因为你要花更多的时间去处理，而那个bug上下堆砌了很多代码。所以开发人员不是很爽。

【注释】10.75个人·天 = ？

我们发现在这个过程中，负责管理产品的成员（游戏策划），比如开发做完一个功能，他们去验收产品的时候，标准相对比较低。基本的功能完成了，大概过去就可以了。这样导致团队对整个产品做成什么样的品质标准，其实大家的理解是参差不齐的。有人说，这样是不是不行，但有的人会说，这样就可以了。由于是参差不齐的，这样导致产品的整体品质也会比较低。因为这里面，只要有一些短板，只要这个产品有问题，有些bug，你会觉得整个产品的品质是比较低的。所以基本导致了这样的效果。

【注释】短板原理，又称为木桶原理。木桶里的水的高度取决于桶边缘最矮的木条。因此可以推导出：其他较高的木条对水的容量是没有意义的；要想提升木桶的高度，必须要提升最短木板提升的高度。比如这样的一个残酷的案例：要一个团队去比赛，在跑步训练过程里，规则是团队的成绩以最后一名来计算。如果要快速提升团队成绩，就要踢出这名最后一名的成员，于是成绩保证了。如果让该团队踢球，少了一人，整体实力肯定会受挫。但是我们在细想，抽取掉了最短木板，收缩钢箍，合并木桶，水的高度是提升了。但是木桶的容积降低了。因此在产品后期管理的过程，因为一个致命的bug无法修复，最后直接把那个引发那个bug 的关联设计删除，屏蔽掉。最后外观品质保证了，但是产品内容的丰富性大大降低了。团队也许有人落后了，无法换人的情况下，建议其他人帮助这个人，而不是踢掉他。

然后由于项目中期，我们积累的大量的bug，我们需要修复bug，所以导致了项目阻塞的情况，这样导致团队的士气受到很大的影响。

在这样一个团队，在只有30人的情况下，团队是有一个比较复杂的组织结构的。（尼玛麻雀虽小，五脏俱全）。其实就我理解，30人一个老大，带着剩下的人干就好了。但是当时团队里，有3-4层的组织架构。团队里就会很奇怪，可能很多需求可能来源于产品总监，有可能来源于具体负责的主策划，有可能来源于项目经理，团队就会很纠结，有时候不知道该听谁的。甚至在这么小的一个团队里都会产生一些政治的因素在里面：我到底该听谁的，我到底该和站一队。这让我非常非常的惊讶。

整个项目里，很多信息也不够透明。有很多成员的经验，阅历非常的资深，但是他并不了解需求为什么这样做，所以导致他们的能动性也不是特别强。

那么综合这些各种各样的问题，就像刚才这个部门的总经理所说的效率不高，或者他察觉到和其他项目比较，效率没有那么高，还有很大的提升空间。部分同学，其实我们聊得时候，我们发现了一些问题，然后更他们（管理层）的时候，管理层就会觉得：我们应该没问题，大家这么辛苦的加班，每天工作得很晚，我们应该效率很高，我们应该没问题。具体问道一线的员工，我非常喜欢和一线的员工，工作非常苦逼的屌丝男。他们会觉得说：这个项目挺好的，我们有这么多优秀的人在这里。但是有的人会说：老子实在是干不下去了，我TMD 的真想离职。所以这种心态非常的严重，我非常担心。我知道，这些很想离职的员工都是非常优秀的行业内的人员，因此我认为这些是亟待解决的问题。

那么我做的第一件事情是什么呢？大家看这个图（PPT）也猜到了一些。如果你是这个敏捷咨询师或者教练的话，你的第一件事情是做什么？（观众答）调整组织架构，这是一定要做的事情。这为观众同学提得非常好。但是我也说过，我是一个新来的，我是一个外务部的，很可能就被大家就说：唉，你这个人，没水平，什么都不懂，还是出去吧。通常会有这种情况。我们不管是内部，还是外部的教练，在进行这种变革的时候，通常很被抵触。而且作为我们（教练）来看，团队本来就很多这样或者那样的问题，但是团队的成员会说：我们是不是没有什么问题，然后我们也很努力。于是我做了一件大家没有想到的一件事情。刚才我们不是说了这个团队的心态不是很开放。所以在这个时候，我去跟他们提建议的时候，他未必会接受：这是我们的问题，我们要去解决。

在朝鲜，他们说的一句话是什么？我们是世界上最幸福的国家（We Are The Best！）那么谁是最不幸福的国家呢？美国。这是朝鲜的理念。所以这个事情就是说，我们的团队是存在问题的。然后让团队自己来说，我们想办法来用一些开放心态的思维方式（来解决这个问题）。所以我们去做了一个培训：开放心态。我记得是在去年的敏捷大会上，我们邀请到一个著名的敏捷大师：Linda Rising 分享了一个敏捷心态(MindSet)

【注释】年近七十的敏捷大师Linda Rising分享了什么是敏捷心态(Mindset），她的演讲以一个小孩子的有趣实验开始，阐明了固话心态和敏捷心态的区别：

1. 固化心态认为能力是不变的，像身高一样；而敏捷心态认为能力是可以增长的，像肌肉一样

2. 固化心态的目标是能有不错的表现；而敏捷心态的目标是为了学习

3. 固化心态认为失败有损形象；而敏捷心态认为失败能够得到更多的信息

4. 固化心态尽量避免挑战；而敏捷心态拥抱挑战

5. 固化心态认为只有没有天赋的人才需要努力；而敏捷心态认为努力是精通的必经之路

6. 固化心态的人面对挑战的表现是无助的；而敏捷心态的人面对挑战表现出了良好的适应力

研究表明，心态会影响人们选择什么样的目标，面对失败的反应，有关付出和策略的信念和对待他人成功的态度。而这种心态理论对于组织和管理者同样适用！因此我们要积极培养我们的孩子和团队敏捷心态，而不是固定心态！这让我想起了另外一句话：“发展中的人是最可怕的”！保持发展的势头和向上的精神，对于敏捷团队至关重要！(本注释摘自ＩＢＭ中文开发者社区：《Smart DJ解读中国敏捷大会》)

他的这个演讲是关于怎么开放心态，我把这个借鉴过来，做了这样一个培训。结构收效还是让我很惊讶的，这些同学经过一段时间之后，内心的结有点松落了，愿意去听这些东西。这就是当时我们做的第一件事情。

同时我们现在做的这件事的水平，虽然大家已经觉得做得不错了，但是大家觉得这不是终点，这不是最好的，我们一定还可以做得更好。大家可能会遇到一些程序员说我们人员不够，美术人员改方向等很多客观的问题。但是我觉得这些问题一定会有解决办法，只要大家充满信心去做，我们以更乐观的心态去看待我们的问题。

这个Adidas有个著名的口号：没有不可能（Nothing is impossible）！帮助团队看到这些光明点，找到这些解决方法。继而我们就帮助团队一点一点的去解决这些非常具体的问题。从需求来讲，之前是多层管理，那么们的解决办法，你就是产品总监或者产品经理（主策划）你一个人说了算。其他人可以提供意见，可以YY，可以提供各种反馈，最终确定这个事情的优先级，确定验收结果的人必须是策划团队，也必须是一个主策划说了算。我们把这个权利全归于一个人。

那么在这个过程中，我们发现的各种问题。比如其中一个很奇怪的现象，我们在测试一些功能的时候，发现一些bug，然后发现这个迭代可能做不完了。项目经理可能会说，算了，我们转到下一个需求吧，于是放到下一个迭代了。这是就把很多bug当成需求去修复，从而放到后面来安排，这样反而导致很多问题（如：技术债务）。我们把所有的问题，所有的需求，所有的任务还是功能都安排到一个需求池里。请主策划来排最终的优先级，然后进入我们的迭代需求池，这样我们的开发人员就只面对迭代需求池。因此不用告诉我先改什么，后做什么，我只需要看这个迭代需求池就可以了。如果有任何的疑问，可以去跟策划团队和主策划沟通这块地方，我先做什么，后做什么。这样团队就不会纠结于我到底要听谁的，听老板？听这个迭代需求池。因为这个迭代优先级是由整个策划团队讨论出来的。

第二期，我们发现无论是整个项目计划，还是迭代计划会议，还是晨会都会出现浪费时间的现象。那么我们就逐一去解决，比如迭代需求会议，我们把一些准备工作提前。把团队分成几块分别去做迭代计划会议，这样可以保证整个迭代计划会议从原来以项目经理为中心的一天的会议，变成了一个小时，可以由一个小型团队来做的，这样就节省了64.5人·天的时间。

我们对晨会和故事墙进行了一些优化，之前的晨会可能是一个leader带着其他的同学讲一讲。这样大家都对着leader讲，于是我们弄了个玩具，拿到玩具的人就开始讲，讲完后抛给其他人，这样就不会给团队客观上造成一个核心，大家都感觉到是公平的，而且这个过程大家都觉得比较有趣。这样的迭代会议不会变成向一个人去汇报，我来展示我自己的工作。我的工作完成否，我的计划是什么样的，让大家非常自信的去做这样的一个事情。而且开晨会，团队没有这样一个核心。

我们实现了这个方法以后，我观察了两天，我发现一个奇怪的现象。之前团队都是比较被动的，我站在这里之后（开晨会）。我讲一下我情况，对这个团队的leader或项目经理汇报。一大早之后，我们一个比较资深的美术同学，她就主动到故事墙上来，主动来移动一下卡牌(尼玛原先是PM在移啊！)。这个在过去一年时间里面，是从来没有发生过的。团队没有这种自发的行为，因为他们就觉得我就被动去晨会里给你汇报！那么这个时候，她认为，这是我的事情，一会儿我讲的时候，不能丢脸，因为我确定我在一个最新的状态，那么她就会主动的去移动这些卡片。那么晨会的时候，大家就会认为在晨会的过程中，我做的东西是不是符合我的计划，如果没有完成，会觉得很丢脸，会觉得压力很大。所以整个项目，多数情况下进展得比较顺利的，个别时候大家也会比较着急。会拉一下相关的同学，这个迭代，可能我们的项目迭代计划有问题（主动质疑计划的不合理）。之前的很多故事卡的移动也非常滞后，很多时候靠我们团队的 leader 去移动这些故事卡。现在要求每个团队的成员自己去移动，并且能够发现一些问题。（比如看板里，Testing的卡片太多了，大家就会知道团队瓶颈出现在测试环节上。）如果在周四挤兑了太多的任务，大家会自己主动想办法解决这个问题。

当我们把这些比较好的实践，用一些比较科学的方法搭建好后，我们要把这个团队的节奏建立起来。我们把整个一周的时间固定下来，比如说每周一要开一个迭代计划会议，我们规定是一个小时，于是我们必须在一个小时之内搞掂，而不会去浪费其他时间。那么团队成员就知道，整个一周哪些时间是可以用来安排正常的开发，哪些时间可能用来做一些讨论，计划会议，这个团队会非常好的管理着他们自己。但是会有多花一些时间去讨论，但是这种情况会相对比较少一些。

那么我讲到的之前的这种多层的组织架构是有问题的。一个产品总监的具体想法要落实到一个开发人员身上的话，要经过3-4级的过滤。大家都知道，每越过1级，交流的成本会增加，信息的准确度大大降低。所以最低级和最高级的理解，已经是天差地别了。那么我觉得这些管理人员的属于职能型的，美术方面的专家（美术总监），技术方面的专家（技术总监）。他们非常不擅长于管理，那么项目经理会把整个项目的信息流给垄断。敏捷项目管理中，项目经理的职能是什么？他是管理者吗？他应该是一个很好的教练，同时还应该是一个服务者。他应该帮助团队发现问题，帮助团队解决问题。而不是让项目经理自己去解决这些问题。

整个项目管理的风格不适合类似于创业团队的非常高效的沟通方式。所以我和部门的总经理和部分同学商议一下更合理的解决方法：我们把组织架构和团队进行一个非常大的调整。

首先，项目经理未必适合我们团队的风格。于是我们把他给安排到另一个国际化的团队里。他们非常重视周密的计划，非常细微的沟通的。于是我们的团队里不需要项目经理！我们把刚才这些艺术总监，技术总监，主策划（产品总监），他们不愿意做管理，他们更愿意在专业领域里做一些突破。那么OK，就让他们在专业领域里对这些同学进行辅导。产品总监直接对应到每一个特性团队。每个特性团队里，我们请一个特定的同学做我们的leader。这种人是一个兼职，他有他的本职工作，兼职工作是保证他们特性团队里的产品按时交付。他们就是一个兼职的项目经理。那么这个团队里就没有强烈的管理氛围，这些人是专业性，另一些人则是兼职干活，最终管理的人只有一个人。他就负责主要的管理和沟通的。其他人就主要为这个产品服务，大家把这个产品做好。于是大家可以花更多的时间去做产品，而不是管理。之前是管理的人多，做事的人少；现在变成了，几乎都是做事的人。

之前是一个团队有一个大的计划，现在变成每个小团队都以自己的小计划。但是产品总监会给大家设定一个目标，整个月结尾大家的目标。说到整个目标，我们把这个团队只有一个目标的情况：“整个月结尾我们要完成神马！”我们把这个目标变成我们的基础目标，与此同时，我们设立了一个挑战目标。我们跟团队的成员说，我们做完这些基础的工作之后，还会有更大的挑战。试运行了一个月以后，我们团队给我一个惊喜的结果。我们的基线目标完全完成，挑战目标大部分完成。这让我发现我们的团队，还是有上升空间，还是很有潜力的。大家想办法去消除浪费，把事情做得更好，就会想出很多种办法。

这里有一个比较非常典型的例子。当时我们有一个做游戏角色的特性团队的leader带领整个团队去发现整个过程里出现的一个问题。之前做一个游戏角色需要4个月的时间。基本上是一个串行的过程，在这个同学的带领下，我们把整个过程变成并行。我们可以使用替代资源，把游戏的核心玩法给做出来，然后团队在这个基础上不断的打磨。等着demo做好之后，在等两个月，美术资源到位之后，再花不到一个礼拜的时间，再整体实现到程序里。这样做一个英雄，基本上缩短到1个月。大家可以想象一下4个月到1个月这是一个什么样的改变。这个团队的工作效率有多大的提高，是显而易见的。我们在场的这位工作人员会说，我们一个月会产出4个角色，以前是一个角色都做不出来，我们团队的效率不断的在提高。

在这个过程中，团队文化也在潜移默化的改变。这种文化不是喊口号的文化，而是做事情的方法。之前提出需求要等待很久，后来变为团队自主来决定做什么，团队成员的参与度提高，之前很多美术都没有参与感。现在是我有这样一个想法，我迅速的给我自己的团队，我更leader沟通，我要立刻去做了。大家之前会等老板排计划，现在变为成员们觉得，团队是我的，这个计划也是我的。我要去安排一下，什么才是高优先极的，什么事情才值得做。我们去和团队的leader去沟通优先级，于是立刻去做。在之前，很多同学都是自己被逼着加班，那么到现在很多同学都会在周末花半天的时间把角色再好好画一下。

这里面还有很多很多的改变，从之前的依赖，被管理方式变成一个自组织，组我驱动的一个方式。整个组织架构的改变，以及项目实践中的改变对团队文化形成巨大的改善。团队形成了一个非常开放的心态：乐于学习，追求精品和持续改进。我们有一个给跟踪团队进度的同学统计了一个表格，整个团队的效率。计划的饱和度，实际速度都有了非常大的提高。第一点速度在40%左右，然后提高到了50%。计划饱和程度也翻了一番。经过四个月之后，我们把项目的效率真实的翻了一番。在场的很多同学在项目管理当中也会遇到很多的困惑和问题。有没有人把团队在四个月的时间里提高1倍。如果没有的话，大家回去思考这个案例。

我总结一下，我之前讲的这个案例，最核心的点是组织架构的改变。让团队知道基线目标和挑战目标是什么？这个团队在我刚开始看来，是一个典型的大公司的一个团队，等四个月之后，我发现这个团队更像一个创业型团队，一个有着创业精神的团队。大家不是接任务，去做任务。

相比这个团队，我去了解其他很多团队和其他项目，我发现这些团队有个共同点。

他们的团队的组织架构非常的扁平；团队会像真实的用户思考；整个团队都有一个把产品做到极致的决心和态度。任何一个细节我都不放过，差一点点也不行，这就让大家有这种态度。前两天我和一上海的产品总监沟通：这个游戏环节，做得好不好，我也觉得挺OK，把他发布也可以，但是一旦发布，我后面还有两千多例类似的问题被放走。那么我的产品整体品质就下降了。那么我们也不可能做成世界一流的MMORPG。腾讯多数这样的团队使用非常科学的方法，不仅仅是敏捷方法，还包括很多其他方法。

这里我想跟大家分享一下，我看到这些团队，有一些项目。我学习到一些非常宝贵的经验，像用户一样思考。首先要了解真实的用户，让他们非常非常的爽。这里给大家举一个小故事。

一个精神病院，里面有一个病人，他和其他病人不一样，他非常的奇怪，他每天早上九点钟会打一把小花伞去蹲墙角，一蹲就是一天。精神病院的医生觉得太奇怪了，又不吃药，直接把他架走了。架走到病房里之后，他还是拿一把小花伞走到病房墙角下，继续蹲着。医没有任何办法，就请了一个心理医生，这位心理医生看了这个情况之后。他每天九点钟也打折一把小花伞，蹲在病人的旁边。第一天过去了，病人走的时候，他也跟着走。第二天还蹲在他旁边。这样过了一个礼拜，从来不说话的这位精神病人终于说话了：你也是一朵小蘑菇吗？这个说明了什么？只有和用户在一起，和用户生活在一起。了解他们真实的工作场景，生活场景，才能真正了解用户，他们的想法是什么？

我们刚才有一个真实的例子是：大家可以购买午餐，这个午餐挺便宜的。有部分同学会认为：我不买午餐就无法参加下午的 Open Space！我当时就吃惊了，这怎么可能呢？没买午餐也可以参加下午的 Open Space。其实我不明白用户是怎么想的。

当我们制作这种大型的游戏的时候，对用户的了解是非常重要的。我们做一个英雄场景，用户作为一个英雄去极大怪兽。但实际上是这样的，密密麻麻摆满了用户。这是一个真实的游戏场景，我们的用户不是一个人玩，是一堆人这样玩。如果没有和用户在一起，你永远无法了解到用户的真实想法。当我们设计一个游戏的场景，我们希望每个玩家构建自己非常漂亮的城市，盖各种高楼大厦。实际上玩家是这样玩的，他把整个所有土地里面都建成了农田来获取收益。他甚至拆掉所有房子，建成农田。还有同学在这块地上摆了一个字：“办证”！你永远不知道玩家怎么玩的，你没有和玩家在一起，你不知道玩家是这样玩的。

我们做这个大型的游戏的时候，我们真心的去走访，到网吧，到玩家的家里，去看看他们是怎么玩游戏的，他们的心态到底是怎么样的，他们需要什么样的帮助，什么玩法才能给他们带来真正的快乐。这是我们要做的事情。之前我们认为我们的游戏用户会集中在北京，上海。但是我们发现这些用户基本上都是宅男，基本上都在2、3线城市。这个和我们的认知是非常不同的，国外也不是这样的。

产品上线之后，我们通过后台的数据，发现用户在使用过程中，哪些地方被卡住了。哪些地方不爽，哪些地方有问题。比如这块地方流失比较严重，我们挑出来，不断的去研究。然后细化出来，逐一去解决。更有意思的时候，当你深入玩家。我们进入到玩家的QQ群，论坛，微博，你发现很多很有意思的事情。我们之前做了一个版本，有些玩法，玩家并不是很喜欢。他们会说：“你们搞成这样很牛啊，人人智商都是250”。大家都觉得这里要改，但是开发人员会觉得很欢乐。“你们御龙能不能快点”。也有的玩家提出了：谢谢你们的努力。虽然之前有玩家来喷，来吐槽，我们觉得有压力，但是我们愿意去改。当玩家对你们进行鼓励的话，大家会更好的做这个产品来给玩家。

然后我们希望把整个产品能做到极致。大家都知道，有一个问题：产品经理会说，我们做这样一个玩法吧，或者开发这样一个功能。但是开发人员会说，我实现不了！多数人都会遇到这种情况。这很难实现产品经理（游戏策划）对一个极致产品和优秀产品的诉求。在实际的经验里面，个别时候，我们会用一些变通的执行来解决这个问题。

给大家讲一个小故事：这是在某公司的年会上。年会结束的时候，在举办年的大厦的八层。大老板说我们今天的会议结束了，我想知道看大家谁最有执行力。与会的管理人员都深深的举手说：我最有执行力。老板看了看窗外说：好，你们谁从这里跳下去。团队里一个最有执行力的同学叫王二，无论如何要证明他有执行力，然后和同事们道别，一只脚跨出窗外，准备跳下去。这时候老板拉住他：年轻人，别冲动。我希望你跳下去，请你要思考一下我的这个需求是不是真的合理。我真正的需求是有一个人能够站在一楼上！从八楼到一楼有很多很多的办法，未必是真的跳下去。你要理解我需求的真实性。你想执行可以有各种变通的办法，未必是真的要采用跳下去这种唯一的方法。于是王二把团队叫来，用梯子，绳子帮忙，王二安然无恙的从八楼降落到一楼。同样实现了目标，只是用了不同的方法。

这里我们提一个轻敏捷的理论：

1. 快速验证设计

2. 价值驱动，消除浪费

3. 自主性程度

第一点，快速验证。怎么才能快速验证，必须有一个可持续发布的版本，用各种持续集成工具和自动化测试工具，让版本可持续的发布，任何一次构建都能反馈出一个健康的版本可以部署到市场里发布。

第二点，质量保证测试。有人问：是不是敏捷就一定要写自动化测试，我觉得未必。我辅导的团队没有写自动化测试，他们依然可以保证质量。即多级保证质量，需求质量，需求写得非常清楚，不至于让团队在开发的过程中有大量的返工，不至于让团队过度的纠结。当一个版本开发完毕之后，首先自测，然后请产品经理（游戏策划）帮忙测试，最后请测试人员帮忙测试。而不是整个版本测试，当一小个功能做完以后，立刻进入测试环节。早测试，提前测试，多测试，这样形成多级的测试来保证质量。

第三点、我们一定要对用户的行为进行记录。通过记录来发现用户哪些行为是哪些事合理的，哪些有问题，哪些是遇到磕盼，我们把这些解决了。通过数据来解决这些问题。我可能给团队一个目标，让大家去实现这个目标，让所有信息透明。不至于说，某位成员因为不知道信息而走了大量的弯路。而让整个项目信息透明。这样就可以让团队形成压力，知道我们的进展得是否顺利。如果在敏捷实践的过程里，任何东西如果你觉得是形式化的东西，立刻就扔掉，永远不要接触这样的东西，任何一个实践必须解决某个问题。或者提高你的效率，或者改善你的质量，或者改善了你沟通交流的方式。如果都没有改善的话，那么这不是一个好的实践，不适合我们的实践，或者我们的实践没有做对。

当我们把目标确定下来的时候，团队成员会说，这个和我们的切身利益是相关的。大家是认可的，你做好了就有很好的利益。多余的会议，流程，汇报，我们不需要做这些东西，我们需要花更多时间做产品。不断通过用户CE去了解哪些地方可以去改进。

最后我们希望团队完全自主式的前进，让老板充分授权。现场有很多管理者，你回去想一下，你有没有给你的敏捷团队充分授权。为大家定义清晰的目标，并且能放手让他们去干。在他们遇到困难的时候，你第一时间伸出援手去帮助他们，作为一个教练去帮他们解决问题。

然后就是说，帮助团队成员。在深圳就比较好，我不但把自己的事情做好了，我还让与我合作的同学做起来更简单，更轻松。我做完这个，我再做一些接口性的工作。

把每一件事情都想象成一个产品。我把事情做好，把事情做完，我还注重它的体验。不仅仅是产品的体验好不好，而是做事情的体验好不好，其他与我合作的同事他们的体验好不好。

最后灰色事情，这个事情不该我做。这个事情他做。我听到很多团队有很多种抱怨，这个程序不给力，美术不给力。我经历的很多例子当中，有很多吃亏的同学，当遇到一些灰色地带的时候。争抢灰色地带同学，最后都获得了更好的职业发展，他们比其他人更好，更快的成为经理，总监，待遇也有很大的提高。

接下来我给大家放一段视频：《永不放弃》

……（10分钟，看视频，很震撼!）

Q&A略过（录音不完整，有完整的录音的可以提供给偶，或者补充进来）。

整理注释：Jason·White @ Shenzhen

2012年11月18日

【录音稿】导入创业精神--专治大公司病——Scrum敏捷游戏开发相关推荐

大公司病怎么治？贝索斯致股东信泄露了天机
大公司病怎么治?贝索斯致股东信泄露了天机 4月13日消息,据CNBC报道,美国电商巨头亚马逊创始人兼首席执行官杰夫·贝索斯(Jeff Bezos)日前发表了2017年度致股东信,认为迅速作出决策和保持 ...
也谈大公司病3——治大国不是烹小鲜
2019独角兽企业重金招聘Python工程师标准>>> 序多数大公司大了后都不可避免会遇到大公司病,机构臃肿,行动缓慢,协调困难,思维僵化.为此,大公司采取了各种各样的做法,建设 ...
博文共赏：也谈大公司病3——治大国不是烹小鲜
[编者按]<博文共赏>是InfoQ中文站新推出的一个专栏,精选来自国内外技术社区和个人博客上的技术文章,让更多的读者朋友受益,本栏目转载的内容都经过原作者授权.文章推荐可以发送邮件到edi ...
张勇向大公司病开刀：面对未来，变阵是为了更好地应战
一家万亿市值的公司试图从内向外"拆开"自己,再重新"组装",这可能是2023年以来关于组织变革最重磅的新闻. 2023年3月28日晚,阿里巴巴集团董事会主席兼首 ...
也谈大公司病2——减少错误不等于增加成功
序多数大公司大了后都不可避免会遇到大公司病,机构臃肿,行动缓慢,协调困难,思维僵化.为此,大公司采取了各种各样的做法,建设企业文化,调整组织机构,更换领导人,加强流程规范,建立特区,建立快捷通道,引 ...
博文共赏：也谈大公司病2——减少错误不等于增加成功
序多数大公司大了后都不可避免会遇到大公司病,机构臃肿,行动缓慢,协调困难,思维僵化.为此,大公司采取了各种各样的做法,建设企业文化,调整组织机构,更换领导人,加强流程规范,建立特区,建立快捷通道,引 ...
也谈大公司病1——正确是最大的错误
序多数大公司大了后都不可避免会遇到大公司病,机构臃肿,行动缓慢,协调困难,思维僵化.为此,大公司采取了各种各样的做法,建设企业文化,调整组织机构,更换领导人,加强流程规范,建立特区,建立快捷通道,引 ...
《大公司病》阅读笔记
<大公司病>阅读笔记原文地址 http://www.infoq.com/cn/news/2012/10/big-company-disease-1?utm_source=infoq&am ...
Atiti.大企业病与小企业病大公司病与小公司病
Atiti.大企业病与小企业病大公司病与小公司病 1. 大企业病,一般会符合机构臃肿 .多重领导 .人才流失的特点.1 2. 大企业病避免方法1 3. 小企业病 1 3.1.1. 表现1 4. 如何 ...

【录音稿】导入创业精神--专治大公司病——Scrum敏捷游戏开发

【录音稿】导入创业精神--专治大公司病——Scrum敏捷游戏开发相关推荐

最新文章

热门文章