Оператор склада писал напрямую программисту. Директор по логистике ставил задачу руководителю разработки - разработчик откладывал то, над чем работал. Прилетала задача от CEO - все бросали всё.
ИТ не работало медленно. Просто работало одновременно над всем.
Когда я попробовал собрать картину - что ИТ сделало за последний месяц и как это повлияло на бизнес - не получилось. Задачи приходили из почты, мессенджеров, нескольких параллельных Excel-файлов. У разных людей были разные версии одного и того же списка. Формального приоритета не было ни у одной задачи: всё было одинаково срочным, потому что каждый заказчик считал своё важнейшим.
Сначала посчитали
Попросил команду собрать данные: сколько задач завершено за месяц - не взято в работу, не начато, а завершено и передано пользователям.
Формально закрытых набиралось около 10 в месяц. Если отфильтровать мелкие правки, возвраты, переделки и задачи без понятного бизнес-результата - в год оставалось 23-25, которые что-то реально меняли для бизнеса.
Люди работали много. Метались между задачами, переключались, возвращались, переделывали. Параллельная работа над всем давала именно такой результат: постоянное движение, минимальный реальный выход.
Дальше посчитали backlog. Методика была простой, но требовала дисциплины.
Каждую задачу оценивали в часах в три этапа: сначала аналитик, потом разработчик, потом архитектор. Если оценки расходились - не усредняли и не брали максимум. Разбирались до консенсуса: что именно будет делаться, почему одна оценка отличается от другой. Расхождение в оценке почти всегда означало расхождение в понимании задачи.
Текущую скорость команды считали не по ощущениям, а по факту закрытых задач в еженедельных релизах. У каждой задачи была оценка в часах. После релиза считали, сколько оценочных часов реально дошло до пользователей - это и была фактическая ёмкость. Отдельно смотрели точность плана: какой процент обещанного вышел в срок. Первое нужно для расчёта backlog, второе - для оценки предсказуемости команды.
Взяли суммарные трудозатраты по всем задачам в очереди, поделили на фактическую недельную ёмкость.
Получилось три года.
Три года при текущей скорости и текущем потоке. Компания накапливала запросы быстрее, чем способна их выполнять. Разрыв только рос. Ручные операции продолжали оплачиваться. Улучшения в продажах и логистике откладывались. Backlog в три года - это не длинная очередь. Это список проблем, которые бизнес уже оплачивает ручным трудом.
Почему CEO не может быть диспетчером
Пока у задач нет владельца и критерия приоритизации, единственный человек, чей голос что-то значит - тот, кто выше всех в иерархии. На практике каждый запрос от CEO автоматически становится приоритетом номер один, вне зависимости от того, что команда делала в этот момент.
CEO хорошо видит стратегию. CEO плохо видит текущую загрузку команды, стадию каждой задачи и стоимость переключения. Когда у системы нет реестра и правил входа - CEO принимает оперативные решения без полной информации. Каждое такое решение масштабирует хаос вниз по организации.
Все думали, что ИТ делает медленно. Проблема была жёстче: компания сама не могла решить, что ей нужно.
Пять шагов
Я не начал с Jira, Scrum или новой системы управления задачами. Инструмент только аккуратно оформил бы старый хаос.
Шаг 1: владельцы систем
Для каждой системы определили одного человека: не "кто использует", а "кто отвечает за то, как система работает". Это дало точку ответственности для каждого входящего запроса.
Шаг 2: фильтр на входе
В каждой функции выделили IT Business Partner. Его задача: когда приходит запрос, сначала разобраться, что именно нужно бизнесу, и найти лучший способ закрыть. В разработку задача идёт только тогда, когда без кода закрыть нельзя. На старте это был один человек, совмещавший роль BP и бизнес-аналитика.
Логика фильтра:
Шаг 3: три волны фильтрации
Собрали всё из почты, мессенджеров, файлов в один список. Работали в три волны.
Волна 1: убрали около 60% задач. Дубли, устаревшие запросы, задачи без актуального заказчика, запросы, смысл которых никто уже не помнил.
Волна 2: ещё около 30% закрыли без разработки - через настройку, изменение процесса или управленческое решение. Два примера:
Люди просили сделать отчёт в 1С - "такой же, но с другим порядком колонок". В системе отчёты настраиваются под себя. Функция была, просто о ней не знали. Закрыто за 30 минут объяснением. Ноль разработки.
Люди просили доработать форму документа заказа - хотели видеть информацию об ожидаемых поставках. В системе есть другой режим той же формы, в котором эта информация отображается. Люди не знали о его существовании. Закрыто переключением режима. Ноль разработки.
Воронка в итоге выглядела так:
Сырой поток: 100%
Волна 1: -60% (дубли, устаревшее, нет владельца)
Волна 2: -30% (настройка / обучение / процесс)
В разработку: ~10% (часть — в аутсорс)
Для понимания - пример задачи, которая фильтр прошла.
Расчёт заявок на 3PL-склады для отгрузки товара в магазины. Данные по сети поступали до 2 ночи. Расчёт шёл батчем по всей сети и завершался к 8 утра. 3PL принимали заявки по отгрузке день в день до 6 часов. На практике это означало: товар, рассчитанный на сегодня, физически приезжал завтра. Ручными операциями лаг не закрывался.
Изменили алгоритм: вместо батч-расчёта по всей сети сделали волновой. Как только данные по конкретному магазину поступили - сразу считаем, собираем задачу для конкретного 3PL и отправляем заявку. Не ждём остальных.
Поставки пошли точно по расписанию. Задача прошла фильтр, потому что была понятная экономика, владелец в логистике и без изменения алгоритма не решалось.
Шаг 4: правило 4 часов
Правило входа для новых задач: если в результате доработки у сотрудника будет экономиться менее четырёх рабочих часов в день - доработку не делаем.
Логика: при экономии в один час в неделю сотрудник не станет делать больше, ему не станут меньше платить. Ресурс разработчиков потрачен. В P&L это почти никогда не видно. Деньги на разработку потрачены впустую.
Четыре часа - не магическая цифра. Это порог, при котором изменение начинает давать измеримый результат в деньгах или скорости. Ниже - разработка финансирует иллюзию улучшения.
Правило не абсолютное. Если экономия небольшая, но затрагивает 50 человек - суммарный эффект считается по всем, а не по одному. Задачи на выручку и SLA оцениваются через потенциальные потери, а не через экономию часов. Compliance и ИБ идут в отдельную очередь - там другая логика входа.
Шаг 5: capacity planning
Зафиксировали правило: 50% рабочего времени разработчик тратит на создание нового. Остальное - исправление ошибок, технический долг, переключения.
Формула ёмкости:
В нашем случае: 8 × 40 × 50% = 160 часов / неделя
Из реестра выбирали задачи ровно под эту ёмкость - это и есть ограничение WIP: в работе одновременно только то, что команда реально может закрыть за неделю. Фиксировали список: вот эти задачи будут сделаны через неделю. Конкретный список. Конкретные сроки. Прозрачно для всех.
Все восприняли скептически. Привыкли к тому, что сроки - разговор ни о чём.
Через неделю 85% задач из списка было сделано.
Не потому что 85% - космический показатель сам по себе. А потому что раньше никто не мог предсказать вообще ничего. Появился план, и план выполнялся.
Что стало дальше
После того как входящий поток перестал разрывать команду, оказалось: на новое можно планировать не 50%, а ближе к 75% рабочего времени. Переключений стало меньше. Команда не распылялась.
Горизонт планирования расширился до месяца. Точность месячного плана - выше 90%. Около 80% запросов стали закрываться за 2 недели.
Сделали второй расчёт backlog тем же методом: оставшиеся задачи после чистки, подтверждённая ёмкость команды.
Три месяца. Не три года.
До | После | |
Задачи с реальным результатом / год | ~25 | ~500 |
Backlog | 3 года | 3 месяца |
Точность плана | не фиксировалась | >90% |
В разработку | ~100% потока | ~10% потока |
Новые разработчики | - | 0 |
Эти две цифры нельзя читать как рост производительности разработки. 23-25 до - только задачи, закрытые через разработку с понятным бизнес-результатом. ~500 после - полный цикл: разработка, настройка систем, изменение процессов, обучение, аутсорс. Изменился контур учёта: раньше считали только код, теперь считали закрытый бизнес-запрос до результата - независимо от способа закрытия.
Команда не стала писать код быстрее. Не появились новые разработчики. Не внедрялась новая методология.
Изменилось другое: компания начала выбирать, что делать, и прекратила делать то, что не нужно. Throughput вырос за счёт отбора, ограничения WIP и снятия лишних переключений.
Где это ломается
Модель предполагает несколько условий. Без них результат будет другим.
Нет культуры отказа. Если руководители не готовы говорить "нет" на запросы сверху, BP-фильтр перегружается исключениями. Всё "срочное" попадает в обход правил.
Нет измеримых владельцев функций. Если у бизнес-процесса нет ответственного, нет и критерия для оценки запроса. BP не может принять решение без опоры на владельца.
Нет поддержки сверху. Правило "4 часа" и единый реестр работают, пока первое лицо не назначает приоритеты напрямую. Одно исключение от CEO - и модель начинает разрушаться.
Команда слишком мала для выделенного BP. При команде до 3-4 разработчиков роль BP может не окупаться как отдельная ставка. Тогда функции BP берёт тимлид или CTO - но с явными правилами, а не интуицией.
Очередь задач становится управлением только после жёсткого отбора по деньгам, владельцу и ресурсу. Всё остальное - список желаний без обязательств.
