Отчет сделали за неделю.
+2% к обороту не появились.
Это был кейс из крупной FMCG retail сети: больше 70 млрд руб. оборота и больше 600 магазинов. Название компании не раскрываю, но масштаб важен. На таком размере любое управленческое обещание быстро превращается в деньги, ресурс и приоритет.
Директор по рознице пришел с задачей: нужен отчет по продажам в заданной структуре. Срочно.
Аргумент был сильный. По его словам, отчет должен был дать +2% к обороту. До этого такую задачу не могли сделать два года.
Ситуация выглядела привычно: бизнес давно просит, ИТ долго не делает, руководитель функции не получает нужный инструмент, компания теряет деньги.
Я поставил задаче высший приоритет.
Через неделю отчет был готов. В нужной структуре, с нужными данными, в согласованном виде.
Через месяц CEO собрал нас и задал директору по рознице один вопрос:
"Где +2%?"
Ответа не было.
Отчет был. Результата не было
С точки зрения разработки задача была выполнена.
Запрос приняли. Требования уточнили. Отчет сделали. Пользователю передали.
Если смотреть только на delivery, все выглядело нормально. Но CEO смотрел не на факт релиза. Он смотрел на обещанный бизнес-эффект.
Задача получила высший приоритет не потому, что компании был нужен еще один отчет. Она получила высший приоритет потому, что под нее заявили рост оборота.
Именно поэтому вопрос CEO был не "где отчет?".
Вопрос был: "где +2%?"
И вот здесь вскрылась настоящая проблема.
Компания принимала задачи по силе обещания, а не по ответственности за эффект.
Сильное обещание еще не эффект
Фраза "+2% к обороту" звучит убедительно.
Тем более если ее говорит директор по рознице. Тем более если задача два года не решалась. Тем более если вокруг уже накоплена усталость от длинного backlog.
Но отчет сам по себе не увеличивает продажи.
Он может показать проблему, ускорить управленческое решение, дать правильный срез по магазинам, периодам, группам товаров или отклонениям.
Но дальше кто-то должен изменить действие: поменять заказ, пересобрать выкладку, изменить контроль, дать задачу супервайзерам, добиться реакции от магазинов, проверить показатель после изменений.
Если после отчета ничего не меняется в управлении, отчет остается отчетом.
Даже если он сделан быстро.
Даже если он удобный.
Даже если два года его ждали.
Где ломалась логика
До этого момента многие задачи проходили в разработку по силе формулировки.
"Даст рост продаж".
"Повысит контроль".
"Ускорит работу".
"Снизит потери".
"Наконец-то наведет порядок".
Каждая из этих фраз может быть правдой. А может быть хорошей упаковкой для задачи, у которой нет владельца эффекта, механики влияния и проверки результата.
Слабая задача не всегда выглядит слабой. Иногда она выглядит очень убедительно: ее приносит сильный руководитель, внутри есть реальная боль, а ИТ действительно долго не могло ее закрыть.
Но боль не равна эффекту.
Срочность не равна экономике.
Релиз не равен результату.
После вопроса CEO "где +2%?" это стало видно всем.
Что изменил CEO
После этой встречи CEO сказал: теперь каждый крупный запрос идет только с обещанным эффектом и последующей проверкой.
Он утвердил новую схему как обязательную.
По каждой значимой задаче стали фиксировать три вещи:
что заявляли;
сколько потратили;
какой эффект получили.
Не презентацию на 30 слайдов. Не длинный проектный отчет. Не красивую историю про цифровизацию.
Три строки.
Обещание.
Ресурс.
Факт.
Это не было наказанием руководителей. Схема просто делала обещания проверяемыми.
Пока задача звучит как "нам срочно нужно", спорить трудно. У каждой функции своя боль: у продаж - продажи, у логистики - поставки, у склада - отгрузки, у розницы - магазины.
Но когда рядом с задачей появляется строка "заявленный эффект", а потом строка "фактический эффект", разговор меняется.
Руководитель функции уже не просто просит ресурс ИТ.
Он берет на себя обязательство показать, что этот ресурс был нужен.
CEO начал использовать эти отчеты в коммуникации с руководителями. Не в логике "ИТ опять не успело", а в другой логике:
вы заявили такой эффект;
на задачу потратили такой ресурс;
задача выполнена;
прошел срок проверки;
покажите факт.
После этого количество задач ради задач сократилось на порядок.
Не потому что бизнесу стало меньше нужно изменений. А потому что слабые запросы перестали проходить через нормальный разговор.
Если руководитель не готов назвать эффект, ресурс и способ проверки, задача сразу выглядит иначе. Уже не как стратегическая необходимость, а как желание получить внимание ИТ без обязательств за результат.
После этого схема вошла в регулярный контур управления backlog и приоритизацией. Не как разовая реакция на один неудачный отчет, а как правило работы с потоком задач.
Задача не закрывается релизом
В старой логике задача закрывалась, когда ИТ сделало.
В новой логике этого стало недостаточно.
Бизнес должен был принять результат. Это не формальность.
Приемка бизнесом означает, что владелец функции подтверждает:
да, это то, что нужно;
да, это можно использовать;
да, теперь я могу проверить эффект;
да, дальше ответственность за показатель находится в моем контуре.
Разработка отвечает за реализацию.
BA отвечает за качество входа: смысл задачи, владельца, эффект, критерий приемки.
Бизнес отвечает за результат в своем процессе.
Если это не разделить, ИТ быстро становится крайним за любую несбывшуюся надежду бизнеса.
Отчет не дал +2% - виновато ИТ.
Функция не поменяла процесс - виновата автоматизация.
Руководитель не использовал инструмент - виновата система.
Новая схема разрезала эту путаницу.
ИТ показывало, что сделано и сколько стоило.
Бизнес показывал, что изменилось после внедрения.
Что такое ценность задач +400%
Когда я говорю, что ценность задач выросла примерно на 400%, речь не про бухгалтерский ROI по каждой доработке.
Мы считали иначе.
Смысл был в доле полезных задач в потоке.
До изменений в работу попадало слишком много запросов без подтвержденной ценности: дубли, устаревшие задачи, срочные желания без владельца, задачи без приемки, задачи, которые можно было закрыть настройкой, обучением или изменением процесса.
Формально это был backlog. По сути - плохо разобранный поток ожиданий.
После фильтра в работу проходили в основном задачи, у которых были обязательные признаки: владелец эффекта, заявленный бизнес-результат, оценка затрат, критерий приемки, понимание, почему без разработки не обойтись, и проверка план / факт после выполнения.
За счет этого выросла не скорость написания кода.
Выросла полезность потока.
Если раньше значительная часть ресурса уходила на неподтвержденные обещания, то после фильтра в работу попадали задачи, за которые бизнес был готов отвечать.
Доля полезного потока выросла примерно в 4 раза.
Вот что я называю "ценность задач +400%".
Не каждая задача стала приносить в четыре раза больше денег. Компания просто перестала оплачивать разработкой плохо сформулированные желания.
Это не отменяет ROI
Там, где эффект можно посчитать в деньгах, его надо считать в деньгах.
Но не каждую задачу можно честно разложить в точный ROI до старта.
Задачи по SLA, рискам, качеству данных, compliance, управленческому контролю или снижению операционных ошибок часто считаются иначе.
Но это не повод пускать их в работу без проверки.
Если нет точного ROI, должен быть другой жесткий контур:
какой показатель должен измениться;
кто владелец этого показателя;
какой ресурс нужен;
что будет приемкой;
когда проверим план / факт;
что делаем, если эффекта нет.
Без этого задача не готова к разработке.
Она может быть важной, срочной, политически чувствительной. Может идти от сильного руководителя.
Но не готовой.
Почему это работает только при поддержке сверху
Такую схему нельзя удержать только силами BA или ИТ.
Если первое лицо не поддерживает правило, система быстро откатывается. Достаточно нескольких исключений:
"это задача от CEO";
"это просит директор";
"это срочно";
"давайте сейчас сделаем, потом разберемся".
И поток снова начинает управляться статусом и давлением, а не эффектом и ресурсом.
В нашем случае перелом произошел именно потому, что CEO использовал схему лично.
Вопрос "где +2%?" стал не разовой репликой.
Он стал новым правилом управления задачами.
Руководители поняли: теперь мало получить релиз. Нужно будет показать, что изменилось после него.
Что изменилось в поведении руководителей
Самое заметное изменение было не в таблице.
Изменился способ формулировать задачи.
Когда руководитель понимает, что через месяц его спросят не "получили ли вы отчет?", а "где эффект, который вы заявляли?", он начинает думать раньше.
До постановки задачи.
Часть запросов после этого исчезает. Часть уходит в настройку. Часть - в обучение. Часть - в изменение процесса. Часть становится нормальной задачей разработки, потому что там действительно есть эффект, владелец и механизм влияния.
Так поток становится чище.
Не потому что люди стали осторожнее просить.
А потому что запрос без ответственности стал хуже проходить через систему.
Для собственника вывод простой
Собственник платит не за релизы.
Он платит за изменения, которые дошли до результата.
Список выполненных задач не отвечает на главный вопрос: что изменилось в бизнесе?
Нужен другой контур:
что бизнес заявил;
какой ресурс компания потратила;
что было сделано;
кто принял результат;
какой эффект получили;
кто отвечает за расхождение между обещанием и фактом.
Тогда разработка перестает быть черным ящиком. И бизнес-заказчик тоже перестает быть неприкасаемым источником срочных задач.
У каждого появляется своя зона ответственности.
ИТ отвечает за реализацию.
BA - за качество входа и проверку смысла.
Бизнес - за эффект.
CEO - за правила, которые не дают системе снова скатиться в ручное давление.
Финал
Релиз - это техническое событие.
Он показывает, что задача дошла до поставки.
Бизнес-задача заканчивается позже: когда владелец принял результат, когда проверили план / факт, когда стало понятно, изменился показатель или нет.
Если этого нет, разработка может быть успешной, а бизнес-задача - проваленной.
Релиз закрывает работу ИТ.
Бизнес-задачу закрывает только измеримый эффект.