敏捷全球之旅2012 中国 @深圳敏捷部落
主
讲
时
地
记 录：白恩鹏
演讲简介：
关键词：组织改革 产品极致 开放心态 轻敏捷
开始：
(主持人)欢迎大家加入敏捷深圳之旅，通过本次大会，来打造深圳的敏捷社区，为大家创建一个可以互相交流的圈子，促进深圳IT精英们的成长。那本次活动也得到了@平安科技（深圳）有限公司的大力支持，在此表示感谢。同时感谢@图灵图书为大会的互动提供了奖品。那么话不多说，就有请我们的第一位讲师，来自敏思特咨询的首席合伙人，腾讯高级管理顾问——@王晓明。其实他还有很多的Title和经历哈，接下来就让我们欢迎他来为大家一一介绍。
（王晓明）非常感谢大家能在周末一大早来参加这样的一个活动，这上面也讲了我们这个活动（@深圳敏捷之旅）也举办了三期。没一起都会获得大家很多的支持，有很多的都是老朋友，老面孔了，有些是新朋友。那么希望今天这个活动，大家能够开心的度过。
OK那么今天我分享的这个主题《导入创业精神》。这个听起来是一个很虚的主题哈。那么我们在虚一点。那么我是一个咨询师，同时还有各种title：敏思特的首席创始人，合伙人，现在是腾讯的高级管理顾问组织转型的导师，同时帮助腾讯的进行了多次的大规模的组织转型，另一个头衔是@创新工场的创业导师，曾经是@华为的首位敏捷转型咨询师。非常幸运的成为了今年商业评论的管理开发者的撰稿人。如果大家有兴趣的话可以看一下，第九期，关于敏捷管理的文章，这也是在中国首次在这样的刊物上发表于敏捷相关的文章。
首先今天我想通过一个一个非常真实的，惊心动魄的故事，今天与会的一些同学也经历了这个项目。在去年末的时候很幸运的与腾讯合作，接受这个部门团队的邀请，和这个团队合作，帮助这个团队去解决它的一些问题，或者帮助发现有没有要解决的地方。
那么首先我介绍这个团队的时候，这个团队几乎是整个部门里最优秀的三十几个人组成的。无论是在产品设计方面，还是在技术方面都是非常优秀的，尤其是在美术方面，他们部分人甚至是在@暴雪工作过。这个团队有着非常高远的志向：打造一款面向全球的高品质竞技游戏。这个在我看来，简直是我心目当中的一个梦之队。
继而我发现这个团队非常的优秀，但是这个部门的总经理希望我能和团队合作，发现团队的一些问题。我就和团队的一些核心的成员进行了一些访谈，那么首先我问了一下他们的总经理和产品总监，他们给我的一个反馈就是：团队的效率还不是特别高。有么有可能帮助团队提高些效率。我个人认为这么优秀的团队，效率不应该低，对吧。然后我就再问一些更深入的问题，发现他们不是想说明的特别的透彻。
然后我又进一步询问了其他的团队成员，这位（产品策划）成员说，在做这种大型的游戏，对工具引擎要求非常的高，非常的严格。我们的工具引擎还不是很完备，所以导致我们很难提高这样的效率。
接下来又问了美术的负责人，我们希望产品（经理）不要再改方向了，我们之前已经改过几个方向，团队很痛苦。
【注释】：这里的方向一般是指美术风格，比如角色的性格，背景。一般的，美术绘制要保证游戏角色，场景在剧情，历史，故事的条件下保持一致。画风，色彩，细节，纹理等细节都要保持高度的一致。美术出图，一般要经过原画，审核，定稿，上色，细化等复杂的工艺过程才能提交。一旦在最后要求修改性格，内容，故事背景，那么只能从原画开始从新定义，修改，然后又是重复漫长的工艺过程。所以修改产品方向，容易影响到美术风格，修改的代价是非常巨大的，也不是一般人承受得住的。英国的敏捷教练Jez Humble曾在清华大学深圳研究院做过一个@持续交付的分享，他举了一个宝马和吉普的例子：如果宝马坏了，要修缮，代价是非常昂贵的。这么多艺术家的美术成果一旦要改方向，要改动的代价很大。
在这样一个团队，在只有30人的情况下，团队是有一个比较复杂的组织结构的。（尼玛麻雀虽小，五脏俱全）。其实就我理解，30人一个老大，带着剩下的人干就好了。但是当时团队里，有3-4层的组织架构。团队里就会很奇怪，可能很多需求可能来源于产品总监，有可能来源于具体负责的主策划，有可能来源于项目经理，团队就会很纠结，有时候不知道该听谁的。甚至在这么小的一个团队里都会产生一些政治的因素在里面：我到底该听谁的，我到底该和站一队。这让我非常非常的惊讶。
整个项目里，很多信息也不够透明。有很多成员的经验，阅历非常的资深，但是他并不了解需求为什么这样做，所以导致他们的能动性也不是特别强。
那么综合这些各种各样的问题，就像刚才这个部门的总经理所说的效率不高，或者他察觉到和其他项目比较，效率没有那么高，还有很大的提升空间。部分同学，其实我们聊得时候，我们发现了一些问题，然后更他们（管理层）的时候，管理层就会觉得：我们应该没问题，大家这么辛苦的加班，每天工作得很晚，我们应该效率很高，我们应该没问题。具体问道一线的员工，我非常喜欢和一线的员工，工作非常苦逼的屌丝男。他们会觉得说：这个项目挺好的，我们有这么多优秀的人在这里。但是有的人会说：老子实在是干不下去了，我TMD 的真想离职。所以这种心态非常的严重，我非常担心。我知道，这些很想离职的员工都是非常优秀的行业内的人员，因此我认为这些是亟待解决的问题。
那么我做的第一件事情是什么呢？大家看这个图（PPT）也猜到了一些。如果你是这个敏捷咨询师或者教练的话，你的第一件事情是做什么？（观众答）调整组织架构，这是一定要做的事情。这为观众同学提得非常好。但是我也说过，我是一个新来的，我是一个外务部的，很可能就被大家就说：唉，你这个人，没水平，什么都不懂，还是出去吧。通常会有这种情况。我们不管是内部，还是外部的教练，在进行这种变革的时候，通常很被抵触。而且作为我们（教练）来看，团队本来就很多这样或者那样的问题，但是团队的成员会说：我们是不是没有什么问题，然后我们也很努力。于是我做了一件大家没有想到的一件事情。刚才我们不是说了这个团队的心态不是很开放。所以在这个时候，我去跟他们提建议的时候，他未必会接受：这是我们的问题，我们要去解决。
在朝鲜，他们说的一句话是什么？我们是世界上最幸福的国家（We Are The Best！）那么谁是最不幸福的国家呢？美国。这是朝鲜的理念。所以这个事情就是说，我们的团队是存在问题的。然后让团队自己来说，我们想办法来用一些开放心态的思维方式（来解决这个问题）。所以我们去做了一个培训：开放心态。我记得是在去年的敏捷大会上，我们邀请到一个著名的敏捷大师：Linda Rising 分享了一个敏捷心态(MindSet)
【注释】年近七十的敏捷大师Linda Rising分享了什么是敏捷心态(Mindset），她的演讲以一个小孩子的有趣实验开始，阐明了固话心态和敏捷心态的区别：
1.
2.
3.
4.
5.
6.
研究表明，心态会影响人们选择什么样的目标，面对失败的反应，有关付出和策略的信念和对待他人成功的态度。而这种心态理论对于组织和管理者同样适用！因此我们要积极培养我们的孩子和团队敏捷心态，而不是固定心态！这让我想起了另外一句话：“发展中的人是最可怕的”！保持发展的势头和向上的精神，对于敏捷团队至关重要！(本注释摘自ＩＢＭ中文开发者社区：《Smart
同时我们现在做的这件事的水平，虽然大家已经觉得做得不错了，但是大家觉得这不是终点，这不是最好的，我们一定还可以做得更好。大家可能会遇到一些程序员说我们人员不够，美术人员改方向等很多客观的问题。但是我觉得这些问题一定会有解决办法，只要大家充满信心去做，我们以更乐观的心态去看待我们的问题。
这个Adidas有个著名的口号：没有不可能（Nothing is impossible）！帮助团队看到这些光明点，找到这些解决方法。继而我们就帮助团队一点一点的去解决这些非常具体的问题。从需求来讲，之前是多层管理，那么们的解决办法，你就是产品总监或者产品经理（主策划）你一个人说了算。其他人可以提供意见，可以YY，可以提供各种反馈，最终确定这个事情的优先级，确定验收结果的人必须是策划团队，也必须是一个主策划说了算。我们把这个权利全归于一个人。
我们实现了这个方法以后，我观察了两天，我发现一个奇怪的现象。之前团队都是比较被动的，我站在这里之后（开晨会）。我讲一下我情况，对这个团队的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日
扫一扫
1266
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
