В 1С-командах есть фраза, которая моментально ломает планы на день:
“Срочно посмотри”.
Или ее более официальная версия:
“Это задача с повышенным приоритетом”.
Проблема в том, что задач с повышенным приоритетом в бэклоге иногда уже несколько. И каждая, конечно, важная. Каждая нужна вчера. Каждая “мешает работать”. Каждая кому-то болит.
Но если всё срочное — значит, срочного нет.
Это не красивая фраза для плаката. Это рабочая проблема сопровождения 1С. Когда каждая задача объявляется срочной, команда перестает понимать, что действительно важно. Приоритет начинает определяться не влиянием на бизнес, а тем, кто громче написал, чаще напомнил или выше по должности.
А дальше начинается знакомая картина: разработчик бросает задачу, переключается на “пожар”, через полчаса выясняется, что пользователь просто ввел не тот пароль. Или документы “не выводятся”, потому что стоит неверный отбор. Или “система неправильно работает”, потому что пользователь забыл процесс.
Сама по себе такая ситуация не катастрофа. Пользователи ошибаются, забывают, путаются, нервничают. Это нормально.
Ненормально, когда каждая такая ситуация без проверки сразу попадает к разработчику как критичная.
Срочность без критериев — это не приоритет, а шум.
В этой статье разберем, как отличать реальные критичные задачи от громких запросов, какие критерии использовать для приоритизации и почему, если всё срочное, команда перестает делать важное.
Срочная задача и громкая задача — не одно и то же
В идеальном мире срочность определяется последствиями.
В реальном мире сопровождения она часто определяется громкостью.
Кто быстрее написал в чат. Кто позвонил. Кто добавил красный восклицательный знак. Кто написал “пользователь работать не может”. Кто пришел от руководителя. Кто сказал, что “это буквально на пять минут”.
И вот уже задача получает высокий приоритет, хотя настоящей диагностики еще не было.
Примеры из жизни:
- пользователь не может зайти в 1С — оказывается, вводит неверный пароль;
- не открывается документ — нужно проверить права, состояние документа или ссылку;
- 1С “не выводит документы” — у пользователя стоит неверный отбор;
- отчет “не считает” — выбран не тот период или организация;
- “ничего не работает” — не работает один конкретный сценарий у одного пользователя;
- “всё сломалось” — пользователь забыл, как должен работать процесс.
Это не значит, что такие обращения не нужно обрабатывать.
Нужно.
Но между “пользователь написал тревожное сообщение” и “разработчик бросил текущую задачу” должен быть фильтр.
Без такого фильтра команда очень быстро начинает жить в режиме постоянного реагирования. А режим постоянного реагирования почти всегда убивает плановую разработку.
Почему пользователи называют всё срочным
Пользователь не обязан мыслить категориями бэклога, SLA, критичности и стоимости переключения разработчика.
Он видит свою проблему.
У него не открывается документ. Не находится нужная строка. Не формируется отчет. Не получается провести операцию. Не сходятся цифры. Руководитель ждет результат. Срок горит.
Для него это действительно срочно.
И в этом есть важный момент: пользователь не всегда манипулирует. Часто он просто не видит всю картину.
Он не знает, что в очереди уже есть падение обмена, ошибка после релиза, проблема с зарплатным процессом, срочный отчет для руководства и задача, которая влияет на клиента.
Поэтому задача руководителя, аналитика или ответственного за поддержку — не ругаться на пользователя за слово “срочно”, а перевести его тревогу в понятные критерии.
Не спорить:
“Это не срочно”.
А уточнять:
- сколько пользователей затронуто;
- какой процесс остановлен;
- есть ли денежные последствия;
- влияет ли это на клиента;
- есть ли обходной путь;
- когда нужен результат;
- что будет, если решить завтра;
- кто подтверждает приоритет.
После таких вопросов часть “срочных” задач становится обычными. И это нормально.
Когда срочность ложная
Ложная срочность — это не выдуманная проблема. Это ситуация, когда тревога высокая, а реальное влияние на бизнес после проверки оказывается низким.
Например:
Пользователь не может зайти в 1С
Звучит критично.
Но после проверки выясняется, что база доступна, другие пользователи работают, сервер живой, а конкретный пользователь вводит не тот пароль или использует не ту учетную запись.
Это нужно решить, но это не критичный инцидент уровня “1С недоступна”.
1С не выводит документы
Звучит как ошибка данных или прав.
Но иногда причина проще: установлен неверный отбор, выбран не тот период, не та организация или пользователь смотрит не тот список.
В таком случае разработчик вообще может быть не нужен. Достаточно консультации, инструкции или проверки настроек формы.
Система “неправильно работает”
Частый сценарий: пользователь забыл процесс.
Он помнит, как должно быть “примерно”, но не помнит условий. Потом пишет в формате “срочно, важно, что-то не хватает, что-то не так работает”.
Команда подключается, тратит время, проверяет данные, а потом выясняется, что система работает корректно.
Такие ситуации особенно неприятны, потому что они съедают фокус. Формально задача была. По факту разработка не продвинулась.
Проблема не в том, что пользователь ошибся. Проблема в том, что ошибка пользователя без первичной проверки стала срочной задачей разработчика.
Что действительно можно считать критичным
Критичная задача — это не та, где кто-то громко написал “срочно”.
Критичная задача — это та, где есть значительное влияние на бизнес и потенциальный ущерб, в том числе денежный.
Я бы относил к критичным задачам такие ситуации:
- рабочая база недоступна для многих пользователей;
- массово не проводится ключевой документ;
- остановлен процесс продаж, закупок, оплаты, зарплаты, согласования или отгрузки;
- не проходит критичный обмен, от которого зависят данные или документы;
- ошибка после релиза мешает работе большого количества пользователей;
- есть риск финансового ущерба;
- есть риск нарушения сроков отчетности или обязательств перед клиентом;
- данные искажаются, дублируются или теряются;
- проблема затрагивает клиента или внешний контур взаимодействия;
- нет обходного пути, а процесс должен быть выполнен сейчас.
Вот здесь срочность оправдана.
Если не работает ключевой бизнес-процесс, нет времени на спокойное ожидание плановой очереди.
Но важно другое: именно такие задачи должны получать высокий приоритет. А не любые обращения, где написали красным и большими буквами.
Критерии приоритета: на что смотреть
Для 1С-команды приоритет лучше определять не одним словом “срочно”, а набором критериев.
Я бы начал с трех главных:
- деньги или влияние на деньги;
- влияние на клиента;
- массовость проблемы.
Этого уже достаточно, чтобы отделить реальный пожар от неудобства одного пользователя.
| Критерий | Вопрос | Почему важен |
|---|---|---|
| Деньги | Есть ли прямой или косвенный финансовый ущерб? | Ошибки, влияющие на деньги, должны подниматься выше обычных неудобств |
| Клиент | Видит ли проблему внешний клиент или заказчик? | Клиентские последствия обычно требуют более быстрой реакции |
| Массовость | Сколько пользователей или подразделений затронуто? | Массовая проблема важнее локальной |
| Остановка процесса | Можно ли продолжать работу? | Остановленный процесс требует отдельного внимания |
| Обходной путь | Можно ли временно решить без разработки? | Если обход есть, срочность может быть ниже |
| Срок | Есть ли реальный дедлайн? | Не каждый “сегодня” является настоящим сроком |
| Релиз | Проблема появилась после изменения? | Ошибки после релиза часто имеют повышенный риск |
| Данные | Есть ли риск потери, дублей или искажения данных? | Поврежденные данные потом дороже исправлять |
Если задача не проходит ни по одному серьезному критерию, возможно, она не срочная. Она может быть нужной, полезной и неприятной, но не критичной.
Матрица приоритетов без лишней бюрократии
Не обязательно строить сложную систему приоритизации на 20 уровней.
Для реальной 1С-команды часто достаточно четырех уровней.
| Приоритет | Когда использовать | Пример |
|---|---|---|
| Критичный | Остановлен важный бизнес-процесс, есть риск денег, клиентов или массового простоя | Рабочая база недоступна, массово не проводятся документы, не идет критичный обмен |
| Высокий | Проблема важная, влияет на группу пользователей или срок, но есть временный обход | Отчет нужен к сроку, есть ошибка в важном процессе, но работу можно продолжать вручную |
| Средний | Задача нужна для нормальной работы, но не останавливает процесс | Неудобство в форме, доработка отчета, уточнение печатной формы |
| Низкий / плановый | Улучшение, косметика, оптимизация, желание сделать удобнее | Переименовать поле, добавить необязательный отбор, улучшить расположение команды |
Главное — чтобы приоритет был не эмоциональной наклейкой, а управленческим решением.
Если задача получила критичный приоритет, должно быть понятно:
- какой процесс остановлен;
- кто подтвердил критичность;
- сколько пользователей затронуто;
- какие последствия будут при ожидании;
- какие задачи мы ради этого откладываем.
Последний пункт особенно важен.
Срочная задача не появляется в пустоте. Она вытесняет что-то другое.
Если мы говорим “сделать это срочно”, честный следующий вопрос:
“Что тогда не делаем сейчас?”
Почему “это на пять минут” почти никогда не на пять минут
Фраза “это на пять минут” сама по себе не вредная. Иногда задача действительно маленькая.
Но в 1С даже маленькая задача редко состоит только из пяти минут кода.
Нужно понять контекст, открыть базу, найти объект, проверить права, внести изменение, протестировать, понять влияние на другие сценарии, обновить расширение или внешнюю обработку, передать на проверку.
А главное — нужно переключиться.
Каждое переключение съедает больше времени, чем кажется на первый взгляд.
Разработчик не просто отвлекся на сообщение. Он вышел из контекста текущей задачи.
У него в голове был сценарий, код, гипотеза, данные, место ошибки, следующий шаг. После переключения всё это нужно восстановить.
Есть ощущение, что на возвращение в задачу может уходить условно 10–15 минут, а иногда и больше. Даже если само обращение заняло немного времени.
Теперь представим, что таких переключений за день несколько.
| Ситуация | Видимое время | Скрытая потеря |
|---|---|---|
| Ответить на “срочно посмотри” | 5 минут | Потеря фокуса и восстановление контекста |
| Проверить “не выводятся документы” | 15 минут | Оказалось, неверный отбор, но разработчик уже отвлекся |
| Разобрать “не могу зайти” | 10 минут | Причина — пароль, но текущая задача остановлена |
| Созвониться по “важной мелочи” | 20 минут | После созвона нужно снова погружаться в код |
На бумаге это мелочи.
В реальной работе это день, в котором вроде бы все заняты, но важная задача не продвинулась.
Что происходит с командой, когда всё срочно
Если команда живет в режиме постоянной срочности, последствия появляются быстро.
1. Срываются плановые задачи
Бэклог может быть нормальным, оценки адекватными, планы разумными. Но если каждый день прилетает несколько “срочно”, плановая работа начинает ехать.
Потом это выглядит так, будто команда плохо оценила задачи.
Хотя на самом деле она занималась другим.
2. Растет стресс
Каждое переключение повышает напряжение.
Особенно когда разработчик не понимает, насколько новая задача действительно важнее текущей.
Если приоритеты непрозрачны, человек ощущает не управление потоком, а хаос.
3. Падает качество
Когда разработчика постоянно дергают, он начинает делать быстрее, но не всегда лучше.
Меньше времени на проверку. Меньше времени на нормальный анализ. Меньше желания аккуратно разобраться в причине. Больше соблазна сделать “чтобы отстали”.
4. Растет техдолг
Срочные задачи почти всегда вытесняют несрочные, но важные.
Документация, рефакторинг, нормальные логи, оптимизация, разбор причин повторяющихся ошибок — всё это легко отложить.
Проблема в том, что отложенное потом возвращается новыми пожарами.
5. Команда перестает делать важное
Это главный эффект.
Если всё срочное, команда перестает делать важное.
Она начинает обслуживать поток тревоги.
А поток тревоги не всегда совпадает с бизнес-ценностью.
Какие задачи можно спокойно ставить в очередь
Не каждая задача от пользователя должна попадать наверх очереди.
Есть задачи, которые важны, но не требуют немедленного вмешательства разработчика.
Например:
- мелкие неудобства в форме;
- желание добавить новый отбор в отчет;
- косметические правки печатной формы;
- улучшение расположения кнопок;
- доработка, которая не блокирует процесс;
- вопрос, который решается инструкцией;
- ошибка одного пользователя без влияния на бизнес;
- запрос “сделать удобнее”, но без срока и ущерба;
- ситуация, где есть нормальный обходной путь.
Такие задачи не нужно игнорировать.
Их нужно фиксировать, уточнять, оценивать и ставить в очередь.
Пользователь должен видеть, что его запрос не потеряли. Но команда не должна каждый раз бросать всё ради любого неудобства.
Как ввести приоритеты без конфликта с пользователями
Приоритизация может восприниматься пользователями болезненно.
Особенно если раньше было так: написал напрямую разработчику — он посмотрел.
Поэтому важно не просто сказать “теперь всё через очередь”, а объяснить зачем.
Не так:
“Мы не будем смотреть ваши задачи без заявки”.
Лучше так:
“Чтобы не терять задачи и быстрее решать действительно критичные проблемы, мы фиксируем обращения и определяем приоритет по влиянию на бизнес”.
Пользователь должен понимать, что приоритеты нужны не для того, чтобы его оттолкнуть.
Они нужны, чтобы:
- критичные проблемы решались быстрее;
- заявки не терялись в личках;
- разработчики не переключались хаотично;
- было понятно, почему одна задача идет раньше другой;
- руководитель мог управлять очередью;
- команда не тратила день на ложные пожары.
Простой шаблон для оценки срочности
Для первичной классификации можно использовать короткий набор вопросов.
| Вопрос | Варианты ответа |
|---|---|
| Сколько пользователей затронуто? | Один / группа / подразделение / вся компания |
| Остановлен ли бизнес-процесс? | Нет / частично / полностью |
| Есть ли влияние на деньги? | Нет / косвенно / прямой риск ущерба |
| Видит ли проблему клиент? | Нет / возможно / да |
| Есть ли обходной путь? | Да / неудобный / нет |
| Есть ли жесткий срок? | Нет / внутренний / внешний или регламентный |
| Появилось после релиза? | Нет / неизвестно / да |
| Есть риск потери или искажения данных? | Нет / возможно / да |
Если по большинству ответов влияние низкое, задача не должна автоматически становиться критичной.
Если есть деньги, клиенты, массовость, остановка процесса или риск данных — приоритет нужно поднимать.
Что должен понять руководитель
Приоритет — это не эмоция.
Приоритет — это управленческое решение.
Если руководитель говорит “сделайте это срочно”, он одновременно говорит:
“Отложите ради этого что-то другое”.
Это нормально, если решение осознанное.
Но плохо, если приоритеты меняются каждые два часа из-за новых сообщений.
Команда не может одновременно:
- делать плановые доработки;
- закрывать техдолг;
- поддерживать пользователей;
- чинить инциденты;
- готовить релизы;
- отвечать на личные сообщения;
- разбирать все “срочно” без фильтра;
- и при этом не срывать сроки.
Где-то нужно выбирать.
И чем яснее этот выбор, тем спокойнее работает команда.
Мини-чек-лист для 1С-команды
Проверить зрелость приоритизации можно простыми вопросами.
| Вопрос | Да / нет |
|---|---|
| Есть ли понятные критерии критичной задачи? | |
| Отделяются ли инциденты от обычных доработок? | |
| Проверяются ли простые причины до передачи разработчику? | |
| Фиксируются ли задачи из личных сообщений в общей очереди? | |
| Понятно ли, кто подтверждает высокий приоритет? | |
| Видно ли, какие задачи откладываются ради срочных? | |
| Есть ли отдельная обработка мелких неудобств и улучшений? | |
| Разбираются ли повторяющиеся “срочные” обращения? | |
| Понимают ли пользователи, почему задача не всегда делается сразу? | |
| Есть ли у команды время на важные, но несрочные задачи? |
Если на большую часть вопросов ответ “нет”, значит срочностью управляет не процесс, а поток сообщений.
Как навести порядок за 30 дней
Не нужно сразу внедрять тяжелую систему приоритизации.
Можно начать проще.
Неделя 1. Собрать реальные “срочные” задачи
- Выписать задачи, которые за последние недели приходили как срочные.
- Отметить, какие из них действительно влияли на бизнес.
- Отдельно выделить ложные срочности: пароль, отбор, период, забытый процесс.
- Посмотреть, кто чаще всего инициирует срочные обращения.
Неделя 2. Ввести критерии
- Согласовать критерии: деньги, клиент, массовость, остановка процесса, обходной путь, сроки.
- Определить, какие задачи считаются критичными.
- Разделить инциденты, консультации, доработки и улучшения.
- Договориться, кто подтверждает высокий приоритет.
Неделя 3. Настроить входящий поток
- Фиксировать срочные обращения в общей очереди.
- Проверять простые причины до передачи разработчику.
- Не принимать “срочно” без описания влияния.
- Показывать, что вытесняется из плана ради срочной задачи.
Неделя 4. Закрепить правила
- Обсудить с командой, стало ли меньше хаотичных переключений.
- Показать пользователям примеры критичных и некритичных задач.
- Добавить матрицу приоритетов в процесс поддержки.
- Разобрать повторяющиеся ложные срочности и закрыть их инструкциями или настройками.
Цель не в том, чтобы спорить с пользователями о каждом обращении.
Цель в том, чтобы команда не жила в режиме вечного “срочно посмотри”.
Главный вывод
В 1С-сопровождении всегда будут срочные задачи.
Будут падения, ошибки, релизы, обмены, отчеты, пользователи, руководители и процессы, которые нельзя останавливать.
Но если срочным становится всё, команда перестает понимать, что действительно важно.
Она начинает реагировать на громкость запроса, а не на влияние на бизнес.
И тогда страдает всё:
- плановая разработка;
- качество решений;
- фокус разработчиков;
- сроки задач;
- техдолг;
- отношения с пользователями;
- спокойствие команды.
Поэтому приоритеты нужны не для бюрократии.
Они нужны, чтобы критичные задачи действительно были критичными, а обычные задачи не притворялись пожарами.
Я бы оставил главный тезис таким:
Срочность без критериев — это не приоритет, а шум.
Если задача влияет на деньги, клиента, массовый процесс или может привести к ущербу — поднимаем приоритет и разбираем быстро.
Если пользователь забыл процесс, поставил неверный отбор или хочет мелкое удобство — помогаем, фиксируем, объясняем, но не ломаем ради этого весь план разработки.
Потому что когда всё срочно, команда перестает делать важное.