技术团队启示录：TOP100实践案例(txt+pdf+epub+mobi电子书下载)

作者：麦思博（北京）软件技术有限公司

出版社：电子工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

技术团队启示录：TOP100实践案例试读：

前言

作为IT行业最早的一批从业者中的一员，我一直在思考和研发中心管理者交流时谈到的问题，例如“互联网环境变化这么快，我们技术团队该何去何从”、“同样的产品为什么××的用户体验比我们好这么多”，等等。这些问题我无法一一作答，但我认为，有必要于每年在世界范围内，选取有代表性的技术研发实践案例来做一个总结，将一些著名研发团队一线带头人手中的项目以及工作思路分享出来，让更多的有如上疑问的从业者能够从中得到成功的经验或者失败的启示。

全球软件案例研究峰会（以下简称“TOP100 Summit”）已经走到了第三个年头，它是一个通过社区化方式、案例的形式来传递技术管理实践经验的高峰论坛。它在业界第一次在全球范围内高密度汇集了100个研发团队的智慧。TOP100 Summit通过案例“浓缩”了各大研发中心的一线带头人、技术精英甚至是决策者一年来的经验与感悟；呈现了技术从业者眼中的“大牛”们的“私房”方法论；将目光聚焦在互联网语境下研发团队的变革之路上。

TOP100 Summit中所有的分享者都是技术力量的组成部分，他们代表的技术团队是每个技术人心中的“梦之队”。对于所有在技术领域呕心沥血的人来说，能够在一年一度的TOP100 Summit倾听分享者的故事，感受他们的思想，挖掘他们在实战中的经验与教训，总结归纳出一些真实的原理，应该是我们能为他们带来的最大的价值吧。

当然，这个价值不能让参会者独享，这也是精选会议中优秀案例并集结成册的初衷。成功的经验固然值得研习，失败的教训也是宝贵的财富。本书的每个案例都来自于真实的团队，所以每个案例并不是针对个人的赞歌，而是磨砺出一个优秀的研发团队、一个优秀的技术管理者的真实记录。

建立一个案例“智库”是我们的梦想，也是我们的使命。通过TOP100 Summit会议以及本书，我们希望建立一个链接全球优秀“技术大脑”的经验分享平台，打造一个基于全球视野下的技术管理者的“WIKI”，帮助大家在互联网时代开放、自由地汲取案例带来的独特价值，转化为所有研发中心可用的促进成长的案例。

另外，要说明的是，为了使读者原汁原味地感受到作者的风格，本书在编著过程中尽量保持作者的叙述方式。同时受限于篇幅，我们从深入探索的100位研发团队带头人的案例实践精选出了40多个案例进行分享，以飨读者。

最后，案例“智库”的建立远非一朝一夕之功，为了给所有技术管理者带来更高质量的案例，为了推动案例更快速地转化为实际的生产力，我们已经推出了《TOP100全球软件案例精选集》和《技术团队启示录：TOP100案例实践》两本书。我们还将继续努力，一起期待更精彩的案例吧！

路漫漫其修远兮，吾将上下而求索！

对于产品技术的管理者而言，每年都要审视这一年行业的变化，学习其他公司的先进经验，同时提升自己。最好的方式莫过于案例研究，这本书精选了TOP100 Summit的精品案例，系统地讲述了同行们这一年的成绩和启示，值得一读。——阿里巴巴产品经理、畅销书《人人都是产品经理》作者苏杰

这是一本每个技术人都应该收藏的参考书。从世界500强到刚刚起步的小团队，从布局到实现，从设计到研发，每一个案例都带来不同的思考和启发。——用户体验布道师、前三星中国设计研究所用户体验部负责人林敏

企业是创新的源动力，通过此书你可以了解到，在企业内具体创新的方法，而不只是一些空洞的理念。创新也好，提高效率也好，其核心还是在于人和流程的管理，通过本书提供的案例，你能够看到一个又一个鲜活的例子，给人以启迪。——前豆瓣网技术总监清风

在知识爆炸的时代，新的方法、实践和架构等新鲜事物不断涌现，仅靠一个人、一个团队去慢慢摸索是跟不上节奏的。通过这本精选的实践案例集，我们既可以找到互联网企业，也可以找到传统企业是如何通过各种创新实践去探索新产品的开发方法的；可以看到自组织团队这样“高大上”的概念是如何落实到实际组织中的；可以从案例中借鉴架构如何演进以满足高并发和海量数据的快速处理。借鉴精选案例中智能硬件终端产品开发中的各种问题，可以“少踏很多坑”，从而让自己的产品快速推向市场。在产品开发快速迭代的今天，自动化测试成了各个团队最高优先级的事情，通过本书可以看到自动化测试如何帮助产品保证质量的同时进行快速发布。——原百度高级敏捷与精益咨询师袁店明

作为TOP100 Summit“测试管理/质量平台”议题方向的出品人，我亲历了案例的选择和分享过程，感受到了来自Google、Facebook、华为、腾讯、百度等一流公司精英人士的智慧、探索和思考所带来的力量。这种力量不仅仅是知识的力量，更是实践经验所带来的创造力和感染力，能够给我们启迪和鞭策，帮助我们成长，帮助我们克服一个又一个的困难。本书作为一种载体，使可能会沉寂下来的经典案例、一时闪现的灵感与思考所得又重新流动起来，流动到我们身边，和我们的智慧融在一起，产生新的力量。——国内软件测试界领军人物、同济大学软件学院教授朱少民

第1篇　产品创新/用户体验

这是一个追求用户体验的时代，无论是从企业战略角度还是从产品技术变革角度来看，都是在以用户需求来寻找最佳的产品形态，从客户需求驱动产品管理，以用户价值解读产品精神。从交互设计到设计决策，再到情感化产品设计思路……让我们重新审视产品过程中的取舍之道。

产品技术之道——漫谈UC浏览器

移动互联网是一个竞争异常激烈的行业，以往人们说企业兴衰是“三十年河东，三十年河西”，但这对移动互联网行业早已不再适用了。君不见，曾盛极一时的诺基亚和黑莓公司，在过去的短短几年间从如日中天的市场地位，到如今相继落入被收购或等待被收购的境地。

如今的用户对产品的期望越来越高，再加上可选择的产品范围也越来越广，使得产品开发压力越来越大。即便自身的产品有了一点发展壮大的苗头，也几乎不可避免地迎来“三只蝙蝠（BAT，指百度、阿里、腾讯）”的正面竞争压力。产品如何能够在瞬息万变、竞争激烈的行业大潮中，生存下来并扩大自身的用户规模和影响力？这对所有的互联网从业者来说，都是一个需要直面的问题。

优视科技有限公司（UC公司）作为移动互联网行业的一个老兵，一直专注于移动浏览器领域，用心耕耘了9个多年头。从一家只有几个人的默默无闻的小公司，发展到今天在移动互联网领域具有举足轻重地位的企业。UC浏览器也从一个纯粹的网页浏览器工具，发展到今天成为一个可以承载各种内容和服务的平台和生态系统。众所周知，移动浏览器是一个技术门槛很高，各个巨头必争的产品。UC是怎样在历经功能机到智能机的时代变迁和用户上网需求的巨大变化，依旧保持着自身领先的产品优势和市场地位的呢？

让我们把时间先拨回到UC创立的2004年。那一年，手机上网对大多数人来说还是一件既新潮又痛苦的事情。当时市面上还是Java手机为主，终端性能比较差，屏幕和内存都很小。同时，移动网络很慢，下载一个新浪首页差不多要两三分钟，资费也很高。更要命的是手机自带浏览器基本只能看WAP页面，不单页面数量少而且效果也比较粗糙。UC深知用户当时最核心和迫切的上网需求是要一个又快又省流量，还能看Web页面的手机浏览器。

通过深入分析用户需求的关联和本质，UC的创始团队敏锐地意识到“快、省”这两个核心用户需求，在很大程度上是一脉相承的。如果流量变得很小，自然而然网页数据传输的时间就会变得很短，用户就会感觉很快了。而怎样在内容不变的情况下将数据量变得更小呢？很自然就会想到是通过数据压缩。依此类推地进行各种相关分析，并结合自身在通信行业深厚的技术积累，UC创造性地提出了“云+端”的产品技术架构，通过云端服务器压缩网页并做格式转换后，把网页的排版显示结果发送回客户端，使得用户上网的速度一下子提升了很多，同时还具备了当时很多手机浏览器所不具备的Web页面浏览的功能。

一款产品从好用到极致到口碑，从来就不是一蹴而就的。就拿省流量来说，UC浏览器从开始的简单数据压缩到各种综合压缩方法和内容裁剪等同时运用，在保障用户关注的核心内容不丢失的情况下，持续地优化改进。从开始的节省50％～60％的流量，一直到后来最高达90％的流量节省，不断地赢得用户的口碑。此后，UC还针对用户上网输入网址困难、搜索困难、页面浏览要左右滑屏等痛点，不断进行相关的产品创新，持续改善产品体验。UC通过一点一滴改进，使得手机上网从一件痛苦的事情，变成一场轻松愉快的活动。正是这些创新和紧贴用户需求的努力，为UC浏览器赢得了广大手机上网用户的良好口碑，逐步确立了自己在移动浏览器领域的领先地位。

时间一分一秒地走到了2008年的年中，那时候UC在行业内已经小有名气了。当时市场上发生了一系列重要的变化：iPhone、Android等智能机平台已经发布并逐渐突显出未来霸主的气质，同时移动网络也在加快进行升级换代。先前促使UC取得领先地位的流量压缩和页面转码服务，在可预见的未来将越来越难以满足用户追求更炫交互能力，更强上网体验的需求。在发展节奏上，UC一方面加快了原有U2浏览器产品的迭代步伐，希望通过快速的版本迭代来加快对用户问题的响应速度以及提升产品创新的节奏，继续扩大在移动浏览器市场的产品竞争力和用户口碑；另外一方面悄悄地启动了U3全功能浏览器的产品研发。经过3年多潜心研发，U3浏览器终于顺利进入市场，UC也随之成为国内首家具有全部浏览器内核能力的企业。

然而，产品发布远不是产品的终点站，而是产品创新的新起点。在U3浏览器发布后，UC敏锐地看到移动浏览器这个超级App正从一个纯粹的网页浏览工具往移动信息和服务平台方向迈进。于是，UC积极主动地进行了一系列重要的产品布局，包括完善U3浏览器的HTML5标准支持能力、推出具备强大硬件加速能力的U3浏览器产品。此外，还不断地通过产品技术创新来增强UC浏览器的开放能力，先后推出了Web应用中心，UC插件平台、应用书签平台，让UC浏览器具备承载更多功能和服务能力，成为一个集信息服务、移动娱乐、生活服务为一体的移动开放平台。

具备完整内核的浏览器是一个技术含量很高，内部实现非常复杂的产品。为了更好地把控产品发布后的用户口碑，U3浏览器坚持采用快速迭代和灰度发布的策略。通过公司内测、论坛内测、特定渠道灰度发布等方式，提前收集产品的关键体验数据，确保没有问题后再正式推出，让广大用户拿到手上的是经过充分验证后体验良好的产品，避免了不必要的负口碑。如何对这样一个复杂产品做到高质量的快速迭代，又是一件非常困难的事情。UC通过不断学习和总结经验，一方面不断简化不必要的产品研发流程，引入敏捷的开发模式来减少不必要的时间耗损，另一方面非常注重工具完善、知识传播和数据统计分析等，努力让团队成员具备更高的工作效率以及能够更快地发现产品迭代过程中的问题，使得上百人组成的产品研发团队能协调高效地工作，快速推出新版本。

无论是在U2还是U3浏览器年代，UC始终不渝地秉承给用户提供极致手机上网体验的理念。一方面不断学习研究相关产品的优缺点，经过融会贯通和自主创新后，应用到产品改进上；另一方面对产品研发各个环节的人员进行持续不断的教育，让极致的理念深入人心，成为大家做事的习惯。在UC，每当有人觉得某个功能做得已经不错了，很可能一转身就会有人提出疑问：我们真的在这点上已经做到极致了吗？有没有更优化的方式？这些可能来自各方的追问，让我们的产品在推出后赢得了更多的用户口碑。

产品创新和功能开发，从来就不应该是闭门造车，只有更了解用户的真正需求，才能创造出深受用户喜爱的产品。“低头赶路，抬头看天”，除了自身内部的优化创新外，UC也非常重视对用户意见的收集。在UC做产品、研发、测试的很多同学都比较喜欢去泡各个相关论坛，因为那里有来自第一线用户的声音和意见。然而用户虽然了解自己的需求，但不见得能够非常清晰透彻地表达自己的需求。一个经典的产品小故事是，当年福特汽车的创始人亨利·福特曾经这样解读自己的发明：“如果我问我的客户，他们要什么？他们的回答一定是‘一匹更快的马’”。不过福特先生没有去找马，他深刻地理解到客户的本质需求是更快，而不是“更快的马”。“马”只是用户自己所以为的解决方法。

随着产品的用户规模越来越庞大，来自不同用户的声音也越来越多，纷繁复杂，一个不小心就会被带到阴沟里面。面对用户的诉求和建议首先要擦亮眼睛，先分清楚哪些是真正的需求，哪些可能是误导。然后，要透过表面的需求，紧紧抓住用户最内在的需要，采用最合适的方法来满足用户的需求，而不要被“更快的马”所迷惑。

“车机”用户体验研究及设计

纵观车机的发展演进，用户体验发展趋势可以用图1-3来表示。从以前独立运行的个体逐渐发展成为和周边环境相关联的一个节点。从强调机械化驱动逐渐发展到强调情感化和信息娱乐化。图1-3

在这样的发展变化情况下，车机的设计首先就需通过用户调研收集真实的使用情况，以及用户的背景情况，进而决定实际的设计内容。本次用户体验研究和设计主要聚焦在图1-4中的前三个过程：调研、概念设计、详细设计。图1-4三、用户体验的研究过程

在研究过程中分别从社会学、人因学两方面进行了使用偏好分析，从用户需求和使用场景两方面进行了功能的定义。图1-5至图1-13为调研结果，调研的样本为1088。图1-5图1-6图1-7图1-8图1-9图1-10图1-11图1-12图1-13

