Разработка высоконагруженных систем — типовая инженерная задача. Для неё есть паттерны, инструменты и понятные подходы. Но что делать, когда нагрузке подвергаются не приложения, а люди? Когда одновременно растут сроки, количество задач и неопределённость — и сбой даёт уже не система, а команда?

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

Пролог

Неделя 1, понедельник

Проснулся сегодня без будильника. На завтрак хочется приготовить что-то необычное. По дороге в офис пролистал мемы в любимом канале, прочитал вчерашние новости. В офисе пока мало людей. Хватит разговаривать у кофемашины, пора делать мир лучше! Сегодня в планах продолжить работу над редизайном нашей системы. Новые подходы помогут снизить затраты на её расширение, а существующие пользователи будут испытывать меньше трудностей, которые регулярно возникают из-за старой архитектурной проблемы. Да и поддержка скажет спасибо: на недостаток тикетов там никогда не жаловались. Сегодня подходящий для этого день: встреч меньше обычного, все при делах. День подходит к концу. На экране уведомление с сообщением для команды от нашего менеджера: к нам приходит новый важнейший проект RT-2119.

Неделя 2, понедельник

Будильник прерывает сон на самом интересном месте. Быстрый завтрак, и в дорогу. По пути в офис надо перечитать итоги пятничного вечернего обсуждения проекта RT-2119. Не успел дочитать: внимание отвлёк отчёт от руководителя группы поддержки за выходные дни. Тикетов в выходные было намного больше, чем на прошлой неделе. Кажется, исправить проблему при помощи редизайна системы не успеваем. Придётся применить временный фикс, который берегли на крайний случай. Проблему не исправит, но даст время доделать новую архитектуру. Протискиваюсь мимо коллег у кофемашины. Быстро сделаю кофе и побегу к столу: встреча по RT-2119 сегодня раньше обычного.

Неделя 3, понедельник

С трудом открыл глаза, сразу иду смотреть корпоративный мессенджер. Кто-то обсуждал в воскресенье проект RT-2119. А это что? Разработчик вчера вечером прислал merge request с доработкой в рамках редизайна нашей системы. Планировали закончить ещё в четверг, но затянувшиеся споры при обсуждении контрактов повлияли на сроки разработки. Если не успеем протестировать, то и сегодняшний релиз по RT-2119 придётся перенести. А из-за этого опоздаем с началом уже нового проекта, который мы получили на прошлой неделе, — RT-2120. Позавтракать не успеваю, зацеплю что-нибудь по дороге. Традиционный отчёт от руководителя службы поддержки. Cудя по сегодняшнему отчёту, мы снова приближаемся к показателям прошлой недели. Надо посоветоваться с командой насчёт плана действий. В офисе сегодня особенно людно. Утренняя встреча начинается с быстрого разбора инцидента с прошлой недели: при релизе обнаружился баг, пришлось откатываться. Когда вообще с этим разбираться? Весь день встречи по RT-2119 и RT-2120.

Неделя 4, понедельник

И зачем я поставил на будильник такой раздражающий звук? Хотя любой звук будет раздражать, если он звучит через три часа сна. Какая-то неправильная фаза сна начинается на третий час, во время неё особенно сложно просыпаться. Зато засыпается после домашнего хакатона вполне легко. Так, если не встану прямо сейчас, опоздаю больше чем на десять минут. Собираясь, пролистываю груду непрочитанных сообщений. Тут отвечу позже, тут и без меня разберутся, а это сейчас не в приоритете. Я бы и рад по пути дочитать отчёт от саппорта, но алерт, сигнализирующий об инциденте, требует внимания: есть риск финансовых потерь. Дорога в офис проходит на звонке инцидента. Как не вовремя, мы и без этого опаздываем по срокам RT-2119 и RT-2120. На кофемашину нет времени, да и около неё сегодня аншлаг. Зацеплю энергетик из вендингового аппарата. Так, ежедневная встреча. Что у нас сегодня?

Про давление

Такая ситуация не возникает за один день. Это результат нарастающего и неснижаемого давления. Для начала разберёмся, из каких факторов оно складывается.

• Количество параллельных задач — большое количество контекстов вынуждает нас тратить ресурс на переключение контекстов. Каждое такое переключение требует когнитивных усилий.

• Количество незавершённых задач — хотя и звучит сходно с предыдущим пунктом, но это не одно и то же. 

• Сроки — один из самых очевидных источников давления. Жёсткие дедлайны повышают цену ошибки и сокращают время на принятие решений.

