如何聪明地失败

　　而，在变化无常的环境中，失败是难免的；如果管理得当，失败也能对我们非常有用。事实上，如果一个组织不能平和地看待失败，它可能就无法承受创新和成长过程中必然存在的风险。 　　我们与其逃避失败，不如培养一些“智慧型失败”（intelligent failure）。1992年，杜克大学的西姆-希特金（Sim Stikin）在《组织行为研究》杂志上发表了一篇题为“Learning Through Failure ：The Strategy of Small Loses”的文章，在文中他提出了“智慧型失败”这个概念，那它就会变得更加灵活，更能承担风险，也更懂得组织学习。 　　失败的好处 　　我接下来要描述的失败中，有些是特意设计的实验的结果，有些则完全在计划和预料之外。但是，所有这些失败都提供了宝贵的知识和经验。经历几次失败，可以帮助你： 　　获得更多的选择 　　一项行动可能出现的结果越多，成功的概率就越低。如果你多尝试几次，就能提高胜算。在高风险环境中运作的企业就运用了这种逻辑，如风险投资公司（其投资成功率约在10%-20%），制药公司（一般先研制出数百种新分子实体，才会有一种新药面世）、电影制作公司（调查表明，1.3%的电影赢得了80%的票房收入）等。 　　了解哪些行不通 　　许多成功产品都是建立在失败项目的基础之上。从某种程度上来说，苹果公司（Apple）的Macintosh电脑就是在失败的Lisa项目基础上发展起来的。Lisa产品如今已经被人遗忘，但它率先采用的图形用户界面和鼠标操作，仍在今天的电脑中广泛应用。 　　在高度不确定的环境中，传统的市场调研方法几乎没有什么用。如果你在1990年问别人，他们愿意为网络搜索付多少钱，没人能听懂你在说些什么。在实用的搜索引擎问世之前，需要开展大量的试验。早期的运营者尝试采用付费搜索的经营模式。后来一些公司探索出基于广告的经营模式。再后来，谷歌（Google）开发了一套系统，使该经营模式的盈利能力实现了最大化。如果没有前面这些试错，谷歌很可能无法打造出我们今天所熟知的基于算法的搜索工具。 　　创造条件，吸引资源和注意力 　　企业往往不断去寻找新的项目，而不是花时间去解决现有项目存在的系统问题。因此，索性让大麻烦显现出来，这样人们才会投入全部精力去救险。 　　几年前，我为纽约市政府工作的时候，就亲身领略了如何有策略地利用失败。当时，我领导一个IT团队，为纽约市政府安装一套自动采购系统。我一点也没想到，为这个项目争取政治支持和资金来源会有多困难。幸好，我的老板是个政治天才。一天下午，我在做一些分析的时候，发现原油系统中的数据损毁了。我立刻行动起来，决心挽救危局。然而，当我向老板讲了我的计划后，他平静地对我说：“什么都别做。有时候事情到了无法收拾的底部，人们才会下决心去解决。”他说得一点都不错。原有系统的崩溃，为新系统安装提供了强有力的证据，也成为了获得政治支持的转折点。 　　为新领导者腾出位置 　　一个令人悲哀的现实是：即使到了今天，许多领导者仍是由其他人照着自己的模子挑出来的。这种“守本分”的领导者不会去质疑那些心照不宣的假设和想当然的规则，结果令整个产业深受其害。只有当这些假设和规则被证明无效时――不幸的是，这往往发生在企业遭受重创的时候――董事会才会另择贤才。不过，这样的改变可能带来奇效。美国汽车制造业就提供了这样一个案例。谁会想到，艾伦-慕拉利（Alan Mulally）这位波音公司的前任高管，在出任福特公司的CEO后，能够鼓舞人力、力挽狂澜？ 　　培养直觉和技能 　　研究人员指出，人们所说的直觉，实质上就是高度发展的模式识别能力。那些没有经历过失败的人，其直觉所依赖的经验体系存在一种关键的缺失。许多风险投资者都有一个原则：不把资金投给从未经历过失败的创业者。 　　Xbox360是微软（Microsoft）进军游戏领域的一款成功产品。该产品的研发团队曾经经历过多次失败，包括3DO游戏平台、WebTV、苹果公司问题不断的显示业务，以及微软短命的UlmitateTV业务。由于积累了无数次失败的经验，团队成员在研发过程中能够识别警示信号，正确地调整方向。例如，早期的Xbox产品使用外部厂商的芯片，价格昂贵，据称2001年～2005年微软在该业务上亏损了约40亿美元。于是，Xbox360团队选择了其他厂商，与它们密切合作开发芯片，并保留了知识产权，从而是该产品很早就开始盈利。 　　智慧型失败的原则 　　显然，并非所有失败都有用。有些失败，哪怕能够为我们提供宝贵的经验教训，也应当不惜一切代价加以避免。但如果你也认为，在动荡不定的环境下失败有时是难免的，那么我们就有必要制定相关计划，对失败加以管理，并从失败中学习――在许多情况下，还要把它们看做实验，而不是失败。以下的七条原则，可以帮助你的组织更有效地从失败中学习。 　　原则1、启动项目之前，先界定成功和失败的标准 　　有一件事一直让我很诧异，那就是同一项目小组的成员对于成功的标准往往有着截然不同的看法。我研究过这样一个案例：一家生产环境治理设备的公司希望推出一个新产品系列。公司市场部认为，该设备的卖点在于，它满足了一项新的严格监管标准。而工程部则认为，高性价比才是卖点所在――为了压低成本，他们在设计时把市场部想过要重点推介的性能都砍掉了。这种理解上的差距，很容易导致愚蠢的失败。幸好，公司及时发现了这个问题，并统一了双方的意见，从而避免了一场可能的市场灾难。 　　原则2、将假设转化为知识 　　当你在处理一项完全没有把握的任务时，你最初做出的假设几乎肯定是错误的。通常，要获得更准确的假设，唯一的途径就是尝试。不过，在开始实验之前，你一定要有明确的假设。你得把他们写下来，并与团队成员分享。你还要确保你和你的团队能随时根据新获得的信息对他们进行修正。这样做的时候要注意一种风险，那就是我们都有一种倾向，只重视那些能证实我们已有观点的信息――这被成为“证实性偏见”（confirmation bias）。要解决这个问题，一个实用的办法就是，让一个团队成员去搜集能证明你们行动有误的信息，若等到你们已经大张旗鼓，不愿意改变想法的时候，就为时已晚。 　　企业如果不把假设记录下来，往往会遇到两大问题。首先，人们会把假设当成事实，在开会时，某个经理可能大胆预测，某个市场可以实现销售500万美元――会还没结束，这500万美元可能就已经被纳入来年的预算！当猜测最终被证明是错误时（几乎肯定是这样），这种思维跃进就会导致各种失常行为。其次，这样的企业不会尽全力去学习。它们可能会不断纠正方向，边做边学，但是如果它们没有严谨地将结果与期望进行比较，就无法获得明确的经验教训并进行分享，未来的项目无法从中获益。 　　在阐明和修正了假设之后，你应该设计一个商业实验，对这些假设进行检验。和科学实验一样，商业实验也是为了证明结果是否达到预期，至少你能从中学到一些东西。 　　原则3、失败宜趁早 　　果断、快速的失败有诸多重要好处。首先，你不必再为这个行将失败的项目浪费更多的资源。其次，由于行动和结果在时间上接近，确定其中的因果关系在时间上接近，确定其中的因果关系也就容易得多。再次，越早排除某个行动，就能越快地接近你的目标。最后，尽早失败，也就减轻了硬着头皮干到底的压力，因为这时候投入还不是很大。 　　要确保失败尽早反生，一开始就对项目的各个要素加以检验。“敏捷软件开发”（agile software development）取得的结果常常要好于传统的序列化系统设计，主要就是这个原因。在敏捷的开发环境中，程序员会迅速、反复地把编写的小段代码与其他程序员和用户进行分享，然后开发团队再向前推进工作。这与传统的开发方式形成了鲜明的对比。在传统方式中，分析员会花数月时间记录用户的要求，然后再把这些要求交给程序员，程序员这才开始编程。等到发现问题时，项目可能已朝着错误的方向走了好几年。 　　要想尽早失败，你可能需要改变资源配置方式。例如，你可能不是要在整个项目周期内实现净现值最大化，而是想把财务评估从时间和资金两方面进行细分。你可能还想投资于更灵活的资产和人员，直到你积累了足够的经验，有信心建立一个大业务。 　　另外，我们不应该忽略快速失败给员工带来的好处。如果员工觉得，一个项目的失败会让他们等上好几个月才能参加新的项目，或者会让他们失业，那么失败就会削弱士气。但是，如果有许多项目在实施，一个项目的终止意味着他们会马上转入另一个（可能更有趣的）项目，那么项目失败就会影响到员工的士气。例如，在Sagentia技术顾问公司，员工们总是飞快地从一个项目转移到另一个项目。该公司财务总监尼尔-埃尔顿（Neil Elton）告诉我：“他们会主动发送电子邮件，并附上简短的简历，‘我原本很忙，但现在不忙了。你能给我机会发挥我的技能吗？’”员工的这种态度表明，该组织懂得如何聪明地开展实验。 　　原则4、控制负面风险，降低失败成本 　　这是从尽快失败中得出的重要推论。在设计项目时，应该考虑到如何降低失败可能造成的损失。有时候，在进行重大投资之前，最好先对产品或服务原型进行一次小规模测试。当年，日本化妆品企业花王（Kao）有意涉足软盘生产领域，它面临的一个大问题是，消费者是否会购买花王品牌的软盘。于是，公司向另外一家制造商购买了一批符合其质量要求的软盘，贴上“花王”品牌后销售给消费者。结果，市场反响积极，于是这项计划得到了推行。结果当时市场反响不好，花王公司可能就会终止项目，而发生的成本并不大。 　　这种方法可能要求你打破固有的习惯。我曾与一家高科技公司合作过，该公司首席创新官表示，公司在决定是否进入新的产品领域之前，一般会请“穿白大褂的实验室专家”进行技术可行性研究。此类研究不但费用高昂――在20万美元以上――而且在商业可行性方面，也不太能够说明问题。于是，这位首席创新官开始制作潜在新产品的实务模型，然后向潜在客户进行展示。从多次展示中，公司了解到，产品外形、易用性，与现有系统的匹配性等非技术因素，会影响客户接受新产品。上述两种方法在成本上的差异可谓悬殊：制作模型的成本一般在2万美元左右。两者在速度上的差异也很大：模型展示只需要几个星期，而实验室研究则需要9-12个月。 　　3M公司素以包容失败而著称，但在前任CEO吉姆-麦克纳尼掌权期间，这种文化遭受了打击。麦克纳尼曾任职于通用电气公司，来到3 M后，他努力在整个公司推行六西格玛质量管理法，连研究实验室都不例外。尽管这种管理方法在3M的各个工厂创造了奇迹，但由于它注重可预测的结果，使得员工们都不愿意冒险去尝试一些未经验证的想法。2005年，乔治-巴克利出任CEO后，他面临的一个挑战是，恢复敢于冒险的企业文化。他停止在实验室使用六西格玛管理方法，鼓励科研人员大胆探索新的想法――只要负面风险不大就行。在经济衰退期间，3M推出新产品时“做一点，卖一点”的传统理念与巴克利倡导的金字塔底式创新（即能够吸引广阔市场的低成本产品）成功地结合了在一起。 　　原则5、减少不确定性 　　在企业已经熟悉的领域鼓励失败，并没有多大意义。但是，在一个与你现有能力完全无关的领域体验失败，也不会对你有多大好处：你得到的收获可能派不上用场，因为你并不了解北京情况，也不知道如何将学到的东西与你现有知识联系起来。 　　谷歌公司很善于开展实验，但是，在计划推出一项非网络电台业务时，它却走过了头。公司想参照互联网广告模式，对电台广告实行自动定价。广播电台将一部分（最好是全部）广告时段交给谷歌，后者让广告主对这些时段进行竞拍。然而，问题出现了，因为广播电台不愿意拱手让出对广告业务的控制权。更糟的是，谷歌的广告竞拍成交价要低于电台与广告主之间的直接成交价――尽管谷歌辩称，广告需求的增加最终会推高拍卖价格，但各家电台还是不愿意尝试。媒体购买公司也不愿意和谷歌合作，因为谷歌不接受提前商议价格和广告打包等传统做法。2009年，谷歌关闭了这些业务，公司CEO埃里克-施密特将此次失败归因于公司没有能力衡量电台广告的效果――而在网络环境下，谷歌可以通过跟踪浏览量和点击量做到这一点。谷歌在这项业务上投入了1亿多美元，虽然这对谷歌来说并不算多，但关键是，他们从中似乎没学到什么有用的东西。事实证明，谷歌的核心业务与广播业务相距实在太大了。 　　在任何一个决策点上，都应该尽量减少需要解决的不确定因素。要做到这一点，一种方法就是采用贝恩公司的克里斯-祖克提出的“相邻业务”策略。例如，你可以将现有产品引入新的市场：宜家在许多国家销售的家居基本上都是一样的。你也可以向你的客户提供新的相关产品，你还可以依托现有能力打造新的业务：美国空气化工产品公司就利用其工厂管理能力，开辟了新业务。不管采取哪种方式，关键是，要在与你成熟活动较为接近的领域，汲取失败的经验教训（和利用成功经验）。祖克表示，主要不确定因素应该限制在市场范畴内（定价市场接受度、产品外形等），或技术和能力范畴内（标准、可扩展性、人才供应等）――不能在两个方面同时存在不确定因素。 　　还有一种方法可以避免让实验走过头，那就是把长期项目分成若干小项目。以纳米技术的商业化为例。总有一天，我们能够在单个分子水平上建构物体，那将是一次真正革命性的变革。但是，要实现这个目标，我们可能还要等上相当长的一段时间。那么，目前我们是怎么应用纳米技术的？想想抗皱休闲裤，还有不留指纹的手机屏幕。这些产品虽然不起眼，却很有意义：它们把全新的科技成果应用在我们熟悉的产品上，促进我们学习新知。 　　原则6、打造崇尚智慧型失败的企业文化 　　人们总是担心自己负责的工作若是出了什么差错，就会影响个人前程。（当然，他们的担心往往是对的！）企业高层需要营造一种环境，鼓励员工聪明地去冒险，同时不会惩罚由此导致的失败。一些企业已经发现，秉承这一原则对自己是有益的。 　　企业CEO们可以在这方面展现出强大的领导力。雷富礼掌管宝洁期间，就把敢于直面失败作为企业的核心信条。他再三强调，极高的成功率是渐进式创新的标志，而他要寻找的是突破式创新。在任期间，他出版了《游戏颠覆者》一书，在书中他列出了（甚至庆贺了）他领导的11次代价最高的产品失败，重点讲述了公司从每次失败中收获的经验教训。他总结的失败原因形形色色，从“消费者习惯需要做出重大改变”（一套家用干洗设备）到“想法太窄”（几款新型衣物洗涤剂），不一而足。 　　这种企业文化应该渗透在组织的各个层级。一位曾与我合作的部门负责人，常在绩效考评时对他的团队成员说：“请举出几件自己没能做成的事。”这一要求极好地说明了，凡追求高成就必定要尝试一些不成功的事。 　　原则7、总结经验教训，并与他人分享 　　如果智慧型失败的经验教训没有与整个团队（最好是）整个组织进行分享，那么其价值就会低得多。获取和传递所学经验的方法有许多。其中最常用的有项目进程中的小型评估总结会、到达关节点时的阶段性评估，以及项目结束时的事后评估会。无论采用哪种方法，关键是要厘清最初的假设是什么、发生了什么、这又对先前的假设意味着什么， 以及下一步该怎样做。我们要保持克制，避免相互指责，这一点至关重要――当我们把一些基本想法视为“假设”而非“预测”或“数据”时，就更容易保持克制。 　　一家大型组织实施的I T项目出现了严重的问题。最近，我帮助该组织进行了项目评估总结。在开会前，我跟几位关键决策者进行了面谈，理出了一条重大决策的时间线。会议一开始，我们先解释了I T系统经常出现的问题的一些普遍原因。这样做的目的，是向大家传递一个信息：“遇到这种问题的不只有你们。”接着，我们讨论了4年前项目获批时做出的一些核心假设。团队中后来的成员听到这些假设后感到很吃惊。随后，我们分析了对项目发展产生重大影响的五个决策，讨论了当时所持的一些假设、我们原本可以采取的一些不同做法，以及我们可以从中获得的经验教训。最后，我们分组进行了讨论；一个小组决定如何应对眼前的状况；另一个小组则总结经验教训，供其他项目借鉴，以及避免今后出现类似的问题。为确保会上总结的经验教训得到有效的传递，我们还安排专人记录和传递这些经验教训。 　　从失败中学习，摸索着走向成功――凡掌握这个奥秘的企业，定能在动荡不定的环境中，力压同侪，实现蓬勃发展。