技术负责人如何应对工作中频频被打断

本文翻译自《Managing your interrupt rate as a tech lead》原文分为三篇,作者是 Nicholas C. Zakas,他也是《Professional JavaScript for Web Developers, 3rd Edition》的作者。本文主要是在讲 tech lead 如何进行时间管理,写得特别好,建议仔细阅读一下。

我在 2008 年成为了技术负责人(tech lead),起初并不知道这是一种怎样的体验。在我的认知里,技术负责人和其他软件工程师没有太大区别,唯一的差别是技术负责人可以对技术决策做出最终决定。然而,我没想到的是,在那之后的日子里,发生了很大的变化。特别让我震惊的是,要越来越多的时间被花费到讨论上,而不是编码。

我的日程被会议填满了,在这些会议里与产品经理、项目经理和工程经理讨论项目。与此同时,其他工程师也经常打断我,向我问一些问题。不知不觉,我似乎没有完成太多工作。

对于新的技术负责人来说,这是一种常见的经历:你之前所掌握的时间管理技巧不再起作用。相反,你每天都会被频繁的打断,让你无法完成自己的工作,而且也没人来指导你如何去应对工作频频被打断这一问题。

1. 种瓜得瓜,种豆得豆

1.1 为什么技术负责人会遇到工作被打断问题

尽管技术负责人的角色在不同公司甚至不同项目中有所不同,但通常由两类任务组成:

  • 帮助他人 - 作为技术负责人,你会花费一部分时间帮助其他工程师完成他们的工作。这可能包括提供正式的代码或规范审查、指导、检查进展、回答问题,或其他各种事项,以帮助团队前进。

  • 自己的工作 - 你也需要有自己的产出。这可能是代码、技术规范、演示文稿、项目计划或其他你作为主要推动者的工作。

在与他人合作和独立开展工作之间来回切换,需要不同的时间管理技巧,这通常是技术负责人所面临的难题。他们觉得自己的工作是确保团队没有困扰,并让团队不断地前进。因此,一旦处于失联的状态,就会对工作效率产生负面影响。他们鼓励团队成员在任何时候都可以打断他们寻求帮助,通常通过实时通信渠道,比如聊天或即时消息。他们认为这样做可以建立信任,同时确保团队成员不会因为等待回复而受阻。虽然这种方法背后的思路值得称赞,即希望为团队成员提供支持,但最终结果是一天的工作混乱不堪,很难或根本无法在个人的工作上取得进展。

由于每次被打断需要大约 15 分钟才能重新集中注意力,技术负责人在这种以打断为驱动的环境下很难完成任何事情。那么解决方案是什么呢?

1.2 你的团队实际上并不需要那么依赖于你

当我第一次成为技术负责人时,我们团队使用 Yahoo Messenger 进行沟通。(对于不了解的人来说,Yahoo Messenger 是 2000 年代流行的即时通讯程序。)作为一个分布在不同楼层、不同校区乃至不同国家的团队,能够快速找到有问题的人是我们日常工作中的重要部分。作为技术负责人,我经常收到来自团队中 24 名前端工程师以及后端工程师、产品经理和工程经理的消息。

我的压力特别大,以至于我与我的主管开了一次会,探讨我是否适合这个职位。我向他描述了我的一天是如何度过的,他非常冷静地给了我一些建议。

"起初,你很好地引导团队成员在需要帮助时来找你。现在,你需要引导他们自己解决问题。并非每个问题都是 Nicholas (本文作者) 的问题。如果是只有你才能解决的问题,那就没问题,你可以去解决。但是如果是其他人可以解决的问题,就让他们自己去解决吧。"

新上任的技术负责人通常会认为,只有他们尽可能多参与项目才能成功,起初我也是这样想的。事实上,你参与项目的部分越多,团队的功能性就越低,进展就越慢。你的团队成员(理论上)被雇佣是因为他们也是有能力的成年人,可以在你的帮助下或者没有你的情况下交付高质量的软件。有时候你会帮助他们解决问题,但大多数时候他们有能力自己解决问题。

