Оператор склада писал напрямую программисту. Директор по логистике ставил задачу руководителю разработки - разработчик откладывал то, над чем работал. Потом прилетала задача от CEO - и все бросали всё.
ИТ не работало медленно. Просто работало одновременно над всем.
На планёрках у CEO раз в неделю разбирали одно и то же: ИТ опять что-то не сделало. ИТ объясняло, что делало другое, потому что пришла другая задача. Кто ставил другую задачу, уже не имело значения. Значение имело другое: ситуация повторялась каждую неделю.
Я начал с простого: попробовал собрать объективную картину - что именно ИТ сделало за последний месяц и как это повлияло на бизнес. Не получилось. Задачи приходили из почты, мессенджеров, нескольких параллельных Excel-файлов. У разных людей были разные версии одного и того же списка. Формального приоритета не было ни у одной задачи - всё было одинаково срочным, потому что все заказчики считали своё важнейшим.
Был показательный эпизод. В форму заказа функционал добавляли, убирали, потом снова добавляли - несколько раз подряд. Одни пользователи просили включить, другие - убрать. Никто не был владельцем. Никто не мог принять финальное решение. Разработчики получали противоречивые задачи и выполняли их в зависимости от того, кто последним написал в чат.
Когда посчитали
Я попросил команду собрать данные: сколько задач реально завершено за месяц - не взято в работу, не начато, а завершено и передано пользователям.
Формально закрытых задач набиралось около 10 в месяц. Но если отфильтровать мелкие правки, возвраты, переделки и задачи без понятного бизнес-результата - в год оставалось 23-25, которые действительно что-то меняли для бизнеса.
Не потому что люди не работали. Они работали много - метались между задачами, переключались, возвращались, переделывали. Параллельная работа над всем одновременно давала именно такой результат: постоянное движение и минимальный реальный выход.
Тогда же сделали расчёт backlog. Взяли все задачи в очереди, сделали верхнеуровневую оценку трудозатрат по каждой, взяли текущую скорость команды и просто поделили одно на другое.
Получилось три года.
Три года при текущей скорости и текущем потоке задач. Это не план работ. Это расчёт, который показывает: компания накапливает запросы быстрее, чем способна их выполнять. И этот разрыв только растёт.
Ручные операции продолжали оплачиваться. Улучшения в продажах и логистике откладывались. Сотрудники тратили время на обходные действия, потому что система не менялась. Backlog в три года - это не длинная очередь задач. Это список проблем, которые бизнес уже оплачивает ручным трудом и задержанными изменениями.
Почему CEO не может быть диспетчером приоритетов
Пока у задач нет ни владельца, ни критерия приоритизации, единственный человек, чей голос что-то значит - это тот, кто громче всех кричит или кто выше всех стоит в иерархии. На практике это означает, что каждый новый запрос от CEO автоматически становится приоритетом номер один - вне зависимости от того, что команда делала в этот момент.
Это не проблема CEO. Это системная ошибка архитектуры управления задачами.
CEO хорошо видит стратегию. CEO плохо видит текущую загрузку команды, стадию каждой задачи, стоимость переключения и то, что именно придётся отложить ради его нового запроса. Когда у системы нет прозрачного реестра и правил входа - CEO вынужден принимать оперативные решения без полной информации. Это и есть ручное управление в худшем смысле слова: дорогое, непрозрачное, масштабирующее хаос вниз по организации.
Все считали, что ИТ делает медленно. Проблема была жёстче: компания сама не могла решить, что ей действительно нужно.
Что стали делать
Проблема была не в методологии. Проблема была в праве выбора: кто решает, что делать, в каком порядке и по какому критерию.
Я не стал начинать с Jira, Scrum или новой системы управления задачами. Инструмент бы только аккуратно оформил старый хаос.
Первый шаг - определили владельцев систем и данных. Для каждой системы - тот, с кем нужно согласовывать любые изменения. Не "кто использует", а "кто отвечает за то, как система работает". Это дало точку ответственности для каждого входящего запроса.
Второй шаг - поставили фильтр на входе. В каждой функции выделили человека, который знает процессы этой функции, знает, что уже автоматизировано, и знает возможности используемого ПО. На старте это был один человек, совмещавший роль IT Business Partner и бизнес-аналитика. Его задача: когда к нему приходят с запросом - сначала разобраться, что именно нужно бизнесу, и найти лучший способ это закрыть. Только после этого - ставить задачу в разработку. И только тогда, когда без разработки закрыть нельзя.
Третий шаг - единый реестр и три волны фильтрации. Собрали всё из почты, мессенджеров, разрозненных файлов в один список. Дальше работали в три волны.
Первая: убрали около 60% задач вообще. Дубли, устаревшие запросы, задачи без актуального заказчика, запросы, смысл которых никто уже не помнил.
Вторая: ещё около 30% закрыли без разработки. Не через код - через настройку, изменение процесса или управленческое решение.
Два примера из этих 30%.
Люди просили сделать отчёт в 1С - "такой же, но с другим порядком колонок". Оказалось: в системе отчёты настраиваются под себя. Функция была, просто о ней не знали. Закрыто за 30 минут объяснением. Ноль разработки.
Люди просили доработать форму документа заказа - хотели видеть информацию об ожидаемых поставках. Оказалось: в системе есть другой режим той же формы, в котором эта информация отображается. Люди не знали о его существовании и ходили смотреть в другой раздел. Закрыто переключением. Ноль разработки.
После двух волн в разработку ушёл только оставшийся остаток - часть точечно отдали в аутсорс.
В итоге около 90% первоначального сырого потока не дошло до разработки: дубли, устаревшие запросы, задачи без владельца, то, что закрылось настройкой, обучением или изменением процесса.
Четвёртый шаг - оценка и подтверждение руководителями функций. По оставшимся задачам - верхнеуровневая оценка трудозатрат и ожидаемого результата. Каждый руководитель согласовывал свой список. Показательная деталь: при согласовании многие сами вычёркивали задачи - смотрели на оценку и понимали, что смысл был не тот, который казался изначально.
Пятый шаг - правило входа для новых задач. Выработалось жёсткое правило: если в результате доработки у сотрудника будет экономиться менее четырёх рабочих часов - доработку не делаем.
Логика простая. Если экономия один час в неделю - сотрудник не станет делать больше, ему не станут меньше платить. Ресурс разработчиков потрачен, в P&L это не отразится. Значит, деньги на разработку потрачены впустую.
Четыре часа - не магическое число. Это порог, при котором изменение начинает давать измеримый результат в деньгах или скорости.
Capacity planning и первый недельный релиз
Когда список задач стал управляемым, следующий шаг был технически несложным, но психологически важным.
Исходили из правила: 50% рабочего времени разработчик тратит на создание нового - остальное уходит на исправление ошибок, технический долг, переключения. Восемь разработчиков, 20 доступных часов на новое в неделю каждый - это ёмкость, с которой нужно работать.
Из реестра выбрали задачи на это количество часов. Зафиксировали: вот эти задачи будут сделаны через неделю. Конкретный список. Конкретные сроки. Прозрачно для всех.
Все восприняли скептически. Привыкли к тому, что сроки - это разговор ни о чём.
Через неделю 85% задач из списка было сделано.
Это был фурор.
Не потому что 85% - это космический показатель сам по себе. А потому что раньше никто не мог предсказать вообще ничего. Теперь был план, и план выполнялся.
От недели к месяцу
Внутри команды начали анализировать точность планирования. После того как входящий поток перестал разрывать команду и переключения сократились, оказалось: на новое можно планировать не 50%, а ближе к 75% рабочего времени.
Горизонт планирования расширился до месяца. Точность месячного плана вышла выше 90%. Около 80% запросов стало закрываться в согласованный срок - примерно за 2 недели.
Сделали второй расчёт backlog - тем же методом: оставшиеся задачи после чистки, подтверждённая ёмкость команды.
Получилось три месяца.
Не три года. Три месяца.
Что изменилось в цифрах
До: 23-25 задач с реальным бизнес-результатом в год. Не "формально закрытых", а тех, которые что-то меняли для бизнеса.
После: порядка 500 задач в год - уже не сырого потока, а согласованных и доведённых до результата изменений. Рост примерно в 22 раза без расширения штатной команды.
Backlog: с трёх лет до трёх месяцев.
Точность месячного плана: выше 90%.
Около 90% первоначального сырого потока не дошло до разработки.
Команда не стала работать быстрее. Не появились новые разработчики. Не внедрялась новая методология. Изменилось одно: компания начала выбирать, что делать, и прекратила делать то, что не нужно.
Вывод для собственника
Backlog на три года - это не план. Это признание, что компания перестала выбирать.
Когда у каждого отдела есть прямой доступ к разработке, когда у задач нет владельца и нет критерия отбора - ИТ не может быть управляемым. Не потому что там плохие люди или слабая команда. А потому что ни один человек физически не справится с хаосом входящих запросов без системы фильтрации.
Если ИТ не может сказать, что будет сделано на следующей неделе и почему именно это - у вас нет управления разработкой. У вас есть занятость.
Вывод для CEO
Ручная приоритизация через CEO - это не контроль. Это дорогостоящая иллюзия контроля.
Каждый раз, когда CEO переставляет приоритеты напрямую, не видя полного реестра и реальной загрузки команды, он принимает решение без информации. Команда выполняет его. Что-то другое - откладывается. Это "что-то другое" потом появляется как следующая проблема на планёрке.
Система работает ровно тогда, когда CEO видит не отдельные задачи, а портфель с приоритетами, владельцами и предсказуемыми сроками. И когда у него есть механизм влиять на приоритеты, а не заменять собой диспетчера.
Очередь задач становится управлением только после жёсткого отбора по деньгам, владельцу и ресурсу.
Всё остальное - это список желаний без обязательств.