Вернуться к блогу
Hola, Amigos! На связи CTO в Amiga Артем Салеев.
К нам часто приходят с запросом: «Сделайте функцию X, как у конкурентов». Иногда за этим стоит реальная задача. Иногда – тревога: у конкурентов есть, значит и нам надо.
Я не против разработки. Я против дорогих догадок.
Рискованный путь начинается с идеи и быстро приводит к переделкам. Рабочий – связывает цель, пользователей, процесс, метрики и только затем код.
Разработка – это не список хотелок. Это часы команды, архитектура, интеграции, тестирование, поддержка и деньги заказчика. Если мы не понимаем, какую цель закрывает функция, кто ей пользуется и как мы измерим результат, мы не пишем код. Сначала разбираемся.
Не потому что любим усложнять. Просто самая дорогая ошибка в заказной разработке часто случается еще до первого коммита.
Когда я говорю «разобраться до старта», я не имею в виду дашборд для инвесторов или бесконечные документы на сто страниц. На старте проекта нам нужно понять три вещи: бизнес-задачу, пользовательский путь и устройство будущей системы.
Бизнес-задача отвечает на вопрос, зачем продукт компании. Какие процессы он меняет? Где сейчас теряются деньги, время или клиенты? Кто принимает решения? Какой результат бизнес считает успешным?
Пользовательский путь показывает, кто будет работать с продуктом и в какой ситуации. Не абстрактная «целевая аудитория», а конкретные роли: клиент, менеджер, администратор, партнер, сотрудник склада, провизор, владелец точки.
Бизнес-анализ на старте отвечает не за экраны и не за события в аналитике. Его задача – понять, какую бизнес-проблему решает продукт и почему эту проблему вообще стоит решать разработкой.
Мы разбираем текущий процесс, участников, точки потерь, ручные операции, стоимость ошибки и критерии успеха. Например: где менеджер тратит время вручную, где клиент выпадает из сценария, какой отдел принимает решение и какой показатель должен измениться после запуска.
Иногда после такого разбора становится видно, что бизнесу нужен не новый раздел в приложении, а интеграция, изменение статуса заявки, автоматизация одного шага или отказ от функции, которая не влияет на результат.
То есть бизнес-анализ помогает ответить на вопрос «зачем», а уже системный анализ – на вопрос «как это должно быть устроено внутри продукта».
До проектирования команда разбирает текущий процесс, участников, критерии успеха, точки потерь и стоимость возможной ошибки.
Системный анализ переводит этот разбор в язык разработки: сущности, статусы, роли, ограничения, интеграции, API, сценарии и требования к реализации.
Отдельно мы заранее продумываем метрики. Продуктовые выводы появятся уже после запуска, когда у нас будут реальные данные. Но события, параметры и точки сбора нужно заложить до релиза – иначе потом команда увидит только «что-то просело», но не поймет, где именно сломался путь пользователя.
Допустим, заказчик хочет добавить новый раздел в приложение. На первый взгляд задача понятная: нарисовать экран, сверстать, подключить бэкенд, протестировать и выкатить в продакшн.
Но до разработки нам важно выяснить другое:
Без этих ответов команда начинает гадать. И каждая догадка оплачивается по ставке разработчика, дизайнера, аналитика, тестировщика и менеджера.
Мы не хотим, чтобы клиент платил за догадки. Поэтому на старте задаем неудобные вопросы.
Нам важно увидеть не только будущий экран, но и работу вокруг него. Как сейчас действует отдел продаж? Где менеджеры делают ручные операции? На каком шаге клиент уходит? Какие данные уже есть в CRM, 1С, ERP или внутренней системе? Кто отвечает за результат?
Иногда вывод получается проще, чем ожидали: достаточно интеграции, понятного статуса заказа или автоматизации одного болезненного шага.
Дальше смотрим, как человек проходит от первой точки входа до целевого действия: записи, оплаты, заявки, покупки, повторного обращения. Здесь важны не только экраны, но и мотивация. Что пользователь уже знает? Где сомневается? В какой момент ему нужна подсказка? Где интерфейс должен быть быстрым, а где – объясняющим?
После этого результат исследования превращается в рабочие артефакты для команды: модель данных, статусы заявки, схему ролей, список интеграций, ограничения, требования к API и понятные границы MVP.
Именно здесь становится видно, что нужно разработать сейчас, что можно вынести во второй релиз, а что вообще не решает задачу бизнеса.
Перед началом разработки фиксируют бизнес-процессы, пользовательские сценарии, системную логику, а также метрики и события.
Метрики и события
Продуктовая аналитика применяется после запуска, но события под нее нужно заложить заранее. Иначе через месяц после релиза сервис работает, люди ходят по экранам, бюджет потрачен, а ответить на вопрос «почему просела конверсия?» невозможно.
Мы заранее описываем ключевые точки: просмотр экрана, начало сценария, успешное действие, ошибка, отказ, повторный шаг. Для одних проектов достаточно GA4/Firebase или AppMetrica, для других нужны Amplitude, Mixpanel, серверные события и отдельная логика хранения данных.
Последовательность событий помогает увидеть весь путь пользователя – от просмотра экрана и старта сценария до ошибки, повторной попытки или успешного действия.
В проекте для сети АЗС ХТК задача была не в том, чтобы «сделать красивое приложение с нуля». У компании уже была мобильная платформа на Битрикс, больше 70 000 зарегистрированных пользователей, бонусы, история покупок, акции и обратная связь.
Проблема была жестче: Битрикс прекратил поддержку мобильного модуля. Если бы приложение исчезло из App Store и Google Play, бизнес потерял бы прямой канал коммуникации с клиентами, а пользователи – доступ к накопленным данным и бонусам.
На старте мы разобрали не только интерфейс, но и связи между приложением, сайтом, бонусной программой и пользовательской базой. Системный анализ помог описать API, сценарии регистрации, начисление бонусов, историю операций, пуш-уведомления и офлайн-режим.
Так мы не раздували MVP случайными функциями, а собрали первую версию вокруг критичных сценариев: сохранить клиентов, перенести данные и быстро вернуть бизнесу стабильный мобильный канал. Подробнее об этом проекте можно прочитать в статье про мобильное приложение для АЗС на Flutter.
В проекте Stock заказчик работал с неликвидным горным оборудованием. До проекта информация приходила в разном виде: PDF, Excel, письма, списки от партнеров. Менеджеры вручную разбирали сотни позиций, а покупателям было сложно быстро найти нужное оборудование.
Если бы мы начали сразу с витрины маркетплейса, получили бы красивый интерфейс поверх хаоса. Поэтому до разработки разобрали не только экраны, но и данные: категории, характеристики, фильтры, структуру карточки товара, путь продавца до публикации объявления и путь покупателя до обращения.
Для MVP оставили базовые действия: личный кабинет продавца, публикацию объявления, поиск, фильтрацию и возможность написать продавцу. Регистрацию компаний, проверку по ИНН, расчет доставки, поддержку, избранное, отзывы и оценки вынесли в развитие после запуска, когда стало понятно, какие сценарии действительно нужны пользователям.
Отдельная часть работы – ML-категоризация. Команда привела к единому виду больше 1500 товарных позиций, подготовила 200 эталонных карточек и построила структуру до 4 уровней вложенности. В результате модель стала определять конечные категории товаров с вероятностью 85%, а добавление новых карточек ускорилось в разы.
Здесь разбор до старта сработал не как «таблица ради таблицы», а как способ превратить неструктурированные данные в продукт, которым можно пользоваться.
Разрозненные таблицы и документы превратились в структурированный каталог горного оборудования с категориями, фильтрами и карточками товаров.
Для аптечной сети «Ваша №1» мы делали B2B-сервис по обработке претензий. Снаружи задача могла звучать просто: нужен личный кабинет, где аптеки оставляют обращения по поставкам.
На практике проблема была в процессе. Претензии обрабатывались вручную, часть коммуникации шла по телефону и сторонним каналам, заявки могли теряться, а владельцы аптек и провизоры часто работали с мобильных устройств.
Перед дизайном мы провели предпроектное обследование: разобрали роли пользователей, сценарии подачи претензии, работу с накладными, статусы, фильтры, сортировку, уведомления и требования к API для команды клиента.
Именно этот разбор позволил сделать не просто форму заявки, а сервис, где можно управлять поставками, претензиями и документами в одном месте. В результате со стороны клиента этим процессом стал заниматься 1 человек вместо 10.
Вот почему анализ до старта не тормозит проект. Он показывает, где на самом деле находится узкое место.
Что фиксируем | Зачем это бизнесу | Во что это превращается для разработки |
Цель и критерии успеха | Понятно, ради какого результата тратим бюджет. | MVP-границы, приоритеты, критерии приемки. |
Роли и пользователи | Команда видит не абстрактного «пользователя», а конкретные ситуации. | Схема ролей, права доступа, сценарии использования. |
Процесс и узкие места | Не автоматизируем хаос и не переносим ручную боль в интерфейс. | Статусы заявок, бизнес-правила, карта процесса. |
Данные и интеграции | Снижаем риск внезапных ограничений в середине разработки. | Модель данных, API, список интеграций и ограничений. |
Метрики и события | После релиза можно понять, что работает, а что нет. | План событий, параметры, точки сбора данных. |
Подготовка на старте не делает проект медленнее. Она убирает хаос, который обычно всплывает в середине разработки.
Без нее команда пишет код, получает новые вводные, переделывает уже готовое и выходит за бюджет. Выглядит динамично, но пользы мало.
С нормальной подготовкой у проекта появляется опора:
Перед стартом команда проверяет цель, пользовательский путь, интеграции, риски, границы MVP, модель данных, события и метрики.
Это не гарантия, что каждая гипотеза сработает. В продуктовой разработке так не бывает. Но команда перестает принимать решения вслепую.
Если вы планируете мобильную разработку, веб-разработку или сложный личный кабинет с интеграциями, такой разбор особенно важен: чем больше зависимостей, тем дороже ошибка в начале.
В Amiga мы не начинаем разработку с догадок. Мы заходим в проект как технический партнер: связываем бизнес-цель, системную логику, метрики и реализацию до того, как команда начинает писать код.
Поэтому на старте мы можем спорить, задавать неудобные вопросы и предлагать сократить лишнее – не чтобы замедлить проект, а чтобы быстрее прийти к работающему результату. Сильный продукт начинается не с кнопки и не со стека. Он начинается с понимания, зачем эта кнопка бизнесу. Если хотите проверить идею до разработки, посмотрите материал «Три вопроса, без которых мы не беремся за проект» – он хорошо продолжает эту тему.
Чтобы команда понимала не только список функций, но и бизнес-цель, пользователей, процесс, ограничения и критерии успеха. Это снижает риск переделок, помогает не тратить бюджет на бесполезный функционал и повышает вовлеченность специалистов. Когда результат можно измерить после запуска, команда видит, как ее работа повлияла на продукт и бизнес.
Анализ отвечает на вопросы «зачем», «для кого», «как работает процесс сейчас» и «как поймем, что стало лучше». ТЗ фиксирует уже более конкретные требования к реализации. Хорошее ТЗ обычно появляется после нормального разбора задачи. Подробнее можно прочитать в статье Amiga о том, как составить ТЗ.
Иногда можно, если задача маленькая, понятная и не влияет на важные бизнес-процессы. Но для сервисов, личных кабинетов, маркетплейсов, мобильных приложений и интеграционных проектов такой старт часто приводит к переделкам.
Минимум – события на ключевых шагах пользовательского пути: вход в сценарий, просмотр важного экрана, успешное действие, ошибка, отказ, повторное действие. Конкретный набор зависит от продукта и бизнес-цели.
Зависит от масштаба проекта. Иногда достаточно нескольких рабочих встреч и короткого описания сценариев. В сложных продуктах с ролями, интеграциями и нестандартной логикой нужно полноценное предпроектное обследование.
У этапа должен быть понятный результат: согласованные сценарии и границы MVP, роли и статусы, описание интеграций и модели данных, основные риски и план метрик. Анализ не затягивает проект, если открытые вопросы зафиксированы, у решений есть ответственные и сроки, а собранных материалов достаточно для следующего этапа. Если одни и те же вопросы возвращаются без новых данных, границы постоянно меняются и решения не фиксируются, процесс начинает буксовать.
Если вам нужно просто «сделать приложение, чтобы было», можно начать с экранов и списка функций. Так быстрее на старте, но дороже на дистанции.
Если вы строите ИТ-продукт, который должен приносить деньги, экономить время команды или менять клиентский опыт, начинать нужно с понимания: какую цель решаем, какой процесс меняем, какие данные собираем и как поймем, что решение сработало.