这是否意味着人们在解决问题时不会像你帮助他们那样迅速?实际上,并非如此,而这两者也没什么关系。每个人在解决之前从未遇到过的问题时,都会比较慢。通过自己努力解决问题,比直接得到解决方案更有助于巩固学习。通过过早地介入并为他人解决问题,实际上会剥夺他们更具成效的学习体验。通过努力解决问题所学到的经验是成长的源泉。

1.3 你得到的打断是你奖励的结果

虽然一些打断是因为人们遇到困难,但很多打断并不是因为他们真的遇到麻烦,而是因为他们不想花时间自己解决问题。如果他们可以发信息给你,并在几分钟内得到回应,那么他们为什么要花 15 分钟自己解决问题呢?这太低效了!当他们得到他们寻求的答案时,你们都会获得多巴胺的刺激,你为帮助别人前进感到自豪。这是一个上瘾的行为,对你们两个人都没有好处。

在我在 Yahoo 工作时,我注意到一个令人沮丧的模式:人们给我发送只是写着"嗨"的消息。我会回复以了解他们想要什么,结果发现那只是一些他们本可以自己处理的普通问题。这个"嗨"是另一种即时满足的行为,这只是一次询问,以确定我是否有空,然后再决定是否打扰我告知他们想要什么。

经过几个星期的这种情况,我决定尝试一种不同的方法。当我收到一个只说"嗨"(或"你好"或类似的)的消息时,我不会立即回复。我会等待看看他们是否会跟进并解释他们需要什么,如果他们没有,那就结束了。而且大多数情况是他们并未跟进,这告诉我两件事:1)他们所需要的其实并不那么重要,2)他们找到了如何自己处理的方法。而且作为额外的收获,一旦我这样做了几个星期,"嗨"这样的消息几乎就消失了。

这对我来说是一个重要的教训:你得到的打断是你奖励的结果。如果我继续迅速回复"嗨"的消息,我将继续收到它们。通过不立即回复,我给出了负面反馈,教导每个人不要打扰我。他们无法通过这种行为获得他们寻求的多巴胺刺激。另一方面,如果他们给我发具体的问题,我会立即回答。所以我在不想要的打断上提供了负面反馈,而在我想要的打断上提供了积极反馈。

要控制你不想要的打断,只需不立即回应。练习在收到不想要的打断后等待一个小时,逐渐教导人们不要期望即时满足感。(如果一个小时感觉太长,可以先等待 15 分钟再回应。设定一个计时器,直到它响起后再回应。你会习惯的。)

1.4 其他你可能在鼓励的打断方式

当然,"嗨"消息并不是你可能无意中鼓励的唯一交互方式。每当我听到有人抱怨与他人的互动时,我经常会想起首席执行官教练杰瑞·科隆纳问他的客户的这个问题:

"你如何能够串联一切来制造那些你说你不想要的条件?"

你遇到的许多打断都直接与你对待它们的方式有关。因此,每当你遇到一个不受欢迎且不重要的打断时,请问自己你做了什么来鼓励这种行为,以及你能够做些什么来阻止它。以下是一些人们常常困扰的其他常见打断情况:

  • 下班后的电子邮件 - 我曾经与很多人谈过,他们认为下班后的电子邮件是他们工作生活的正常组成部分。虽然对某些人来说可能是真的,但下班后的电子邮件几乎总是因为你回复了下班后的电子邮件而产生的。当人们知道你在下午 5 点后查看电子邮件时,他们就会在下午 5 点后发送电子邮件;当人们知道你在下午 5 点后不查看电子邮件时,你将在下午 5 点后几乎不会收到电子邮件(或者至少,你收到的电子邮件不需要立即回复)。

  • 阻塞时间内的会议 - 一些技术负责人学会在日程安排中为工作或个人任务设置阻塞时间,但当有人在这段时间安排了会议时,他们却接受了。猜猜发生了什么?一旦你这样做了,你就传达了这种打断是适当且可接受的信号,因此这种情况会更加频繁发生。当我通过拒绝会议邀请将我的阻塞时间视为神圣而保护起来时,我就不再收到那些会议请求了。

  • 专注时间的打断 - 如果你与团队在办公室共同工作,建议设置专注时间指示器,让人们知道你不希望被打断。常见的指示器包括戴着耳罩式耳机、小纸条上贴着绿色/红色标记以及方格间上方挂着红绿灯。当然,当你设定了专注时间指示器后,需要拒绝试图打断你的人。保护你的专注时间会逐渐教导人们等待。

