Что ИИ ломает в продуктовой команде и почему старые роли больше не работают

Спикер: Андрей Южаков

Раньше работа двигалась по цепочке: аналитика → дизайн → разработка → тестирование. Каждый передавал дальше контекст в виде артефакта. С агентами всю цепочку может пройти один человек.

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

На примере банковского продукта мы проверили новую модель на большом сценарии в интернет-банке. С помощью агентов удалось самостоятельно подготовить требования, API, UX, архитектуру, бэкенд, фронтенд, gateway и тесты. Первая версия появилась примерно за неделю.

Но дальше начали ломаться привычные процессы.

Первая поломка: автор изменения больше не обязательно владелец результата.

Границы ролей размываются. Менеджер продуктов может написать код, разработчик — придумать и реализовать фичу, дизайнер — самостоятельно внести изменение в продукт. Но возможность что-то сделать ≠ ответственность за качество результата.

Например, раньше дизайнер готовил интерфейс, а затем ждал приоритизации и разработки. Теперь он может получить доступ к агенту и репозиторию и самостоятельно внести изменение. Но ответственность за UX остается на дизайнере, а за техническую надежность — на инженере.

Поэтому важно определить, кто отвечает за бизнес-результат, клиентский опыт, техническое качество и стандарты — и кто в итоге может сказать: «это можно выпускать в продакшн».

Вторая поломка: генерировать мы научились быстрее, чем проверять.

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

Узкое место сместилось с создания решения на проверку его качества: после перехода на новый процесс с агентами до 78% времени стало уходить на code review.

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

Третья поломка: привычные профессиональные роли перестают совпадать с тем, что реально делает человек.

Раньше было понятно: frontend-разработчик отвечает за свой участок, backend-разработчик — за свой, аналитик, тестировщик и дизайнер — за свои.

Но что происходит, когда с агентом можно сделать работу соседней роли или вообще пройти всю цепочку самостоятельно?

В примере банковского продукта мы перешли к модели, в которой один человек ведет изменение end-to-end: от постановки задачи до реализации и проверки качества. Так появилась более широкая роль product engineer — человека, который лидирует клиентское изменение целиком, а не только свой технический кусочек.

Такая перестройка вызывает вопросы: «Почему я должен писать тесты?», «Почему должен вести документацию?», «Я буду делать чужую работу хуже».

Поэтому просто дать команде агентов недостаточно. Нужно заново ответить на вопрос: за что мы ценим человека в продуктовой команде?

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

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

Поэтому при перестройке команды важно определить:

— кто отвечает за результат для клиента;
— кто отвечает за надежность и качество;
— кто принимает решение о выпуске;
— кто ведет изменение целиком.

И еще одно правило: если после ошибки не появилось новое правило, тест или стандарт — скорее всего, мы просто заплатили за эту ошибку и ничему не научились.

@productsense