从这些调研中可以看到男性居多。在年龄层方面，设计师需要关注25岁～35岁这样的年龄段的用户心理和生理特点。而在日常的使用中，上下班以及短途出游旅行的较多。

从人因角度来看，主要在感官、情绪、环境、硬件这几个方面会对设计以及操作造成较大的影响，如图1-14所示。图1-14

从用户的需求来看，又分了重点功能、拓展功能、附属功能三个层次，如图1-15所示。图1-15

人们一般的使用场景包括“行”和“停”两个状态，“行”包括日常行车、长途行车、风雪雨雾；“停”包括短暂停车、堵车、较长时间停车。当用户需求和使用场景进行匹配的时候，就能够较为直观地得出图1-16所示的对应关系。图1-16四、“车机”设计理念

在经过对车内外环境的分析、使用者心理和生理的影响分析、驾驶人员在行车和停车不同场景下的对应需求分析等几方面综合后，可以得出“车机”的设计理念。那就是“安全第一”兼顾“愉悦享受”，如图1-17所示。图1-17

由此可以进一步得出视觉的设计理念和原则，如图1-18所示。图1-18五、“车机”设计方案

在做具体设计方案的时候，将要综合之前的研究细节，同时把握设计中需要关注的点，整合应用，以视觉为例，我们可以得出如下的设计指导：（1）界面主打色采用灰、深蓝等深色系，保证暗光环境下的舒适操作。（2）屏幕可根据光线强弱自动调整亮度。（3）明确可点击的控件设计。（4）清晰易于识别的字体大小，基本不小于24px（16sp）。（5）Default英文字体：Android Roboto。（6）其他语言及中文字体：Droid sans Fall back。

在布局方面，可以有如图1-19的几种推荐。图1-19六、“车机”设计整体构思

在以安全为前提的情况下，人机交互、流程逻辑、页面布局、视觉设计等几方面可以有机地整合在一起，如图1-20所示。图1-20

与海外高端运营商联合创新——中兴设计实践

挪威VPBX项目是中兴通讯与海外高端运营商联合创新设计的实践案例。该项目在概念、设计、开发和交付等项目实施阶段，系统性地引入了UCD设计方法，不仅成功地帮助客户创造了价值，而且提升了产品的综合竞争力。

本次实践适用于涉及人机界面的软件界面的研发设计，用于持续提升产品的用户体验。本次实践的具体过程、步骤和方法可供同行借鉴。二、问题的提出

挪威VPBX是典型ICT（Information Communication Technology）产品，兼具电信能力和互联网能力，主要服务对象是中小型企业以及企业员工。企业员工使用该产品，可以随时随地通过互联网使用虚拟私有电信业务。经过前期与挪威VPBX运营商的沟通和交流，我们发现海外高端运营商不仅对用户体验非常重视而且认识深刻。比如以下几点：（1）认为用户体验是需求的重要部分，需要前期就进行交流。（2）认为界面上的功能交互设计必须紧密结合用户任务场景。（3）认为用户体验工作要贯穿整个研发过程，直到产品上线。（4）认为在整个产品设计开发过程中，要邀请用户一起参与。

想要把该产品设计和用户体验做好，需要将UCD设计方法无缝地引入到中兴通讯的固有研发流程中。然而，这不是一件容易的事情。往往会因为种种原因无法与研发流程进行很好的整合，从而使得UCD相关工作在某些研发环节发生脱节或者被放弃的情况，导致无法真正做到“以用户为中心”。尤其是用户研究和概念设计等工作，若无法在流程中实施，那么最终的设计会显得苍白且缺乏依据。

为了保障产品设计真正做到“以用户为中心”，我们提出与海外高端运营商开展联合创新设计，同时根据运营商和客户的具体情况，做了一些实践尝试，包括针对性地调优UCD设计方法。三、解决思路

我们参考ISO 13407国际标准《Human-center design processes for interactive systems》的方法和流程，结合公司研发流程的特点，最终采用如图1-21所示的迭代设计过程，所有设计活动的最终目的都是获得用户和组织对系统的最佳满意度。图1-21

该设计过程的一个显著改进点是，将“获取用户对产品体验的基本需求”活动作为闭环中的一个环节，即启动每次功能迭代设计的时候，都会对产品体验的基本需求进行回顾和重新确认，而不是只在项目开始的时候开展这个活动。之所以这样，是因为挪威VPBX产品的电信功能逻辑复杂，多个电信功能交叉可能会衍生出新的能力，而这个衍生能力可能会对已迭代设计的功能体验产生影响。

为保障流程及设计的顺利进行，我们组建了专门的UCD设计团队，角色关系如图1-22所示。UCD设计经理负责管理团队，同时作为接口人负责与客户保持对功能需求的同步理解，确保团队朝正确的方向去努力。图1-22

实际上，UCD设计团队由4人组成，其中交互设计师的角色由UCD设计经理兼任。由于挪威VPBX产品的专业术语很多，而且最终交付是英语和挪威语的产品，为了保障Demo和最终版本在界面用语和文档描述上的最佳表达和排版质量，我们协调了一位国际化工程师加入UCD设计团队，专门负责产品国际化方面的沟通和确认。四、实践过程

公司研发流程的四个阶段，我们分别指定了关键设计活动和必要的输出物，如图1-23所示。每个阶段的关键活动环节采取迭代设计，正好与公司的敏捷开发过程紧密结合在一起。图1-23

下面详细介绍具体过程。1．概念和设计阶段

概念阶段的关键活动是“用户研究”，核心是获取用户对产品体验的基本需求，为后续设计提供充分依据。值得关注的是，严谨而又非常注重用户体验的挪威VPBX运营商准备了一个8人组成的用户体验顾问团队。该团队在讨论原始需求和概念设计方案的时候就开始一起参与产品设计，直到产品上线运营。

UCD设计团队承担该用户研究任务，和运营商的用户体验团队保持紧密的沟通交流。我们分别从客户深度交流、竞争产品分析和客户资料分析等三个方面来开展。如图1-24所示。图1-24

具体方法，我们基本参考ISO 13407国际标准，这里不再赘述。值得一提的是，UCD设计经理前后3次飞抵挪威，持续2个月时间与客户面对面沟通需求和Demo。期间客户和我们一起参与设计，围绕用户使用场景展开，在开放、平等的合作氛围中共同讨论最优方案。通过共同探讨，诸如社会、文化和思想差异等这些深层次的问题逐步明确。比如挪威的日历呈现方式与国内不一样，与其他一些欧美国家也不一样；再比如挪威有不少小企业，虽然员工人数只有两三人，但是他们在心理上更希望向客户展现实力和专业的一面。该阶段的过程资料相当多，用户研究的相关输出如图1-25所示。我们最终将这些资料加以整理，输出了《用户研究报告》。图1-25

完成了用户研究，结合对产品和业务的理解，我们就可以开始做设计了。本阶段的主要工作包含四个大部分：信息架构，交互设计，视觉设计和前端实现，如图1-26所示。图1-26

特别值得说明的有以下几点：（1）每次迭代输出的Demo，项目组内会有正式的评审环节。评审由UCD设计团队发起，评审人员包括需求、开发和测试工程师等。评审方式采取逐页面、逐条目进行，一方面评审功能是否满足需求，另一方面评审实现上是否可行，同时确保项目组成员对功能需求和实现细节达成一致理解，避免出现偏差。（2）评审后的Demo会发给客户，由UCD设计经理或需求工程师在挪威现场给客户详细讲解设计方案；同时客户会安排他们的真实用户对Demo进行用户体验测试，每批次参与测试的人员大约15人左右，然后UCD设计团队根据多方的综合意见完善设计方案。（3）每次迭代明确下来的设计方案，都会整理补充到《UCD设计说明书》文档中，一个目的是记录备忘，另一目的是指导开发实现。2．开发和交付阶段

进入开发阶段的时候，UCD设计团队主要工作内容是配合开发完成编码实现，确保最终产品按设计方案实现。期间UCD设计团队会将发现的问题整理成《易用性问题清单》，如图1-27所示，并督促开发修改。图1-27

我们设计活动的最终目的是赢得用户和组织对系统的最佳满意度，所以在产品正式交付给运营商，并且上线运营一段时间后，我们组织了满意度问卷调查，如图1-28所示。从问卷结果看，满意度达到既定目标。同时问卷收集到的反馈意见，将在下一个版本中实现优化。图1-28五、效果评价

通过和客户一起参与设计的合作实践，不仅可以使客户和真实用户及时、直观地感知未来产品，从而提升用户满意度，而且可以弥补研发团队对客户市场的理解缺陷，提升产品核心竞争力，帮助客户创造价值。

这种联合设计模式和协作机制，本身就是一个创新。而且联合设计的过程中，无论功能设计还是界面设计，处处闪烁着创新的火花。大家目标一致，努力向用户提供“最佳用户体验”的产品。

该产品从2011年上线运营以来，用户数量以每年100％以上的速度递增，市场占有率逐月提升，盈利每年上亿欧元，用户满意度得分为每年最佳。该产品现在已是挪威VPBX运营商的拳头产品。六、启示

挪威VPBX项目的实践过程验证了UCD设计方法适用于典型ICT产品的设计和研发，不仅可以有效地提高用户体验需求分析的准确性，帮助客户创造价值，而且可以切实提升产品的综合竞争力。

值得推荐的几个关键实践：（1）“和客户一起参与设计”是联合创新设计的核心点。从项目启动开始，就邀请客户和真实用户参与到产品设计中。（2）有一支专门的UCD设计团队做支持，项目全体成员齐心协力。在每个环节大家合理分工，紧密配合。（3）良好的设计管理，建立闭环的问题反馈和解决机制。踏踏实实做好每件事情，每个环节的输出都力求专业、规范。（4）本次实践采用的过程和方法基本参考ISO 13407国际标准，同时根据项目具体情况做了必要改良。请参阅者实事求是地借鉴参考。七、参考资料

［1］Alan Cooper，Robert Reimann，Dacid Cronin．About Face 3交互设计精髓．刘松涛等译．北京：电子工业出版社，2012．

借力商业技术于空间机器人

五十年前，当我们把人送上月球时，美国航空航天局的技术资金是无可匹敌的。大约在同一时间，我们正在开发第一款像太空侵略者和导弹司令这样的游戏和输入设备。自那时以来发生了不少事情。事实上，大约十年前，游戏产业总营业利润已经超过了世界的组合空间预算，并且差距一直在不断扩大。

很显然，我们需要从三大原因来看待商业合作伙伴。首先，如前所述，他们的预算远远超过我们；他们有更多的资金投入到消费者调研（即设备的人体工程学、耐用性、易学性等）。其次，他们外派的这些设备不仅为公众所足能负担，而且正因为如此，这些设备也到达了大多数消费者的手中。如果我们为已放在观众起居室的设备构建一个应用程序，那么入行门槛就低得多了。最后，美国航空航天局主要从事空间探索，这是我们做得最好的。以我们有限的预算，我们必须寻求商业合作伙伴，来做一些不仅仅对我们的预算有成本效益的事情。二、解决方案

我想更详细地探讨的具体案例是我们的人类机器人系统（HRS）项目。简言之，我们的目标是建立用于控制下一代太空机器人更逼真的界面。这些机器人包括Robonaut2（国际空间站上的一个机器人）和宇航员（一个六条腿、两层楼高、一吨重的机器人）。同时，我们开始着手探索并建造远程环境的栖息地，以及小行星甚至更远的未来机器人任务。

在我们的团队中，我们采用以用户为中心的设计（UCD），如图1-29所示，直接将用户的经验和专业知识用于我们的软件设计中。解决每个问题的一般过程中，一开始都需要在用户研究上花费些时间，进入实地并且在自然环境中与用户们共同坐下来进行考察。对于我们特定使用的案例，这将意味着与地质学家进行实地考察，并观察他们如何工作。利用第一手经验和采访，我们会编制出一个设计方案，并且制定出低分辨率的原型。这些原型通常几乎没有任何互动，虽然它们有时是以数字化的方式设计出来的，但通常还是在纸上设计出来。我们可以用最少的投资快速迭代地设计，同时尽早发现问题，问题发现得越早项目成本增加得越少。图1-29三、进程

我们考虑到的第一个技术问题是机器人的延时操作。操作宇宙飞船往往需要我们提前去思考和计划，因为这需要几分钟到几小时与他们通话。例如，我们最远的太空探测器需要大约15分钟才能与“火星”对话以及大约30个小时和“航行者”对话。为了在长延时的情况下操作宇宙飞船，我们通常每天或每周都做计划，并且每天或每周与他们通话。针对几秒钟（例如从地球到月球）的更短的延迟时间，我们操作的一般策略是“颠簸和等待”之一。基本上，我们发送一个命令，等待看它是否正确执行，然后才发送另一个。我们的研究着眼于我们能否充分利用命令执行完成的等待时间。

凭借我们的原型和设计理念，可以敲定一些可视化的策略，如图1-30所示，允许操作者提前设定机器人适时所处的地点。我们允许用户设置一系列驾驶机器人的预定航点，并且用我们所称的“不确定性卷”来补充界面。这就是由于机械和环境误差，机器人在任何指定时间可能结束的潜在区域。此外，我们介绍了坚定状态的一个想法，这表现于界面上机器人的幻影版本。如果我们在给出延时的规定时间发出新命令，该坚定状态就是机器人的位置。这样一来，只要我们在坚定状态之前进行操作，我们就能根据递增的机器人更新数据来对机器人计划进行更改了。图1-30

现在，我们有一个工作界面，我们以用户为中心设计进程的下一个步骤是通过实验运行该界面。拥有所有附加功能的界面可以改进机器人延时操作的计划时间吗？为了回答这个问题，我们设立了一个利用盒子的测试驾驶课程，并且利用视差修改了商业机器人，以作为我们的测试探测器使用。通过初步测试极少数的候选人，我们获得了不同的结果，并且通过使用我们的新工具，在用户数量上并没有做得更好。我们意识到控制箱界面有一点过强，但是调整过少，我们并没有获得预期的结果。另一方面，我们还在继续接收有关环境可视化和计划工具的响亮的正定性的反馈。最后，我们决定停止测试，并返回进程的设计阶段以进行更多的研究。