• Уровень неопределённости — начиная от способов решения задачи, заканчивая тем, что вообще является задачей. Неопределённость резко повышает когнитивную нагрузку из-за необходимости дополнительных решений и проверок.

• Количество решений и цена ошибки — каждое решение требует когнитивных усилий. В условиях ограниченного времени и высокой цены ошибки возрастает когнитивная стоимость принятия решений: необходимо действовать быстрее, но при этом точнее, что увеличивает риск поспешных и неверных решений.

Мы не всегда можем остановить внешнее давление. Но можем научиться понимать, из чего оно складывается, как оно влияет на наше состояние и на наш внутренний ресурс, который помогает нам с ним справляться, — на нашу энергию.

Про энергию

Чтобы сразу избавиться от эзотерического флёра в этом термине, давайте попытаемся дать ему определение.

Что обычно нами движет в работе над задачами, принятии решений и достижении целей? Из чего состоит ресурс, за счёт которого это вообще возможно?

• Когнитивная энергия — способность удерживать фокус, принимать решения, мыслить соразмерно задаче и сохранять перспективу мышления.

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

• Физическое состояние — состояние организма, уровень усталости и базовой физиологической устойчивости.

Таким образом, энергия — это многомерное понятие, описывающее наше ресурсное состояние: способность действовать и принимать решения в условиях оказываемого на нас давления.

Давление vs энергия: 4 уровня

Давайте вернёмся к герою нашего пролога и проследим за тем, как изменяется его состояние со временем.

Динамику давления и энергии схематично можно представить таким образом:

Самодиагностика

В любой момент важно понимать уровень и природу оказываемого на нас давления, а также объём доступного ресурса. Иначе попытки собраться, взять себя в руки, начать оптимизировать процессы превращаются в работу вслепую.

Перед тем как выбирать стратегии и инструменты, стоит зафиксировать своё текущее состояние.

Для этого попробуй ответить на следующие вопросы, ориентируясь на то, как проходили последние одна-две недели:

• Какой уровень давления (1–4) я испытываю в задачах, которыми занимаюсь?

• Какие задачи оказывают на меня наибольшее давление прямо сейчас?

• Что в этом давлении является ключевым фактором: сроки, неопределённость, количество контекстов, цена ошибки?

• Какой один следующий шаг может снизить влияние этого фактора давления?

• Какие задачи сейчас вызывают прокрастинацию?

• Какой фактор давления в этих задачах можно снизить, чтобы к ним вернуться?

• Что в текущих условиях может поддержать или восстановить мой уровень энергии?

Выбираемся из-под давления

Неделя 4, понедельник: снижаем давление и минимизируем ущерб

С чего начать? Мессенджер разрывается от сообщений. Календарь забит встречами. Каждая задача — срочная и важная. Только берусь за одну задачу, как она распадается ещё на три. Так мы далеко не уедем. Нужно остановиться. Не принять очередное решение, не ответить на сообщение, не закрыть по-быстрому пару задач. А остановиться и разобраться, что вообще происходит. Первая мысль: нужен план. Отлично, но с чего начать план? Сначала надо понять текущее состояние дел. Проведу самодиагностику.

Я начинаю раскладывать всё, что навалилось: инциденты, поддержка, бизнесовые и технические проекты. Инциденты — это потери прямо сейчас. Поддержка — не критично, но уже бьёт по пользователям. Бизнес-проекты — давление сроков и неопределённость. Технический проект редизайна системы — неопределённость и риски сделать хуже.

И тут становится очевидно: одновременно делать всё — значит не сделать ничего нормально. Нужно выбирать. Но выбирать на уровне собственного понимания правильного нельзя: цена ошибки слишком высокая. Значит, нужен другой подход.

Триаж

В условиях максимального давления и многозадачности обычного планирования и приоритизации недостаточно. Вместо этого необходимо проводить триаж — быструю приоритизацию задач с фокусом на минимизацию ущерба.

Триаж — термин в менеджменте, применяемый для процесса выбора задач для выполнения, в ситуациях, когда выполнить все задачи заведомо невозможно. В этом случае по принципу медицинской сортировки выбираются только самые важные задачи, у которых есть шанс быть завершёнными. 

Первый вопрос: где ущерб максимальный? Инциденты и часть поддержки — очевидный ответ. Если их не трогать, потери будут нарастать прямо сейчас. Проекты сложнее: мгновенного эффекта нет, но откладывание ведёт к будущим потерям — срыву сроков, необходимости догонять, росту сложности и компромиссам по качеству, из-за чего часть ценности может быть упущена.

