Почему утроение разработки не утраивает эффективность бизнеса

Представим, что компания проверяет 100 гипотез в квартал. Предположим, что 20 из них подтверждаются и заметно двигают бизнес‑метрики. После внедрения в процесс разработки AI‑агентов, стоимость ее реализации снижается, а цикл от намерения до работающей фичи сокращается. Допустим, теперь компания, с теми же ресурсами, может проверять уже не 100, а 300 гипотез в квартал.

На первый взгляд, бизнес должен радоваться, ведь производительность выросла втрое. Но Discovery, качество данных, экспериментальная инфраструктура и управленческое внимание не выросли втрое. Первые 100 гипотез могут сохранить прежнюю конверсию в 20%, а следующие двести — дать, например, по 5%. Получится 30 успешных гипотез вместо 20. Производственный output вырос втрое, а количество положительных результатов — только на 50%. Расчёт иллюстративный, но вопрос финансового директора по итогам года вполне реален:

«Мы утроили производительность. Почему бизнес‑результат не утроился?»

Ответ на него — не в разработке.

Сняв ограничение в Delivery, узкое место по Теории ограничений не исчезает, а переезжает. Организация обнаруживает следующие ограничения: достаточно ли у неё сильных гипотез, достоверных доказательств, качественных экспериментов, управленческого внимания и способности довести выпущенное изменение до принятия клиентом и роста бизнес‑результата? Именно с этой точки я предлагаю посмотреть на whitepaper Сбера AI‑Disrupt PDLC.

Если кто ещё не знаком с ним, настоятельно рекомендую ознакомиться, потому что далее я буду опираться на изложенную в нем архитектуру, структуру и терминологию: вот исходные документы, обновлённые в июне, — короткая версия  и длинная, за авторством Кирилла Меньшова, старшего вице‑президента и главы блока «Технологии» Сбера. На Хабре уже есть разбор для тех, кто пишет код, поэтому я не буду подробно пересказывать содержание документа, но затрону несколько ключевых для данной статьи идей.