我们要解决的第二个技术挑战是在一个远程环境中创造更好的沉浸效果。当我们的科学家研究一个从遥远的星球返回的结果时，他们常常在计算机屏幕上观察它。这提供了有限的视野以及场景被误导的本体感觉。当科学家们聚在一起谈论他们对环境不同的不完整的版本时，问题变得更加恶化。对于这个设计练习，我们开发了一些设置，包括投影穴、屏幕阵列以及头戴式显示器（HMD），如图1-31所示。最后，我们决定使用Oculus公司开发的Rift HMD，用于定位跟踪的转动头部跟踪和VICON动作跟踪系统。从火星探测器现场我们拍摄了全景二维图像，从探测器上的导航摄影机我们收集了三维影像，并且将其二者融合。我们的设置允许用户在火星实地的虚拟环境中观看并走动。图1-31

对于该应用的用户测试，我们决定通过告诉用户绘制一张如他们想象的自上而下的现场地图，来评估火星场景的初步认识。我们会让用户轮流在我们的身临其境的环境中在电脑屏幕上探索二维全景，这是科学家访问这些场景的现有方法。当使用沉浸式系统时，我们所学到的超出了我们的预期。科学家估计的距离超出[T（17）=2.91，P＜****0.02]的2倍，而且估计的角度超出[T（17）=3.27，P＜0.01]的3倍。基本上，在我们的设置中，科学家们能够更好地把握火星场景中指定目标的距离和方向。有意思的是，在二维控制阶段，误差值不仅在用户之间不同，而且他们在不同的方向和路径上也不同。在我们的身临其境的环境中，无论技术水平如何，我们的科学家执行了相对类似的方法。此外，在我们公布结果之前，一半的参与者实际上相信他们已经在两个系统上表现得同样出色。我们的定性数据同样显示，他们喜欢我们身临其境的系统，并且全体一致地表示在将来会再次使用该系统。四、启示

在这两个案例研究中，在我们开始认真对待开发之前，追踪了我们的UCD进程以最大限度地提高设计迭代。对于延时驾驶实验，并没有达成我们预期的结果，但是进程使我们发现与我们早期软件有关的问题，以便今后在项目中节省费用。这两种应用都需要今后的改进和测试迭代，以满足在用户研究过程中的科学家们早期口述的更多目标。利用商业的最新技术为我们正在建设的系统注入新的功能，我们将同样继续进行实验。五、参考资料

［1］http://www.serrewet.com/user-centered-design/

［2］http://www.youtube.com/OpsLabJPL

Netflix在亚马逊AWS云平台上的应用和创新案例

从2009年开始，Netflix逐渐把它的IT系统迁移到AWS云平台，并开始进行业务转型——从DVD租赁商演变为在线视频供应商。Netflix是一个典型的利用互联网和云计算进行大胆创新，并对传统业务实施成功改造的例子。本文将详细介绍Netflix进行业务变革的背景及相关过程。Netflix基于AWS云平台做了许多平台和架构层面的开发和设计，并积极把他们开发的一些工具通过开源的方式分享给其他互联网用户。Netflix在AWS云平台上的最佳实践和工具软件可供更多云计算应用人员借鉴。二、Netflix的背景

每个普通的工作日夜晚，北美约三分之一的流量会经由网络从Netflix进入千家万户。Netflix的流量通常在每晚10点左右登顶，随着午夜到来，人潮尽皆散去，一切又重归沉寂。Netflix是一家成立于1997年的在线影片租赁提供商，其一开始的主要业务是通过提供超大数量的DVD，然后通过邮寄的方式提供给客户。从2009年开始，Netflix逐渐把它的IT系统迁移到AWS云平台，并开始进行业务转型——从DVD租赁商演变为在线视频供应商。经过几年的发展，Netflix成功地将业务模式从物理的DVD租赁转型为以提供在线视频服务为主。除了跟传统影视节目供应商合作外，Netflix还开始自己制作节目。它制作的连续剧《纸牌屋》不但创造了访问高峰，还开创了在线视频服务商原创作品获得艾美奖的先河。按照智能宽带网络解决方案供应商Sandvine的数据，目前在高峰期，Netflix的互联网下载流量已经占到北美地区的三分之一，而支撑Netflix的整个IT系统基本上构建在AWS之上。三、面临的挑战

Netflix首先面对的是一个业务战略上的挑战。在2007年2月25日，Netflix宣布了他们的一个重要业务里程碑——他们邮寄了10亿张DVD。但是随着互联网技术和终端设备的快速发展，传统的邮寄DVD方式显然不是未来的发展方向。当时，他们遇到了典型的创新者困境：传统的邮寄DVD方式的业务在那个时候是他们的主要收入来源，如果开展在线视频点播业务会不会给他们已有的成熟业务造成冲击？

Netflix最后决定向自己挑战，开始进行业务转型。开展在线视频服务对Netflix的IT基础设施提出了更高的要求，因为用户从选择、购买过程服务的消费完全依赖于他们的IT平台。Netflix在构建运维自己的IT基础设施和业务转型过程中也遇到了一些挑战。一个是在2008年8月，Netflix发生了一次大规模的宕机事件，这使它在3天内完全无法寄出DVD，每天的业务损失高达几百万美元。后面的事故分析发现是自己运维的数据库系统出现了严重问题。另外一个挑战是Netflix发现自己的业务发展非常快速，IT部门不能及时响应业务层面的需求。IT部门也来不及构建足够的数据中心容量来支撑业务的增长。图1-32记录了Netflix实际API请求数量的增长情况，其需求增长超过了数据中心容量。

同时，在进行业务转型的过程中，每次产品的发布（比如基于iPhone的服务）都会推动新的需求高峰。新业务让需求预测变得更为困难。Netflix迫切需要一种新的IT服务方式来帮助公司完成业务转型。图1-32四、解决思路

云计算将使IT成为一种像水和电一样的公用设施服务，因此Netflix很早就决定利用云计算生态系统的快速发展来获得推动力。Netflix想要通过云计算来解决他们构建和运维IT平台的那些挑战，但是由于业务的快速发展以及业务侧重点的不同，他们没有选择自己构建云计算平台，而是决定采用公有云服务，这样可以充分利用云计算的敏捷性和规模效应。从概念上就像我们大家日常也都使用电，但是我们并不需要事先构建一个电厂才能使用它。一方面，使用云计算让Netflix可以更加专注在更贴近业务的创新上，而不是把精力花费在底层数据中心的构建和运维上面；另一方面，云计算让他们能够快速推出新的产品和服务，加快创新速度，并从容应对各种访问量的变化，提升服务质量。

Netflix根据业务发展方向和需求制定了一个明确的公司云平台战略，其整体的指导思想是充分利用云计算服务，从而把公司的主要精力放在业务创新和差异化工作上。Netflix的云计算战略主要分为三个层次。首先是利用第三方云计算服务提供基础设施。从2008年开始，Netflix没有新增任何自己的数据中心，它把在线视频服务完全迁移到云平台。其次，为了更好地使用云服务，Netflix在基础设施云服务之上构建了平台服务。这个平台服务是一个能够增加他们开发效率的定制化平台。最后，Netflix把公司日常办公用的IT服务也迁移到软件即服务类型的云计算平台上。所以，Netflix的整体云平台战略是一个全方位的IT发展方向的调整，能够满足不同层次IT服务需求，同时能够利用快速发展的云计算生态系统。

考虑到Netflix的业务特点和规模，Netflix对云平台有比较高的要求。首先是云平台规模。Netflix有数千万的订阅用户，而且在线视频服务在计算、存储和网络等方面的需求量都是非常大的，因此Netflix需要的云平台必须有足够大的规模来支撑他们的业务容量，以及将来业务的发展。第二个要求是云平台的敏捷性和灵活性。作为一个大规模的在线服务供应商，Netflix需要一个能够进行快速迭代开发，然后又可以通过编程的方式自动化管理和控制大规模的基础设施服务，所以平台的API支持能力非常关键。另外，在线视频服务有着非常明显的时间特点，比如服务的高峰一般都是在晚上的黄金时段，因此Netflix要求云平台既要具有能够灵活控制的敏捷性，又要能够满足弹性需求。还有一个要求就是云平台服务的高可用性。如果把Netflix的核心业务运行在云平台上面，那Netflix的业务发展就会非常依赖云平台的服务。Netflix提供的各种服务，尤其是在线视频服务的可用性会高度依赖底层支撑云平台服务的可用性。当然，提供高可用的服务给Netflix的最终用户也跟Netflix在云平台上应用和服务的架构设计等都紧密相关。

Netflix从2008年开始尝试了几家不同的云服务，经过一段时间的使用，Netflix在2009年决定全面采用亚马逊AWS，开始大规模部署其在线视频服务。Netflix充分利用了AWS的规模以及它丰富的产品特性和自动化能力。随着全球化业务的扩张，Netflix通过AWS的区域（Region）分布进行全球部署。五、实践和经验分享

Netflix虽然在2009年决定把整体IT构建在AWS云平台上面，但是由于其整个应用服务是比较庞大和复杂的，因此Netflix也是分阶段逐步在AWS上面进行构建和完善的。在2009年，Netflix首先把对计算需求最大的服务需求——视频编码服务在AWS上进行构建。Netflix需要对成千上万的视频进行编码处理，其编码处理使用了几千个EC2实例和PB级的S3数据存储。从2010年开始，Netflix全方位地展开对AWS的应用，加速向云计算服务方式转变。在2010年初，Netflix对播放服务进行了改造，针对PC和Mac提供了使用Silverlight技术的播放器，然后基于AWS平台实现了数字版权管理（DRM）、视频的播放标记管理和CDN路由分析等。Netflix还在2010年重新设计了他们的Web网站，重写了展示逻辑，优化了后台搜索服务，另外对视频的分类管理、评分、推荐都进行了重建。为了使得Netflix提供的服务能够给开发人员提供更多的灵活性，Netflix开始基于底层AWS云平台构建自己的服务API。它通过developer.Netflix.com对外提供开放平台API服务。比如，外部开发人员可以通过这些API进行多种终端设备配置支持，进行Facebook服务集成等功能。这样，Netflix逐步通过迁移和新建服务相结合的方式在AWS云平台上构建了自己完整的IT系统。图1-33示意了Netflix视频流工作模块的构建情况。图1-33

在过去5年多时间的实践中，Netflix不仅仅在AWS云平台上提供了在线视频服务，他们同时还开发了自己的平台层服务和许多开源项目。对这些开源项目，Netflix非常慷慨地在http://netflix.github.com网站上进行了分享。另外，Netflix还积极地通过他们的技术博客网站http://techblog.netflix.com跟大家分享他们在AWS云平台上的各种最佳实践。

下面介绍一些Netflix推荐的最佳实践。1．实践1：考虑到可能的故障而设计

在AWS云平台上进行架构设计的一个经验法则是要作为一个悲观主义者来设计云计算应用架构——假设会出问题。因为我们知道硬件总会发生故障，服务器会发生宕机，唯一不确定的就是在什么时候发生而已，所以我们在应用架构上要进行高可用设计。比如：我们需要有一个清晰的数据备份和恢复机制，并自动化这个流程。在构建应用服务时要构建能够在重启时继续运行的服务进程，系统的状态可以通过从消息队列重新读取信息来恢复。另外，在处理应用会话时要避免基于内存的会话或有状态的上下文，把这些数据放到持久性的数据存储中。这样做的好处就是能够让应用利用云平台的弹性能力进行横向伸缩。Netflix为检验他们在AWS上服务的高可用性专门做了一系列被称为“猴子军团”的测试工具，比如Chaos Monkey等，来专门来检验其应用服务在AWS平台上的鲁棒性。2．实践2：基于云的产品设计

为充分利用AWS云平台的特性，Netflix完全根据云平台的特性进行了应用设计。这也是AWS推荐的一种用户采纳云计算的方式。比如，Netflix对应用进行了松耦合设计，他们的服务和组件之间都通过标准服务接口或通过消息队列连接。Netflix的视频服务具有非常强的时间周期性，因此充分利用AWS云平台的Auto Scaling就显得非常重要。3．实践3：基于云的大数据分析

为更好地了解用户观看视频的各种行为习惯等，Netflix有非常强的大数据分析需求。以当红连续剧《纸牌屋》为例，这不是一部普通电视剧，它是大数据时代的产物，是一部播出前就知道会火的电视剧。因为在决定投拍《纸牌屋》之前，Netflix就从海量用户数据的分析中发现喜欢1990年英国版《纸牌屋》的观众几乎都是导演大卫·芬奇的粉丝，他们还都喜欢奥斯卡影帝凯文·史派西。于是Netflix请大卫·芬奇翻拍《纸牌屋》，由凯文·史派西担纲主演。大数据和云计算可以说是“天生一对”，AWS云平台可以在数据生成、数据收集和存储、数据的分析和计算等方面为Netflix的大数据分析业务提供支持。比如，Netflix不需要自己管理Hadoop群集，而只需要使用AWS提供的EMR（Elastic Map Reduce）服务就可以使用基于Hadoop的大数据分析服务了。Netflix还在AWS平台上开发了Genie项目，专门简化其基于EMR、Hive、Pig等平台上的数据分析和挖掘。4．实践4：灵活的开发和管理模式

为更好地基于云平台开发和运维好一个应用服务，Netflix不仅仅在应用架构上进行了重新设计，他们在团队组织架构上也进行了调整，以更好地适应云服务的模式。他们的新模式给开发人员更多的灵活度和责任感。一方面，开发/运维与业务部门结合更紧密，另一方面，他们把运维工作变得分散和自动化。六、启示