Следующий вопрос: чем можно пожертвовать? Инцидентами — нельзя. Это прямые потери. Поддержкой — частично: проблемы есть, но есть обходные пути. Проектами — нужно разбирать по одному. Наши доработки по RT-2119 не на критическом пути. Можно сдвинуть. RT-2120 — цель проекта в соблюдении требований законодательства. Сдвиг — это штрафы. Наш технический проект по редизайну системы — долгострой без сиюминутного эффекта. Можно отложить.

Выбор становится очевидным:

• фокус на инцидентах;

• RT-2120 — оставить в работе;

• поддержка — по остаточному принципу;

• RT-2119 и редизайн системы — на холд.

Управление ожиданиями

Итак, решение принято, но его нужно донести до всех стейкхолдеров, иначе ничего не изменится. Поддержка продолжит репортить о проблемах, по проекту RT-2119 уже ждут апдейт по новому релизу, а в календарь летят встречи для его обсуждения. Если ничего не делать, то эффекта от триажа не будет.

Связываюсь с коллегами по каждому направлению: 

• С поддержкой — сообщаю, какие проблемы оставляем в работе, а какие откладываем.

• С заказчиком RT-2119 — явно обозначаю необходимость приостановки работ и причины.

• С заказчиком RT-2120 — подтверждаем приоритет и ожидания.

Важно не просто сообщить о принятых решениях. Важно проговорить контекст, трейдоффы и риски. Без этого их будут оспаривать или игнорировать. Когда у всех есть единое понимание ситуации, проще удерживать фокус на приоритетах, а коллеги по отложенным направлениям понимают, что делать дальше, пока наше участие в них на паузе.

После этого уже появляется ощущение контроля. Задач меньше не стало, но стало понятно, какие из них действительно важны.

Неделя 5, понедельник: бережём когнитивную энергию

И вроде план был надёжный, как швейцарские часы, но ощущение лёгкости и ясности довольно быстро прошло. Мы сфокусировались на инцидентах, их причины и последствия устранены. Но, согласно регламенту инцидент-менеджмента, мы должны проработать и закрыть action items в рамках post-mortem. У нас есть понимание, как и что нужно сделать, но постоянно переключаемся на другое важное направление — системный анализ по RT-2120. И то и другое от нас ожидают уже на следующей неделе. Как назло, по RT-2120 мы опять застряли на обсуждении API с коллегами из соседнего отдела. Задач всё ещё больше, чем исполнителей. Надо бы рабочей группой задержаться после встречи, обсудить план действий.

Контроль многозадачности и WIP-лимиты

Многозадачность — один из самых быстрых способов увеличить давление и ускорить расход когнитивной энергии. Чем больше активных контекстов мы держим одновременно, тем чаще вынуждены переключаться между ними и тем выше стоимость каждого такого переключения, что в итоге приводит к избыточным временным и ресурсным затратам. Плюс очевидно, что чем больше активных задач мы удерживаем одновременно, тем медленнее движемся по каждой из них.

Поэтому мы решаем ввести WIP-лимиты (work in progress) — ограничить количество одновременных задач для снижения числа активных контекстов. Особенно важно устанавливать лимиты на количество энергозатратных задач, таких как задачи с высоким уровнем неопределённости.

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

• В рамках инцидентов есть задачи с низкой неопределённостью (багфиксы, метрики и алерты) и высокой неопределённостью (нужна проработка надёжного технического решения).

• По RT-2120 ситуация похожая: большая часть функциональных требований уже проработана, но остались проблемы в системном анализе важного интеграционного взаимодействия с командой из соседнего отдела.

Нам надо распределить задачи между собой. Худшее, что можно поместить в список задач одного человека, — одновременно разрешать неопределённость по нескольким не связанным между собой направлениям. Поэтому мы делим задачи и их контексты, следуя логике модели Cynefin:

• на простые — разработка декомпозированных задач по RT-2120, багфиксы и мониторинг в рамках post-mortem инцидента 1;

• сложные — системный анализ по RT-2120;

• комплексные, запутанные — проработка технического решения и action items для инцидента 2;

• хаотичные — таких не нашлось, и на том спасибо.

Список задач понятен. Теперь расставляем приоритеты с фокусом на сокращении вредной многозадачности и снижении количества активных контекстов.

