Буду иногда разбирать реальные кейсы. Начнем с классики. Поддержка старых версий iOS.
⚠️ Проблема: разраб хочет поднять минимальную версию. Для бизнеса это потеря охвата. Для разрабов это отказ от легаси. Конфликт интересов очевидный.
💎 Решения:
Если вкратце: Техника не продается техническими аргументами. Продается через риск, деньги, анализ конкурентов и маленькие шаги.
1️⃣ Ты правильно начал, что оценил сколько пользователей на 13 iOS. Бизнес любит цифры.
Но в целом это цифра в вакууме. Сколько платежеспособных пользователей сидит? Почему они важны? Зачем тратить дополнительные ресурсы на их поддержку? Сколько фич не было сделано или сделано хуже из-за ограничений старой оси?
Иногда поддержка обходится дороже, чем обновление и важно как раз показать эту разницу бизнесу.
2️⃣ Ты сравнил UIKit vs SwiftUI. Для бизнеса это мало что значит.
"Переходить на SwiftUI и съезжать с монолита" звучит как многолетний рефакторинг с непонятным бизнес профитом. В банковском приложении, где система вся хрупкая, и любая фича потенциально приносит кучу бабок. Мы зачем-то без четкой причины хотим поменять одно на другое.
Аналогично я не понимаю какая же бизнес причина должна быть с переводом с VIPER на TCA. Если все работает, то зачем? На чем мы экономим? В чем риск? Мне как инженеру тоже недоконца понятна аргументация.
Потенциально это все упрется в нестабильность и фиксы багов. Потратится куча времени.
Обычно идет какой-нибудь этап апробации:
"Давайте следующий новый экран или фичу напишем на SwiftUI. Без рисков для существующего кода, просто проверяем гипотезу."
Или я пишу Tech Design Review. Где описываю почему нам нужна эта технология. Не просто поиграться и "потому что разрабы хотят". А с четкими и сознательными аргументациями.
3️⃣ Сравни что делают конкуренты. Если большинство банков ушли с 13, то это сильный аргумент. Это снимает страх. Руководство слышит лучше, чем "UIKit устарел" (хотя я с этим не согласен).
4️⃣ Часто проблема не в аргументах, а как их доносят. Во всех компаниях и командах я стараюсь участвовать в развитии архревью. Например в команде иос и bdui делал инструмент TDR и ADR. Он помогает лучше, быстрее и детализированее разобрать в проблемах. Командно оценить необходимость и качество решения.
В авито например это было сделано на максимальном уровне. Каждый разраб высокого грейда должен раз в пол года защитить и реализовать крутой TDR. Так оценивают его контрибьют. Сделайте это процессом оценки влияния инженера на работу.
Это мои 4 общих совета. Посоветуйте подписчику свои идеи. Или поспорьте с моими)
А если вам понравилась рубрика ставьте 🔥 или закидывайте свои кейсы в лс или сообщения канала.