Netflix充分利用AWS云平台的服务和规模，比如Netflix使用的EC2实例数量达到几万个。Netflix基于AWS不仅创建了一个全新的视频业务，还得到了巨大发展。Netflix的视频流从2009年到2013年增长了约100倍。由于Netflix视频服务的时间周期性，云计算是非常经济的一种应用模式。根据Netflix副总裁Yury Izrailevsky在参加亚马逊AWS Re：Invent大会上发布的数据，与传统模式相比他们的视频流服务成本降低了87％，充分利用了AWS云平台的弹性和规模效应。除了业务成功外，Netflix通过Github开源门户也向外展示了其强大的技术实力和互联网的分享精神，他们在AWS上的经验和工具分享为更多云计算用户提供了便利和启发，从而推动云计算生态系统一起向前发展。七、参考资料

［1］Netflix delivers 1 billionth DVD．http://www.nbcnews.com/id/17331123/#.VEDuftKnr2M

［2］Redesign Netflix API．http://techblog.netflix.com/2011/02/redesigning-netflix-api.html

［3］How Netflix Build a Scalable Java Oriented PaaS running on AWS．http://www.slideshare.net

第2篇　团队管理/组织发展

在这个快速迭代的技术时代，构建互联网化的团队管理是每一个管理者的思考，从精益思想到精益团队管理，以及如何发挥自组织团队管理，打造阿米巴模式的小而美团队。如何使用敏捷驱动的团队？如何建立组织中的可视化看板？掌握动态运营管理机制成为新一代管理者的必备素质。当然，这里不缺乏好故事，极客精神提升团队效能、跨界管理、游戏化的员工管理、顶层设计下的组织转型……

快速提升初建团队需求分析能力

公司新成立了一条产品线，因为公司战略目标考虑，要求该产品线当年利润率要比其他产品线增长10％以上。作为产品线负责人，我必须在控制产品线人力成本的情况下，努力提高团队的产出，完成目标。

我在组建产品线时，选用的新人占较大比例，这样能有效控制人力成本。为了提高产出，我分析了哪些管理行为在提高产出方面比较重要。我选择了提升需求团队能力提升作为关键切入点，主要原因是：（1）需求是软件项目的起点。需求端出现小的偏差，在后续软件生产过程中会放大数十倍，导致代价急剧上升。因此需求端的良好管控，对控制成本，提高产出的意义重大。（2）需求团队新人多，培训新成员是一种“高杠杆率”行为。一个月内经理投入10小时进行培训，如果每个成员的产出能提高1小时，那么80人的团队就能提高80小时的产出。投入回报率很不错。二、如何去做

软件需求分析有很多方法论，主要分为两派。一派是“重方法论”，强调在前期需求分析过程中尽最大努力去精确定义需求细节，减少后期的需求变更。一派是“敏捷方法论”，强调需求变更无法避免，因此只需要考虑最近要做的需求细节，通过快速迭代、不断重构，来快速适应需求的变化。

我们产品线项目的主要客户是政府和大型国企，是典型的强势大客户，它们本身一般处于垄断地位，机构庞杂，位置分散，沟通起来代价较高，比较适合传统的“重方法论”。但是，随着市场竞争逐渐激烈，垄断企业也发生了变化。为了能够快速响应业务变化，软件厂商也必须在某些业务领域能快速响应需求变化。笨重的软件厂家会失去竞争优势，被客户所淘汰。

通过对所处环节的分析，我们决定在方法论中各取所长，采取适合现状的实践路径。

位基服务，Location-based service（LBS），是通过移动运营商的无线电通信网络或者外部定位方式获取移动终端用户的地理位置，并为用户提供相应服务一种增值业务（来自维基百科）。大众点评是一款典型的位基服务。另外，位基服务还用于导航、虚拟游戏、紧急电话定位，等等。位基服务的概念最早出现于20世纪90年代。到了90年代末，位基服务的概念和定位技术得到标准化。但是位基服务到了2004年以后才得到了长足的发展，这与智能手机的普及是息息相关的。智能手机解决了位基服务中的两个难题。第一，几乎所有的智能手机都加载了廉价的定位芯片，用户不再需要分别购买定位设备；第二，智能手机时时和用户在一起，手机的位置就是用户的位置。

智能手机的广泛使用为开发位基服务提供了坚实的基础和巨大的机会。根据Juniper Research的预计，位基服务在2014年可以创造140亿美元的市场价值。

位基服务对于Facebook有着很重要的作用。它是连接用户和商家专页的一个新渠道。用户可以通过签到或者点评和商家建立联系。用户的行为也可以用来给用户产生商家推荐和改进商家搜索等等。与此同时，位基服务也使得商家被更多的用户所熟识。通过联系商家和用户，位基服务为双方提供了益处，增强了用户和现实世界的交互。

Facebook于2009年底开始了第一款位基服务产品的开发——签到，并于2010年夏天推出该产品。签到造就了Facebook第一批LBS的用户，也促成了Facebook的第一个地方搜索的后端。接下来，Facebook认识到位基服务不只是作为一个单独的产品存在，它可以存在于更多的产品中并且能够成为产品开发的基础。于是Facebook开始了位基服务和其他各种产品的整合，包括图像、视频、链接和活动等。很快Facebook意识到现有的地方搜索后端不能满足用户的需求。于是Facebook重写了地方搜索的后端。新的后端支持多个搜索模式，更可靠、可扩缩、更灵活。在此之上，Facebook开发了基于类别的地方推荐和查询，并推出了商家点评的服务。到目前为止，Facebook上每周有超过7亿次的地方查询。每周有超过5亿条内容带有用户添加的地方信息，这些内容出自于或者涉及到超过1.5亿的用户。这个发展的过程中有若干有影响的决定和值得分享的经验和教训，作者挑选了以下几个案例来具体讲述。

案例一，多模式的地方的搜索。Facebook最初只支持签到和小范围的地方的搜索。局限于后端的设计，用户只可以查询他们位置附近若干公里以内的地方。Facebook很快就发现这不能支持很多的用例。比如，用户旅游之后发布照片需要搜索曾经去过的地方，这些地方可能离用户现在的城市很远。为此Facebook重新设计了地方搜索的后端，增加了不同的地方搜索模式来支持各种不同的用例。比如，在其中一个模式里，用户可以搜索世界各地的地方；在另外一个模式里，搜索结果会优先显示城市，等等。在这个案例里，用户的需求驱动了产品的定义和服务的方向。

案例二，“广义签到”的概念。这个概念很大地帮助了位基服务和其他产品的整合。签到通常是指此时此刻用户所在的地理位置。我们通过数据分析发现，很多的用户对于分享现在的位置有顾虑，他们却很习惯于分享曾经去过的地方或者将来要去的地方。比如，用户出行之后分享之前的照片，用户组织下个周末的活动。这里面都需要地理信息。我们把这些过去的、现在的或者将来的地方分享通称为广义的签到。用户过去去过的地方就是过去的签到，将来要去的地方就是将来的签到。这个统一的高层次的产品概念简化了背后数据结构的设计，统一了产品的行为，也使得用户可以比较容易地学习和掌握我们的产品。

案例三，优化产品体验。为了把位基分享服务做得易用，Facebook进行了很多的测试。提高产品使用性能的测试保留了下来。这其中包括地方的推荐，合理处理地方搜索失败，等等。比如用户没有找到某个地方，我们允许用户简单定义这个地方来完成发布自己的状态更新。这些思考被整合到一个地方分享的控件，使得Facebook其他的产品可以很容易地集成位基服务。

案例四，用户参与，众包／crowdsourcing。现实世界的商家在不断变化，这使得地方信息的及时更新变得很困难。Facebook大胆地采用了用户参与来解决这个问题。用户可以较容易地创建系统中并不存在的地方。为了保证整体的数据质量，用户创建的地方最初只对这个用户的朋友可见，并在搜索中排在较低的位置。其他的用户和这些地方的交互会提高这些地方的可见度。Facebook还允许用户添加和修改地方的信息，比如地方的城市、街道、电话和开放时间，等等。得到超出一定票数的信息会胜出并成为这些地方的最终信息。用户的积极参与使得Facebook有可能保持地理信息点的不断完善和更新。

综合以上的案例，我想总结四点Facebook位基服务发展的启示。第一，理解和满足用户的需要很重要，这为产品保证了用户的数量和增长的潜力。理解用户的需求需要收集大量的用户行为并进行分析。重写地方搜索后端就是其中的一个例子。正是用户的需求促使我们放弃已有的后端和设计了新的后端。理解用户的需要和产品的创新还需要进行很多的测试，正如我们为优化产品体验所做的各种尝试和分析。第二，内部测试。Facebook没有正式的测试团队，所有的工程师都是产品的开发者和测试者。新的产品或者大的产品改动都需要先进行内部员工的测试。内部测试帮助产品开发团队集思广益和调整产品思路。很多优化产品体验的建议来自于其他团队的工程师。第三，容错系统，合理地处理系统设计以外的情况。比如，允许用户定义新的地方来完成自己状态更新的发布。这非常有利于保持用户体验的流畅性和用户对产品的信心。第四，增长，增长，再增长。一个产品的发布不是开发的结束，而是开发的另一个开始。不断地观察用户的使用习惯和结合用户的建议，可以帮助产品迭代和发展，使其更加贴近用户的需要。这可能是一个漫长的过程，执行力很重要，质量很重要，稳步的进展很重要。正如Facebook的CEO马克·查克伯格所说：“Building some really great takes long time．…Execution matters，quality matters and steady progress matters．”

大型研发团队的知识管理实践

大型研发团队都会面临一个问题——“人来人往”。“人来”——新人加入团队时，如何让新人快速成长、快速融入产品团队？“人往”——技术骨干离开团队时，如何减少损失、规避风险？

网龙拥有1000多人的研发团队，被称为IT界的“黄埔军校”，常有竞争对手在公司附近的宾馆驻点挖角，网龙是如何减少研发人员流失带来的冲击？

网龙是国内最早做移动互联网的一批公司中的一个，其91无线被百度以19亿美金收购，网龙是如何快速培养无线新人的呢？

网龙获2011亚洲最受尊敬的知识型组织（MAKE）奖，背后有哪些故事呢？

本文将与您分享网龙在大型研发团队中的知识管理实践。二、2个案例——知识管理实践案例

知识管理并不是一个新概念，比如：开会时您记笔记，就是在做个人知识管理；大家熟知的有道云笔记、印象笔记就是帮您做知识管理的。您参加一次技术研讨会后在团队中分享您的收获，就是在做团队知识管理。

知识管理是如何解决研发团队的“人来人往”的问题呢？

案例1：开发人员碰到一个技术问题（图2-1所示），加班了3天时间终于解决，多么痛的领悟！图2-1

其他人在做类似的项目，也可能碰到同样的问题，是否也要花同样的时间来解决？

不！通过知识管理，可以提高解决共通问题的效率！如图2-2所示。图2-2

案例的启示——不重复发明轮子！通过知识管理帮助解决共通问题，减少重复投入。

案例2：一名程序员4年前进入公司，成长得很快，做得很出色，晋升为主程序员，可惜后来离职了。

他给公司留下了什么？从图2-3中可以看出，4年来，他在公司的知识库中留下了51个经典案例！这些案例被学习次数超过2000次！图2-3

案例的启示——员工离职时，如果带走电脑设备，估计很多人会跳起来，可是，他带走的更有价值的东西——他的知识与经验，反而没引起注意！

上述案例绝不是个例，给大家分享一组网龙程序知识管理的数据：（1）知识库中沉淀知识条目20834个。（2）知识条目被学习次数776609次。（3）促进了7111次线上技术交流。（4）技术创新195个。（5）技术创新复用次数469次。三、3个要素——知识管理的要素

要在研发团队中实施知识管理，有哪些方面很重要呢？1．知识管理要素1：“老大”重视知识管理

这是非常重要的一点，要把它列在第一位。知识管理不是一朝一夕就能见到成效的，“老大”如果不重视，不投入资源，知识管理很容易半途而废。

知识管理的难点在于很难量化知识管理的价值，比如：您会经常做笔记，您也认为做笔记对您的学习与成长有帮助，但具体有多大帮助？您的收入中有多少是做笔记帮您带来的？这是业界难题，所以，要推行知识管理，首先要“老大”认可、有这个价值观。2．知识管理要素2：与项目结合

知识管理要与项目及产品结合才会有人主动去应用，才能体现其价值。这也是企业知识库与百度、谷歌差异化的地方：企业知识库中沉淀的内容都是实际项目、实际产品开发过程中沉淀下来的具体、有效的实践经验与教训。做类似项目的同学往往会经常碰到类似的问题，在企业知识库中可以以最快的速度找到他想要的东西。所以，我们给企业知识库的定位是“离您最近的知识库”。3．知识管理要素3：PPT——People，Process，Tools

People：要有专人负责推进知识管理。

我们在岗位上设置了宣传专员（负责宣传与推广）、开发专员（负责知识库的开发与运维）、创新专员（负责创新的组织、评审、应用推广），并且从一线业务部门中挑选业务骨干担任知识官，充当桥梁的作用，帮助发现业务部门的知识管理需求、推进创新与知识在业务部门的应用、知识库的内容审核等。

Process：要有配套的制度与流程，如考核、激励、宣传、积分体系等。

管理界有个格言：您想得到什么，就要考核什么（You get what you measure）。

知识管理与业务部门的KPI结合，与员工的绩效、晋升结合。

知识官的考核与排名决定了他们能拿到多少知识官津贴。

我们从两个层面进行激励：物质激励与精神激励。

物质激励：员工参与知识的沉淀、分享、学习都会获得积分，积分可以通过抽奖与竞拍来获得相应的奖品（我们总结出程序员比较喜欢的奖品是数码类产品以及技术书籍）。

精神激励：员工在知识库中发表高质量的内容，往往会收到很多好评，优秀内容会被管理员推荐到首页，并得到重点推广，这对员工的激励甚至超过物质激励。传统印象中大家可能会认为技术人员都很低调闷骚，但我们发现技术人员其实都很希望自己的技术与技能得到别人的肯定。

Tools：知识管理不是一个概念或虚无缥缈的理念，要有知识库来落地，通过这个平台来实现知识的沉淀、传播、应用。