Все работы по RT-2120 довольно продолжительные по времени. А вот небольшие фиксы и мониторинг по инцидентам — задачи небольшие и понятные. Закончим их, и один из инцидентов можно будет вычеркнуть из списка незавершённых дел, а это минус один контекст. Пользуясь этим подходом, мы продолжаем планировать и приоритизировать: сначала простые быстрые задачи, которые снизят количество контекстов. Далее — задачи сложнее и более растянутые по времени. Сложные и комплексные задачи получают коллеги поопытнее, простые — коллеги помладше. Один из старших разработчиков недоволен таким решением: он декомпозировал важную фичу по RT-2120 и хотел сам её реализовать. Но мы убедили его, что его аналитические навыки помогут лучше справиться с неопределённостью, а значит, и начать работу над последней частью проекта получится быстрее.

Мы расположили задачи последовательно и понимаем, что сроки по части RT-2120 незначительно сдвинутся. Изначально сроки давались без учёта критичности влияния параллельных задач. Оценка стала пессимистичнее, но зато гораздо реалистичнее. Что ж, работу с ожиданиями никто не отменял. Сообщим стейкхолдерам, и за работу.

Неделя 6, понедельник: ищем подход к неопределённости

Задачи постепенно начинают покидать бэклог. Да, значительная часть из них — это простые задачи, но ведь часто наша работа и состоит в том, чтобы получить набор понятных и выполнимых задач из запутанного вороха симптомов, проблем и вопросов. Подход, выработанный нами на прошлой неделе, работает. Мы закончили с одним инцидентом, нашли техническое решение для закрытия другого инцидента и уже работаем над доработками. Скоро сможем вернуться к работе над проблемами поддержки. Но пока мы всё ещё упираемся в проработку API по RT-2120 — это последнее, что отделяет нас от того, чтобы подробно декомпозировать задачи для исполнителей. И именно здесь мы застряли. Почему?

Работа с неопределённостью

Вскоре мы поняли: проблема не в том, что у нас нет решения. Проблема в том, что мы не понимаем, какую задачу мы вообще решаем.

Неопределённость — крайне токсичный источник давления. Она кратно увеличивает когнитивную нагрузку и размывает границы задачи. Мы одновременно пытаемся ответить на вопросы «что делать?», «как делать?», «как понять, что сделали правильно?». Так как неопределённость сама по себе представляется нечётким пространством вопросов и вариантов решений, крайне важно начать придавать этому пространству правильную форму. В первую очередь понять, какую проблему мы хотим решить, и осознанно выбрать лучший вариант для решения выявленной проблемы.

Вместе с этим мы должны понять, на каком уровне детализации мы рассматриваем проблему прямо сейчас, как выглядят другие уровни и как между ними перемещаться. Формально это можно рассматривать через разные модели: C4 для архитектуры, трассировку требований, SLA/SLO/SLI для нефункциональных требований. Но в моменте важнее сам принцип: надо разложить задачу по уровням детализации, построив «карту местности».

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

Именно это и мешало нам договориться насчёт контрактов по RT-2120! Мы поняли, что достичь согласия нам мешает то, что и мы, и наши коллеги совсем по-разному представляем себе функциональность того API, который должен быть разработан.

Чтобы прийти к общему видению, мы начали строить нашу карту через трассировку требований:

• С заказчиком сформулировали бизнес-потребность: какую ценность должен получить бизнес.

• Уточнили бизнес-требования: как должен измениться бизнес-процесс, чтобы удовлетворить бизнес-потребность.

• Зафиксировали функциональные требования: как должны измениться системы для того, чтобы выполнить бизнес-требование.

Связывая требования между собой, задавая вопрос «какую проблему решаем?» на каждом уровне нашей «карты», мы подобрали удовлетворяющую всех структуру API.

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

И тут приходит ещё одна мысль: мы постоянно испытываем сложности с задачами с высоким уровнем неопределённости в основном потому, что не знаем, как действовать. Эдакая неопределённость в квадрате. Но если найти определённость в работе с самой неопределённостью, она перестаёт быть проблемой и становится обычным этапом задачи.

Неделя 7, понедельник: восстанавливаем перспективу мышления

Мы набрали неплохой темп. Теперь мы не просто закрываем задачи из бэклога, — команда фокусируется на том, чтобы сокращалось число контекстов. По крайней мере, число контекстов перестало расти. Впервые за долгое время появляется возможность выдохнуть, оглянуться назад и понять, что именно нас вытянуло:

• Триаж и управление ожиданиями убрали лишнее давление.

• Снижение многозадачности вернуло фокус.

• Подходы к работе с неопределённостью снизили временные потери.

Мы нащупали принципы, помогающие нам выбираться из-под высокого давления. Но достаточно ли этого?