当然,你肯定会遇到更多你鼓励但实际上想要避免的行为的情况。你能够避免所有打断吗?当然不能。有一些合理的打断,但这种情况比填满你整天并造成不必要压力的打断要少得多。

1.5 小结

技术负责人需要学会平衡自己的工作任务和帮助团队其他成员。这必然会产生一些摩擦,因为大多数技术负责人倾向于将团队的需求放在个人之上,所以他们会明确或含蓄地鼓励打断。虽然这可能对团队中的其他人有利,但这也意味着你没有时间完成自己的工作。

好消息是,你对于接受打断拥有 99% 的控制权。当现状不适合你时,你不必接受它。通过每一次互动,你都在训练你的同事什么样的打断是可接受的,如果你遭到了你不想要的打断,那么你可以通过消除积极反馈来改变这种情况。

你的团队成员是成年人,他们被聘请来做一项特定的工作,虽然通过不断打断你他们可能更高效,但他们也可以在不打断你的情况下正常工作。你可以鼓励他们尝试自己解决一些问题,如果真的遇到困难再向你寻求帮助,或者告诉他们你现在不方便但几个小时后会有时间,看看会发生什么。在第二部分中,我将讨论如何管理你的日程,以最大程度地减少对你工作的不必要的打断。

2. 主动出击,填充日程

如果你和大多数人一样,你的工作日程主要用于展示给他人你的空闲时间。当别人想和你交谈时,他们会在你的日程上的空白时间段安排会议。随着越来越多的会议被安排,空余时间变得更少,留给别人与你安排会议的选项也减少了。在成为技术负责人之前,你的会议数量仍然给你留下了很多编码的空闲时间。毕竟,你的主要工作仍然是产出代码,你的同事(希望如此)会尽量减少打断。但作为技术负责人,这些空闲时间段被占用得更快。你永远不知道会议请求何时会显示在你的日程上,这使得开始任何需要专注的任务变得困难。幸运的是,还有另一种方法。

2.1 倒置你的日程,使用时间块

另一种方法叫做时间块。与其让你的日程大部分为空白,让人们通过发送会议邀请来填满它,不如从给特定任务设置时间块开始。也许你需要编写或审核技术规范?在日程上为此安排一个小时的时间块。你需要编写一些代码吗?在日程上留出 90 分钟的时间块。你负责批准拉取请求吗?早上和晚上各留出 30 分钟的时间块来处理这些事务。如果你在想,"等一下。如果我用所有这些任务填满我的日程,看起来我比实际上要忙",那么是时候换一种思路了。

无论你需要做什么,都需要时间,甚至包括人们认为是"免费"的事情,比如查看电子邮件或吃午饭。当这些任务不在你的日程上时,实际上会产生你有空闲时间的错觉。这些事情仍然需要完成。只不过看你的日程的同事不知道你何时会做这些事情。对他们来说,一个空闲时间段意味着你可以参加会议,即使你计划在周三下午处理那个迭代任务。