我们的知识库是基于wiki进行二次开发，并与企业微博、IM、ERP整合，建立SNS的机制，促进知识的流动与传播。四、4个步骤——知识管理的推进过程

知识管理在大型研发组织中的推进过程：整体规划、分步实施、重点突破、小步快跑。

整体规划：知识管理要与公司的业务战略结合，涉及到多个部门，要搭建相应的激励、考核、宣传制度，要建设知识官团队，要建设知识库，是个企业信息化的系统工程，所以要从整体上进行统一的规划。

分步实施：知识管理的推进，要由点到面，逐步推进，因为资源有限，贪多求全反而什么都做不好。

重点突破：先从需求最迫切的部门开始、先从公司的战略产品开始，这样容易见到成效，并积累经验，为推广到其他部门与业务打下基础。现在已有多个其他业务部门主动要求加入我们的知识管理体系，如策划部、QA部。

小步快跑：遵循互联网的产品思维，快速迭代、快速试错，出现问题可以及时调整。

那么，只有大型研发团队才能做知识管理吗？对于只有几十人的研发团队，可以没有知识官团队、可以没有知识库平台、可以没有知识管理制度，但只要您有这个意识，就可以从您开始，定期总结心得与经验，分享给小伙伴们，逐渐影响身边的人。五、启示

知识管理的实践过程是个艰辛的探索过程，因为知识管理不像项目管理有成熟的知识体系与理论框架来指导，业界也鲜有最佳实践的总结。

我们经过几年的摸索与实践，总结了上述几点实践经验，希望对您解决研发团队中“人来人往”的问题有所启发。

自组织团队的实践与讨论

不知大家在平时的工作中，有没有遇到过这样的团队：

它的管理似乎杂乱无章，从它的组织条文中，你找不到比较明确且严谨的规章制度，但在它的周围似乎有一只无形的手，在掌控着所有成员的行为规范，不严格，但却很高效。

它没有严格的上下班时间，规定最晚上班时间不得晚于上午十点，但超过十点也不会扣工资。尽管如此，绝大部分成员在绝大多数工作日里却可以在一个固定的时间窗口共同工作，并且工作时间远远高于正常的上班时间。

它的会议总是无法准时开始，因为绝大部分会议成员正在奔波于其他问题的讨论场之间，大家似乎更关心会议能否达到预期的目的，而不是会议本身。

它的管理架构千头万绪，有无数人都有权力在项目的进行过程中“指手画脚”，随时都有各式各样的输入，我们总会担心技术开发人员会不会被这些不停变化的需求搞得晕头转向。但是，多数情况下（当然不是每次），项目的进行却可以按部就班，稳步推进。有效需求被执行，无效需求被“屏蔽”，被付诸实现的不一定都是重要需求，但不被实现的多数被证明是不重要的。

有这样一个团队，作为Leader，所有人都说你是如何如何重要，甚至你自己都觉得在这个团队里举足轻重、没有你不行。但是，在偶然的机会里，你因为某件急事需要到外地出差两周或者一个月，因为事情紧急，在出差之前都没有来得及做妥善的工作安排和工作交接，并且在整个出差过程中你也极少有机会与“家”里面沟通。当你忧心忡忡地赶回来时，却发现整个项目仍在顺利进行。尽管有一些小事情存在延误或者方向的偏离，但似乎并不影响整体项目进度，甚至在这段时间里，客户的一些紧急问题都被处理得井井有条。第一次你会有很强的心理落差，觉得自己之前是多么的愚蠢和自负，这个团队里，你根本就是个可有可无的角色。一般情况下，团队的构成如图2-4所示。图2-4

有这样一个团队，它的责任划分并不明晰，当作为一个外来人员，要搞清楚一个问题究竟应该找谁处理经常是非常困难的事情。但在它的内部成员之间似乎总是存在一种莫名的默契，多数问题，经过两到三个人的传递几乎都可以找到落脚点。在问题的沟通会上，这种现象更加明显。例如今天发生了一个内存不稳定的问题，作为PM，当你看到这个问题时头顿时大了起来，因为可以处理这种问题的有两个部门，负责芯片驱动的驱动组以及负责系统平台的平台组，当你正在担心两个组可能对此问题进行推脱时，在会上，双方负责人几句简单的、针对问题原因的讨论后，很快就由某个组的同事把问题领走了。在你想追上他们询问对此类问题的职责分界线到底在哪里时，他们却极少说得清楚，反正就是知道该由谁处理。

这究竟是一个什么样的团队？通常情况下它会包括如图2-5所示的这些成员。图2-5

让我们尝试总结一下这个团队的特点：（1）它以客户需求和测试为驱动。（2）团队组织结构松散，但效率很高。（3）项目协调人员在团队组织中占较大比重。（4）团队成员不一定水平一致，但目标明确。（5）基本一致的职业道德水平和文化修养。（6）责任分散在每个成员身上。（7）项目经理以及各个部门的Leader，多数充当服务者的角色。他们有行政上的权利，但很少使用。注意，不是不使用，而是很少使用。（8）这是一个崇尚英雄的团队。

我不知道这样的团队模型在管理领域或者软件工程领域究竟该如何定义，找了很多资料，似乎“自组织型团队”的定义更加接近。下面是在孟岩先生的博客中摘抄的一段文字，对“自组织型团队”有比较明确的定义。

原文摘录如下：请记住Mishkin Berteig这个名字，也许在不远的将来他会成为敏捷运动的一位重量级人物。两个星期前我与同事Helena参访了这位年仅34岁的敏捷专家。在采访中他讲的一些观点是到目前为止我听到过的对敏捷方法最直观、最清晰的解释。采访的内容将会经过Helena的精心整理之后发表在杂志上，但其中有一些东西却是我迫不及待地想写出来的。在采访中我让Mishkin举出三个最佳的敏捷实践，他说这个不好回答，对于不同的组织会有不同的答案。不过一般来说，测试驱动、快速迭代是立竿见影的两个最佳实践。而如果说到意义最深远的一个最佳实践，那应该是所谓的“建立自组织型团队”。所谓自组织型团队，在Mishkin看来，是一种新出现的组织形式。与传统的、用指令和权力组织起来的团队不同，自组织团队是由一群志向和理念接近，为了共同的目标走到一起来的人主动结成的团队。以下是Mishkin Berteig的采访记录片断：记者：“有人说敏捷方法是反管理（anti-management），您是如何看待这一观点的？”Mishkin：“首先，管理目的是帮助组织顺利地完成工作。我们有很多不同的管理风格，最常见的是命令和控制型的管理方式。这种方式是建立在军事化管理的基础上，由领导者发布一些教条化的命令。他们做好详细的指令，然后让别人服从这些命令，最后人们也就只是按照这些指令进行工作而已。但是，这显然不是最好的管理方式。在一些情况下，这种强硬的军事化管理固然奏效。但是，这并不是放之四海而皆准的灵丹妙药。在软件行业以及其他更具创造性的行业里，让每一个参与项目的人都具有一定的管理职能非常重要。同样，在敏捷开发中，自我管理和自我组织的团队也是非常重要的。这种团队强调的是每个成员的自发性，而这与传统意义上的管理是不同的。这也是为什么有些人说敏捷方法是反管理的原因所在。实际上，管理还有另外一个目的，那就是为团队服务。管理必须为团队提供支持，管理必须设法为团队清扫障碍，以便团队能够迅速成长，充满创造力，并最终开发出优秀的产品。实际上，在美国和加拿大，很多公司都是如我刚才所描述的一样，他们不喜欢命令式的管理。有意思的是，人们往往觉得权力这个东西很好，但实际上并非如此。因为当你对别人发号施令时，别人往往不听你的。不管是什么命令，人毕竟不是机器，他们有自己的思想和想法。一旦你发现你的命令没有被执行，那种挫折感是很折磨人的。在敏捷团队中，情况就完全不一样。例如，团队成员提出他们可能需要更换一台速度更快的服务器，或者他们需要更换办公室里的桌椅。不管是哪种情况，他们总是需要一个人来办这件事情。这时，管理者说，这件事我可以帮忙。我出一个预算，然后把这个预算交给团队里的另一个人来购置这些东西。这样的结果对管理者来说应该是更加令人满意的，因为管理者自己也在做一些有意义的事情。这正是敏捷方法给他们所带来的好处之一。”记者：“请您说说在敏捷方法中最有效的三种实践方式？”Mishkin：这个很难说，因为在不同的组织，情况会稍微不同。不过，对于一些规模较小的公司来说，要开发软件，最重要的可能是测试驱动开发（test driven development）和迭代式开发（iterative delivery）。在项目初期，这两种实践是最简单也是最重要的。但是，从长远来看，还有一个实践显得更为重要，那就是自组织的团队（self-organizing team）。在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。所以，我觉得敏捷方法中最重要的三种实践是测试驱动开发、迭代式开发和自组织团队。记者：“在您提到的三个实践中，自组织团队给我留下了特别深刻的印象，那么自组织团队与一般意义上的团队有何区别？它又有何内在特点？”Mishkin：“首先，一个团队和一群人是有本质区别的。一群人是指一帮在一起工作的人，他们彼此之间并没有太多的沟通，他们也并不视彼此为一体。很多时候，我们误把一群人当作一个团队，但实际上它并不是一个真正意义上的团队。在软件行业中，人们往往说自己是一个团队。在他们看来，只要有一个项目，有一两个设计师、构架师、开发人员和测试人员，就能构成一个团队。实际上，它并不是一个团队，因为这些人没有形成共同的工作理念和文化，而是各自在做各自的工作。所以，自组织团队的第一个要素就是必须有一个团队，而不仅仅是一群人。其次，团队的形成必须经历几个时期。在团队建立初期，成员都很兴奋，大家相互之间了解也很容易。但是，过了一段时间后，问题就会出现了——团队成员的性格各不相同。张三想做这个，李四也想做这个，那到底该由谁来做呢？团队面临的问题就是设法协调好两者之间的矛盾。在经历了初期的一些磨合之后，团队成员就会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些规矩是不言而喻的。比如，每个人都知道上午九点来上班。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间相互理解，工作效率非常高。然而，要形成这样融洽的高效团队，也需要付出时间和精力。管理者需要为团队成员提供培训，团队成员也必须不断改进工作。当进入最后一个阶段时，你就拥有了一个真正的团队。在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指导更像是一个目标，一个致力于开发出更好的软件的目标。但是，如何让团队成员朝着目标一起努力是团队自身需要解决的问题。团队成员自愿分担不同的工作任务，而不是等别人来告诉他们怎么做。团队成员们会自己说，我想学习新知识，我可以来做这部分工作。这样，原来做测试的人员也开始学会编程了，做数据分析的人员也可以试着做商务上的工作，而开发人员或许也会发现自己具有设计方面的才能。这是一个自组织团队的内在特点。管理者从来不会说，你是一个优秀的测试人员，你来做这项工作吧。相反，测试人员会自己说他喜欢做这项工作。此外，自组织团队还会告诉管理者它能完成多少工作量。管理者不会说这是你的工作任务，你必须完成它。相反，团队成员自己说这些工作我们可以完成。总之，自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向它的组织做出承诺。但是，实现这些承诺对于自组织团队来说非常重要。否则，一旦出现问题，团队成员之间就会出现信任危机。”记者：“那么管理者在自组织团队中担任的是一个什么样的角色？”Mishkin：“在自组织团队中，管理者最重要的角色应该是一个服务者的角色。我认为，对于一个领导者来说，服务者是最好的角色。要当好一个服务者，需要具备特定的才能，因为并不是每一个人都可以当好一个为团队服务的领导者。有些人喜欢发号施令，而不想给团队成员提供服务。有些人服务很到位，却缺乏领导的权威。所以，要将服务与领导这两个角色很好地结合起来需要一定的能力。第一，管理者需要具备绝对的真诚与可信。一个为团队服务的优秀的领导者不能向团队隐瞒任何事情。管理者必须询问团队成员的问题，并给予他们充分、彻底的解答。不管出现问题还是好消息，管理者都要告诉团队成员。实际上，要真正做到心胸坦荡对很多人来说并不容易。此外，管理者还需要足够的勇气，因为团队可能需要你来解决一些难题，而解决这些困难可能会威胁到组织中其他人员的利益。所以，管理者必须有足够的勇气来承担这份责任，告诉大家说你可以为团队出面解决这个难题。最后，管理者还需具备远见卓识，他必须对团队目标具有非常清楚的认识，并带领团队实现目标，而在这一过程中，管理者不能强迫团队做任何事情。”去年gigix被ThoughtWorks给招了进去，按他自己的话说，“过上了幸福生活”。他跟我多次讨论过ThoughtWorks的文化和理念。有一次他提到，TW的CEO Roy Singham是个马克思主义者，在他的带领下，TW的主旨根本就不是赚钱，而是把最优秀的developers凝聚到一起来做事情。我知道很多人看到这里会冷笑一声，打心里不相信这种事情，做公司哪有不想赚钱的？但是再仔细想想，你就会觉出不俗之处。一个CEO敢于对全公司员工讲这样的话，就意味着对员工作出了一个心理上的承诺，这个承诺的分量是很重的，如果将来Roy的行为违背了这样的原则，那么他自己肯定会遭到惩罚。因此，这是一个有勇气的、比较真诚的承诺。这样一个为公司上下所认同的理念，很自然地会使TW团队区别于其他公司的团队。作为结果，这家名义上不以赚钱为主要目标的公司，就全球范围来说非常赚钱；作为一家以企业应用开发为主业（也就是我们通常说的“接单做项目”）的公司，TW并没有像大部分同类公司一样陷入毫无生气的苦役之中，而是显得非常有活力，非常具有创造力，在为世界各地的客户提供良好服务的同时，还能够不断开发出一些非常出色的开发类产品。奥秘何在呢？我一直对此想不清楚。跟Mishkin谈过以后，我的答案清晰了一点：TW的团队自组织程度非常高，是典型的高度自组织型团队。推而广之，很多优秀的技术企业，其团队都具有比较高的自组织程度，团队里洋溢着主动向上的气氛，对于技术创新充满热情，能够开发出非常优秀的技术产品。不过，很多企业在发展到一定程度的时候，开始强调管理。这虽然没错，但是究竟往哪个方向来改善管理呢？是要建立自组织型团队呢？还是建立一个命令式的团队？在一些管理不善的团队里，领导者对程序员的散漫和自由主义深恶痛绝，往往祭出严格的管理条款来加以限制，但很少听说有效的，最后往往是使情况更加恶化，这是为什么？为什么反而在一些从条文上看去松松垮垮，制度上存在不少漏洞（比如考勤制度、报销制度）的团队里，我们却能看到“团结紧张，严肃活泼”的工作气氛？“自组织型团队”为我们提供了一个很好的视角。

