260 оплаченных часов разработки ушли на отчеты, которые по сути показывали одно и то же.

Не на новый продукт. Не на изменение процесса. Не на задачу, которая дала бизнес-эффект.

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

Это был не маленький внутренний порядок в ИТ. Речь про крупную FMCG retail сеть: 600+ магазинов и более 70 млрд руб. оборота.

Именно на таком масштабе особенно хорошо видно, зачем компании нужен сильный бизнес-аналитик. Не для того, чтобы ускорять программистов. А для того, чтобы не пускать в разработку то, что вообще не должно становиться кодом.

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

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

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

Бизнес часто просит код там, где ему нужен порядок. Отчет с другим порядком колонок. Форму с нужными полями. Кнопку, которая уже есть в системе. Автоматизацию процесса, который сначала надо перестать ломать руками.

Снаружи это выглядит как поток задач.

На деле часто это очередь дорогих недоразумений.

Отчет, который закрыли за 30 минут

Один запрос выглядел нормально: нужен отчет в 1С. Такой же, как существующий, только с другим порядком колонок.

Для бизнеса это была простая доработка. Для разработки - еще одна задача в очереди. Для руководителя - мелочь, которую почему-то долго не делают.

Разобрали.

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

Задачу закрыли за 30 минут объяснением. Без разработки, релиза, тестирования и нового кода, который потом нужно поддерживать.

Вторая история была похожей.

Люди просили доработать форму документа заказа, чтобы видеть информацию об ожидаемых поставках. Звучало как нормальная доработка, пока не посмотрели внимательнее.

В системе уже был другой режим той же формы. Там эта информация отображалась.

Снова без разработки.

Вот здесь и проявляется настоящая работа бизнес-аналитика. Не принять хотелку, красиво оформить требования и передать дальше. А остановить задачу до разработки, если разработка не нужна.

Как мелочь превращается в оплаченные месяцы

Потом мы отдельно навели порядок в отчетах.

Нашли 14 отчетов, которые по сути показывали одно и то же. Отличались фильтры, порядок колонок, расположение полей и внешний вид таблицы.

Для пользователя это были разные отчеты. Для компании - один и тот же смысл, размноженный в 14 вариантах.

Эти отчеты создали примерно за 6 месяцев разные разработчики.

Если считать по 20 часов на один отчет, то 13 лишних вариантов - это 260 оплаченных часов разработки.

Почти два месяца работы одного разработчика ушли не на новый продукт, не на изменение процесса и не на задачу с бизнес-эффектом.

Они ушли на размножение одного и того же отчета в разных формах.

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

"Это новая бизнес-задача или еще одна форма того, что уже есть?"

Почему я перестал принимать формулу "бизнес попросил - ИТ должно сделать"

В старой логике запрос от бизнеса почти автоматически становился задачей для ИТ.

Кто-то попросил отчет - делаем отчет. Кто-то попросил поле - добавляем поле. Кто-то попросил новую форму - ставим в очередь.

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

Пользователь не знает функцию системы - пишем доработку.

Руководитель не хочет менять процесс - пишем доработку.

Два подразделения не договорились о правилах - пишем доработку.

У задачи нет владельца результата - все равно пишем доработку, потому что "срочно".

Так разработка превращается в дорогой сервис по упаковке организационного хаоса в код.

Команда занята. Backlog растет. Бизнес недоволен сроками. Все выглядят перегруженными, но причина глубже: в разработку попадает слишком много сырого входа.

Фильтр перед кодом

Я не начал с Jira, Scrum или новой доски. Инструмент только аккуратно оформил бы старый хаос.

Сначала нужен был фильтр.

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

Фильтр держался на четырех вопросах.

Первый - это дубль или устаревший запрос?

Если да - закрыть.

Второй - это можно решить настройкой, обучением или изменением процесса?

Если да - закрыть без разработки.

Третий - у задачи есть владелец и оценка эффекта?

Если нет - вернуть инициатору.

Четвертый - есть измеримый смысл делать именно разработку?

Если нет - отклонить или вернуть на доработку постановки.

Раньше можно было принести задачу и сказать: "Нужно сделать". Теперь приходилось отвечать, зачем это нужно, кто владелец результата, что изменится после внедрения, сколько ресурсов это съест и почему без разработки не обойтись.

Для зрелой системы это нормальный разговор.

Для компании, где срочность долго заменяла аргументацию, это сначала выглядит как сопротивление. Но это не сопротивление. Это управление ресурсом.

С 50-80 задач в неделю до 15-25

До фильтрации в поток входило примерно 50-80 задач в неделю.

Это не значит, что все они были задачами разработки. Просто компания называла их задачами.