通过在日程上放置你需要完成的实际任务,你正在做两件事情:

  • 准确地规划你的日程安排,所以你知道什么时候该做什么。如果一个会议邀请在任务时间块期间到来,你清楚知道如果接受它,你将放弃什么。

  • 让同事们知道你真正有空参加会议的时间。当你的日程被任务填满,并留出一些空闲时间段时,人们通常会默认在这些时间段安排会议。这样,周三下午的迭代任务就不会被打断。

无论哪种情况,你都在为你的可用性和时间使用方式创建一个更准确的视图。

2.2 常见的需要放在日程上的任务

确定要放在日程上的任务比看起来更具挑战性。一些任务很容易界定,并可能存在于迭代计划中,但你每天还做些什么呢?以下是一个非详尽无遗的任务类型列表,可以放在你的日程上:

  • 异步沟通 - 你肯定需要时间检查公司使用的任何沟通系统,无论是电子邮件、Slack、Yammer 还是其他任何方式。你可能会在一天中的某个时候定期进行这样的检查,但更好的方法是在一天中安排时间进行检查。

  • 午餐/休息 - 每当你想自己花点时间时,把它放在你的日程上。全天都要定期休息和恢复精力,将这些放在日程上会提醒你去做。

  • 家庭事务处理 - 如果你有任何需要定期检查的个人问题,也要放在你的日程上。

  • 社交媒体检查 - 不管在工作中是否检查社交媒体是一个好主意,很多人都这样做。如果这是你的例行事项,应该放在你的日程上。(如果这是你的工作内容,那肯定应该放在你的日程上。)

  • 分配的任务 - 无论你使用的是迭代、看板还是其他形式的计划,你可能被分配了一些任务,有交付内容和截止日期。把它们放在你的日程上,并具体标注你将要完成的任务(而不是"编码时间",你可能不知道自己打算做什么)。

  • 代码审查 - 作为技术负责人,审查同事的代码是一项常见任务。你可能希望每天安排时间进行审查,甚至一天进行几次,以确保人们不受阻碍。

  • 临时任务 - 你可能会有一些自己分派的任务,这些任务也应该放在你的日程上。再次提醒,务必标记出这个时间块,以便清楚知道你打算用那段时间做什么。例如,审查规范、审查简历、撰写博客文章、撰写文档和准备演示文稿等任务都是这样的例子,这些任务可能没有在你的工单系统中正式分配给你,但你仍然需要完成它们。

  • 日程计划 - 每周五,花 15 到 30 分钟的时间来设置下周的时间块。你应该对自己即将处理的任务有足够的了解,以便使自己能在周一上班时准确安排时间。

从这个列表中可以看出,你的日程不再只是用来安排会议。它可以用于任何需要消耗你时间的任务。会议将始终通过会议组织者找到你的日程,而这些任务只有在你有意添加它们时才会出现在日程上。

时间块的黄金法则是:如果做某事需要时间,那么它就会出现在你的日程上。

2.3 消除时间块中的干扰

也许时间块中最重要的部分是在预定时间段内消除所有干扰。毕竟,如果你在检查规范的一个小时时间段内被电子邮件、Slack 或社交媒体打断,那么这个时间块有多有用呢?因此,消除干扰对于使时间块成功非常关键。

当你在进行任务块时,尽量消除所有干扰。以下是一些建议:

  • 关闭电子邮件、Slack 和社交媒体(不仅仅是最小化窗口,要关闭应用程序)。你应该在日程上安排了定期检查的时间。

  • 考虑将手机设置为"勿扰"模式,以消除应用程序的提示音和信息通知。

  • 关闭任何你没有在使用的应用程序(包括网页浏览器)。

  • 如果你正在使用网页浏览器,请关闭所有你没有在积极使用的标签。可以使用像 Momentum2 这样的扩展来帮助你在打开新标签时集中注意力。

如果你正在使用具有"专注模式"的应用程序,请将其打开。例如,Visual Studio Code 有一个名为"禅意模式"的功能,可以将屏幕上的其他内容屏蔽掉。

