Что делать, если в команде нет четкого пайплайна
Что проверяют
Что вы сделаете сами, без полномочий менять процессы. Ждут не описание идеального процесса, а первый шаг в своей зоне ответственности, который останется полезным, даже если команда больше ничего не поменяет.
Как отвечать
Начните с того, что слово «пайплайн» стоит сузить до конкретной боли. У фронтенда обычно ломается одно из трёх: в основную ветку попадает нерабочий код, никто не знает, что уже уехало на стенд, откат руками занимает вечер.
Дальше по шагам:
- договориться о признаке готовности задачи, чтобы «готово» значило одно и то же у всех;
- собрать проверки в одну команду: линтер, типы, тесты, сборка. Это делается за час и не требует ничьего согласия;
- повесить ту же команду на автоматическую проверку веток, чтобы сломанная сборка была видна до ревью, а не после;
- поднять предпросмотр ветки, чтобы дизайнер и менеджер смотрели результат сами;
- и только потом обсуждать ветвление, релизы и владельцев кода.
Хороший ответ заканчивается наблюдаемым признаком: перестали чинить основную ветку по утрам, релиз перестал требовать дежурного.
Где спотыкаются
Приносят выдуманные цифры вроде роста продуктивности на треть. Проверить их нельзя, и собеседник слышит шаблон вместо опыта. Назовите изменение, которое видно без замеров.
Второе: начинают с выбора трекера и ритуалов. Инструмент не заменяет правил: без признака готовности и автоматических проверок доска просто отражает тот же беспорядок.
Третье: рассказывают, как вводили процесс распоряжением сверху. Ценнее показать, что вы сделали маленький шаг, получили результат на своей задаче и только после этого предложили распространить его на команду.