Оператор склада писал напрямую программисту. Директор по логистике ставил задачу руководителю разработки. Разработчик откладывал текущую работу и переключался. Потом прилетал запрос от CEO — все бросали текущие задачи и переключались. Иногда в день по два раза.

Проблема была не в том, что ИТ работало медленно. Проблема была в том, что ИТ одновременно бралось за все, что к нему приходило.

Когда я попробовал собрать картину за месяц — что ИТ реально сделало и что дошло до бизнеса — нормальной картины не получилось. Задачи жили в почте, в мессенджерах и нескольких Excel‑файлах. У разных людей были разные версии одного и того же списка. Формального приоритета почти нигде не было. Каждая задача считалась срочной, потому что каждый заказчик считал свою задачу главной.

Сначала пришлось посчитать

Я попросил команду собрать. не общий список активности, а только завершенные задачи за месяц — что сделали и передали пользователям. Формально закрытых набиралось около 10 в месяц. Но когда убрали мелкие правки, возвраты, переделки и задачи без понятного бизнес‑результата, картина стала совсем неприятной. Анализ последнего года показал, что в год оставалось 23–25, которые что‑то реально меняли для бизнеса.

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

Дальше посчитали backlog. Хотелось было понять не только сколько команда закрывает, но и сколько работы ждет в очереди.

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

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

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

Получилось три года.

Три года при текущей скорости и текущем входящем потоке. Компания накапливала запросы быстрее, чем команда успевала их закрывать. Разрыв рос. Ручные операции оставались ручными. Улучшения в продажах и логистике откладывались. Backlog на три года в такой ситуации это не просто длинная очередь. Это список проблем, за которые бизнес уже платит каждый день.

Почему CEO не должен быть диспетчером задач

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

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

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

Что начали менять

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

Сначала назначили владельцев систем

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

Потом поставили фильтр на входе

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

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

На старте эту роль выполнял один человек. Он совмещал BP и бизнес‑аналитика.

Логика фильтра схематично выглядела так:

Далее разбрали очередь в три прохода

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

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

Вторым проходом еще около 30% закрыли без разработки: настройкой, изменением процесса или управленческим решением. Покажу на двух примерах.

Например, просили сделать отчет в 1С: такой же, но с другим порядком колонок. При разборе оказалось, что отчет уже можно настроить под себя. Функция в системе была, пользователи просто о ней не знали. Задачу закрыли за 30 минут объяснением. Разработка не понадобилась.

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

После двух проходов воронка выглядела так:

Сырой поток: 100%

Волна 1: -60% (дубли, устаревшее, нет владельца)

Волна 2: -30% (настройка / обучение / процесс)

В разработку: ~10% (часть — в аутсорс)

Для контраста — пример задачи, которая фильтр прошла.

Расчет заявок на 3PL‑склады для отгрузки товара в магазины. Данные по сети поступали до 2 ночи. Расчёт шёл батчем по всей сети и завершался к 8 утра. 3PL принимали заявки на отгрузку день в день до 6 часов утра. На практике это означало: товар, рассчитанный на сегодня, физически приезжал завтра. Ручными операциями этот лаг не закрывался.

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

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

Потом ввели правило 4 часов

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

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

При этом человек не начнет делать больше работы. ФОТ не меняется. Скорость процесса растет (иногда это еще и вредно). Значи смысла тратить на это время разработчика нет.

Если доработка экономила немного времени, но касалась 50 человек, эффект считали по всем участникам процесса. Задачи на выручку и SLA смотрели не через экономию часов, а через возможные потери. Compliance и ИБ шли отдельно — там другая логика приоритета.

И финал — capacity planning

Для планирования приняли осторожное правило: на новые задачи считаем только 50% рабочего времени разработчика. Остальное оставили на ошибки, технический долг, уточнения и неизбежные переключения. Первая реакция бизнеса была — «Как так? Это же мало.» Но мы сразу договорились начать с качества, а не со скорости.

Формула ёмкости:

В нашем случае: 8 × 40 × 50% = 160 часов в неделю.

Из реестра брали задачи ровно на эту емкость. Это и было ограничение WIP: в работе оставалось только то, что команда реально могла закрыть за неделю. Список фиксировали заранее: какие задачи берем, что должно быть готово через неделю и кто принимает результат.

Все восприняли скептически. Привыкли, что сроки — разговор ни о чём.

Через неделю 85% задач из согласованного списка были сделаны. Сделали то, что пообещали.

Что изменилось через несколько недель

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

Горизонт планирования расширили до месяца. Точность месячного плана стала выше 90%. Около 80% запросов стали закрываться за 2 недели.

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

Получилось три месяца вместо трех лет.

Эти две цифры нельзя читать как рост производительности разработки. 23–25 до изменений — это задачи, которые прошли через разработку и дали понятный бизнес‑результат. ~500 после — это уже весь поток закрытых бизнес‑запросов. Разработка, настройка систем, изменение процессов, обучение, аутсорс. Изменился сам контур учета. Раньше считали код. Теперь считали закрытый бизнес‑запрос до результата, независимо от способа закрытия.

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

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

Где это ломается

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

Нет права отказать. Если руководители не готовы говорить «нет» даже на запросы сверху, BP‑фильтр быстро превращается в формальность. Все срочное снова идет в обход правил.

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

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

Если в команде 3–4 разработчика, отдельная роль BP может не окупиться. Тогда эту функцию может взять тимлид или CTO. Но правила входа все равно должны быть явными, иначе все снова уедет в личные договоренности и интуицию.

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

Все остальное — список пожеланий, за который никто не отвечает.