Почему 1С-команды выгорают: стресс, срочность и хаос в сопровождении

Поводом для этой статьи стала книга Роберта Сапольски о стрессе.

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

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

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

В таких ситуациях стресс создает не одна большая проблема. Его создает постоянная неопределенность.

Что делать первым? Кто решил, что это срочно? Почему задача пришла в личку? Это ошибка или пользователь просто забыл процесс? Почему требование появилось только на демо? Кто владелец решения? Когда это должно попасть в релиз? И почему снова виновата 1С?

Мне кажется, 1С-команды часто выгорают не потому, что люди слабые. Они выгорают потому, что процесс плохо организован.

Код может быть сложным. Но хаос сложнее

В 1С есть достаточно сложных технических задач.

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

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

Можно открыть конфигуратор. Можно посмотреть журнал регистрации. Можно воспроизвести сценарий. Можно сравнить данные. Можно поставить точку останова. Можно прочитать запрос. Можно сделать тестовую копию. Можно попросить коллегу посмотреть вместе.

С кодом можно разговаривать через факты.

С хаосом вокруг задач так не получается.

Хаос — это когда у задачи нет нормального описания, но срок уже “сегодня”.

Хаос — это когда три человека считают свою задачу самой срочной.

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

Хаос — это когда требование согласовали, разработчик сделал, аналитик показал, а на демо появляется новая фраза:

“Это всё хорошо, но без вот этого и вот этого мы работать не сможем”.

И этого “вот этого” на этапе сбора требований не было.

Вот такие вещи выматывают сильнее сложного кода.

Сложный код можно разобрать. Хаотичный поток задач сначала нужно остановить, структурировать и только потом с ним работать.

Главная фраза стресса: “срочно посмотри”

Если бы нужно было выбрать одну фразу, которая лучше всего передает хаос сопровождения 1С, я бы выбрал:

“Срочно посмотри”.

Она короткая, но внутри нее обычно спрятано всё:

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

Плохой признак, если “срочно посмотри” становится нормальным способом постановки задач.

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

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

“Я весь день что-то тушил”.

И самое опасное — в таком режиме сложно почувствовать результат. Ты постоянно занят, но не всегда двигаешься вперед.

Когда “аларм” оказывается не алармом

В 1С-сопровождении часто бывают ситуации, когда проблема прилетает с максимальной тревожностью:

“Аларм! Всё сломалось. Система неправильно считает”.

Команда бросает текущие задачи. Разработчик подключается. Аналитик проверяет. Пользователь показывает пример. Начинается совместная перепроверка.

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

С технической точки зрения это не инцидент. С точки зрения команды — время уже потрачено, фокус потерян, нервная система получила очередной сигнал: “в любой момент может прилететь пожар”.

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

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

Здесь важно не скатиться в обвинение пользователей.

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

Если все задачи срочные — значит, срочных нет

Еще одна классическая болезнь сопровождения:

“У нас все задачи срочные”.

Иногда хочется ввести градацию:

• немного срочно;
• средне срочно;
• очень срочно;
• максимально срочно;
• срочно-срочно, прямо сейчас;
• срочно, но после другой срочной.

Звучит смешно, но в реальной работе это часто именно так и выглядит.

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

Это очень быстро ломает доверие внутри команды.

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

Для срочности нужен не эмоциональный ярлык, а критерии.

Я бы формулировал жестко:

Если задача не прошла через критерии срочности, это не срочная задача. Это тревожное сообщение.

Тревожные сообщения тоже нужно обрабатывать. Но не всегда ценой срыва текущей работы команды.

Неопределенность требований как отдельный источник стресса

В 1С много стресса появляется не на этапе написания кода, а на этапе требований.

Особенно когда задача вроде бы согласована, все заинтересованные стороны сказали “да”, разработчик сделал, команда подготовила демо, а потом начинается:

“Да, это хорошо. Но нам бы еще вот это”.

И дальше:

“Без этого мы работать не сможем”.

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

Для разработчика и аналитика это неприятно не только из-за дополнительной работы. Это создает ощущение беспомощности: ты вроде сделал то, о чем договорились, но договоренности оказались временными.

После нескольких таких ситуаций появляется внутреннее сопротивление:

“Я уже не хочу связываться с этой задачей, потому что знаю: что бы мы ни согласовали, на демо всплывет что-то еще”.

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

Что делать с требованиями, чтобы снизить стресс

Полностью убрать изменения требований невозможно.

Но можно снизить неопределенность.

Я не считаю, что нужно превращать каждую задачу в огромный документ требований. Это тоже крайность.

Но минимальная ясность должна быть.

Для 1С-задачи часто достаточно короткого набора:

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

