Предыстория

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

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

Кажется, что после COVID стало нормальным, когда у специалиста несколько работ.
Может, и работодатели уже смирились с этим? «Задачи закрываются и ладно».

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

Начну с темы, на которой я фокусировался последнее время — мобильная разработка на Flutter.

В этой статье

1. Пошаговая структура разработки:

   1. Аналитика и постановка задачи

   2. Дизайн и ожидания пользователей

   3. Разработка и автоматизация

   4. Тестирование и роль QA

   5. Релиз-менеджмент и ветвление

   6. Подготовка к релизу: чеклист

2. Что дальше?

Начнем по шагам: постановка задачи, аналитика, дизайн, разработка, тестирование, релиз, следующий цикл

Какое приложение создаем?

Когда хочешь сделать приложение, нужно понимать, что ты хочешь сделать.
Это — роль аналитика. Без неё никуда. Сохраняем её в команде.

Оговорюсь, что иногда её исполняет Project Manager, когда ресурсов мало и нужна сильная коммуникация с заказчиком. Усиливает роль тем, что GPT помогает расписывать требования — знай успевай накидывать и делать факт-чек.

Примечание: факт‑чеку будет посвящена отдельная статья, потому что много копий сломали с моим приятелем системным аналитиком, обсуждая «стоит ли доверять GPT проработку требований и документацию, или проще написать самому, чем проверять за ним».

Как будет выглядеть?

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

Дальше вопрос: насколько нам подходит шаблонный дизайн (например, Material)?
Как правило, сейчас это не работает. Пользователи искушены. Продукт должен не просто работать, но и выглядеть нормально. Иначе выберут конкурента.

А что такое «нормально»? Здесь тысяча школ и подходов. Дело вкуса.
Никакой AI не угадает, как заказчику «нормально».
Поэтому делаем упор на дизайнеров, но объясняем им правила разработки и генерации компонентов и вёрстки из Figma.

Итого у нас есть:

• требования,

• дизайн,

• кодогенерация традиционными способами и с помощью AI.

Как будем разрабатывать?

Здесь я хочу разобрать инструменты и их эффективность, но главное — отстроить процесс, чтобы AI‑инструменты забрали максимум рутины в разработке.
А принятие решений на уровне ревью и факт‑чека оставались за разработчиком.

Основные опоры:

1) Код, требования, дизайн, документация — всё храним в одном репозитории:

• тогда могут работать штуки вроде Cursor

• git, git diff, Merge Request — как инструмент акцепта со стороны разработчика

• git как связующее звено для разных промтов

2) CI/CD как основа для факт‑чека. Усилена e2e, golden и widget‑тестами

3) Идём от TDD, так как важен факт‑чек

Контроль результата

Итак, у нас появился какой‑то код и регулярные сборки.
И тут мы доходим до проверки того, что же у нас получилось.
Речь про QA.

Ослабление роли разработчика, повышение общей непредсказуемости, а значит — рисков, приведёт к тому, что нагрузка на QA вырастет.
По сути, эта компетенция становится bottleneck и кузницей кадров для подобной структуры.

Базовые подходы:

• всеобъемлющий подход к тестированию: требований, дизайнов, приложения

• анализ corner‑cases — желательно на уровне требований

• составление базы скриптов

• автоматизация тестирования

Делаем релиз

Последняя составляющая — релиз‑менеджмент.

Первое — это стратегия работы с ветками: здесь будет взят базовый GitFlow. Главное — он понятен разработке. Можно вести несколько параллельных веток.

Но подход будет усилен шагом в сторону Trunk‑Based за счёт тотального использования feature‑flags:

• на уровне сборки

• на уровне CI/CD

Причины:

• версии могут сильно разойтись → усложнение merge»ей → повышение вовлечения разработчиков

• для работы с AI удобнее иметь одну версию продукта

Второй важный момент: приоритизация багов и работа с версионированием и зависимостями.
Что важно для подготовки релиза?

Кратко:

1. Обновляем версии приложения

2. Обновляем версии пакетов на последние стабильные

3. Прогоняем линтер, тесты, устраняем ворнинги

4. Запрашиваем рекомендации по рефакторингу у AI, делаем поиск ошибок (после merge что‑то могло пойти не так)

5. Ставим в работу приоритизированные баги по итогам релиза

6. Ставим в работу фичи

Описываем риски для QA по пунктам 2–6 
Делаем сборки и смоуки с QA после пунктов 2–5

Такой процесс я держу сейчас в голове.

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

• подбор инструментов, промтов

• шаблон приложения (отдельная статья)

• обкатка MVP на примере приложения (отдельная статья)

Буду рад вопросам, комментариям, дополнениям.