总体目标是,当你说你要在周一的 13 点到 14 点之间检查规范时,你实际上是在检查规范,而不会被其他事情分心。只专注于你在此期间分配给自己的任务,并一直工作直到完成或达到下一个合适停止点。

2.4 日程的前后变化

为了让你对时间块在实践中是什么样子有一个概念,看看在实施时间块之前和之后,你的日程可能会是什么样子是很有帮助的。如果你是一位技术负责人,尚未设置用于时间块的日程,你的日程可能如下所示:

之前的日程:每天早上 9:30-9:45 进行日常站立会议;周三中午吃团队午餐;一对一会议和其他会议零散地安排在整个星期中。

紫色的预约日程是由你的团队设定的,蓝色的预约日程是你与其他人实时互动的时间。当你看这个日程时,除了每天上午 9 点 30 分的日常站立会议和每周三下午 1 点的团队午餐外,日程上大部分都是空白。当然,它实际上并不是空的 - 你需要那段空闲的时间来完成被分配给你的所有工作,以及预期的但通常未计算在内的所有工作。无论何时有人想要与你安排事情,你日程上的任何空闲时间都可以使用,在这个日程上,有很多空闲时间。

一旦你过渡到时间块,你的日程会更像这样:

时间块日程:每天都有特定的任务在特定的时间安排,中间夹杂了其他会议

当你看到一个时间块日程时,很容易发现原始日程上的所有空白空间实际上并不是空闲的。那些日常站立会议、团队午餐以及第一个日程中的其他所有会议仍然存在,但现在你可以看到在这些会议之间你要完成什么任务。我用红色标记了涉及特定软件的任务,用黄色表示你独自完成的任务,用绿色表示休息时间。你的日程上仍然有空闲时间,但比之前少得多。

2.4 保护你的时间块

在为日程设置时间块并计划消除干扰之后,还有最后一步需要注意:保护你的时间块免受同事的干扰。根据你所在公司的日程文化,你的同事可能能够看到你在时间块上标记的内容,或者他们只会看到那段时间是"忙碌"的。在这两种情况下,你可能会在你的日程被阻塞的时间段收到会议请求。你如何应对这些请求将决定你的同事是否会尊重你的日程。

正如在第一部分中所讨论的,你会得到更多你所鼓励的打扰。如果你总是接受在时间块上的会议请求,那么你就传达了你的时间块并不重要,别人可以随时安排会议。另一方面,如果你总是拒绝在时间块上的会议请求,人们可能会感到沮丧,并抱怨你从来没有空闲。自然而然,正确的做法在于取中间道路。

假设人们在很大程度上遵守你的日程可用性,只偶尔会在时间块上发送会议请求,最简单的做法是询问这个请求的重要性。毫无疑问,在紧急情况下,你需要改变当天的计划并重新安排时间块,但这应该是例外而不是规则。规则是让人们找到你日程上的一个空闲时间段,并在那里请求会议。如果由于某种原因无法找到合适的时段,那么你的责任就是确定会议请求的重要性,只接受最重要的邀请。如果副总裁想要召集一组 10 个人讨论新举措,那么你很可能需要调整你的日程安排;如果同事想请教你对他们撰写的内容的意见,那可以等待。

在处理这些请求时要根据情况行事,但始终以拒绝为默认,并提议一个你有空闲时间的新日期和时间。有时可能要等到下周才有空闲,对许多请求来说这是可以接受的。

2.5 小结

在成为技术负责人之前,你可能没有花太多时间管理自己的日程,所以你的日程很可能大部分都是空闲时间,偶尔会安排一些会议。剩下的时间都是属于你自己的,而且大部分时间都用来完成任务。偶尔出现在你日程上的会议并不是什么大问题,因为你有很多空闲时间来履行其他的职责。