通过上面的文字，可以看到我们所碰到的这个团队与“自组织型团队”很接近，但有一点，Mishkin认为“自组织型团队”的成员都需要具备很强的自觉性和自发性，这与我们的团队似乎并不是很匹配。这一点我是这样理解的：当一个团队达到一定规模的时候，我们不能奢望所有的团队成员的文化素养、职业道德以及个人发展欲望都有相同的水准或者达到某个特定的水平。相反，一个“自组织型团队”如果要在现实世界中真正存在，以下几点要求应该更加重要：

首先，它应该具有足够的“宽容度”，能“容得下”各式各样的人才，这样才能广纳贤才，发挥各自的特长，创造更大的价值，正所谓不拘一格降人才。而“宽容”并不是毫无节制的，团队需要对个人有一定的“塑造性”。团队内的成员彼此影响，大家通过长时间的磨合以及团队整体文化的熏陶，性格与价值观趋于认同，做事方式和方法形成默契，自然而然便可融为一体，并形成团队需要的自觉性和自发性。

当某位成员无法被有效“塑造”时，自组织团队就需要依靠它的“自我净化能力”对这些人员进行“清理”。清理掉的人员并不一定是传统意义上“不好”的人员，但一定是与此团队不匹配的人员。

严格意义上的自组织型团队其实并不容易实现，尤其当团队规模较大时。既然这样，我们可能应该考虑将更多精力放在如何发现并保护我们团队的自组织性上面。

下面几点管理建议可以讨论一下：（1）规章制度很重要但需要“因地制宜”。（2）关注管理手段的实效性，避免为了管理而管理。其中一种情况是，在现行机制下绩效水平、员工积极性等都很不错，是否要让新的管理手段或者政策破坏这种“和谐”的局面。（3）管理人员充当服务者的角色比管理者更有效。（4）网状管理架构强调的是职权的分散而不是简单的复制。

从绩效考核到绩效管理

软件研发团队的绩效管理一直以来都是个大众热衷谈论的敏感话题。似乎每个人都能说上几句绩效管理的优缺点，绩效管理的理论也广为人知，然而关于绩效管理的实战案例却少有人分享。无数人对现有的绩效管理不满，然而对敏捷之类的绩效管理，大家又觉得过于理想。时至今日，争论不仅没有停息，反而愈演愈烈。

本文将一个软件研发中心两年来的绩效演变为案例，结合笔者在绩效管理上的探索经历，展示如何带领团队从传统的绩效考核一步步走向绩效管理。二、案例简述

这是一只异地研发团队，简称C研发中心，在成立三年后终于被公认为有激情敢承担的团队，开始承担起更大的职责。其绩效管理的模式在经过了多轮演变后，已经成为了团队发展的发动机。

虽然结果是令人鼓舞的，但是过程却总是曲折的。在这三年中，C研发中心经历了许多挑战，绩效管理也发生了一波三折的变化。1．美好幻想：绩效管理很美好

在加入C研发中心之前，我对该企业的价值观和绩效管理有所风闻，听说就是强大的企业文化帮助了企业的成功。加上自己之前作为外企的“top performer”，对绩效管理心存感激，就是因为绩效管理挖掘了自己的优劣势，找到了方向，自己才干得很好。在自己即将加入有强大绩效管理能力的团队，学习新的绩效管理知识时，我对未来充满了美好幻想。2．初入牢笼：可怕的绩效考核

然而，理想是美好的，现实是残酷的。让人没想到的是，绩效考核、命令控制打造了一支高执行力但缺乏自主性的团队。由于这一点C研发中心负责的产品被公司取消，团队陷入被解散的危机。风雨飘摇中，人心惶惶，我也陷入了困境。下面是这段时间发生的3个典型案例。

初到公司，我就被主管堵门。因为没有明确指令他们不知道下一步工作该如何开展。而我因为不了解情况坦承自己无法做决定而饱受质疑。同年12月，整个研发中心基本停摆，几乎所有正在研发中的软件都不能上线，都需要延期。因为所有测试同学的KPI里面都写着UI自动化测试的覆盖率，绩效考核期快到了，他们必须去提升UI自动化测试覆盖率，即将上线的软件面临无人测试的困境。因为主管掌控了绩效考核权，所以团队做事需要观察主管喜好。听说要加强沟通、提升透明度、扩大影响，于是人们的周报都是精心制作的职场感悟、工作思考，不这样不足以让主管看到。因此，作秀风泛滥，江湖俗称“秀亮点”。3．转机出现：整顿调整，抓住机会

2012年上半年，公司进行了组织机构变更，研发中心也被调整，更换了领导，调整了定位。研发中心的人员作为公司共享资源池，动态承接公司项目。为了和外包NDC区别，简称ADC。一时间又风雨飘摇，部分人选择离开。

这时，在新领导的支持下，我们抓住机会进行了绩效梳理，组织了岗位层级职责梳理和价值观培训，统一了组织绩效考核的判断依据。通过晒目标的方式，让研发中心管理团队对研发中心的绩效目标、相互协作方式达成共识。为团队制定了细致详尽的绩效辅导方案，并逐一辅导沟通。通过双周会的形式，让整个团队对组织的绩效情况有所了解，明确后续工作并针对问题制定措施。我们还尝试了集体评估绩效的方式，让绩效结果不再由主管单方面决定，这使得绩效评估更加公开透明。危机成为统一人心的机会，团队开始逐步形成一定次序，人心也稳定下来。

但真正的转变还是来自业务上的成功。当公司将一个基本已经确定失败的项目从总部放到研发中心来后，团队顶住困难，化危机为机会，用4个迭代带来了逆转。4．柳暗花明：乘胜追击，多线开花

为了拿到更好的绩效结果，C研发中心进行了更多探索和尝试。

尝试建立多个稳定团队，让开发测试同学组成跨职能的稳定团队，长期服务于一个固定业务。梳理了PM、主管、架构师等人的职责分工，明确了结合员工层级岗位的工作指引。在团队建立、项目启动时，通过团队Inception，统一对项目目标的认识。随着组织结构逐步向交付小团队转变，调整了绩效模板，交付小团队为团队的交付结果负责。同时，建立了交付能力模型，推动交付小团队能力评估和现状分析。

通过上述措施，C研发中心从传统的命令驱动式组织机构转变为以多个交付小团队为中心的交付结构。前期的各项准备工作激发了各个小团队的工作激情，让小团队放心为团队结果努力，业务开始出现多线开花的趋势，逐渐开始承担起更加核心的业务，C研发中心逐步得到认可。5．新的探索

初步取得成功后，C研发中心继续尝试新的旅程。C研发中心进行了组织机构调整，让组织更加扁平化，每个管理者大概管理20人左右，减少了单对单的绩效辅导；尝试调整发布频率，让某域的多个小团队通过每月一次的发布改变与客户的联系，有效改变了该域在客户心目中的形象。不仅集体进行绩效评估，还集体进行绩效设定，绩效工作逐渐变成了公开的日常工作，团队逐渐从对绩效管理的关注中转向怎么拿到更好的结果。三、经验教训

C研发中心经过两年多的发展，从濒临关闭、众人失去信心的情况中走了出来，开始承担起公司比较重要的职责。这两年多来，C研发中心的绩效管理模式也从比较传统的绩效考核走向新绩效管理的探索，业绩与绩效管理模式的发展基本同步。下面是对绩效管理活动提出的一些尝试和规避建议。1．避免固定不变的绩效管理模式

固定不变的绩效管理模式看似标准公平，但实际上真正带来的是僵化，就如那让人诟病的GDP。绩效管理模式需要随组织发展需要变化，与组织同步发展，甚至推动组织发展。2．避免绩效考核与敏捷不匹配

一支死气沉沉、全靠绩效考核推动的团队是不可能敏捷的。而且细致入微的绩效管理与微观管理是好伙伴。在C研发中心，强推敏捷软件研发的结果就是，把偶尔加班变成了一直加班，个人工作负担和压力巨大，但都不敢表露出来。3．避免绩效考核的斗智斗勇

以考核为中心的绩效管理模式往往会演变成绩效设定时的斗智斗勇。员工期望设置难度低、标准清晰、容易达成的目标，而主管则期望设置难度高、相对模糊、难以达成的目标，双方斗智斗勇，相持不下，直到设定时间用完为止。建议避免这种情况的出现。4．避免绩效考核强推SMART目标

SMART目标才是“高大上”，所有的绩效管理都强调SMART。但是，在软件研发中强推SMART的问题是，到最后只考核了那些容易考核的过程指标，并且这些易于考核的指标往往代表着上个世纪的软件研发，最后带来的是组织的僵化、低战斗力。5．尝试晒目标

晒目标是一个会议活动，在该会议上让同一组织的成员相互晒出自己的绩效目标。本活动可以让组织成员一起思考组织的目标能否通过各自目标完成而完成，相互间存在哪些协作点，这对目标共识、沟通协作等都有不小帮助。6．尝试人员盘点

在绩效考核时期，细致的人员盘点对主管的管理帮助巨大。当团队逐渐走向绩效管理后，人员盘点将不再是主要的管理工具，无需经常进行。7．尝试职责分工岗位层级梳理

明确分工、流程固化是很多组织的行为习惯。然而，没有永远合理的分工流程，人员能力、互动一直在变，组织也会遇到外部变化。每隔一段时间，进行一次职责分工岗位层级梳理是非常必要的，让每个人清楚自己的位置。所谓的敏捷自组织团队，则是以更快的速度调整。8．尝试设定与考核分离

考核是按比例的，设定是按指标的，只有神仙才能在设定指标的时候就能按照最后达成的比例来调整指标。既然你不是神仙，为什么最后考核的时候是按照前面设定的指标来考核呢？这不是骗人吗？所以，得想办法把设定与考核分开，设定是设定，考核是考核。9．尝试稳定团队为业务负责

绩效考核的难题在于，绝大多数组织是按照资源利用率最大化来优化的，并未考虑到绩效考核，从而让绩效结果与组织的实际业务结果基本上没有连接，这给绩效考核带来了很大的难度。稳定团队是一种很有意思的尝试，被激励的稳定团队力求拿到更好的业务结果，可以让绩效考核更简单更有效。10．尝试让绩效管理从有到无

很多组织的绩效管理都做得很重，组织成员的注意力不在工作上，而是在绩效管理上。这种不专注的工作状态并不能给组织、个人带来更好的工作绩效。建议将绩效管理的工作逐渐融入到组织拿结果的过程中，让组织的员工更加专注于去拿到好的绩效结果。11．尝试持续变革绩效管理模式

绩效管理看起来很简单，实施起来很复杂。需要结合组织当前的情况，不断对实施方式进行变革，绩效管理活起来了，组织也能活起来。一方面批判组织的僵化，另一方面却想用僵化的绩效管理提升组织活力，这似乎有点说不通。四、启示1．绩效是组织的，也是个人的

很多人对绩效都有误解，认为绩效的关键在于是否能有效考核并激励个人。然而，绩效其实是连接组织与个人的重要工具，绩效管理的真正价值是让个人的努力能够真正给组织产生价值，帮助组织拿到更好的绩效。

仅能推动个人努力工作，却未能给组织带来更好结果的绩效管理比比皆是。很多管理者自觉不自觉地承担起绩效分解的工作，将绩效目标进行。然而，他们自身并未站在软件研发的前沿，他们对绩效分解的方式还来自于上个世纪，这往往导致错误的方向。但这不重要，关键问题还是在于员工执行力不足，而他们早就准备好了理由。

在这种情况下，很多个体也接受了明显不合理的分解。他们不再关注组织的绩效，只关心自己绩效设定中的指标有没有达成。久而久之，他们就变成了本组织固定分解模式下的螺丝钉，不再有拿结果的能力，甚至不再适应其他组织螺丝钉的要求。2．绩效是阻碍，还是助推器？

鉴于软件研发组织中的绩效实施情况是如此让人怨声载道，很多人都认为绩效是软件组织发展的一大障碍，呼吁取消绩效。然而，绩效只是工具，工具的好坏更在于使用者。从本案例（也有其他案例）可以看出，合理使用绩效，绩效就不仅不是障碍，而且能够推动组织发展。3．管理者、员工眼中的绩效层次

闲来无事，构思了一个绩效管理的成熟度等级，仅供参考，请勿对号入座。

管理者的绩效管理成熟度：①用绩效控制工作；②绩效辅助理清工作；③绩效是团队做出来的；④绩效是自己做出来的；⑤创造让员工成功的环境。

员工的绩效管理成熟度：①为指标工作；②为工作工作；③为团队工作；④为自己工作；⑤工作就是工作。五、建议

最后，祝愿更多人能不再为软件研发团队的绩效管理而困惑，用好绩效管理工具，让绩效管理真正成为组织发展的助推器。

IT技术团队管理中的反激励和应对措施

开门见山，我先定义一下什么是反激励，以避免不同的朋友有不同的理解。反激励是指管理者在日常的团队管理中实施某项举措，本意是做激励，但是却得到了相反的结果。毫无疑问，我们要尽量避免这种情况发生。

在开始讨论之前，我们来看一个常见的现象——手机控。很多朋友每天会有很多次去看手机，看看有没有漏掉电话、短信，刷微博，看微信，看新闻，等等。其实我们也知道，这么做没有什么意思，但是我们还是会去做。这是为什么呢？我个人认为原因之一是大家寻求的是一种信息上的刺激感。在空闲时间尚且如此，工作中更是应当注意激励（刺激的一种类型），因为工作带有一定的强制性和枯燥性。我只是用这个小例子来说明激励的重要性，因为本文的讨论是围绕反激励展开的，对于激励的重要性就不再赘言了。

