1.2 今天上班可以放羊
程序员的修炼——从优秀到卓越
如果你受雇于谷歌，那你只须拿80%的时间用在本职工作上。而另外20%的时间，你可以用来做任何想做的事情，前提是，你所做的事会以某种方式帮助谷歌进步。至少理论上是这样的。
到目前为止，谷歌的20%时间政策在软件开发行业里已经很出名了。不过，大家有所不知的是，如果追溯回去，这个概念其实早在1948年就由3M公司1提出了。
1974年，3M公司的一名科学家Art Fry提出了一个巧妙的发明。他认为，如果能把黏胶涂在一张纸片的背面（其实他的同事Spencer Silver几年前就有过这样的梦想），那他就能做出一种完美的标签，可以用作在教会的诗歌本中标记位置。他把它称作为“即时贴”。Fry在他“15%的时间”里做出了这个当今社会里标志性的产品（他在2008年5月接受史密森尼博物院2的采访时也提到了这个产品）。而这“15%的时间”正是3M公司（在1948年发布）的一项政策，它允许雇员利用一部分工作时间去“做白日梦”，并且把他们自己的想法付诸实践。这看起来像是一种心照不宣的员工福利。但事实上，这部分时间为3M公司创造了很多畅销产品，它也为如今的一些顶尖的技术公司（比如谷歌和惠普）开创了先河。
关于惠普的这个政策，我并没有找到太多的资料记载。偶尔有人提及时，它也总是被称作为“惯例”，而并非是一个明确的政策。Robert X. Cringely提供了更多的细节：
那个政策不是谷歌发明的，真正的发明者应该是惠普才对。而且，惠普创立这个政策的过程相当正式，它规定那10%的时间就是星期五的下午。想象一下：每个星期五的下午，在Palo Alto3，所有的工程师都在实现一些狂野的想法——这是何等的一番景象啊！这个政策还规定，那些工程师有权进入所谓的“实验仪器室”，在星期五下午，只要工作需要，他们可以从实验室管理员那里取走任何东西，包括显微镜、磁控管或者一桶丙酮等；他们不会因此受到任何质疑。这个政策刮起了一股创新疾风。于是，惠普的一些最伟大的产品诞生了（比如打印机）。
也许真的是惠普发明了这个政策，因为大家都知道，惠普公司早在1939年就成立了。众所周知，Dave Raggett在惠普工作期间发明了HTML，他在整个过程中扮演了很重要的角色。他很显然就是利用了那10%的时间。
尽管这个概念在谷歌之前就已经有了，但谷歌的的确确比其他任何人付出了更多，去检验它是一个有效的策略，并且让它在技术圈子里流行起来。无独有偶，我在谷歌的招聘网站上也没有找到任何关于20%时间福利的说明，但它确实是谷歌文化中不可分割的一部分。他们继续这个政策是有充分理由的，因为包括Gmail、Google News、Google Talk和AdSense等著名项目都是靠20%的时间做起来的。据谷歌的一位前员工Marissa Meyer4所说，谷歌的产品中有一半之多都来源于那20%的时间。
在惠普、3M和谷歌，他们最优秀、最受欢迎的产品中有“很多”都起源于一些碎片时间，在这些时间里，他们允许员工做任何他们想做的事情。这意味着什么呢？我们是否都应该在工作时间“放羊”，去试验我们自己的想法吗？这正是《The 20% Doctrine》（20%主义）这本书探讨的问题。
跟20%的时间密切相关的另一个说法是“创意日”（Hack Day）。“创意日”从常规计划表里切出特定的24小时，以鼓励多个大型团队在这个时间段聚在一起合作（或者友好竞争）。2005年的时候，Chad Dickerson在雅虎创立了最初的一个“创意日”。
上周五，在松散组织起来的一帮同事的协助之下，我在雅虎组织了第一个内部的“创意日”。“Hack”一词带有骇客文化的韵味，但同时也表明一个事实，那就是我们在尝试修复一个工作得不是特别好的系统。想法真的很简单：我们部门的所有工程师在那天都从本职工作中解脱出来，然后做他们想做的任何事情。唯一的规则就是，要在24小时内做出点东西，然后在那段时间结束的时候把它展示出来。其实，就这个事件本身而言，其基本运作方式在一些小型的创业公司里较为常见，但还从来没有人在一家知名公司里大规模地尝试过呢！
雅虎的第一个“创意日”显然是成功的。在一个挣扎着要创新的公司里，大概有70个原型在短短24小时之内一下子冒了出来，它们在一个热情欢快的氛围里被展示出来，人们禁不住都欢呼雀跃。那些习惯于穿着T恤衫的开发者们都废寝忘食，他们在周五晚上为了他们的原型程序而工作得很晚，别无他求，只为展示他们真正想要做的东西。Eric Raymond写了一本关于开源软件的书，名字叫《The Cathedral & the Bazaar》5（大教堂与集市）。他在书中是这么说的：“但凡优秀的软件，都源自于开发者个人的渴望。”很显然，雅虎的很多开发者都有他们个人的“渴望”，但只有在“创意日”的疏导之下，它们才被集中地激发出来。
Atlassian公司6的做法是每个季度举办一次“发布日”（ShipIt Day）。他们从2005年开始就这么干了。有趣的是，他们也曾尝试模仿谷歌的20%的时间政策，但结果不是很理想。
很显然，最大的问题是如何安排那20%的时间。有人是这么说的：“在交付新功能和修复bug的压力之下，切出20%的时间是不可思议的。”Atlassian需要频繁地发布产品，因此让团队有计划地停下来是很困难的。尤其对于小团队来说，让他们从核心产品开发周期中抽出一段时间是难以承受的。这跟团队主管是否苛刻没有关系。往往还是那些在用20%时间的开发者，他们不愿意因此增加同事们的工作负担。他们热爱他们正在开发的产品，并且对自己的付出引以为荣。然而，他们不想被人看成是在享受特权，而让别人去承受沉重的工作压力。
我个人认为，不管你在哪里工作，说服管理层支持类似于“创意日”或者20%的时间政策是值得的，因为由此带来的成功案例很多，而且大家都有目共睹。但在采取行动之前，请考虑一下你和你的公司是否准备就绪了。
1．项目计划表是否足够宽松？
如果你的项目计划表紧得没有任何空余时间，要想切出20%的时间或者举办“创意日”（哪怕只是偶尔为之）都是不现实的。如果你身边的每个人都在全负荷地拼命工作，而且长时间一直是这种状态，那么……这可能是有问题的。当然，每个人时不时总会面对一些紧要关头，但如果你的工作环境感觉起来永远都是紧要关头，那么你必须先把这个问题解决了再说。读一下Tom DeMarco7的《别让员工瞎忙》这本书吧，也许会有所启示。
2．公司文化容得下“白日做梦”吗？
如果有人会因为“看起来”不是很忙而被谴责，那么你公司的工作文化也许不能支持像“创意日”这样的活动。你必须要让“尖头发老板8”级别的人认识到，花在思考和“做白日梦”上的时间是有效工作的一部分。“白日做梦”与工作不是对立的；恰恰相反，创造性地解决问题需要这种“白日梦”。
3．可以接受失败吗？
当你获得“想做什么就做什么”的自由之后，你必须善加利用这个权利。我的意思是，员工不能再受条条框框的羁绊，他们要有在自己的“臭屁”项目上不幸失败的自由，并且不会因此受到责备或裁决。如果没有失败（以及很多经历），那就算不上是真正的试验，也不可能有创新。从失败中快速学习并继续前进，这种策略的价值是巨大的！
4．个人的试验是否能得到尊重？
跟集体项目的任务列表上的紧迫事项比起来，如果个人所做的试验得不到应有的尊重，那么“创意日”这样的活动注定会失败。作为公司，或者作为同事，你必须深信：重要的创新和改进可能会在任何时候以自下而上的方式来自于公司的任何人——它们不会按照神奇的总体规划上预定的间隔自动蹦出来。
花点时间去做你认为能够改善工作的任何事情吧，这不只是可以容忍的，更应该是受到鼓励的。对此做一些正式的规范和认可，可能大大有助于让大家少一点“工作就是干活”的感觉。