Что делать, если руководство хочет сменить технологию фронтенда, а вы не согласны
Что проверяют
Отделяете ли вы техническое предпочтение от интересов продукта и умеете ли спорить стоимостью, а не вкусом. Ещё смотрят на зрелость: примете ли вы решение, принятое не вами, и сможете ли после этого сделать переход безопасным.
Как отвечать
Сначала выясните, какую боль хотят вылечить сменой стека. За таким решением обычно стоит симптом: долго выкатываем фичи, тяжёлый бандл, плохая индексация страниц, трудно нанимать, текущая мажорная версия без поддержки. Пока симптом не назван, спорить не о чем.
Потом проверьте, лечится ли он внутри текущего стека. Серверный рендер и потоковая отдача, разделение бандла по маршрутам, обновление мажорной версии, единая библиотека компонентов вместо разнобоя, типизация и тесты обычно закрывают большую часть жалоб дешевле переписывания.
Если причина всё же в стеке, переводите разговор в цифры: сколько человеко-месяцев займёт миграция, что будет с потоком фич в это время, как переносятся тесты и аналитика, что с производительностью и индексацией, есть ли на рынке люди. Хорошая позиция звучит не как «не надо», а как «вот цена, вот риски, вот чем придётся пожертвовать».
Предложите проверку на кусочке: новый стек на одном изолированном разделе рядом со старым, решение принимаем по результату, а не по презентации. Если решение уже принято, отработайте план поэтапной миграции и настаивайте на одном изменении за раз.
Где спотыкаются
Спорят вкусами и авторитетами. Довод про удобство конкретной библиотеки несопоставим с доводом про сроки найма, и разговор заканчивается ничем.
Второе: обещают переписать всё за пару спринтов. Миграция фронтенда почти всегда длится дольше оценки, потому что за ней тянутся формы, состояние, авторизация, аналитика и тесты.
Третье: соглашаются вслух и саботируют в коде. Полупереписанный проект с двумя стеками обходится дороже любого из двух решений, принятых честно.