Продуктовые команды больше не будут такими, как раньше
С приходом ИИ меняется управленческая система ролей и процессов в компании.
Сначала был Waterfall — длинная последовательная цепочка от требований до релиза. Управление строилось через последовательность этапов, заранее зафиксированные решения. Скорость была низкой, изменения - дорогими.
Потом пришёл Agile. Компании перешли к небольшим кросс-функциональным командам, коротким итерациям и регулярным инкрементам. CI/CD и автоматизация поставки позволили релизить код быстрее, но сам продуктовый цикл всё равно зависит от скорости человека и прохождения этапов: discovery отдельно, delivery отдельно, инкремент - раз в неделю-две.
AI меняет не скорость отдельных этапов, а сам цикл создания продукта.
Сегодня гипотеза может быть сформулирована, визуализирована, реализована и протестирована за часы, а не за спринты. Discovery и delivery начинают схлопываться в единый поток обучения.
Это напрямую меняет и роли в команде.
Product Manager формулирует гипотезы, работает с prompt’ами, сам собирает первые прототипы, запускает быстрые тесты и управляет не бэклогом, а скоростью обучения продукта.
Роль разработчика тоже смещается. Код всё чаще пишет машина. Человек становится reviewer’ом и архитектором: задаёт технические рамки, формулирует качественные prompt’ы, проверяет результат, отвечает за надёжность, безопасность и масштабируемость.
Дизайн перестаёт быть узким bottleneck’ом. Ведь дизайн встроен в процесс создания продукта.
Тестирование как отдельная стадия постепенно исчезает - проверки встраиваются в сам процесс генерации решений.
Как вам новая реальность и насколько вы уже адаптировались с ней? 💬
· 05.02
Может от того, что я привык измерять с позиции глухого бекэнда масштаба enterprise, но пока не могу согласиться. Вижу естественную возможность ускорения на этапах бизнес-решений, тестов, принятия решений; можно хорошо ускориться на этапе проработки архитектурных решений, системным аналитикам можно помочь, но не заменить, то же с разработкой, особенно типовых решений и автотестов, но хоршего QA инженера, кажется, подменить будет не просто. Резюмируя: да, поле деятельности для ускорения обширное, но с оговорками. И с точки зрения бизнеса движение в этом направлении гораздо эффективнее массовых сокращений персонала
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён