Зачем 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 нужен мандат от борда на остановку инициатив, не прошедших проверку.

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

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