# 10 大脑时问与身体时间 第 9 章中描述了圣塔德雷莎。在开工前进行调研时，迈克库尔和他的助手们研究了开发人员在不同工作模式下花费的总时间。针对典型的一天，他们收集到开发人员的时间分配如表 10-1 所示。 表 10-1 开发人员怎样分配他们的时间 | 工作状态 | 时间分配比例(%) | | --------- | --------- | | 独自工作 | 30 | | 和别人一起合作 | 50 | | 和两个或更多人合作 | 20 | 从噪声的角度来看，该表的特征显而易见：在 30%的时间，人们对噪声敏感，而在其余时间，他们又是噪声的制作者。由于工作空间是人们独立工作和协同工作的混合区，从而带来了模式上的冲突。那些独立工作的人们对于这种冲突尤感不便。虽然在任何给定的时间段，他们只代表了少数人，但就此忽略他们却是一种错误；因为这是在他们独立工作期间大家应该做的工作。其余时间就耗费在部门活动、休息与聊天中了。 ### 流 在单一思考的工作时间里，理想情况下人们处于心理学家称为“流”( Flow)的状态中：流是一种深度的近乎于冥想的融人情况：在此种状态下，有一种普适幸福感存在，人们几乎不会意识到时间的流逝：“我开始工作。等我抬头一看，三个小时就过去了。”这里不会有工作量的感知；工作开展就像流一样自然：你可能经常处于这样的状态，我们就不再赘述了。 并非所有工作都需要进入流的状态才能变得高产，但对于从事工程、设计、开发、写作或类似的工作，流是必需的。这些任务都需要精神高度集中，只有处在流的状态下，你才能够很好地工作。 不幸的是，你无法像开关那样随时启动流。你需要一个缓慢的过程来进入状态，15 分钟或更长时间的集中才能把自己锁定在流里面。在这个引入过程中，你对噪声和干扰是非常敏感的。在一个毁灭性的环境，可能让你很难甚至不可能进人流的状态。 一旦锁定在流里，状态可能会被一个针对你的干扰（比如电话）或持续的噪声（“请注意，广播找人！保罗·博图拉卡请回电……”）破坏：每次被打断后，就需要再一个引入过程使你回到流的状态。而在引入过程中，你并不是真正在工作。 ### 没有流的无休止状态 假设打来的电话平均时间为 5 分钟，你重新引入的时间为 15 分钟，那么一个电话在沆时间（工作时间）上的损失就是 20 分钟。一打电话就会浪费掉半天时间，再加上其他的干扰，剩下的半天时间也泡汤了。这就是为什么“朝九晚五在这里什么也做不了。” 与工作有效性降低一样严重的是随之而来的焦躁。一个急切尝试想进人流状态，却又不停被打断的员工一定满脸郁闷。就在他将要完全沉浸其中时，又被拉回到身边嘈杂的环境中。不管他多么希望进入深度思考状态，现代办公环境总会尝试着推着他陷入各种无序的方向。设身处地地想象一下，如果你自己就是表 10-2 中填写了编码战争游戏时间的一位参赛者。 表 10-2 编码战争游戏时间表片段 | 工作时间阶段 | 工作种类 | 什么打断了这一阶段的连续工作时间 | | ----------- | ---- | ---------------- | | 2：13 - 2:17 | 编码 | 电话 | | 2:20 - 2:23 | 编码 | 老板停下来和你聊天 | | 2:26 -2：29 | 编码 | 来自同事的问题 | | 2：31 ～ 2：39 | 编码 | 电话 | | 2:41 ～ 2:44 | 编码 | 电话 | 就这般过了几天，每个人都开始准备寻找新工作了。倘若你是一名管理者，你可能不会太在意这种无法进入流的焦躁。事实上，你就是在不停被打断的模式下完成自己大部分工作的。但任何阻碍让大家进入流的事情都会造成工作效率与满意度的降低，从而导致工作成本的上升。 ### 根据流来计算时间 通常，现在公司的时间计算系统是传统模式；在这种模式下，完成的工作与花费了多少带薪工作时间成比例。当员工根据这样的体系填写时间表时，他们并不会区分花费在工作上的有效时间和焦躁时间。他们汇报的是身体时间而不是大脑时间。 更糟糕的是这样的工作计量数据也用来支撑薪酬计算。这就迫使员工不得不保证填入预先定下的工作时间数字，不管大家额外加了多少班或者其他隐形时间。遵循官方标准的方式或许是薪资部门喜闻乐见的：这就等于在点名时员工回答“到”。但对于任何一种通过生产效率来度量和分析钱的花销的研究来说，这样的记录实在是包含了太多水分，毫无用处。 关于流和引入时间的现象给了我们一个更加真实的方法来分析一项开发工作的时间花销。要计算的不是在岗时间，而是你真正全力发挥开展工作的时间。一个小时的流时间真正有产出，但夹杂在 11 个打断之间的 10 个 6 分钟的工作时段等于什么都完不成。 流计算系统的机制并不复杂，将原来的记录小时数改为记录没有打断的小时数即可。为了得到真实的数据，你必须消除大家的顾虑，不用担心是否填写了太少的不间断小时数。要让大家认识到，若一个星期仅有一两个小时不被打断，并非他们的错误；而是组织的问题，它没有为大家提供一个流友好的环境。肖然，这样的数据是不能提交给薪资部门的，你可能还是需要将出勤时间用于薪资结算。 比起采用出勤时间，基于流计算的工作时间计算体系具有如下两大明显优势：第一，这让大家能够关注流时间的重要性。如果他们获知每个工作日都应该保留两到三个小时的不间断时间，他们就会自发地去保护那些时间。意识到打断的后果可以避免大家不被同伴随意打扰。 第二，这样能够建立起一个有效工作时间的统计。倘若一个产品预计需要三千个有效流时间，已经记录了两千个有效流时间，那么你可以有根据地相信任务已经完成了 2/3。如果使用出勤小时数来做这样的统计，无疑是愚昧而又危险的。 ### E 参数 若你认同一个良好的环境需要给员工提供在流中工作的可能，那么，收集不被打断的时间数据，就可以作为度量环境好坏的参考。倘若不被打断的时间与总时间的比例相对较高，例如到了 40%；那么在这个环境中，只要需要，大家随时都可以进入流的状态。比例偏低，则说明存在焦躁情绪，会降低效率。我们称这样的度量为环境参数或者 E 参数： E 参数=不被打断的小时数／出勤时间的小时数 我们在收集 E 参数时，惊奇地发现该参数值在同个组织的不同地方存在巨大差异。比如，在一个大型的政府机构中，我们记录到的参数值最高达到了 0.38，最低为 0.10。这个机构的领导告诉我们，不管现在多么糟糕，物理环境是不能改变的，因为工作环境的特征都是政府政策和公共服务准则规定的。即便如此，我们仍然发现在一些地方，员工们 T 作在拥挤、嘈杂的开放式环境中；而在另外一些地方，从事同样工作的同级别员工却身处令人愉快的四人办公室。显然，没什么好奇怪的，四人办公室环境的 E 参数值一定会高些。 E 参数可能会威胁到目前的现状。（可能你觉得最好就不要开始收集数据。）如果你报告说一个合理的环境参数为 0.38，而成本削减了的环境参数为 0.10，大家可能很快就会发现成本削减很不合理。在 0.10 环境中工作的员工，比起 0.38 环境中的员工需要花 3.8 倍的出勤时间来完成同样的工作。这就是说，在成本削减的环境中，对工作表现的惩罚比节省的环境成本要多得多。显然，必须禁止这样的异端邪说，否则，我们努力削减工作空间得到的“节省”就不复存在了。在其他任何人读到这本书前，先烧掉它吧。 ### 一座丝巾花园 一开始度量 E 参数时，倘若数值在零附近徘徊，我们也不必感到惊讶。人们可能会觉得记录不被打断的工作小时数多么可笑：“在这样疯猛的环境里，还有不被打断的时间吗？”不要绝望，要记住你不仅仅是在收集数据，你还在帮助改变大家的态度。总是强调不被打断的小时数，就是在逐步提醒官方，应该给大家提供部分没有打扰的工作时间。这种认可让大家不由自主地想要躲起来，忽略一两个电话，或者关起门来工作（当然，还得有扇门才行）。 在我们的一个客户现场，在收集 E 参数数据的工作进行了几周后，办公桌的销钉上开始出现了红丝带。这种现象几乎是自发产生的，没有谁代表公司权力机构来建议说，这就是公司官方的“请勿打扰”标识，完全是大家集体产生的意见；每个人很快就理解了这个标识的重要性，并开始尊重这个标识。 当然，总有几个古怪的家伙会对“请勿打扰”标识嗤之以鼻。同僚的压力让我们大多数人都不好意思表达拒绝干扰的信息，哪怕只是一天中的部分时间。强调一点 E 参数能够帮助我们改变公司的文化，让大家意识到不要随意打断别人。 ### 对工作的思考 我在贝尔实验室的那些年，在两人间的办公室工作。空间很大，很安静，还可以限制电话呼入。我跟韦恩德·托密思共享这间办公室，他后来出去建立了一个生产电子玩具的小帝国。在办公室的日子里，他尝试建立电子交换系统的容错字典。它的体系架构是基于一个 n 空间相似度的模型。该模型本身就令人头疼，以至于韦恩德都没办法对此保持专注。一天下午，我正在搞一个程序列表，韦恩德茫然地看着外面，把脚翘在桌上。我们老板进来看见了问：“韦恩德！你在干啥啊？”韦恩德说，“我在思考。”然后老板说：“你能在家做吗？” -TDM 当年贝尔实验室的环境和当下流行的办公室规划的区别在于，在那些安静的办公室里，我们还能做些与工作相关的思考。今天我们见过的大部分办公场所都存在太多的噪声与干扰，以至于让严肃的思考基本无从开展。更让人感到羞愧的是：你的员工每天早晨带着自己的大脑来工作。只要能够让工作环境变得稍微有点显得平静安宁，他们就能够全身心扑在工作上，而不需要花费任何额外的成本。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.shiker.tech/ren-jian/di-er-bu-fen-ban-gong-huan-jing/10-da-nao-shi-wen-yu-shen-ti-shi-jian.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.