Чем меньше ясности до разработки, тем больше стресса после нее.

Постоянное переключение выматывает незаметно

Еще один сильный источник усталости — постоянное переключение.

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

Но разработка требует погружения.

Когда ты разбираешь сложную задачу в 1С, в голове нужно держать много контекста:

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

И тут приходит сообщение:

“Срочно посмотри, пользователь работать не может”.

Ты переключаешься. Потом возвращаешься. И тратишь время не только на само сообщение, но и на восстановление контекста.

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

Плохой день разработчика — это не всегда день, когда было много сложной работы.

Иногда плохой день — это день, когда не дали нормально додумать ни одну задачу.

Как выглядит выгорание в 1С-команде

Выгорание не всегда начинается с громких слов.

Чаще оно выглядит спокойнее:

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

Особенно опасно состояние:

“Я знаю, что задача проблемная, и не хочу с ней связываться”.

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

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

Стрессор → процессное решение

Мне нравится смотреть на стресс в 1С-команде не как на абстрактную психологическую проблему, а как на набор конкретных стрессоров.

Если стрессор понятен, можно искать процессное решение.

Здесь важная мысль: не каждый стресс можно убрать мотивацией, отдыхом или разговором “держитесь”.

Иногда лучший способ снизить стресс — нормально организовать работу.

Больше ясности — меньше стресса.

 

Что делать руководителю 1С-команды

Если руководитель видит, что команда устает, худшее решение — просто сказать:

“Ну потерпите, сейчас сложный период”.

Иногда потерпеть действительно нужно. Бывают релизы, закрытия, аварии, срочные периоды.

Но если “сложный период” становится постоянным режимом, это уже не период. Это система работы.

Я бы начал не с мотивационных разговоров, а с наведения порядка в потоке.

1. Убрать разработчика из первого удара хаоса

Не каждое обращение должно сразу попадать разработчику.

Часть вопросов должна пройти через первую проверку:

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

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

2. Ввести понятные приоритеты

Если всё срочно, команда быстро перестает верить в приоритеты.

Нужны простые критерии:

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

Срочность должна подтверждаться не эмоцией, а влиянием.

3. Минимизировать переключения

Разработчику нужно время на погружение.

Хорошая практика — выделять фокусные интервалы, когда человека не дергают без реального инцидента.

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

4. Разделять поддержку и проектную работу

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

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

5. Не превращать демо в сбор новых требований

На демо можно и нужно получать обратную связь.

Но нужно разделять:

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

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

Мини-чек-лист: есть ли у команды стресс из-за хаоса

Проверить ситуацию можно простым чек-листом.

Если большинство ответов “да”, команда устает не только от объема работы.

Она устает от отсутствия управляемости.

План снижения хаоса за 30 дней

Не обязательно сразу строить сложный ITSM-процесс. Для начала можно сделать небольшой практический цикл.

Неделя 1. Собрать источники хаоса

• Посмотреть, откуда приходят задачи: личка, чат, почта, система заявок, устные просьбы.
• Отметить, какие обращения чаще всего называют срочными.
• Выписать повторяющиеся проблемы.
• Спросить команду, что больше всего выбивает из работы.
• Выделить 3–5 главных стрессоров.

Неделя 2. Ввести простые правила входа

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

Неделя 3. Настроить приоритеты и фокус

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

Неделя 4. Закрепить улучшения

• Описать короткие правила поддержки.
• Собрать первые повторяющиеся вопросы в базу знаний.
• Разобрать 1–2 частых инцидента по причине, а не только по симптомам.
• Проверить, стало ли меньше переключений.
• Обсудить с командой, что еще мешает работать спокойно.

Цель такого плана — не сделать идеальную команду за месяц.

Цель проще: снизить хаос хотя бы на один уровень.

Главный вывод

1С-команды редко выгорают от одного сложного запроса, одной тяжелой формы или одного неприятного релиза.

Чаще выматывает другое:

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

Код можно разобрать. Ошибку можно найти. Запрос можно оптимизировать.

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

Поэтому я бы не начинал разговор о стрессе в 1С-команде с фразы “людям нужно быть устойчивее”.

Я бы начал с другого:

Нужно сделать работу понятнее. Больше ясности — меньше стресса.

Понятный вход задач. Нормальные приоритеты. Минимальные критерии приемки. Защита фокуса разработчиков. Разделение поддержки и проектной работы. Правила для демо. Работа с повторяющимися проблемами.

Это не делает команду тепличной. Это делает ее работоспособной.

Стресс в 1С не всегда можно убрать. Но хаос точно можно уменьшить.

И иногда это лучшее, что руководитель может сделать для команды.