Когда мы собрали запросы из почты, мессенджеров и Excel-файлов в один список, стало видно, насколько грязным был вход.

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

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

После запуска механизма поток снизился до 15-25 задач в неделю.

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

Только около 10% исходного потока проходило дальше в разработку.

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

Если задача не прошла проверку на владельца, эффект и способ решения, это не задача разработки.

Это шум в дорогой очереди.

Фильтр не должен быть машиной отказов

Хороший фильтр не режет все подряд. Он отделяет слабую хотелку от настоящей бизнес-задачи.

Был пример, который фильтр прошел.

Расчет заявок на 3PL-склады для отгрузки товара в магазины.

Данные по сети поступали до 2 ночи. Расчет шел батчем по всей сети и завершался к 8 утра. Лаг - 6 часов.

На практике это означало простую вещь: товар, который нужен был сегодня, физически приезжал завтра.

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

Нужен был другой алгоритм.

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

Не ждали остальные магазины.

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

Вот для таких задач разработка и нужна.

Не для бесконечного дорисовывания кнопок вокруг слабого процесса.

Правило 4 часов

Отдельно мы ввели правило: если доработка экономит одному сотруднику меньше 4 рабочих часов в неделю, она не проходит в разработку.

Четыре часа - не магическое число. Это управленческий порог.

Если человек экономит 15 минут в день, в P&L это почти никогда не видно. Ему не станут меньше платить. Он не начнет делать существенно больше. А разработчик уже потратил время. Тестировщик проверил. Поддержка получила еще одну особенность системы. Бизнес получил еще один элемент, который нужно объяснять новым сотрудникам.

Деньги ушли. Управляемость не выросла.

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

Смысл был не в числе 4. Смысл был в том, чтобы прекратить финансировать разработкой иллюзию улучшения.

Почему бизнес-аналитик должен уметь говорить "нет"

Слабый бизнес-аналитик превращается в секретаря при разработке.

Он принимает запрос, уточняет поля, пишет требования, согласует формулировки и передает дальше. Формально работа сделана. По факту он просто помог слабой задаче быстрее попасть в дорогую очередь.

Сильный бизнес-аналитик работает иначе.

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

Именно здесь появляется конфликт.

Часть руководителей не хочет отвечать на эти вопросы. Им удобнее жить в логике: "Я попросил - ИТ должно сделать".

Для собственника такая модель опасна. В ней ресурс разработки распределяется не по экономике, а по громкости запроса и положению инициатора в иерархии.

Кто громче пришел - тот получил внимание. Кто выше должностью - тот получил приоритет. Кто лучше объяснил срочность - тот обошел очередь.

Это не управление. Это ручная диспетчеризация чужих ожиданий.

Цена фильтра

Фильтр на входе не внедряется мягко.

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

В их глазах бизнес-аналитик начинает "мешать". Раньше задача звучала просто: "Нужно сделать". Теперь она возвращается с вопросами: кто владелец, какой эффект, почему нужен код, что будет приемкой и что изменится в процессе после внедрения.

Это раздражает, потому что вместо статуса и срочности появляется ответственность.

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

Но фильтра не будет.

Третий риск - обход правил сверху. Если CEO или сильный руководитель в любой момент может поставить задачу напрямую, вся модель начинает разрушаться. Не потому что задача сверху всегда плохая. А потому что одно исключение быстро становится сигналом: правила необязательны.

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

Сначала смысл. Потом владелец. Потом оценка. Потом решение, нужен ли код.

Что изменилось в разговоре с бизнесом

Раньше вопрос звучал так:

"Когда вы сделаете?"

После фильтра вопрос стал другим:

"Что именно должно измениться в бизнесе?"

Это меняет всю конструкцию.

Разработка перестает быть местом, куда складывают чужие желания. ИТ перестает быть функцией, которая молча принимает поток и потом оправдывается за сроки.

Появляется взрослая сделка.

Бизнес формулирует эффект. Бизнес-аналитик проверяет задачу на смысл. ИТ оценивает реализуемость и стоимость. Владелец процесса принимает результат.

Если задача не выдерживает эту проверку, она не попадает в разработку.

И это не саботаж. Это защита денег, времени и внимания команды.

Для CEO вывод простой

Если в компании все задачи автоматически становятся задачами разработки, значит, бизнес не управляет входом.

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

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

Самый дорогой backlog - не тот, где много задач. Самый дорогой backlog - тот, где никто уже не отличает бизнес-задачу от шума.

Собственник платит не за занятость разработки. Он платит за изменения, которые дошли до результата.

Сильный бизнес-аналитик не ускоряет разработку. Он делает более важную работу: убирает лишнюю разработку до того, как она съела деньги, время и внимание команды.

Самый дешевый код - тот, который не написали, потому что вовремя разобрали проблему.