Когда-то я был обычным разработчиком в одном небольшой компании, и поддержка пользователей была одной из моих постоянных болей.

Большинство обращений разбирала поддержка. Если самостоятельно решить проблему не получалось и требовалось понимание устройства системы, тикет приходил разработчикам.

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

На практике разработчики довольно быстро начали выполнять много операций:

  • вручную исправляли некорректные состояния данных;
  • выполняли операции, которых не хватало во внутренних инструментах;
  • разбирали инциденты и технические проблемы;
  • искали причины проблем по логам;
  • писали на скорую руку небольшие внутренние скрипты.

Иногда это действительно была разработческая задача. Но довольно часто разработчик просто становился очень дорогой админкой.

«Поправь клиенту данные СРОЧНО, он простаивает»

Типичный тикет мог выглядеть примерно так:

У клиента неправильное состояние аккаунта. Нужно поправить. Приоритет.

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

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

Особенно опасно, когда такие операции выполняются напрямую в production. Постепенно ручные операции становятся обычным способом решать проблемы. Но в отличие от нормального внутреннего инструмента здесь гораздо проще ошибиться.

Проверка корректности часто сводится к:

Я вроде всё перепроверил, должно быть нормально.

Поддержка постепенно съедает разработку

Главная проблема для меня была даже не в самих тикетах. Проблема была в количестве переключений. Ты занимаешься своей задачей, погрузился в код, держишь в голове контекст. Приходит тикет, нужно посмотреть. Далее изучаешь логи и состояние системы, читаешь чужой код и восстанавливаешь историю проблемы. После решения проблема возвращается в поддержку. Далее, если клиенту помогло, тикет к тебе не попадает обратно, но иногда это было как ping-pong: тикет ходит туда сюда между клиентом и поддержкой.

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

Особенно жарко становилось во время отпусков. Если поддержку хорошо знало лишь несколько человек и один из них уходил отдыхать, нагрузка на остальных резко возрастала.

Если одновременно происходил какой-нибудь инцидент, рабочий день очень быстро превращался в бесконечный поток:

тикет → разбор проблемы → решение → тикет → инцидент → снова разбор.

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

Такая работа очень быстро выматывает

От такой работы устаёшь не только потому, что задач становится больше. Сильнее выматывает постоянное напряжение. Когда ты работаешь с production вручную, практически каждое действие приходится перепроверять: тот ли клиент, правильно ли я понял состояние данных, не навредит ли изменение другим.

В обычной разработке ошибка чаще всего заканчивается упавшим тестом, неудачным code review или багом, который ещё можно поймать до production.

При ручной работе ошибка может сразу затронуть реального клиента. Иногда достаточно одного неправильного действия. Из-за этого даже простая операция начинает требовать повышенной концентрации.

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

Вместо:

Сейчас быстро поправлю данные.

в голове уже появляется:

А точно я ничего сейчас не сломаю?

Постоянно работать в таком режиме тяжело.

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

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

В какой-то момент это уже не просто «много работы». Это прямой путь к выгоранию.

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

Мой самый неприятный фейл

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

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

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

Дальше началась гораздо более интересная часть рабочего дня — восстановление, к счастью, данные удалось восстановить. Но я продолжал седеть на глазах…

Нужно было понять масштаб изменений, восстановить данные и проверить связанные сущности. С такой проблемой я столкнулся впервые…

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

Проблема была не только в моей ошибке. Сам процесс позволял одной человеческой ошибке превратить обычный тикет поддержки в полноценный инцидент.

«Будь внимательнее» — плохое решение

После подобных историй самое простое решение звучит так:

Нужно просто внимательнее работать с production.

Можно добавить еще правила, наподобие:

Перед потенциально опасным действием ещё раз проверь объект и последствия операции.

Всё это полезно, но человек все равно может ошибиться.

Особенно когда он:

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

Требовать от человека бесконечной внимательности бесполезно. Безопаснее должна становиться сама операция.

Что стоило сделать вместо ручного удаления

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

Например:

  1. сотрудник находит аккаунт;
  2. нажимает «Архивировать»;
  3. система показывает, что именно произойдёт;
  4. операция логируется;
  5. аккаунт сначала переводится в архив;
  6. существует возможность восстановления;
  7. окончательное удаление происходит позже.

Можно добавить подтверждение, права доступа, аудит и отложенное удаление.

Тогда ошибка:

Я удалил не того клиента.

превращается в:

Я случайно архивировал не того клиента и через минуту восстановил его обратно.

Это совершенно разные классы проблем.

Админка была. Но этого оказалось недостаточно

Важно уточнить: админка у нас была.

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

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

Через какое-то время количество ручной работы снова накапливалось, кто-то вспоминал:

А давайте всё-таки улучшим админку.

Мы снова что-то делали. Потом процесс опять останавливался и так по кругу.

На мой взгляд, в этом и была одна из ключевых ошибок.

Инструменты поддержки нельзя один раз сделать и считать задачу закрытой.

Продукт меняется → появляются новые фичи → меняются данные → возникают новые проблемы → поддержке приходится адаптироваться.

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

Поддержку нужно постоянно переосмысливать

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

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

Задача разработчиков — не только решить текущий тикет. Нужно ещё спросить:

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

У внутренних инструментов тоже должен быть ресурс

Есть ещё одна проблема, которую легко недооценить.

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

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

Админка уже есть. Зачем нам ещё один разработчик?

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

Здесь появляется отдельная управленческая задача.

Стоимость текущего процесса нужно показать бизнесу в цифрах и объяснить, почему внутренним инструментам тоже нужна разработка.

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

Важно не допустить ситуации, когда один человек одновременно:

  • отвечает за продуктовый функционал;
  • развивает админку;
  • разбирает обращения пользователей;
  • тушит инциденты;
  • помогает другим разработчикам;
  • и при этом ещё управляет командой.

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

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

Но это плохая долгосрочная стратегия.

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

Задача здесь не закрывать все дырки самостоятельно, а сделать проблему видимой:

  • сколько времени команда тратит на поддержку;
  • сколько продуктовой разработки из-за этого теряется;
  • какие операции повторяются;
  • сколько риска создаёт ручная работа;
  • насколько команда зависит от отдельных людей;
  • сколько людей реально требуется для нормальной работы процесса.

Разработчик должен разрабатывать

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

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

Причём возникает неприятный замкнутый круг.

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

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

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

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

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

Если каждую неделю разработчику приходится вручную выполнять рискованные операции с production, проблема уже точно не в отдельных тикетах.

Проблема в процессе, который сделал ручную и рискованную работу нормой.