Узкие места в процессах разработки Я сейчас готовлюсь к одному выступлению, и в рамках подготовки мне нужно было глазами и мозгами просмотреть множество кейсов и исследований, мировых и наших, публичных и из внутренней базы знаний. Там особенность в том, что мы фиксируем бейзлайны, меняем процессы, да много что можем изменить и отслеживаем ключевые метрики, тот же Cycle Time/Lead Time. И знаете что они все показывают? ВСЕ! В кейсах разработка в части написания кода ни разу не была узким местом. Чего там только не было – согласования ИБ, очереди на общие стенды тестирования, аналитика влияния на сторонние системы, подгтовка сред эксплуатацией, ручное регрессионное тестирование, очередь на ревью кода, зависимости от других команд, низкое качество (дефекты), но сама по себе скорость написания кода НИ РАЗУ не была ключевым ограничением. Тут нужно оговориться, что это все компании с сотнями систем, регуляторикой, требованиями ИБ и прочими прелестями. Однако это все не значит, что от того, что мы можем теперь писать больше кода быстрее нет выгоды. Появляется больше возможностей разработать внутренние инструменты, оптимизирующие процессы вокруг написания код, безусловно. Но смотрите, какой парадокс, – если эти разработки обкладывать той же обвязкой, то получается, что компания может даже замедлиться. Возвращаемся к тезису, что ИИ – усилитель существующей организационной системы и эффект зависит не только от инструмента, но и от процессов, платформ и способов работы.