Процесс разработки приложений

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

Ниже — этапы, которые работают для клиентских и полевых приложений, какие артефакты просить, где обычно теряется время и как встроить публикацию в сторах, не превращая её в аврал.

Этап 0. Вход: зачем приложение и какой процесс оно обслуживает

До договора нужен короткий discovery или хотя бы бриф: роли, главный сценарий, системы вокруг, ограничения ИБ, кто принимает решения. Если этого нет, любой процесс дальше будет угадыванием. Как понять, нужен ли стор — нужно ли мобильное приложение. Как сузить первую версию — зачем нужен MVP.

Артефакт этапа: одна-две страницы границ v1 и список «не делаем». Без этого фикс цены вреден обеим сторонам.

Этап 1. Требования и прототип

Требования лучше писать сценариями, не списком кнопок. «Пользователь может перенести запись и видит подтверждение» проверяемо. «Удобный интерфейс» — нет. Прототип закрывает главный путь, пустые состояния, ошибки сети. Правка в прототипе стоит часы, в готовом модуле — дни.

Параллельно собирают доступы: тестовые API, ключи карт, песочница банка. Их отсутствие — главная причина простоя «мы готовы кодить». Шаблон документа — как составить ТЗ.

Этап 2. Архитектура клиента и связь с ядром

Решают: натив, кроссплатформа, PWA; как хранить сессию; как переживать офлайн; как версионировать API. Если ядра ещё нет, его проектируют сразу, иначе клиент обрастёт костылями. Про стык слоёв — ПО и приложения, про проектирование — проектирование и разработка ПО.

Этап 3. Спринты разработки

Спринт без цели — просто календарь. Цель: «запись создаётся и видна менеджеру», а не «сделали три экрана». Демо на устройствах заказчика, не только на симуляторе разработчика. Новый scope не влетает в текущий спринт молча: оценка, сдвиг срока или вырезание другой задачи.

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

Что смотреть на каждом демо

• Работает ли сценарий целиком, не только «красивый экран».
• Что происходит без сети и при 500 от сервера.
• Появились ли скрытые требования («а ещё отчёт»).
• Готов ли контент или снова рыба.

Этап 4. Тестирование и приёмка

Чек-лист сценариев, матрица устройств, регресс после багфиксов, песочница оплат. Заказчик прогоняет предметные кейсы: «скидка по карте лояльности, если остаток меньше». Подрядчик прогоняет технические: прерывание, повторная отправка, смена языка, права.

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

Этап 5. Публикация, пилот, сопровождение

Сторы добавляют календарь, который вы не контролируете полностью. Заложите запас. Пилот лучше закрытый: одна сеть точек, одна география, invite. Метрики и канал багов — с первого дня. После релиза процесс не заканчивается: ОС, SDK, модерация обновлений. Сопровождение шире клиентского стора — разработка и сопровождение ПО.

Роли в процессе

Владелец продукта, аналитик или постановщик, дизайн, клиентская разработка, сервер, QA, иногда DevOps и человек на публикации. На маленьком MVP роли совмещают, но QA на оплатах лучше не «совмещать до нуля». У заказчика должны быть люди на контент, доступы и приёмку — это тоже роли процесса, не «потом как-нибудь».

Когда жёсткий процесс вреден

Вреден ритуал статус-митингов без стенда. Вреден ГОСТ-толстый процесс на двухнедельный прототип. Вредна имитация Agile, где скоуп растёт каждую неделю без пересмотра даты. Процесс должен соответствовать риску денег, а не моде методологий.

Следующий шаг

Соберите этапы в договоре с артефактами на каждом. Назначьте владельца и канал задач. Заложите время на приёмку и модерацию. С этим можно сравнивать подрядчиков: они продают процесс или только обещание «сделаем».

Как устроены работы по приложениям — услуга разработки приложений, по ядру — разработка ПО. Заявка: контакты, Grevin, +7 993 302-62-55.

Календарь, который учитывает магазины и людей

Процесс разработки приложений ломается, когда в диаграмме Ганта нет модерации, отпуска владельца продукта и ожидания тестовых ключей. Заложите буфер: ревью стора, повторная заливка, задержка SMS-шлюза, согласование юридических текстов. Календарь «разработка закончилась в пятницу, в проде в понедельник» почти никогда не срабатывает для стора.

Внутри спринтов держите лимит незакрытых багов критичного пути. Если к релизу копится «потом», вы не в процессе, вы в отрицании. Заведите правило: не начинаем новую фичу, пока блокер главного сценария открыт. Это неприятно маркетологу, который хочет баннер, и спасает запуск.

Definition of done для мобильного инкремента

Готово — это не «замержено в git». Готово: сценарий на двух устройствах, аналитика события успеха, пустое и ошибочное состояние, текст не рыба, нет секретов в логе, сборка ставится на внутреннюю дорожку. Для оплат — песочница пройдена. Для пушей — тестовое уведомление пришло. Без DoD каждое демо спорит о смысле слова «готово».

Заказчик может иметь свой DoD приёмки: «администратор видит заявку без звонка разработчику». Совместите оба списка в начале, не на акте. Иначе процесс формально agile, а по сути скрытый waterfall к скандалу.