Методы раннего обнаружения

Если в моменте давление не ощущается, не стоит пренебрегать вероятностью его внезапного появления. Мы же не хотим, чтобы нас застали врасплох? С опытом команда выявляет для себя типичные источники давления: внезапные срочные проекты, инциденты, рост обращений в поддержку. Ретроспективный анализ и рефлексия помогает их выявить, а значит, и подготовиться.

И тут становится заметна важная вещь. Мы понимаем, что часто «внезапные» проекты не такие уж внезапные. Поводы к их появлению становятся заметными в риторике руководителей и заказчиков, в озвученной стратегии компании. Если речь о техногенных факторах (инциденты, контактность, стабильность), негативную динамику можно выявить при помощи средств мониторинга.

Поэтому мы принимаем решение инвестировать в методы раннего обнаружения и реагирования:

• Регулярные встречи с заказчиками для выявления тенденций стратегического развития компании.

• Метрики по ключевым технологическим направлениям: количеству обращений в поддержку, метрикам «здоровья» сервисов.

• Процессы реагирования на наши типичные источники давления.

• Буфер устойчивости: заранее продуманные решения для потенциальных источников давления.

• Лучшие практики для снижения когнитивной нагрузки в будущем.

Принципы работы под давлением

1. Регулярная диагностика

Сначала зафиксируй текущее состояние: уровень давления и его основной источник — сроки, контексты, неопределённость. Без этого любые решения принимаются вслепую.

2. Снижение давления

При высоком давлении — триаж и минимизация ущерба. При растущем — ограничение многозадачности через WIP-лимиты и сокращение незавершённых задач.

3. Управление ожиданиями

Приоритеты, сроки и трейдоффы должны быть явно согласованы. Без этого давление возвращается, даже если решения верные.

4. Работа с неопределённостью

Если неясно, что делать, начни с определения задачи. Сначала сформулируй, какую проблему нужно решить, затем разложи её на цель, требования и реализацию. Неопределённость снимается структурой.

5. Фиксация контекста

Незафиксированные договорённости, решения и некачественные артефакты создают скрытое давление. Фиксация контекста позволяет не возвращаться к уже пройденным вопросам.

6. Раннее обнаружение

Возникающее давление часто предсказуемо. Сигналы видны в планах, коммуникациях и метриках. Важно научиться замечать их заранее.

7. Буфер устойчивости

Заранее готовь решения для потенциальных точек нестабильности. Даже если нет ресурса внедрять их сейчас, проработанный план позволит быстро среагировать при росте давления.

Эти принципы должны применяться не по отдельности, а в рамках единого процесса: сначала снижается давление, затем наводится порядок, после чего появляется возможность действовать на опережение.

Эпилог

Неделя 8, понедельник

Проснулся сегодня без будильника. На завтрак хочется приготовить что-то необычное. По дороге в офис пролистал мемы в любимом канале, прочитал вчерашние новости. Наш менеджер опубликовал новость о том, что бизнес открывает новое направление. Это точно затронет наш домен. Теперь это выглядит не как внезапная проблема, а как потенциальный источник будущего давления, к которому можно подготовиться. Значит, на доработки по редизайну нашей системы уже сейчас нужно выделить дополнительный фокус. Метрики по поддержке уже улучшаются. Важно не бросить работы на полпути: тренд может развернуться. Сначала закончим сложную доработку по проекту RT-2135, после этого можно подключать в редизайн дополнительный ресурс — времени ещё достаточно. Так, ежедневная встреча. План есть. Погнали.

Давление никуда не исчезнет. Новые проекты всё так же будут приходить не вовремя, инциденты будут случаться, а неопределённость будет прятаться за срочностью. Но теперь мы хотя бы понимаем главное. Когда под нагрузкой оказывается команда, бесполезно требовать от людей просто собраться. Сначала нужно снизить давление. И только потом можно снова ждать от системы под названием «команда» устойчивой работы.

Полезные материалы

• Модель Кеневин — как оценить тип ситуации и выбрать подход к принятию решений.

• WSJF (Weighted Shortest Job First) — модель приоритизации через ценность, срочность и размер работы.

• Gerald Weinberg, Quality Software Management — про системное мышление и стоимость переключения контекста. 

• Eliyahu Goldratt, «Цель», «Критическая цепь», «Правила управления потоком» — книги по теории ограничений систем.

• Daniel Kahneman, «Думай медленно, решай быстро» — про мышление, когнитивные искажения и принятие решений.