工程师坐在办公桌前，对项目取得进展的前景感到兴奋。她正在为下游的UI团队提供一个API。她看了一眼日历，情绪低落下来。与她的经理一对一的会面，另一次向团队汇报项目状态的会议，一次现场采访，一个电话屏幕，让她一天都过得很顺利，确保了除了午餐之外没有一个小时的连续营业时间。她叹了口气；考虑到她必须实现的代码的复杂性，她的代码今天无法完成。这一现象，在保罗·格雷厄姆的《创客时间表》（Maker'sSchedule）一书中得到了恰当的总结，这篇文章是在德尔菲斯（Delphix）为所有工程师和经理举办的一次活动中提出的。这个概念是，那些正在做事情的人希望能够把他们的时间用在更大的块上，以便最大限度地朝着一个目标前进。相比之下，经理们习惯于更频繁地改变任务。毕竟，管理者的工作不是建立一个东西，而是确保团队建设的东西有它需要的东西。我知道你在想什么。哦，呜呜，如果你有太多的会议，就开始提供新的时间表和/或拒绝其中一些。当会议的参与者很少或只是工程设计时，这是可行的，但并不总是那么容易。与其他学科的人会面，尤其是那些有压力的人，比如销售人员，更难拒绝。尤其是销售人员，要么希望得到有助于赚钱的信息，要么就应该得到能阻止他们承诺让公司付出代价的信息。这些会议往往很重要，而且无论如何都会发生。对工程师来说，面试也很难控制，因为面试官和面试官都要考虑面试的日程安排，通常几名工程师会安排在同一天面试应聘者。虽然有可能与某人交换一个位置，但是没有一个简单的方法可以解决这个问题，因为没有人能免疫这种影响。此外，已经建立代码库区域所有权的工程师通常会被其他人找来咨询与他们所拥有的区域相关的问题。有时这些是预定的会议，有时是临时性的。任何一种单独的交互都不会造成太大的麻烦——每种都只代表一个短暂的中断。总的来说，这种影响对制造商的生产力是毁灭性的。我们在德尔菲克斯的很多人真的想解决这个问题。毕竟，制造商们想制造东西。经理们也希望得到帮助来解决问题；我们进入管理层并不是为了损害同事们的生产力！我们很清楚，如果问题有多个原因，可能不只有一个解决办法。如前所述，解决不那么重要的会议的办法就是不召开会议。拥有更多所有权的工程师可能会选择通过保留"办公时间"来压缩对时间的需求。为了帮助安排面试时间，我们正在试用软件来限制发送给任何开发人员的面试次数，并与招聘部门合作，以确保工程师的面试安排在一起，而不是分散在日程表上。这可能意味着我们都需要在尊重面试开始和结束时间方面有更多的纪律，但要求受过高等教育的专业人士遵守纪律并不是一件容易的事。也许到目前为止，我们采取的最大的一步是把一整天定为"创客日"，不鼓励开会和面试。他们不是被禁止的；他们的想法是给制造者一个工具来控制他们自己的生活，而不是为他们控制。它现在作为一个日历邀请每个工程师，阻止了一整天。如果解决问题的第一步是承认问题的存在，那么我想我们现在已经向前迈出了两步。到目前为止，来自团队成员的反馈是非常积极的；似乎"创客日"和我们安排面试方式的改变有助于在整个组织内建立对这个问题的认识。当然，这只是一小步，但我们的希望是，未来我们将能够做更多的事情来满足制造商的需求。