TGViewer
Плохой менеджер Артём Арюткин Плохой менеджер Артём Арюткин @badtechproject · 14.2K subscribers
Post #1771 4.71K
“Task Interruption in Software Development Projects: What Makes some Interruptions More Disruptive than Others?”

Так-с, нашел для вас исследование о влиянии прерываний и переключений задач на разработку ПО.

Что происходит, когда разработчиков прерывают?

Традиционно считается, что внешние прерывания (сообщение, митинг, запрос от менеджера) хуже влияют на продуктивность, чем когда мы сами решаем переключиться на другую задачу.
Но данные из реального мира говорят иначе.

В своей статье исследователи провели два больших анализа:

Анализ логов задач
- 4 910 записей работы 17 профессиональных разработчиков.

Опрос 132 разработчиков
- реальные практики, опыт и восприятие прерываний.

Цель - понять не просто что прерывает разработку, а что именно делает переключение задач более разрушительным.

Главные выводы
⚠️ 1. Самопрерывания (self-interruptions) хуже, чем внешние
Хотя большинство разработчиков считают внешние прерывания более деструктивными, данные показывают обратное:
🔹 самопрерывания приводят к большей потере эффективности и ухудшают последующую работу над задачей.

Это может быть из-за когнитивной нагрузки:
Мы теряем контекст,
Теряем «поток»,
Требуется больше времени на возврат к задаче.

2. Момент, когда происходит переключение важнее характеристик самой задачи

Традиционные параметры задачи приоритет, уровень сложности, стадия влияют на её прерываемость. Но контекст и обстоятельства, при которых происходит переключение, оказывают куда более сильное влияние. К ним относятся:
✔️ тип прерывания (сам/внешнее)
✔️ время дня
✔️ тип текущей и следующей задачи
✔️ контекст проекта и среды работы

Это означает:
👉 работа над задачей в спокойный час с минимальными внешними отвлекающими сигналами менее подвержена разрушительному влиянию, чем та же задача на пике отвлекающих факторов.

3. Переключения имеют когнитивную цену
Разработчики часто не возвращаются к прерванной задаче или делают это с большим «ценой»:
Контекстное переключение требует восстановления рабочей памяти,
Увеличиваются задержки и риск ошибок,
Частые переключения фрагментируют рабочий день.

Практические выводы для команд
✅ Ограничивайте самопрерывания - поощряйте завершение текущих задач прежде чем начинать новые.
✅ Разграничивайте рабочие периоды с высокой концентрацией: вводите «фокус-часы» без прерываний.
✅ Управляйте внешними раздражителями: настройте правила коммуникации (телеграмм, почта, встречи).
✅ Понимайте контекст переключения: важно не только что делаешь, но когда и в какой ситуации.

Почему это важно для инженерной эффективности?

Эта работа - вызов для нас, с точки зрения процессов продуктивности. Она показывает, что традиционные представления о продуктивности часто неверны или неполны.
Если ваша цель сократить время восстановления фокуса, уменьшить когнитивную нагрузку и повысить качество релизов, то понимание природы прерываний и умение управлять ими становится ключевым навыком современной инженерной команды.
  • ❤ 22
  • 👍 9
  • 🔥 6
  • 👎 2
  • 😁 1
More from @badtechproject
  1. Sep 25, 2026ПЯТНИЧНОЕ Когда эксперимент оказался слишком успешным 🙂 Всем отличных выходных! 💬 ПРО ПР…
  2. Sep 25, 2026#пятничное
  3. Sep 24, 2026Ситуация в индустрии напоминает написание кандидатской по какой-то части теоретической физ…
  4. Sep 24, 2026С днем системного аналитика, друзья😉
  5. Sep 24, 2026Почему AI «плохая» технология Ваще, я технологический оптимист, как можно заметить по блог…
  6. Sep 23, 2026Post #2197
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →