Процессы в мобильной разработке нужны не для идеальных отчётов. Они нужны, чтобы проект не рассыпался между сроками, ожиданиями и изменениями.

Обычно наши проекты распланированы на три-четыре месяца вперёд. Половина контрактов идёт по fix price, половина — по Time & Material. На первый взгляд кажется, что управлять ими нужно по-разному. В фиксированной цене любая ошибка бьёт по нашему бюджету. В T&M каждое изменение увеличивает расходы заказчика.

Мы около двух лет экспериментировали и пришли к простому выводу: базовые процессы не должны зависеть от коммерческой модели. Разница только в том, как мы обсуждаем изменения.

В fix price мы открываем документ с границами проекта и говорим: «эта задача не была заложена в смету, давайте обсудим корректировку бюджета». В Time & Material говорим иначе: «на это потребуется ещё 12 часов, берём в работу?»

Процессы остаются одинаковыми. Инструменты тоже. Меняется только диалог.

Что мы убрали из управления

До текущего набора мы пробовали многое. Jira с тяжёлыми воркфлоу, базы в Notion, таблицы в Confluence, диаграммы Ганта. Часть решений была слишком сложной, часть быстро устаревала, а часть превращалась в формальность, которую команда просто обходила.

В итоге остались пять шаблонов. Они не идеальные, но рабочие: не требуют лишней бюрократии и помогают держать проект в понятном состоянии.

1. Скоуп фиксируем до старта

Разработка не начинается с «давайте попробуем». Сначала мы встречаемся с заказчиком, выбираем модель — fix price или T&M — и фиксируем три вещи: что входит в релиз, что сознательно не делаем, по каким признакам поймём, что результат готов.

Списки должны быть предметными. Не «сделать удобный опыт», а «экран корзины», «оплата картой», «пуш при смене статуса заказа».

Такой документ нужен не для споров. Он помогает спокойно разбирать новые просьбы. Если через месяц заказчик вспоминает про «небольшую кнопку», мы не отказываем. Смотрим в скоуп: была ли она там? Если нет — обсуждаем, как её добавить.

В Time & Material оцениваем трудозатраты и включаем задачу в работу. В fix price либо оформляем дополнительные работы, либо переносим что-то другое на следующий релиз.

На подготовку скоупа уходит 3–4 часа. Иногда 5, если заказчик начинает вспоминать механики из приложений конкурентов.

2. Спринт нужен не сам по себе, а с целью и демо

Мы работаем двухнедельными спринтами. Часть заказчиков получает демо раз в неделю. Это зависит от проекта: если продукт сложный или клиент хочет плотно участвовать в процессе, частые показы помогают раньше заметить расхождение между ожиданием и реальностью.

В начале спринта формулируем цель одним предложением. Не «улучшить пользовательский опыт», а «добавить экран корзины и провести оплату». Без конкретной цели спринт легко распадается на набор задач. К демо может выясниться, что второстепенное готово, а основное нет.

Бэклог собираем до старта. В спринт попадают только задачи, которые ведут к цели. Остальное уходит дальше. Перед демо команда проверяет результат внутри. Заказчик видит рабочую версию, а не сырую сборку. Обсуждаем сценарии, интерфейс, логику, но не ищем баги вместе на звонке.

3. Пятнадцать минут утром вместо часовых созвонов

Каждое утро команда встречается на 15 минут. Три вопроса:

1. Что сделано за вчера
2. План на сегодня
3. Есть ли блокеры

Это не отчёт. Это способ держать общее поле в голове. Так меньше вероятность, что два человека делают одну задачу или кто-то застрял молча.

Раньше дейли могли растягиваться почти на час. Пять человек слушали, как двое обсуждают один метод. Мы поняли, что это дорого, и сократили формат. Если нужно углубиться — нужные остаются после встречи, остальные идут работать. В итоге освободилось больше трёх часов в неделю, и это время вернулось в разработку.

4. Ретроспектива: ищем дыры в процессе, а не виноватых

После каждого спринта собираемся на час. Обсуждаем:

1. что сработало
2. что не сработало
3. что удивило.

Последний вопрос оказался самым полезным. Удивление показывает слепую зону в планировании.

Этот пункт появился случайно. На одной из ретроспектив выяснилось: разработчик был уверен, что бэкенд-эндпоинт для push-уведомлений готов, а в задаче его не было. Никто не виноват. Просто на планировании каждый посчитал, что это часть соседней задачи. Мы записали правило: если задача пересекается со смежным сервисом или командой, на границе ответственности нужно явно прописывать, кто и что делает.

По итогам ретроспективы берём два-три изменения. На следующей встрече начинаем с проверки: внедрили или нет. Если нет — разбираем причину. Иначе ретро превращается в разговор без последствий.

5. Перед релизом проходим короткий чеклист

Перед публикацией в магазинах проверяем такие пункты:

1. Все критичные тест-кейсы зелёные
2. Прод бэкенда доступен, документация обновлена (хотя бы для себя)
3. Билды залиты в App Store, Google Play и RuStore;
4. Доступы к админке и аналитике переданы клиенту

Проходим этот список каждый раз, даже если кажется, что всё готово. Перед релизом появляется спешка: хочется быстрее пройти модерацию и увидеть приложение в живую. В такой момент легко упустить что-то простое.

Чеклист занимает несколько часов, но экономит время после релиза. Лучше проверить заранее, чем чинить на проде.

Что не помещается в шаблоны

Есть вещи, которые сложно описать регламентом. Подбор команды под конкретный проект, коммуникация между встречами, оценка рисков по бюджету и срокам. Это опыт, а не процесс.

Иногда заказчик приходит с запросом: «Хочу приложение, чтобы было удобно». Внятного ТЗ нет. Мы не ждём идеальный документ. Задаём три вопроса: кто пользователь, какое действие он должен совершить в приложении, по какому признаку поймём, что приложение работает. Из ответов собираем MVP. Заказчик видит результат и начинает точнее формулировать требования. Это техника: вопросы одни и те же, а ответы и итоговый MVP каждый раз разные.

Почему именно пять

Трёх шаблонов мало, система держится на памяти одного человека, контроля над проектом недостаточно. Восемь и более уже много — команда устаёт от формальностей и перестаёт воспринимать их всерьёз.

Пять — золотая середина: скоуп, спринты с демо, дейли, ретроспектива и чек-лист перед релизом. Остальное подключаем по ситуации.

В КОД9 разработка мобильных приложений держится на этих пяти шаблонах и помогает команде сфокусироваться на разработке, а не на преодолении хаоса.