为什么要讨论反激励呢？激励是个很大的范畴，当我们一时无法知道怎么去做好激励的时候，我们可以先看看如何避免反激励。发现和回避一些做得不好和可能带来负面效果的举措，能够帮助我们做好激励工作。

这里需要说明，我会从我工作过的公司、周边的朋友、网络上等各种渠道收集案例。这些案例仅仅被用来做团队管理的研究用，我个人的立场是中立的，没有个人好恶在里面。二、反激励之一：能者多劳

能者多劳，越能越劳，也就是工作能力越强的人，被分配的工作就越多，而且后面追加的任务也越多。管理者可能没有意识到，从结果来看，能干带来了麻烦。在管理学上，这叫做棘轮效应。

以前搞承包制的时候，一般都是一年定一次承包额。你今年完成了，明年肯定增加。领导说，做得不错，好好干，接着就是调高承包额。而那些完不成任务的呢？下一年往往不会增加额度，甚至还会受到削减承包额的待遇。所以，有的承包人就滑头，通过各种手段弄得自己完不成承包额，虽然有的时候挨几句批评，但是得了实惠。

在IT技术团队中同样也存在这种情况。能力强的员工，往往在任务分配的时候就分得多。有的人干活专注、手快，提前做完了。当他（她）满心欢喜来告诉你提前完成了任务时，很多管理者会说，“好，我这儿正好还有一件事，你做一下”。这相当于对于能力强、效率高的人的一种惩罚。时间一长，谁愿意来告诉你他提前完成了任务？他做完了，不告诉你，还乐得一份清闲。你可能有意树立一个“能者”的典范，让当事人有荣誉感，但是过多的“多劳”并不受欢迎。

应对这个反激励，我的建议是以下三点：（1）管理者在做任务分配的时候要公平为先，然后才是能力强的人适当多做一点，以帮助团队尽快完成，而不能一开始就奔着“能者多劳”去。（2）管理者在做任务调整的时候，心里要明白：每个人都有自己应该完成的一部分工作，因为每个人都拿了薪水。（3）管理者在绩效考核的时候要看到那些额外的工作。人不怕累死，就怕气死。活儿干了，但是领导没看见，没有比这个更让人觉得郁闷的了。三、反激励之二：口头奖励的通货膨胀

记得有一次公司组织培训，培训老师为了提振士气，让大家一边有节奏地拍手一边喊：“好——很好——非常好——好得不得了”。现场一下子就活跃起来了。这些词语在管理者的工作中也常见。本着多表扬、少批评的原则，口头表扬是管理者经常做的事情之一。只是，如果表扬太多，导致泛滥成灾，员工就不知道你是不是真的在表扬，也区分不开什么是“好”，什么是“很好”，或者干脆就不以为然。

一位做软件测试的朋友在网上和我分享她的迷惑：她平日工作不错，认真负责，领导欣赏，经常表扬她。但是，往往到了升职的时候，领导却总是表示抱歉，说没有名额。这让她觉得平日里受到的表扬很假。

这样，口头奖励的通货膨胀就变成了反激励了。如何应对呢？（1）即使口头表扬具备快速、成本低的特点，也要控制数量，避免通货膨胀。如果什么都是“非常好”，那就降低了“非常好”的门槛。尽可能分出来，什么是好，什么是很好，什么是非常好，要有层次性。（2）表扬员工的时候，很重要的一点是管理者的态度要真诚，并让员工感受到。心不在焉，或者口是心非，日子一长谁都能看出来。（3）建立精神激励和物质激励的对应关系，不要让精神激励仅仅停留在口头上。柳传志先生说，对于基层员工，最重要的激励是物质激励。这是很有道理的。四、反激励之三：快速升职

能干的员工，领导个个喜欢，升职的机会自然多。但是，有一种奇怪的现象，升得越快，走得越快（离职）。这是为什么呢？

我们应当承认，一个小组、一个部门的升职空间是有限的。就一个部门来说，部门经理的职位只有一个，非技术岗位有一个类似“总工”的角色，也可能没有，也就这些。当一个人快速升上来，提前看到了天花板，他（她）发现升迁再也无望，自然就会动离职的心思。

另外，如果一位员工说，如果不升职他就要走了，这个时候为了挽留而做的晋升往往起不了多大的作用。晋升了以后，过了一段时间，他还是走了。

针对这个反激励，我的建议是如下四点：（1）管理者要清楚家底子，对于团队和部门内的晋升空间要心里有数。（2）开辟虚拟晋升空间，例如技术专家。团队里可以有Java专家，Oracle专家，SQL Server专家等等，没有什么人数限制。（3）当要做破格提拔的时候，管理者要三思，主要需要考虑的是否会对团队内其他人产生负面的影响？管理者要权衡这个破格提拔所导致的正面和负面影响，并保证正面的影响大于负面的。（4）“铁打的营盘流水的兵”，这是个事实，管理者要接受。当然，资历、绩效达到标准了，该升的还是要升，这里谈的只是避免过快升职。五、反激励之四：工作越清闲越不满意

谁都期望一份好工作，最好是钱多、清闲、离家近。这样的工作到现在为止我还没有看到过。IT行业在国内还是一个特殊的行业，平均工资会高出社会平均工资很多。同样，IT行业的从业人员也会忙一些。在这种大的背景下，当你认为让一个员工工作清闲是一种奖励和激励时，结果可能是相反的。

一个人清闲下来，价值感就会降低：团队有他和没他一个样。加上IT行业发展很快，大家都生怕落后了，这样一闲下来，心里难免发虚。员工能力越强，或者竞争越大的岗位，表现越明显。如果再加上管理者和员工沟通不畅，员工认为被“挂”起来了，会出现问题。

对于这种情况，我的建议是：（1）让团队里的每个人都接近满负荷，然后忙闲搭配。当然也不能长期超负荷，那样会出问题。这不是黄世仁式的剥削。在这个竞争激烈的社会里，谁不是努力奋斗才有成功的可能？接近满负荷工作的时候，为公司创造了更多的价值，也为自己创造了更多的价值和机会。（2）让每个人的工作都有挑战性。具有挑战性的工作是最好的激励之一，而不是清闲。（3）我们鼓励技术员工学会展示自己的工作，但是不要让员工的工作简单和清闲到需要把主要精力花在上面，这样效率很低，而且可能会生出是非来。六、反激励之五：安抚式晋升

本来只想晋升A，后来B一“哭”，你就把B也晋升了。这样为了安抚“会哭的孩子”而做的晋升会给后期管理工作带来很大的麻烦。

原因是这样：在IT团队里做管理，我们都有一个前提，那就是大家都是讲道理的。每一位被晋升的员工都是以后考虑晋升的标准和“案例”，就像欧美国家的案例判决，可以被引用。如果你晋升了一位没有达到标准的员工，相当于把晋升的标准拉低了，以后所有达到这个标准的你都应当晋升，否则就是不讲道理，偏袒某一个人。

如何应对这种可能出现的安抚式晋升呢？我的建议如下：（1）每一次晋升都要三思而行。（2）如果有员工来抱怨，关键是要理解员工的郁闷之处，指出提高的办法。（3）很多时候管理者之所以在员工抱怨时扛不住，是因为觉得内心亏欠对方。所以，管理者在这种情景下，要反思，是自己真的埋没甚至压制了员工，还是员工没有达到晋升标准？如果是自己有偏见，那就纠正。如果是员工还没有达到标准，管理者就要抵挡住自己内心的亏欠感，坚持原则。七、反激励之六：谁擅长，就分给谁

分配工作的时候，擅长的人总是分配到自己所擅长的任务。这样的好处是效率高，管理者也认为是对有经验的员工的一种认可和激励，因为在公开场合承认某某擅长什么，的确是一种激励。这么做也有问题，团队里的员工长期只做自己擅长的，会导致很多人失去了在工作中学习新东西的机会。

我有一个习惯，愿意和公司里离职的同事聊一聊，了解他们的想法。记得有一次一位同事对我说，他之所以离职，是因为这几年总是做相同的工作，而没有机会做新的工作。另外，有的公司存在着“项目霸主”的情况。新项目一来，总是几个资格老的人霸占着，不给别人做，其他人只能干看着。

要应对这种情况应该怎么办呢？我的建议如下：（1）管理者在做任务分配的时候，要效率和培养兼顾。对于计算机行业来说，在工作中的学习机会非常重要。为了保证项目的顺利进行，可按照老人+新人的搭配来做。（2）请管理者记住，工作是需要新鲜感的，不能要求一个人好几年拧一个螺丝。

还有很多的反激励现象，限于篇幅，这里不再一一阐述，下面仅列出其中几点，供大家参考：（1）是不是要给员工打破规章的特别待遇？（2）为了鼓励整个小组，得奖轮流坐庄？（3）完全相信员工，还要不要做监督？（4）严格要求可能会带来副作用。八、激励的3H（Happy）要素

那么，如何做好激励呢？我认为激励工作有三个要素：员工是否开心、团队是否开心以及管理者自己是否开心，如图2-6所示。图2-6

这三个要素中，我要鼓励中、基层的管理者，做激励也要敢于采用自己适合的方式，顺应自己的性格，即把“自己开心”也考虑在内。在这个世界上，人各有不同，有的人开朗一些，有的人内敛一些，但都有成功的范例，条条大路通罗马。找到自己做起来觉得顺畅、符合自己性格特点的方式，自己做得容易，员工也觉得舒服，这才是更好的方式。

游戏式管理系统——盛大网络的管理方法

盛大的“游戏式管理”，是由盛大独创的一套企业组织和人力资源管理系统。“游戏式管理”将游戏中用户的体验，通过真实的环境进行了还原。围绕企业发展战略和目标，建立一个经验值管理系统，采用实时记录的方式，让所有员工犹如游戏中的打怪、做副本一样，完成自己的工作，既充满乐趣，又促进员工的自我激励和自我管理，实现员工个人价值和企业价值的完整统一。

本次实践适用于涉及高科技企业组织和人力资源管理的探索，用于持续提升内部信息化系统对管理的支撑。本次实践的具体过程、步骤和方法可供同行借鉴。二、问题的提出

今日科技/互联网行业的公司数量快速增长，其中部分领先公司的规模大且呈现集团化趋势。如笔者所在的盛大集团，其主要业务横跨游戏、文学、支付、即时通信、地产等多业务领域，员工众多。此类企业在资本市场的估值高，但固定资产越来越轻，无不说明其员工价值越来越被公司内部和外部认可。但这类企业普遍遇到此类问题：员工离职率高、个人业绩得不到有效提升、员工没有归属感、员工忠诚度低等。

今日科技/互联网行业公司的员工生力军，大多是“80后”、“90后”。他们大多伴随着信息产业、互联网产业的成长而长大。基本都具备良好的IT基础知识，高度融入互联网世界，不墨守成规，具有创新的意识和快速接受新事物的能力。成长于互联网下的这一代大多无法接受父辈们的那种传统的条条框框众多的管理模式，不喜欢那些传统的内部管理系统。他们要行使自己的话语权，提出自己的管理规则和方式，建立自己喜欢的企业文化。

企业信息化系统，过去以ERP系统为核心的模式已在业务支持和表现形式上不能满足企业管理所需，不能被广大企业内的领导和员工们所接受。如何建设创新的企业信息化系统，让员工们爱上上班的8个小时，充分调动员工积极性，发挥最大价值，是目前面对的新问题。三、解决思路

盛大信息化系统根据今日企业信息化建设过程中遇到的问题，结合集团高层领导们提出的愿景——像管理游戏一样管理公司，像服务用户一样服务员工——希望新建设的员工绩效管理系统能破除陈规，给员工提供一个很好的舞台。不仅要极大地调动员工积极性，发现员工潜能，让员工自我快速成长，还要让公司从管理的角度做到资源的最优配置。在如下两个方面上进行了突破：（1）敢于构想。完全打破了传统企业中组织和人力资源绩效管理系统的模式。将互联网MMORPG游戏中的优秀元素映射至员工管理的每个环节，摒弃了那种事后考核，领导或同事评价的绩效考核模式。采用实时记录的方式，让所有员工的日常行为都能被系统所忠实地记录。最终将这些数据为绩效考核所用。让员工的平日工作犹如游戏中的打怪，做项目犹如休息中做项目、下副本一般，完成自己的工作的同时充满乐趣，又促进员工的自我激励和自我管理，实现员工个人价值和企业价值的完整统一。（2）缜于思量。形式的创新不代表我们放弃了绩效考核中最根本的元素。所以我们坚持以人性为本，通过反复推敲拟定的规则，强调在绩效评定的整个过程中必须是公平的竞争，必须有明确的和被重复推演的计量规则和计量标准。因为我们认为人性是最真实的，人性有善恶。为了能够让一个组织健康发展，就是要通过好的管理形式去挖掘出人性的善，通过公正的计量去维护人性的善，然后由个体的善转化为组织的善。游戏式管理涉及的HR管理环节如图2-7所示。图2-7四、实践过程

为了实现解决思路中的目标，经过集团人力资源部门和信息化部门经过半年的努力，我们实践出了如下的业务系统模型。1．为所有的绩效表现定义了统一的刻度——经验值

在游戏式管理下，每位员工在入职时就会根据初始薪资获取一个初始经验值和该经验值对应的等级。在后续的盛大生涯中，这位员工可以通过日常工作、参加项目/任务、岗位招标、绩效奖惩等多种方式获取更多的经验值。换言之，一位员工的绩效表现如何，最终都通过经验值来进行了记录，进行了凝聚。在后续的季度考核和年度考核中，经验值将成为最有说服力的数字。员工在游戏管理中的属性如图2-8所示。图2-82．定义了与经验值挂钩的等级制度和与之匹配的岗位职级制度

