五个为什么的实例
IGN娱乐公司(IGN Entertainment)是新闻集团(News Corporation)下属的一家公司。它是一家网络视频游戏媒体公司,拥有全球最多的游戏用户。其各种媒体游戏项目吸引了超过4500万的玩家频繁出没。IGN成立于20世纪90年代,新闻集团在2005年将其收购。随着公司的成长,IGN雇用了几百名员工,包括近100名工程师。
最近,我有机会和IGN产品开发团队交谈了一次。对方在近几年中相当成功,但是就像所有我们在本书中看到的成熟企业一样,他们希望加速新产品开发,寻找更具创造力的办法。他们把工程开发、产品和设计团队召集到一起,讨论通过哪些方法来应用精益创业模式。
这项改变计划得到IGN高级管理层的支持,包括公司的首席执行官、产品开发主管、工程开发副总裁、出版商以及产品主管。他们之前在“五个为什么”上的工作开展得不是很顺利。他们根据产品团队提出的各类问题罗列了一张清单,试图一一解决。这些问题各式各样,从网上分析中的各种矛盾,到合作伙伴的数据传送无法工作。他们第一个“五个为什么”会议开了一个小时,虽然得出了一些不错的见解心得,但就“五个为什么”流程本身而言,简直是场灾难。与这些问题相关并最了解情况的人员都没有参加会议。而且因为这是第一次大家在一起使用“五个为什么”方法,他们并没有遵循应有的形式,还时常离题万里。
这个会议不完全算是浪费时间,但也没有得到本章所讨论的适应性管理所带来的任何好处。
不要把“历史包袱”放到“五个为什么”的流程中IGN曾经试图解决所有浪费多年时间的“历史包袱”问题。但由于这类问题过于复杂,要迅速找到解决方案太难了。
IGN踌躇满志地展开“五个为什么”讨论,但忽视了三件重要事情:
1.要把“五个为什么”方法引入企业组织,必须在出现新问题时召开“五个为什么”会议。
因为“历史包袱”是企业内的弊病,它们会自然而然地出现在“五个为什么”的分析中,你就能利用这个机会逐步改正这些弊病。如果它们没有自然出现,那么也许它们并没有看起来的那样严重。
2.每个和问题相关的人员都必须出席“五个为什么”会议。很多企业组织不要求工作繁忙的员工参加根本原因的讨论,是觉得这样可以节省时间。这种节约要不得,IGN在认清这一点前吃了不少苦头。
3.每次“五个为什么”的讨论开始时,花几分钟时间解释一下这个流程的目的是什么,以及会怎样进行,这对第一次参加会议的人很有好处。如果可能的话,引用以往“五个为什么”的一个成功案例,如果你完全是个新手,可以引用我那个经理人不支持培训计划的例子。IGN发现,只要有可能,尽量使用让团队成员有切身感受的案例,会起到很好的效果。
在我们的会议之后,IGN的领导层决定尝试再召开一次“五个为什么”会议。根据我在本章提到的这些建议,他们委派了工程开发总监托尼·福特(Tony Ford)担任“五个为什么”负责人。托尼原是一位创业者,由于他的公司被IGN收购,他也随之加入IGN。托尼从网络技术工作起步,在20世纪90年代后期创建了很多关于视频游戏的网站。这些经历提供了成立新创企业的机会,他在这家名叫“X盒团队”(TeamXbox)
的公司担任首席软件开发师。2003年IGN收购了“X盒团队”,从那时起,托尼成为了IGN的技术专家、创新主管以及敏捷开发和精益实践的倡导人。
托尼起初没有选择集中在一个狭窄的问题领域。这造成了之前的挫败和沮丧。托尼回忆道,“作为一个新的负责人,我没能有效引导‘五个为什么’的流程,并且我们尝试要解决的问题选得也不太合适。你可以想象得到,以前那些讨论都不太顺利,最后也没有明显成效。我因此有点泄气。”当有人想要一下子对付很多问题时,这种情况很常见,而且它也显示了这些技巧需要花点时间来掌握。所幸托尼坚持了下来:“我认为,有一位‘五个为什么’的负责人相当重要。‘五个为什么’在理论上很简单,但实践起来不是那么容易,所以需要有对它了解透彻的人,来为那些不太了解的人引导讨论的形式和方向。”
当托尼针对一个耽误了期限的项目主持了“五个为什么”讨论后,转机出现了。这次会议充满见地,牢牢吸引了众人,并且最后得出了切实的按比例投入的计划。托尼解释说,“这次成功要归结为更有经验的负责人和与会者。大家都知道‘五个为什么’是什么,而且我有效地把握了大家的讨论方向,避免离题。这是一个转捩点。就在那一刻,我知道‘五个为什么’会成为一种新的工具,必将对我们团队,乃至公司业务的全面成功产生真正的影响力。”
“五个为什么”表面上看起来是关于技术问题和防止错误发生,但是,随着团队成员排除了这些表面上的浪费,他们对如何一起工作产生了新的理解。托尼是这样说的:“我敢说我发现‘五个为什么’超越了对根本原因的分析,它揭示的信息让团队成员形成统一的理解和视角,把他们更紧密地聚拢在了一起。很多时候,问题使人疏离;‘五个为什么’的效果正好相反。”
我请托尼提供一个IGN近期成功的“五个为什么”的分析案例。他的报告如下。
为什么不可以添加或编辑博客里的帖子?
回答:任何一个对文章内容应用程序接口(API)的发帖要求(写入)会收到“500错误”⑤提示。
按比例投入方案:吉米,我们会设法解决API的问题,但是首先让我们的内容管理系统(CMS)对用户更宽松些。要提供更好的用户体验,就得让用户能添加并编辑草稿,不会收到出错信息。
为什么内容API会出现“500错误”?
回答:bson_ext gem和它所依赖的其他gem⑥不兼容。
按比例投入方案:金,把这个gem去掉(已经解决了中断问题)。
为什么这个gem不兼容?
回答:在原有版本上,我们加了一个新版的gem,没料到应用程序意外地开始使用它了。
按比例投入方案:班内特,把我们的rails应用在gem管理方式上改成捆绑模式。
为什么我们在开发中添加了一个新的gem版本却没有测试?
回答:我们不认为在这类情况下需要测试。
按比例投入方案:班内特和吉米,在API和CMS中加入一段单独测试或功能测试,以便将来可以发现这种情况。
为什么我们添加了本来不打算马上使用的gem?
回答:为了准备编码推送,我们想在开发环境中准备好所有新的gem。尽管我们的代码部署完全是自动的,但gem不是。
按比例投入方案:班内特,在持续集成与持续部署⑦的流程中,自动管理并安装gem。
额外收获——为什么我们在周五晚上进行开发工作?
回答:因为没人说不可以,这时候对开发员准备周一的部署工作而言时机恰好。
按比例投入方案:托尼,向团队发个通知。周五、周六或周日都不做开发改动工作,如有特例必须由工程开发部副总裁戴维批准。当全自动持续部署流程到位,我们再来重新评估这条原则。
根据这次“五个为什么”的讨论和我们的按比例投入方案,我们的部署变得更简单、更迅速,我们的流程不再允许开发员把会导致意外后果的gem放入开发系统。确实,我们再没有遇到其他类似问题。像你所说的,我们加强了自己的“集群免疫系统”。
没有“五个为什么”,我们不可能发现以上的这些信息。我想,我们大概会告诉那个开发员别在星期五晚上干蠢事,然后就完了。正如我早先强调的,一次好的“五个为什么”讨论带来两种产物,学习和执行。从讨论中得到的按比例投入方案固然价值可观,但其间的学习过程看似不显眼,对开发员和整个团队的成长却意义非凡。
本书评论