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