作为一名技术负责人,你需要平衡自己的任务和帮助他人的工作,如果允许他人通过会议请求来控制你的日程,那么你将经常被打断,计划好的事情也会受到干扰。解决方案是使用时间块,在你的日程上创建专门用于特定任务的时间块。这些任务包括查看电子邮件、代码审查和编写代码等。任何需要时间或专注力来完成的事情都应该成为你日程上的一个时间块,这样你和同事们都知道在这段时间里你是忙碌的。

仅仅表示在某个时间段你很忙是不够的。你需要通过关闭电子邮件、聊天和社交媒体来消除自己的干扰,以便能够专注于自己的工作;你可以安排一段时间来稍后查看这些。当你为某个特定任务安排了时间块时,只专注于这个任务,不要处理其他事情。

当你收到与你的时间块重叠的会议请求时,你还需要保护你被阻塞的时间。你如何应对这样的请求将决定其他人是否尊重你的日程。如果你总是在被阻塞的时间接受会议邀请,你就会继续收到这些请求。通过拒绝大部分请求并建议一个更合适的时间来保护你的日程。是的,会有紧急情况需要腾出时间,但那应该是例外而不是规则。

也许你会想,这听起来很好,但这是否意味着我整天都在忽视我的同事?我什么时候能和他们交流?答案是在办公时间内,这将在本系列的第三部分进行讨论。

3. 集中处理,提前预约

如果你按照之前两部分的建议去做,现在你可能已经让你的同事们不再随意打断你。你停止了奖励那些你不希望发生的打扰行为,所以这些情况变得越来越少。你已经在日程上划分出了专门用于任务的时间,并拒绝了在这些时间段发送的会议请求。你还选定了每天的特定时间来回复电子邮件和 Slack 消息。但是你感到不舒服。似乎你在忽视你的同事。你喜欢你新的高效水平,但不喜欢感觉自己让队友失望。这就是办公时间(Office hours)的用处所在。

3.1 将打断集中在办公时间中

大学和学院通常要求教授有办公时间,以便学生在课外获得额外的帮助或提问。教授每周发布他们在办公室的时间,学生知道他们可以随时过去(或在这个时间段内安排一个时间)寻求额外的帮助。这样教授就可以不需要处理来自所有学生的不断问题和打扰。作为技术负责人,你也可以采取同样的做法。

还记得系列文章第一部分提到的那些随机的"嘿"消息吗?你可能遇到了类似的情况,人们只需要你几分钟的时间来回答问题。这是你作为技术负责人的工作的一部分,而且这种情况永远不会消失。相反,你可以将所有这些打扰集中到一周的几个特定时间段内。这样,你就不会整天接收到随机的请求,而是让队友们知道他们可以在办公时间内向你提问,并乐意回答他们的问题。

由于你已经在日程上划分时间块,你可以每周多次为办公时间添加时间块。根据你的打断频率,你可能想每天预留一个小时,或者在周一、周三和周五预留两个小时......确切的时间安排可以根据你的需求进行调整。最重要的是,这是一个专门用于集中处理打扰的时间块,而不是让它们在全天不定期发生。

如果你使用的是 Google Calendar,在这种情况下有一个完美适用的功能,叫做预约日程(appointment schedules)。你可以创建一个预约日程,让人们在你的时间段内请求预约。当人们查看你的日程时,他们将看到你的预约日程,并可通过链接在该时间段内安排时间。如果你没有使用 Google Calendar,你可以在日程上创建一个标记为"办公时间"的时间块,并将其设置为"可用"而不是"忙碌",以便让其他人轻松看到你什么时候有空。

起初,你可能会遇到一些抵触这种变化的反对声。人们会觉得如果不能立即联系到你,就无法发挥自己的最大效率。因此,我建议每天开始先安排一个办公时间,并等到你和团队都适应了之后再调整(在极端情况下,每天安排两个时间段可能会有用)。如果人们知道他们需要等待与你交谈的最长时间是 24 小时,那么他们就会感到更少的焦虑。后来,你可以调整时间安排以更好地满足团队的需求。