在游戏式管理下，每位员工的薪资完全由等级决定，更高的等级意味着更高的薪资待遇。而获得更高等级的唯一途径，就是要努力去获得更多的经验值。当目前等级的经验值满级后，无需任何领导批准，自动升级到下一个等级。自然相应的基本薪资水平和福利水平也随即提高。让员工自己给自己涨工资，通过游戏完成一切公司的管理。同时，我们还针对游戏式管理专门优化了职级体系，我们将职级分为专业职级和管理职级2类，设置11类专业职级和12类管理职级。每个岗位的职级都映射到指定的等级，越是对公司重要的岗位，同样的职级下对应的SD等级就会越高。如资深架构师对应的SD等级为45-50，而资深行政专员的SD等级为30-35。游戏式管理的晋升逻辑如图2-9所示，员工通过等级的提升，得以晋升职级，这样你也可以成为盛大网络CEO。盛大的双职体系如图2-10所示。图2-9图2-103．明确了获取经验值的路径

为了鼓励员工既做好日常的工作，也更多地参与公司重要的项目和任务，我们将经验值分为两类：

岗位经验值：员工通过日常工作获得的经验值类型，每个员工会根据其当前的岗位和职级情况获取每日固定的经验值数值。

项目经验值：员工参与项目型工作，或接受了经验值任务所获得的经验值类型。参与并完成越多的项目和任务则能获得越多的项目经验值。4．将经验值和人力成本预算挂钩

在游戏式管理下，经验值并非仅是虚拟的数字游戏，在游戏式管理系统中，每一点经验值都来源于年度人力成本预算，换句话说，每一点经验值背后都有真金白银的预算作为支撑。在年度分配和季度回顾时，集团会按公司业务发展的需要在各组织，项目和任务等多种维度上进行有效分配，保证资源配置的最优化。经验值包的分配逻辑如图2-11所示。越是优秀的团队，越是重要的项目自然能得到越多的经验值总量。图2-115．将游戏式管理理念和更多管理系统所集成

游戏式管理在盛大不仅仅只是一个管理理念，我们将这个想法和诸多盛大集团内部管理信息系统无缝集成，比如：每位员工在考勤系统中的考勤记录会影响日常岗位经验值的结算，而项目管理系统则管理着项目经验值的申请、分配和执行。季度结算时，薪资系统又会按本季度经验值结算的结果自动重新计算员工薪资。当然我们的员工更可以在员工作业平台上对自己的经验值详细状况进行查询，如图2-12、图2-13所示。同时，员工还可估计距离自己下一个职业目标还差多少经验值！图2-12图2-13五、效果评价

在盛大集团人力资源高级副总裁张瑾看来，盛大实施游戏式管理以来，已经有效地促进了人力资源合理配置，使员工形成自我发展和晋升的职业发展模式。同时，这套体系也是提高企业管理效率降低管理成本的一套人力资源管理体系。

通过这套体系，在2013年，共2600位员工通过游戏式管理系统提升了SD等级（盛大经验值体系中的级别）。共535位员工通过游戏式管理系统提升了专业/管理职级。六、启示

企业内部信息化团队在进行系统建设时，需意识到信息化工作上半身是管理，下半身是技术。我们需在信息化系统的形式上进行创新，更多地向互联网产品学习，建设被广大互联网时代员工所接受的信息系统。而在实质上我们因坚守管理的本质，重视企业中基础数据的管理，基础管理流程的落实，做好标准化和规范化工作，提升管理水平。笔者建议未来的企业内部管理系统应做到如下几点：（1）高效的沟通。（2）智慧的工作。（3）规范的管理。（4）活泼的形式。（5）简单的投入。

全球研发中心创新实践——解读惠普全球研发管理方法

创新毋庸置疑是组织发展过程中至关重要的推进力量，每个企业或者组织都非常重视，但是如何推进创新和建立创新的文化是一项比较困难的任务。对于笔者所在的组织——惠普全球软件研发中心同样面临着这样的难题，同时在惠普的大环境上，2005年至今，从马克赫德替代卡莉出任惠普CEO，到短命的李艾科，直到惠特曼2011年出任惠普CEO，惠普在最近8年内经历了4任CEO，企业战略政策摇摆，投资屡遭失败，企业经历了一个比较长的困难时期。在马克赫德时代，由于大力追求节约成本，研发投入相对较少，创新不受重视；又经历了李艾科的一系列轻率而重大的变化，使得惠普走到了近年来的谷底，直到新任CEO梅格·惠特曼推进了5年复兴计划——2012年是诊断与基础期，2013年是调整和重建期，2014年进入复苏与扩张期，2015年开始加速发展，2016年之后重新成为行业的领导企业，并保持这个身份。现在惠普加大了研发的投入，创新又重新被重视。

此外，在IT届新技术的革新不断兴起，技术创新、概念创新和产品创新层出不穷，创新给业界带来了翻天覆地的变化。回顾我所在组织所推进的创新实践，大半年的时间便取得了丰厚的成果，给组织带来了巨大的变化，创新的文化已经初步形成，带来了丰富创新产出。剖析整个过程，有如下主要的收获。二、清晰明确的愿景和目标

我们整个团队在建立之初就确定了非常清晰的愿景和目标，并指导我们的实施和计划。我们就是要建立组织中创新的文化，推进创造性思维，鼓励和提倡大胆创新；通过建立高效的创新平台为每一位员工服务，让创新成为我们的日常活动，并通过知识管理的过程让创新的价值最大化，让创新使得员工和组织能真正受益，并加快整个过程和再创新。三、合理高效的团队

在一开始我们就在管理层的支持下组建了一支非常有激情核心团队，并根据我们组织的特点对团队进行架构，在运行过程中不断壮大我们的团队。每个人都有明确的分工和职责，并采取创新的方式进行高效的团队沟通。由于是多地的团队，所以我们采取了视频会议的方式进行沟通，使大家能够相互了解、充分沟通。团队是我们整个活动成功的基石。四、强有力和持续的推进

我们制定了非常详实的计划，从多个层面上进行推进，并采取多种方式获得我们需要的支持。管理层尤其是高层的支持是尤为宝贵的，我们在3月份开始之前就策划了一些铺垫，在CIO来访中国中心的时候，对其进行专访，获得他对我们创新计划的支持；并在CIO的全体员工大会上进行现场提问，抛出我们的创新大计，获得了非常好的效果和知名度，赚足了眼球。另外我们策划了一个轰轰烈烈的开场，全方位的推广，在中心所有的四个地点同时进行活动，以电视媒体、海报、传单、现场采访、现场答疑和礼物派送等方式一下子将我们的创新互动推向了前台，激起了所有人的参与热情和创新热情。按“季”来推进，季度颁奖也采取四地连线的方式现场直播，在颁奖的同时也增加了不同地域之间的了解和沟通，效果斐然。

另一方面，“Innovation Day”的设立也功不可没。每个月我们都会有一天是“Innovation Day”，这一天我们会推出“Innovation Star”，我们的创新成果，还有一些其他的在线或离线的推广活动，通过这些方式不断地激发创新的氛围，同时让所有人能真正有机会感受到创新带给他们的价值。五、降低准入的门槛，让人人参与创新

一般来讲，创新是需要一定技术基础和时间积累的，能够参与和交付创新的人是非常有限的，因此组织中要想推进和培养创新的文化就比较困难。我们以创新的方式来推动创新。扩大创新的范围、降低创新的起点，使得创新从少数人的事变成人人参与。以“Ideas-＞Solution-＞Value”的方式来推进创新的产出。只要有idea就可以参与我们的创新，同时我们的创新不局限在技术层面或是项目、业务领域，可以是流程的改进、对管理的建议、关于工作环境的创新、关于工会、人力资源等方方面面的创新，从而激起了大家非常强烈的兴趣和积极的参与，掀起了创新的热潮。六、全面有效的激励机制

通过“绑架”大老板来获得最好的支持，一方面是精神和行动上的支持，同时也是财力的支持，可以推出相对丰厚的奖品，吸引大家的积极参与。另外由于“绑架”大老板的成功，一线、二线、三线老板基本也被拿下，获得了很好的资源支持，员工从直接经理那里能够获得很强的支持或者额外的奖励，同时和绩效挂钩，这应该说是实质性的激励。另外，挖掘精神奖励的强大作用，通过我们持续不断的宣传，使得那些少数创新能手和先行者曝光率不断加大，同时他们的创新成果也被实实在在地使用，价值不断被放大，他们获得了很好的群众认可，也成为了很好的创新标杆。蝴蝶效应和鲶鱼效应被发挥出来。七、高效的平台1．在线平台

我们在一开始就创建了我们的Innovation Website，分为Idea Portal和Solution Zone．使得任何人都可以随时随地提交“idea”或是“solution”，同时也可以非常方便地开展相互沟通。另一方面大家也可以很方便的获取我们的“solution”，直接引入到自己的工作或项目中去，使得大家真正受益。2．离线的支持和合作

Idea-＞Solution，对于“superman/superwoman”他们可以实现自己的“Idea”，但是的确有些“Idea”需要我们整合资源，建立专门的团队来实习这样的“Idea”，或是找到最合适的人来实现。我们的团队与组织中各个不同的技术团队保持密切的沟通和合作，通过借力来实现创新的落地，使得大部分有价值或现实意义的创新都能够被快速实现。同时也使得不同的团队能获得很好的发展，也使得人才得到了锻炼。3．专家团队

在实践过程中我们建立了一支非常强大的专家团队，他们是虚拟团队，但是作用非常大，不管是评审和鉴定；同时也是非常好的支持，可以给我们介绍一些新的创新加入者或是为不同的团队提供非常好的技术支持。4．知识管理的过程

创新的成果如果不被使用，那么其价值就在创新完成之后也就结束了，或者说没有被真正发挥出来。所以，我们通过知识管理的过程使创新能被广泛的使用，最大程度地发挥创新的价值，同时激发新的创新，盘活了创新。

创新是实实在在的过程，同时也必须是个持续的过程。我们在组织中推进创新的时间还相对较短，还需要更长时间的摸索和更广泛的交流学习，从而能够取长补短，共同帮助组织推进创新，将创新落在实处，让大家能快乐创新并落地生花，获得极大的创新成果和价值。

一个跨国银行的敏捷转型

为了更快更好地满足业务增长需要，这个跨国银行在全球各分支进行敏捷转型和推广，将敏捷实践应用到大型金融系统开发和维护。本文介绍如下6个方面的实践：（1）Agile center和敏捷教练。（2）敏捷意识和方法的全员培训（3）全球经验积累和分享。（4）避免Half-Arsed Agile（变形一半的敏捷）。（5）自我诊断，团队驱动。（6）注重代码质量。二、背景介绍1．案例简述（1）IT系统是银行运营的重要支撑，是极端重要的，需极端慎重对特。（2）包括变更审批评审文档格式等在内的重型流程成为快速响应的障碍。（3）经过比较选择和试行，进行全球的敏捷转型。2．计划目标（1）更快响应客户，缩短从需求采纳到上线的时间。（2）系统仍然稳定可靠运行。

Nspearit咨询团队为其法国总部、新加坡分部和香港分部提供敏捷咨询教练服务，帮助其胜利实施敏捷转型。三、Agile center和敏捷教练

这家银行综合考虑了自身多年IT开发维护的情况，看到了敏捷软件开发方法的冲击和影响，在法国总部进行了敏捷试点，经过试点之后，决定将敏捷软件开发方法推广到全球各个软件开发团队。

组织级敏捷的考虑要点有：（1）复制先锋团队的有效实践。（2）发现收集团队中的“痛点”。（3）帮助团队切实问题。

为了推进全球范围内的敏捷推广，组建了联合的Agile Center。Agile Center由三部分人员组成：来自团队的代表、组织内部敏捷教练、来自外部的敏捷教练。

对于大规范的敏捷转型，没有经验而单独走向敏捷通常会导致走捷径、误用或失败的情况。

这是一个文化冲击，这个变化需要由敏捷教练通过指导团队来引导，他/她应该是有敏捷经验的，引领了持续的文化转型，是中立、促进者。

基于以上的考虑，这家银行选择了inspearit作为其全球敏捷转型合作伙伴。

Agile Center自身的工作方法采用了敏捷方法。典型的一周安排如下：（1）周一10∶00～11∶00：周一沟通例会。（2）周三17∶30：周三补充例会。（3）周五下午：教练回顾反思。

Agile Center承担辅导团队的职责。辅导团队的典型步骤如下：（1）收集团队敏捷需求。（2）资质判断和准备。（3）教练带领团队一起做。（4）教练陪伴团队一起做。（5）团队自己做。（6）关闭。

Agile Center对各项主题保持持续提升。随着敏捷推广，深入了解到各个团队的不同情况，发现团队的痛点，识别改进机会，并试行改进方案，根据改进试行的情况，来判断推广还是继续探索，其典型步骤如下：（1）收集痛点和改进机会。（2）寻找一个团队或几个团队试试。（3）判断分析试行结果。（4）推广到其他更多团队。（5）观察部署的情况，再识别改进机会。四、敏捷意识和方法的全员培训“做敏捷”不仅仅是采用敏捷实践，更是价值观和观念的深刻变革。

虽然培训不能根本解决价值观和观念深刻变革的问题，但培训是必需的。基本理念、知识和做法通过培训可以覆盖所有相关人员。培训课程得到精心维护，重复讲解，培训材料得到多次更新。

一个敏捷类课程结构如图2-14所示。图2-14五、全球经验积累和分享

敏捷实践和方法在全球共享的wiki上得到了积累和传播。

将知识看成是资产，鼓励全球所有员工积累和分享知识。采用了wiki作为载体，wiki可支持人人参与编辑，人人作出贡献。

Wiki所承载的不仅仅是敏捷类的知识，包括工作中所用到的所有知识。

在大量敏捷实践方法中，选定了部分敏捷实践作为所有团队必须遵循的，并不完全允许团队可以决定团队的一切决策。比如有：（1）所有团队使用相同固定的迭代周期。（2）使用Agile Center发布的敏捷度评估检查表。（3）度量Agile Center指定的关键指标。六、避免Half-Arsed Agile（变形一半的敏捷）

图2-15是来自于http://www.halfarsedagilemanifesto.org/的截屏。

试读结束[说明：试读内容隐藏了图片]

下载完整电子书