Коммуникация и артефакты спринта

Короткое резюме созвона в письме или трекере: решения, открытые вопросы, кто блокирует. Ссылки на сборку. Список известных ограничений. Это занимает пятнадцать минут и экономит неделю «мы иначе поняли». Не дублируйте постановку в Figma, Telegram и почте без канона. Канон один — задача с номером.

Если команда распределённая, договоритесь о пересечении часов и о том, что тишина дольше SLA считается риском срока, а не «все заняты полезным». Владелец продукта, который отвечает раз в десять дней, сам удлиняет процесс. Это прямо описано в ошибках заказчика.

Как встроить ИИ, не ломая этапы

ИИ уместен на черновике тестов и бойлерплейте внутри спринта. Не уместен как замена этапа прототипа с живым пользователем. Не уместен как причина пропустить ревью. Если агент генерирует PR, процесс тот же: стенд, сценарий, человек. См. ИИ для написания кода.

Для ядра системы этапы те же по смыслу, другие артефакты: миграции, права, журнал. Не ведите два несвязанных процесса «сервер как-нибудь» и «приложение по scrum». Связка — ПО и приложения, услуга клиента — разработка приложений.

Риски календаря: контент, юристы, доступы

Процесс разработки приложений часто стопорится не на коде. Нет политики конфиденциальности — стор не принимает. Нет скриншотов с финальными текстами — витрина пустая. Нет тестового пользователя для ревьюера Apple — модерация крутится. Внесите эти работы в доску рядом с задачами разработки и назначьте владельцев с вашей стороны. Иначе команда «ждёт» в статусе, который выглядит как их простой, а простой ваш.

Юридические формулировки «удаление аккаунта», «детский контент», «платежи» влияют на чекбоксы магазинов. Их нельзя дописывать в ночь релиза. Параллельте с разработкой с первого месяца, если стор точно нужен. Если стор не нужен — не тащите этот календарь в веб-кабинет зря. Развилка — сайт или приложение.

Качество на слабой сети и старых устройствах

В процессе должен быть явный прогон: 3G, потеря пакета, сворачивание приложения во время оплаты, телефон 4–5 лет. Если в команде только флагманы, вы тестируете витрину, не рынок. Зафиксируйте минимальные версии ОС в ТЗ — это часть процесса, не мелочь. Расширение поддержки старых ОС — отдельная оценка, её нельзя требовать «ну вы же кроссплатформа» бесплатно.

Доступность: крупные цели нажатия, читаемые контрасты, не только жесты без кнопок. Для части аудитории это барьер входа, для магазинов — повод к вопросам. Заложите проверку в QA-чеклист спринта, не в «потом спецпроект».

Переход от пилота к регулярным релизам

Пилот может жить внутренними сборками. Регулярность — это расписание: окно стора, заметки релиза, кто жмёт кнопку, кто мониторит падения первые 48 часов. Без расписания сопровождение снова становится героизмом. Связка с поддержкой — разработка и сопровождение ПО. Услуга клиентского слоя — разработка приложений, ядра — разработка ПО.

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

Чек-лист процесса, который можно вложить в договор

Этапы с артефактами. Демо раз в 1–2 недели на устройствах. Definition of done. Канал задач один. SLA ответа владельца продукта. Буфер модерации. Чек-лист QA на сеть и оплату. Пилотная аудитория. План первых 48 часов после релиза. Без этого вы покупаете обещание, не процесс. С этим сравниваете подрядчиков предметно: кто может так работать, а кто умеет только «сделаем и покажем в конце».

Связанные страницы: как начать — разработать приложение, сколько стоит — создать приложение, ядро — ПО, клиент — приложения. Заявка — контакты.

Ретроспектива спринта без театра

Раз в спринт три вопроса: что пользователи не смогли сделать на стенде, какие доступы задерживали работу, какой scope прилетел сбоку. Решения пишите в бэклог, не в «давайте стараться». Если ретроспектива только про настроение, процесс не улучшается. Если только про вину заказчика или подрядчика — тоже. Цель — убрать системный простой: нет ключей, нет контента, нет решения по статусу. Это инженерное управление проектом, оно входит в взрослый процесс разработки приложений.

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

Процесс живёт, пока живёт стенд

Нет стенда — нет процесса, есть рассказы. Каждый спринт заканчивается установкой на тестовые устройства заказчика. Если сборку нельзя поставить без разработчика рядом, вы не готовы к стору. Наладьте внутреннюю дорожку в первую треть проекта, не в последнюю неделю. Тогда модерация и пилот не станут первым разом, когда «чужой телефон» открывает приложение. Это дешёвая страховка календаря.

Готовность к стору как отдельный столбец доски

Юридические тексты, скриншоты, тестовый ревьюер, возрастной рейтинг, ответы на вопросы модерации — отдельные карточки со сроками. Пока они в голове маркетолога, процесс врёт «мы почти готовы». Вынесите столбец «стор» рядом с разработкой с того спринта, как решили, что магазин нужен. Этого достаточно, чтобы дата релиза перестала быть фантазией разработчиков про код.

Частые вопросы