几周后,你可能会发现,与之前不经安排的打断相比,你收到的计划好的打断变少了。为什么呢?因为人们在等待与你见面的过程中解决了自己的问题。这是一件好事,因为团队正在学会更有韧性和独立解决问题,从而释放出你的时间,让你专注于自己的工作任务。

此时,你可能正在思考,那对于其他的所有会议,我该怎么办呢?

3.2 为其他会议设置预约时间块

为办公时间预留时间块实际上只是在你的日程上设立特定类型的预约时间块,也就是说这些是用于可能与他人进行预约的定期时间段。技术负责人经常被拉入不同类型的会议中:与其他工程师的一对一会议、与经理的会议、产品或架构审查等。如果有你需要参加的定期会议,好消息是,这些已经在你的日程上有所体现,并且我鼓励你将其设置为重复会议,这样你就不必再去考虑它们了。对于其他类别的会议,人们请求你的时间,最好为这些目的设置预约时间块。

如何设置这些时间块完全取决于你。也许你想要为一对一会议单独设置专门的时间块,与其他类型的会议分开。也许只有一个大的"会议"时间块,可以安排任何类型的会议。你可以根据你经常参加的会议选择最合适的系统。而且请友善地对待你的同事:在早晨或深夜预留会议时间并不能解决问题。确保你的预约时间段是在人们最有可能请求的时间段内。

当然,有时候人们需要在你规定的预约时间之外安排会议,但希望他们提前联系你,告诉你原因。当然,你不能告诉工程副总裁说你不能参加临时会议。但是当你开始更好地管理你的日程时,你会发现某些会议会在特定的时间出现,然后你就可以相应地调整你的时间块。

3.3 日程的前后变化

之前,我向您展示了在使用时间块之前,您的日程可能会是什么样子:

之前的日程:每天早上 9:30 到 9:45 有团队站立会议;周三中午有团队午餐;一对一会议和其他会议零星分布在整个周内。

接下来,您学习了如何使用时间块将任务安排到日程中,并初步规划了您一周的安排。现在,当您添加预约时间块时,您将更清楚地知道特定类型的会议安排在何处:

时间块日程:每天都有特定时间分配给具体任务,办公时间和一对一会议也分别安排在本周的特定时间段内。

这是一个完全按时间块划分的日程,其中包括办公时间和一对一会议的预约时间块,这两种是技术负责人经常被要求参加的重复性会议。办公时间比较规律,通常是午饭后的 30 或 60 分钟;而一对一会议的时间段则根据可用性安排在周二至周四的不同时间。请记住,尽管这些时间已被预留,但您可能并没有在这些时间段内有任何预约。目标是将它们安排到您的日程中,以便在需要时您知道何时会发生。

请记住,您不需要将每一天的每个小时都预留出来。当您在周五进行每周日程规划时,您可能会发现您的任务和预约时间块并没有填满整个日程,这是可以接受的。只要为您知道需要做的所有事情预留了时间块,留下空闲时间段并不是错的。您甚至可能会发现到了周五,所有的空闲时间段都被填满了。

那么,如何过渡到这个新系统呢?

3.4 沟通至关重要

为了更好地控制你的中断率,你必须明确告知什么样的打扰是可以接受的,以及何时可以打扰。突然改变你的行为会给团队带来不必要的干扰,也会让团队成员更难接受。你可以通过提前告知团队并对其反馈持开放态度来尽量减少这种干扰。一个好的方法是解释说你将尝试这个新流程六周,并根据之后的反馈进行调整。

以下是一封重设关于打扰期望的电子邮件示例:

大家好,

作为技术负责人,我在不断发展的过程中发现自己的时间利用效率不够高,也无法达到我希望的效果。为了解决这个问题,我计划从下周一开始做一些工作上的改变,并且想提前告诉大家以防有任何问题或顾虑。我将进行以下改变:

Slack:我将限制在 Slack 上花费的时间。我发现经常被通知打扰很难集中注意力完成任务。我每天只会检查三次 Slack,并且只在那些时间段内回复消息。如果你需要得到简短的答复,Slack 是与我联系的最佳方式。

技术帮助:我每天下午 2 点到 3 点将作为我解答技术问题的办公时间。请在那段时间内安排一个 15 分钟的时间块,我很乐意直接与你沟通。这样,我就能在我知道自己可以集中注意力的时候全神贯注地帮助你。

一对一会议:如果你需要安排更长时间的讨论,请使用我日程上的一对一时间段。 其他会议:如果你需要安排其他类型的会议,请在我的日程中找到空闲时间段。如果你在你所需的时间范围内找不到合适的时间,请告诉我,我会调整我的日程安排。

紧急情况:如果有任何需要我立即处理的紧急情况,请打电话(而不是发短信)给我的手机。我关闭了短信通知,但电话总是会接通。

我计划尝试这个流程六周,看看效果如何,并且非常希望在过程中得到你们的反馈,以便我在有需要时进行调整。同时,如果你有任何问题或顾虑,请随时与我联系。

当你发送这样的电子邮件时,你很少会遇到对改变的阻力。明确要求反馈并允许人们提出问题可以降低问题发生的可能性。你也没有指责别人或告诉别人不要打扰你。相反,你重新界定了希望如何与你进行不同类型的讨论和如何安排时间。这种清晰度在某些情况下会使人们更有可能找你,因为他们不再担心在不合适的时候打扰你。

3.5 小结

技术负责人的角色充满挑战,通常情况下,你的经理可能并不是一个技术负责人,可能无法为你提供关于如何管理时间的最佳指导。在帮助他人和处理自己的工作之间找到合适的平衡非常重要,而管理被打扰的频率是找到这种平衡的最佳方式之一。

管理打扰频率的一种方法是通过时间块划分来调整你的日程,确保每个你想要专注完成的任务都安排在特定的时间段。这样可以防止人们在这些时间安排会议。只要你专注于手头的任务,关闭其他应用程序并避免其他干扰,你会发现你能做更多的事情。为电子邮件和 Slack 设置时间块,确保你在一天中与团队成员保持正常的沟通。

为了弥补随机打扰的损失,安排定期的办公时间可以让团队成员知道什么时候可以与你联系。具体的办公时间安排取决于你和团队的决定,但应该每周进行几次。在找到最适合你的团队的办公时间安排之前,你可能需要经历几轮尝试。你还可以为其他类型的定期会议,如一对一会议或产品评审,设置类似的预约时间块。

作为技术负责人,很大程度上是关于有效分配时间来帮助团队实现目标。本文讨论的工具可以帮助你重新掌握自己的时间,并使你在交付结果方面更加高效,同时让团队能够在没有持续打扰的情况下成长和学习。

相关推荐
小白学前端66642 分钟前
React Router 深入指南:从入门到进阶
前端·react.js·react
web130933203981 小时前
前端下载后端文件流,文件可以下载,但是打不开,显示“文件已损坏”的问题分析与解决方案
前端
outstanding木槿1 小时前
react+antd的Table组件编辑单元格
前端·javascript·react.js·前端框架
好名字08212 小时前
前端取Content-Disposition中的filename字段与解码(vue)
前端·javascript·vue.js·前端框架
隐形喷火龙2 小时前
element ui--下拉根据拼音首字母过滤
前端·vue.js·ui
m0_748241122 小时前
Selenium之Web元素定位
前端·selenium·测试工具
风无雨2 小时前
react杂乱笔记(一)
前端·笔记·react.js
前端小魔女2 小时前
2024-我赚到自媒体第一桶金
前端·rust
鑫~阳3 小时前
快速建站(网站如何在自己的电脑里跑起来) 详细步骤 一
前端·内容管理系统cms
egekm_sefg3 小时前
webrtc学习----前端推流拉流,局域网socket版,一对多
前端·学习·webrtc