Сколько времени занимает планирование
Что проверяют
Понимаете ли вы, что в мобильной разработке план упирается не только в объём кода: между готовой сборкой и пользователем стоят проверка в сторе и раскатка, а откатить выпущенную версию нельзя. По ответу видно, планировали вы когда-нибудь релиз целиком или только свои задачи.
Как отвечать
Начните с того, что планирование бывает разное:
- оценка задачи: разбор экрана на состояния (загрузка, пустой список, ошибка, отсутствие сети), какие нужны данные, что меняется в модели. Для одного экрана это разговор на полчаса, для фичи с новым сетевым контрактом заметно дольше;
- планирование релиза: что успевает попасть в ветку, регресс, метаданные и скриншоты, отправка на проверку. Срок проверки заранее не известен, поэтому дата подачи ставится с запасом;
- проектирование крупного изменения, например перевода экранов с UIKit на SwiftUI или смены слоя работы с сетью. Это отдельная работа с решением, записанным до начала кодирования.
Назовите факторы, которые чаще всего забывают в оценке: минимальная поддерживаемая версия iOS и связанные с ней ограничения API, локализация, доступность, разные размеры экранов, запросы разрешений, миграция локального хранилища. Скажите и про флаги: они позволяют влить незаконченное и не держать долгоживущую ветку.
Где спотыкаются
Оценивают только написание экрана и получают срыв на всём остальном: согласовании макетов, ревью, регрессе на старых устройствах, ожидании проверки в сторе. В оценку входит путь до пользователя, а не момент, когда код собрался.
Второе: не закладывают невозможность быстрого отката. На сервере плохой релиз откатывают за минуты, в приложении придётся выпускать новую сборку и снова ждать проверки. Отсюда поэтапная раскатка и удалённые флаги, о которых договариваются как раз на планировании.
Третье: дают одинаковые сроки задачам разной неопределённости. Экран по готовому макету и интеграция с чужим SDK без документации это разные истории, и во втором случае честнее выделить время на исследование отдельным шагом.