Средний

6 мин

0

Оператор склада писал напрямую программисту. Директор по логистике ставил задачу руководителю разработки - разработчик откладывал то, над чем работал. Прилетала задача от 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 тем же методом: оставшиеся задачи после чистки, подтверждённая ёмкость команды.

Три месяца. Не три года.

Эти две цифры нельзя читать как рост производительности разработки. 23-25 до - только задачи, закрытые через разработку с понятным бизнес-результатом. ~500 после - полный цикл: разработка, настройка систем, изменение процессов, обучение, аутсорс. Изменился контур учёта: раньше считали только код, теперь считали закрытый бизнес-запрос до результата - независимо от способа закрытия.

Команда не стала писать код быстрее. Не появились новые разработчики. Не внедрялась новая методология.

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

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

Модель предполагает несколько условий. Без них результат будет другим.

Нет культуры отказа. Если руководители не готовы говорить "нет" на запросы сверху, BP-фильтр перегружается исключениями. Всё "срочное" попадает в обход правил.

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

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

Команда слишком мала для выделенного BP. При команде до 3-4 разработчиков роль BP может не окупаться как отдельная ставка. Тогда функции BP берёт тимлид или CTO - но с явными правилами, а не интуицией.

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