在工作场所引入“ 20％的时间” [关闭]

20％的时间是雇主的文化，允许员工将20％的时间用于他们认为有趣的项目上-可能是发明新的应用程序或改进了现有的流程等。有些人可能认为这很臭工作，但是该术语对您可能没有任何意义（或完全不同）。

有许多有案可查的案例，说明优秀产品是由公司的20％/臭鼬工作诞生的。似乎是双赢的局面。公司可能会获得出色的新产品或应用，开发人员将有机会展示自己的创造力和创新能力。

我曾无数次尝试在前任雇主中引入某种形式的20％/臭鼬工作，但没有成功。

我怎样才能更好地向管理层证明呢？处理这种工作安排的“正确”方法是什么？

20％时间的主要原因是将容量利用率保持在80％而不是100％。

您可以将软件开发组织视为将功能请求转换为已开发功能的系统。您可以使用排队论对其行为建模。

理论

如果请求到达的速度快于系统可以为它们提供服务的速度，则它们会排队。当到达速度较慢时，队列大小会减小。由于到达和服务过程是随机的，因此队列大小随时间随机变化。

从数学角度讲，可以问这种“随机性”：必须有一些概率分布，那么队列大小平均将是多少？数学（排队论）对此有一个答案：如果到达和服务过程都是马尔可夫，则N = rho ^ 2 / /（1-rho）。

（其中rho是等于服务率和到达率之比的利用率。如果过程不是Markov，则数学过程更为复杂，但不会更改结论。）

如果绘制此函数，则可以看到平均队列长度在利用率高达0.8时保持较低，然后急剧上升并达到无穷大。您可以通过考虑计算机的CPU来直观地理解这一点：当计算机的利用率接近100％时，计算机将变得无响应。

实践

软件开发的经济性使得当排队处于排队状态时，软件公司会付出高昂的成本。这包括错过的市场机会，过时的产品，过时的项目以及因预期需求而造成的建筑特征造成的浪费。

因此，20％的时间是对优化经济成果的问题的科学解答：通过避免高利用率来避免导致高排队状态。本质上是使系统保持响应能力的懈怠。

紧随其后的是一些实际结论：

• 如果您正在考虑20％的时间并进行成本核算（开发人员的时间成本为X，但是/并且公司可以/无法承受），那么您就做错了。
• 如果您将每周的20％分配给星期五，那么您做错了
• 如果您要设置20％的时间的项目建议书提交/审核/批准系统，那您做错了
• 如果您填写时间表，那说明您做错了
• 如果您将创新作为激励因素使用了20％的时间，那您做错了。尽管有20％的项目推出了新产品，但这并不是重点。如果您的公司在核心时间内无法创新，那就成问题了！
• 20％的时间与创造力无关。不要说您将用20％的时间释放自己的创造力，请问为什么您在核心时间内还没有足够的创造力。

意见中的答案

丹，您说对了，并准确地描述了许多人所犯的错误。您无法选择利用率，因为它是一个输出变量。它是两个过程的特征之比，所以它是正确的，因为这些过程就是它们的样子。组织确实对这两个过程都有影响力；能力和需求的匹配是精益软件开发知识体系所要解决的难题之一。利用率是衡量组织中此问题的能力的指标之一。随着您精益计划的进行，会出现松弛现象，并从价值流中消除浪费。但是，如果您指定20％的时间，则最终将陷入可用容量较少的同一利用率陷阱。

金，这仍然是部分文化的事情。我能想到的最接近的文化参考是所谓的组织变革的马歇尔模型的协同作用水平。它出现在成功的精益转型的末尾，或者出现在从一开始就建立精益的组织中。（这是Bob Marshall的白皮书（PDF）的链接。）

参考资料

在软件工程文献中很好地支持了以上逻辑。Mary和Tom Poppendieck在2006年的《实施精益软件开发》一书中对此进行了暗示。唐纳德·赖纳森（Donald Reinertsen）在其2009年的《产品开发流程原理》（第3章）中通过公式和图表对这一主题进行了深入的研究。

写完这个答案十四个月后，我想出了一个更好的答案。

我没有在这样的作品得到官方认可的地方工作。但是通过交谈和尝试了解这种做法，我发现了-嗯，大部分情况下，“ 20％的时间”不是：

• 这确实是一种文化而非政策
• 它不能由高级管理层裁定
• 它不能由开发者委员会发起
• 这不是32小时，而是8小时

“ Skunkworks ”与20％的时间不同。正如您所说的，有20％的时间是开发人员自己选择要从事的工作的时间。Skunkworks完全不同。skunkworks项目是由团队（通常是一支精干的专家团队）进行的高价值，高成本的项目，没有上级管理层的报告，并且团队自行决定在没有管理方向的情况下该项目应如何进行。这些项目通常是出于战术上或业务上需要完成某件事的需要，但是预算却没有余地。如果必须完成某件事，那就完成了-预算太高了。

我管理了一个开发团队，在那里我执行了20％的时间。还是尝试过。我得到了上级的同意，所以这不是问题。问题是团队太小，太专业了。每当出现问题需要立即进行干预时，就会碰到20％的时间。这最终经常发生。

我还发现我的一些开发人员发现我缺乏指导感到不安。即使我说过“只要您想做的事，只要它与编程有关，”他们仍然很难接受“任何”部分。他们认为某些项目会比其他项目更好，因此他们不可避免地要在主产品中处理低级实施要求，诸如此类。我希望他们能够分支并成长，但是他们会更深入地挖掘他们的主要专业知识。

我会再做一次，但是我会明确禁止开发主产品，并且可能会从一些想法中入手以开始使用。

我正在为实施20％政策的初创公司工作。这是我第一个这样做的雇主，当他在求职面试中提出这个建议时，我真的感到很惊讶，因为其他大多数雇主都试图不浪费一个小时。

刚成立时，我就加入了这家初创公司，并且近一年来，我是唯一的开发人员。我花了20％的钱基本上买了几件东西：

• 报告/修复随机开源项目中的错误 -可以像在Github上分叉一个有趣的项目并修复文档中的一些错字一样小。
• 编写开源的“东西” –诸如编程挑战之类的东西，只是为了好玩。
• 参加会议和冲刺 –我每隔几个月就会去一个冲刺，在那里我可以从事项目（其中一些可能由主应用程序使用，而其他则不行）并获得一些经验。我们的应用程序和其他公司开发的应用程序使用了一些库，这些库将开发人员发送到会议，因此可以将其视为对我们公司的直接收益。
• 学习新技术 –这是我学习Go的方式，即使我们在公司中不使用它。我的雇主特别鼓励这一点。最近，我一直在关注一些斯坦福大学的免费在线课程。

时间没有精确地测量，绝对不是32 + 8小时，有时候，当没有足够的时间来切断20％的时间时，有些紧急的事情要做，而其他时候我有更多的时间可以节省。

我正在远程工作，我们使用37signal的Campfire聊天进行通信并宽松地跟踪彼此的存在，并且这些时间被记录为“工作”时间，我已登录到聊天并可供同事使用，尽管很明显，我现在不在从事我们的项目。

根据我的小经验，我们的许多项目实际上都是以此方式开始的。我们有空闲时间和带宽来进行新项目，我们聚在一起，为我们部门提出了潜在的冷静/前瞻性想法。在我们的业余时间，我们开发了一个原型，并在对其进行了充分打磨之后将其展示给高层，通常他们会从中受益。

在我看来，高层知道他们想要什么，如果他们看到了它，却不知道自己需要/想要它，直到他们看到它为止。原型设计使我们能够创建自己的项目，提出建议，然后一旦获得批准，就将更多的时间用于完成它们。