Зачем CIO останавливает работу до её начала

Самое дорогое, что может сделать ИТ - это качественно и в срок написать ненужную фичу.

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

Команда не ошиблась в исполнении. Проблема появилась раньше, когда никто не остановился и не спросил: а стоит ли это делать вообще?

Именно поэтому Discovery - это способ не забивать команду работой, которая не должна была попасть в разработку.

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

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

Почему этап проработки гипотез - это экономика

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

Проработка гипотез тоже стоит денег, но, как говорят, "это другое" - тут затраты управляемые и предсказуемые. Ошибка на этапе гипотезы стоит дни. Ошибка в разработке - месяцы работы "в стол", выброшенный бюджет и потерянная ёмкость команд, которую уже не вернуть.

Это не только мои ощущения. Pendo в 2019 году свела данные по 615 своим подпискам и получила, что около 80% функций в продукте используются крайне редко или не используются вовсе (2019 Feature Adoption Report). Это измерение по SaaS-продуктам, не по корпоративному ИТ. Но метрика "в стол" в моих мандатах показывала то же самое: значимая часть сделанного бизнесу не нужна, и пока её отдельно не считают, этого не видно.

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

Лучший функционал - тот, который решили не писать.

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

Песочница идей

До того как гипотеза попадает на проработку, она проходит через "песочницу". В зрелой компании это часть культурного кода: ни одна гипотеза не идет в поставку ценности без этого фильтра.

Здесь бизнес и продуктовые команды решают, что стоит проверять прямо сейчас. ИТ подключается для быстрой оценки реализуемости, зависимостей и "цены входа". Если не фильтровать поток на входе - разработка просто захлебнется в "хотелках", а реально важные вещи встанут в бесконечную очередь.

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

Что произойдет, если мы НЕ сделаем это в ближайшие три месяца?

Если ответ "ничего критичного" - гипотеза снимается с текущего "пробега". Это сохранение фокуса на том, что действительно горит: новая фича конкурента, требования регулятора или внезапный сбой в продажах из-за смены end-point у API партнера.

"Интересная гипотеза" и "гипотеза, достойная разработки в моменте" - разные вещи.

Как устроена приоритизация

Модель приоритизации - не пресловутая волшебная таблетка, которая сама принимает решения. Это инструмент, который делает невидимое видимым: зависимости, риски и реальную стоимость владения.

Если этого не сделать, ИТ превращается в "черный ящик", где конфликт бизнес-приоритетов маскируется под нехватку ресурсов. А CIO вместо стратега становится громоотводом для всех недовольных заказчиков сразу.

В любой непонятной ситуации виновато ИТ.

Я использую взвешенную модель (P&L, клиентский опыт, риски), но математика не заменяет управленческие решения. Она просто делает их прозрачными. Кто что обещает, за счет чего мы это делаем и кто в итоге отвечает за результат?

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

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

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

DoR и DoD: охрана границ

DoR (Definition of Ready) и DoD (Definition of Done) - гигиенический минимум и защита инвестиций.

DoR - контроль на входе. Не "когда мы закончим", а "имеем ли мы право начинать". Если бизнес-гипотеза не привязана к результату, не определен клиент и не назначен владелец - задача просто не заходит в разработку. DoR защищает команду от работы "в стол" еще до написания первой строчки кода.

DoD - контроль на выходе. Задача сделана тогда, когда соответствует критериям качества и готова приносить ценность. Код на проде - ещё не готовность. Это защита бизнеса от иллюзии завершенности.

Продуктовое кладбище

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

У меня был кейс: два дорогих продукта в разных стримах боролись за один и тот же канал клиентов. Чистый каннибализм в рамках одной компании. Бизнес побоялся принять решение о закрытии одного из них и принес оба ко мне - "подстелить соломку", поставив ИТ между двух огней. Отчётность по обоим при этом была зелёной.

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

Решение разбирали на уровне акционера, и лёгким этот разговор не был. В итоге продукты объединили, одну из команд расформировали. 40 млн рублей экономии в год.

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

На уровне CIO неспособность подсветить такие системные "тромбы" - это риск потери управления. Я не отвечаю за каждое решение внутри стрима (это зона ответственности CPO, PO и ИТ БП), моя задача - управлять аллокацией емкости всей системы. Вычищать такие вещи нужно через жесткую Enterprise-архитектуру и Арх-комитеты. Именно они следят, чтобы новые гипотезы вписывались в целевой ИТ-ландшафт, а старые - не высасывали жизнь из системы. "Зомби-проекты" - это налог на нерешительность, который вся компания платит скоростью своей разработки.

Как это работает на практике

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

Если борд всё равно наказывает за красный, система превращается в ложь. Проекты будут зелёными до самого дня краха.

Метрики для борда. Вместо количества запущенных проектов - три цифры:

Доля завершённых против запущенных.

Процент проектов, закрытых осознанно до того, как сожжён бюджет. Это качество Discovery.

Доля функциональности, которая реально используется через 90 дней после релиза. Это самая неудобная и самая честная метрика.

Основной вывод

Задача CIO - гарантировать, что через ИТ проходят только те задачи, которые реально двигают бизнес. Скорость появляется от умения команды вовремя остановиться. Для этого CIO нужен мандат от борда на остановку инициатив, не прошедших проверку.

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

О том, как компании системно теряют способность видеть правду, - в статье "Лес вырублен - цели выполнены - реальность потеряна".