основные этапы разработки мобильного приложения
Этапы разработки мобильного приложения: аналитика и техническое задание
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.
Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.
Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.
В предыдущих материалах мы рассказывали:
Сейчас поговорим о том, как строится работа над созданием мобильного приложения: что включает в себя этап аналитики и что должно быть в техническом задании.
Мы в студии обычно строим работу так:
Каждый проект — особенный. Для одного можно объединить несколько этапов в один, чтобы реализовать задуманное быстрее и дешевле. Для другого целесообразно пройти все этапы. Мы поможем выбрать оптимальный путь.
Каждое приложение начинается с идеи. Вы рассказываете нам, какие задачи должен решать будущий сервис, и мы приступаем к сбору аналитики. Глубокий срез рынка, анализ уже существующих решений, изучение конкурентов и моделей поведения покупателей… На каждом этапе анализа мы помним о конечном пользователе и продумываем жизненный цикл клиента. Это помогает нам вместе понять, как люди будут использовать новое приложение — и сделать его максимально удобным, понятным и полезным. Такой сервис принесет пользу и вашему бизнесу.
Что в результате: референсы по функциональности и дизайну.
Аналитика — принципиально важный этап. Не надо от него отказываться и начинать работу над проектом с технического задания. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать. Мы обычно собираем лучшие практики и предлагаем клиенту проверенные решения, которые 100% сработают.
Мы составляем подробное описание функциональности и дизайна будущего приложения. Определяем персонажи пользователей, описываем пользовательские истории (User Story), составляем карту путешествия пользователей (Customer Journey Map) и формируем технические требования к сервису. То есть фиксируем, каким должно быть приложение, что оно должно уметь и как это будет работать.
Благодаря такому техническому заданию (ТЗ) наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею.
Пользовательские истории (User Story) пошагово описывают, как пользователь ведет себя в приложении: проходит авторизацию, просматривает каталог, оформляет заказ, совершает покупку. Такая история описывает задачу пользователя, которую он решает с помощью и приложения, и его конечную выгоду. В результате мы получаем список требований, который позволяет определить функциональность будущего приложения и сделать его максимально удобным для пользователя.
Допустим, вы хотите сделать приложение, с помощью которого можно будет распечатывать фотографии как фотоальбом. Основными пользовательскими историями будут создание аккаунта, выбор фотографий из фотогалереи, выбор размера альбома, оплата за альбом с помощью карты, доступ к истории заказов. Мы всегда работаем над пользовательскими историями всей командой и обязательно вместе в заказчиком. Это помогает продумать все нюансы и взглянуть на всю систему целиком, а в будущем избежать сложностей на этапе проектирования и разработки.
Карта путешествия пользователя (Customer Journey Map) позволяет наглядно представить, как разные персонажи будут пользоваться приложением в каждой из пользовательских историй. На такой карте виден весь путь пользователя — перемещение между экранами и клики на кнопки.
Составление карты помогает понять, как технически реализовать все функции приложения.
Мы делаем карту путешествия пользователя в Miro. Вся команда может работать над картой в реальном времени, а заказчик — смотреть результат в режиме презентации.
У каждой студии разработки свой подход к составлению этого документа. Мы считаем, что для успешной реализации проекта в нем должно быть отражено следующее.
2. Функциональные требования к приложению:
3. Нефункциональные требования к приложению:
4. Реализация функциональности приложения:
Не отказывайтесь от этапа аналитики. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать.
Благодаря грамотно составленному ТЗ наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею. Чтобы правильно составить ТЗ, используйте наш чек-лист.
В следующем материале мы расскажем, что нужно знать заказчику про проектирование, дизайн и разработку.
Этот цикл статей основан на книге, которую мы недавно сделали для своих клиентов. В этой книге мы постарались ответить на основные вопросы, которые у них возникают:
Остались вопросы? Не согласны с нами? Хотите высказать свою точку зрения или поделиться опытом? Пишите в комментариях. Давайте обсуждать!
Этапы создания мобильного приложения: проектирование, дизайн и разработка
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.
Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.
Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.
В предыдущих материалах мы рассказывали:
Сейчас поговорим о том, что включают в себя три следующих этапа разработки приложения: проектирование, дизайн и разработка.
Здесь наша работа делится на два направления: UX-дизайн, то есть проектирование, и UI-дизайн, то есть дизайн привычном понимании.
UX-дизайн направлен на повышение уровня удовлетворенности клиентов. На этом этапе мы упаковываем сложные процессы в максимально простое, понятное и полезное приложение, которое работает без глюков и багов.
UI-дизайн определяет то, как будет выглядеть приложение, каким будет его пользовательский интерфейс.
Иногда заказчик говорит: «А давайте не будем тратить время на проектирование и сразу займемся дизайном?». Не делайте так. Допустим, мы исключили проектирование и сделали дизайн. Посмотрели его, и у вас появилась куча идей, как все улучшить. Мы вносим правки и перерисовываем дизайн. Трудозатраты и стоимость проекта вырастают в два раза, а скорость работы вдвое снижается. Дизайнер выгорает, а вы как заказчик недовольны, что проект стал дороже. Все в минусе.
UX-дизайнер продумывает взаимодействие между элементами дизайна, чтобы увидеть, как приложение работает при всех распространенных пользовательских сценариях. Как проходит регистрация и авторизация, как выглядит начальный экран и личный кабинет, как происходит оформление заказа и оплата покупки. Мы проверяем логику приложения и корректируем ее, чтобы сделать пользовательский опыт максимально положительным. В результате получаем прототип — схематичную модель будущего приложения.
Проектирование особенно важно для проектов с большой долей неопределенности. Например, для стартапов.
UX-дизайн — это непрерывный процесс. При выпуске каждого обновления вы должны помнить, как люди используют ваше приложение. Если после обновления пользователям стало не так удобно совершать покупки или им надо сделать больше кликов, чтобы попасть в личный кабинет, значит, вы отклоняетесь от курса и пора поработать над UX-дизайном.
Лучше делать интерактивный прототип, например, в Figma. Перейдя по ссылке, можно пользоваться приложением так, будто оно уже готово и установлено на ваш смартфон. Вы можете перемещаться по разделам, нажимать на кнопки и выполнять различные действия.
Такой прототип полезен как на этапе проектирования, так и для заказчика. В первом случае он помогает выявить несоответствия в сценариях и быстро их исправить. Во втором случае заказчику не придется на словах объяснять, для чего нужен сервис и как он будет работать. Можно просто показать все на интерактивном прототипе, благодаря чему шансы быстро найти инвестора и реализовать проект возрастают.
UI-дизайнер отвечает за внешний вид будущего приложения. Он подбирает шрифты, выбирает цветовое решение, отрисовывает элементы интерфейса: кнопки, иконки, слайдеры, пуш-уведомления.
Если у заказчика есть корпоративный стиль, мы берем гайдлайн и делаем дизайн по нему. Если стиля нет, предлагаем свое видение с учетом трендов, специфики бизнеса и аудитории. В любом случае мы всегда рекомендуем работать по гайдлайнам от Apple и Google.
В зависимости от масштаба проекта дизайн может занять одну неделю или несколько месяцев.
Программирование — один из главных этапов. Написание кода любого приложения делится на фронтенд и бэкенд.
На этапе фронтенда разрабатывают клиентскую часть сервиса, то есть интерфейс пользователя и бизнес-логику приложения.
На этапе бэкенда разрабатывают серверную часть приложения — она отвечает за передачу данных между пользователями или ресурсами.
Что в результате: первый релиз приложения.
Есть множество подходов к разработке интерфейса. Но вам как заказчику не нужно в них углубляться. Достаточно знать два основных.
Нативные приложения написаны для конкретной мобильной платформы: iOS, Android, Windows. Язык программирования, который используется для написания таких сервисов, поддерживается только одной платформой. Например, Swift и Objective-C понимает только iOS, а Java или Kotlin — только Android.
Делайте нативное приложение, если оно должно стать важной частью бизнеса и влиять на продажи.
Нативное приложение может максимально использовать аппаратные и функциональные возможности смартфона или планшета, благодаря чему им очень удобно пользоваться. Но вместе с тем можно использовать оригинальные компоненты и шаблоны.
Плюсы нативных приложений:
Минусы нативных приложений:
При создании таких приложений используются общие наборы средств разработки (SDK). Из-за этого кроссплатформенные сервисы не используют все нативные преимущества каждой платформы. Зато сделать такое приложение дешевле — это оптимальный вариант для проектов с ограниченным бюджетом.
Делайте кроссплатформенное приложение, если нужно быстро проверить гипотезу или протестировать новый продукт.
Плюсы кроссплатформенных приложений:
Минусы кроссплатформенных приложений:
Исходите из своих бизнес-целей и ответьте на следующие вопросы:
Главное отличие между нативным и кроссплатформенным приложением — в скорости и отзывчивости работы. Это как проехаться на Porsche Cayenne и Hyundai Solaris. Оба авто едут по дороге, разгоняются, маневрируют и входят в повороты. Но разница чувствуется сразу.
После того, как вы определились, какое приложение будете делать — нативное или кроссплатформенное — надо разобраться с серверной частью.
Любое приложение отображает данные: показывает, какие товары есть в наличии в интернет-магазине, сколько запасов лежит на складе и кто из контрагентов должен вам денег. Все эти данные хранятся на сервере. Чтобы создать сервер, который эффективно обменивается данными с внешним интерфейсом приложения, надо его тщательно продумать.
На этапе бэкенда участие заказчика минимальное. Вам не надо думать, где хранить данные и нужно ли использовать бессерверную архитектуру — это решают разработчики. Мы в WINFOX всегда выбираем оптимальные для клиента решения. Единственное исключение — это когда надо вписать приложение в уже существующую среду. Тогда вы можете сказать: «Делайте на PHP, а не на Java».
UX-дизайн направлен на повышение уровня удовлетворенности клиентов. На этом этапе мы упаковываем сложные процессы в максимально простое, понятное и полезное приложение, которое работает без глюков и багов.
UI-дизайн определяет то, как будет выглядеть приложение, каким будет его пользовательский интерфейс.На этапе фронтенда разрабатывают клиентскую часть сервиса, то есть интерфейс пользователя и бизнес-логику приложения.
На этапе бэкенда разрабатывают серверную часть приложения — она отвечает за передачу данных между пользователями или ресурсами.
Делайте нативное приложение, если оно должно стать важной частью бизнеса и влиять на продажи.
Делайте кроссплатформенное приложение, если нужно быстро проверить гипотезу или протестировать новый продукт.
В следующий раз мы расскажем, что вам нужно знать про тестирование, стабилизацию и публикацию приложения в сторах.
Этот цикл статей основан на книге, которую мы недавно сделали для своих клиентов. В этой книге мы постарались ответить на основные вопросы, которые у них возникают:
Остались вопросы? Не согласны с нами? Хотите высказать свою точку зрения или поделиться опытом? Пишите в комментариях. Давайте обсуждать!
Этапы разработки мобильного приложения: пьеса в 7 действиях
Время чтения: 7 минут
Отправим вам статью на:
Знаете ли вы, что около 6 140 мобильных приложений выходят в Google Play ежедневно? А к 2020 году число релизов в App Store достигнет 5 миллионов? Статистика говорит об одном: пора разрабатывать своё мобильное приложение. Если вы всерьёз задумались над разработкой приложения, наш обзор вам поможет.
Неважно, что вы планируете создать — инструмент для бизнеса или стартап с широкой аудиторией. Мы развеем ваши страхи и опишем этапы разработки мобильного приложения.
Итак, пьеса “Процесс разработки мобильного приложения” в 7 действиях.
Действующие лица
Клиент — заказчик мобильного приложения, идейный вдохновитель проекта
Azoft — разработчики приложения
Project manager — менеджер проекта
Бизнес-аналитик — исследователь и хранитель знаний о требованиях к продукту
UI/UX дизайнер — создатель интуитивного и привлекательного интерфейса приложения
Разработчик — инженер, который пишет код приложения
QA инженер — специалист по тестированию приложения
Пролог
Сначала клиент приходит с идеей мобильного приложения. Мы просим клиента предоставить нам техническое задание (ТЗ), а если его нет — высылаем бриф на разработку мобильного приложения. Бриф помогает расставить приоритеты, обозначить цели и задачи приложения.
Все приложения разные, и мы используем разные методологии разработки: каскадную модель — Waterfall, и гибкую — Agile. Что бы вы не выбрали, процесс создания мобильного приложения включает оценку, аналитику, дизайн, разработку, тестирование, багфиксинг, релиз и поддержку после релиза. Ключевое различие состоит в подходах. В каскадной модели продукт разрабатывается сразу полностью. В гибкой — приложение разрабатывается итерациями, каждая из которых объединяет в себе все перечисленные стадии разработки.
На выходе:
Действие первое — Планирование и оценка
Первый вопрос, который интересует клиента: “Сколько это будет стоить?”. Следующий за ним: “Когда будет готово мобильное приложение?”. Чтобы ответить на оба вопроса, Azoft проводит оценку и составляет план работ. На этом этапе к проекту обычно присоединяется менеджер проекта. Он может выступать со стороны заказчика или со стороны команды разработчиков. Задачи менеджера проекта: координировать работу команды и общаться с заказчиком.
Но что же означает загадочное слово “оценка”? На этом этапе мы изучаем техническую документацию. Рассчитываем, сколько времени потребуется на разработку и тестирование. Выявляем не описанные сценарии и узкие места в ТЗ.
Экспресс-оценка занимает от нескольких часов до одного дня и даёт примерное представление о трудозатратах. Детальная оценка может длиться от нескольких дней до недели, но она позволяет точно определить, как, когда и какое приложение вы получите в результате. Если бизнес-аналитик подключается к проекту на этапе оценки, клиенту и разработчикам легче получить единое представление о приложении и всё точно рассчитать.
Но какой бы детальной ни была оценка, случается, что заказчики добавляют новые фичи прямо по ходу проекта. Когда мы делали приложение Pro Photo Shoot, соцсеть для фотографов и моделей, его автор, стартапер Уильям Апшоу на этапе разработки понял, каких функций не хватает. Список задач увеличился, мы сделали повторную оценку и сдвинули дату релиза. В итоге бюджет подрос, но мы разработали соцсеть для профи из фотоиндустрии в полном соответствии с требованиями клиента.
На выходе:
Действие второе — Aналитика
Аналитика не всегда входит в процесс разработки мобильного приложения. Бывает, что клиенты самостоятельно выполняют бизнес-анализ приложения, либо приходят с готовым списком требований. Но те приложения, которые прошли этот этап у компании-разработчика, выигрывают, — именно аналитика помогает бизнесу и разработчикам достичь единого видения, и уже на основе этого сделать переоценку требуемых работ и получить детальный бюджет проекта.
Бизнес-аналитики в Azoft выявляют требования к мобильному приложению, предлагают варианты реализации, строят схемы взаимодействия пользователя с приложением, создают основу UI — wireframes.
Большую работу провели наши аналитики на проекте для крупной сети супермаркетов. Заказчик искал способ, как через приложение мотивировать покупателей на дополнительные покупки. Мы проанализировали возможные пути решения и предложили наиболее эффективный вариант — интегрировать в мобильное приложение систему рекомендаций. Программа на базе AI советует пользователям товары на основе их предпочтений и истории покупок.
На выходе:
Действие третье — Дизайн приложения
Иногда клиенты приходят с готовым дизайном. Если дизайна у заказчика нет, мы создаём UI/UX с нуля. Когда аналитик передаёт дизайнеру основу графического интерфейса, вайерфреймы, мы приступаем к визуальному дизайну. Отрисовываем карту экранов, графические элементы, детализированный прототип с учётом различных сценариев использования.
На этом этапе UI/UX дизайнер создаёт статичные прототипы и, по запросу клиента, интерактивные прототипы приложения. Так мы показываем, как будет выглядеть приложение и какого поведения от него ожидать с учётом запланированных фич. Всё зависит от конкретных задач и пожеланий клиента.
Во время отрисовки дизайна приложение обретает свой будущий облик. Здесь очень важно получить обратную связь от бизнес-аналитика и клиента, чтобы дизайн мобильного приложения в полной мере отвечал требованиям.
На выходе:
Действие четвёртое — Разработка
Когда есть развёрнутое ТЗ и оценка, готов дизайн и утверждён прототип мобильного приложения, начинается хардкор. Команда разработчиков пишет код, чтобы реализовать запланированное поведение приложения и соединить логику приложения с серверной частью, если она предусмотрена. А также мы воплощаем готовый дизайн в коде — прописываем все стили и элементы UI, с которыми взаимодействует пользователь приложения.
В нативной разработке мы применяем языки Java и Kotlin для Android, Objective-C и Swift для iOS, и самые современные фреймворки и библиотеки. В кроссплатформенных решениях работаем с React Native и NativeScript.
Как только часть функционала разработана, мы её тестируем и продолжаем трудиться над остальными функциями.
Важно во время разработки, когда сверстали дизайн, подключить дизайнера. Дизайнер проверит, насколько хорошо разработчики реализовали скрины приложения: все ли стили соответствуют выбранным, тот ли выбран цвет, каково соотношение сторон, как скруглили углы и т.д.
На выходе:
Действие пятое — Тестирование и багфиксинг
QA инженеры Azoft подключаются к проекту на старте и тестируют так часто, как только возможно. Это гарантирует высокий уровень качества и помогает клиенту не раздуть бюджет.
На этапе оценки мы тестируем ТЗ. Параллельно с разработкой пишем тестовую документацию, например, тест-кейсы. Когда часть функционала готова, начинается тестирование. Все баги вносим в систему баг-репортинга, после исправления проверяем, что баги пофиксили и это не повлияло на остальной функционал. Перед релизом приложения делаем приёмочное тестирование: проходим основные бизнес-кейсы приложения, чтобы убедиться — поведение приложения соответствует тестовой документации и требованиям клиента.
Когда мы разрабатывали StoryApp — приложение для чтения коротких рассказов, заказчик не сразу определился, какие функции будут в приложении. Мы описали тестовую спецификацию с подробными характеристиками экранов и фич на основании озвученных требований клиента. Когда же во время разработки появились новые функции, например, покупки в приложении, мы были к этому готовы — расширили тестовую спецификацию непосредственно в разгаре проекта.
На выходе:
Действие шестое — Релиз
Когда серия тестов и доработок приложения завершена, а разработчики, аналитики, тестировщики и дизайнеры дружно одобряют результат, приходит время добавить приложение в магазин приложений — Apple App Store, Google Play или любой другой сервис по желанию клиента.
Чтобы приложение прошло ревью сторов, клиент может обратиться к разработчикам за помощью в релизе, а может подготовить и выложить приложение в магазин самостоятельно.
На выходе:
Действие седьмое — Техподдержка и развитие
После публикации мобильного приложения его история не заканчивается. Если клиент обнаруживает баги после релиза, мы их фиксим. Если же первые месяцы жизни приложения показывают, где и что нужно допилить или переделать, есть два варианта: заключить договор на сопровождение или запустить новую фазу разработки с учётом новых переменных.
На выходе:
Эпилог
Разработка мобильного приложения это непросто. Нет такой схемы “Раз-два, и готово”. Многие этапы могут пересекаться друг с другом или идти параллельно. Инстаграму потребовалось больше трёх лет, чтобы стать удобным и любимым миллионами приложением. И они до сих пор продолжают вносить улучшения и добавлять новые фичи. Перед тем как фантазировать, куда вы вложите деньги от продажи своего приложения IT-гиганту вроде Google, приготовьтесь — будет много работы. Смотрите действие первое.
Подпишитесь
Оставьте адрес, и каждый месяц мы будем высылать свежую статью
о новых трендах в разработке програмного обеспечения.
Этапы разработки мобильного приложения: поддержка и развитие
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.
Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.
Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.
В предыдущих материалах мы рассказывали:
Сейчас поговорим о том, как обычно проходят завершающие этапы работы над мобильным приложением: поддержка и развитие нового сервиса.
Приложение появилось в сторах, и вы уже рассказали о нем клиентам. Но это не конец — разработка мобильных приложений не заканчивается при запуске.
Нужно следить за тем, чтобы все корректно работало с технической стороны: серверы выдерживали нагрузки, на диске было свободное место, баги быстро устранялись.
Вместе с тем надо думать о развитии. По мере того, как пользователи будут скачивать и использовать новый сервис, вы будете получать отзывы и на основе них дорабатывать приложение. А еще через некоторое время наверняка захотите добавить новые функции.
В рамках поддержки мы обеспечиваем бесперебойную работу приложения, находим и устраняем баги, выпускаем релизы, работаем с отзывами пользователей. Кроме этого выполняем технические работы по мониторингу работоспособности серверов, резервному копированию, обеспечению свободного места на диске, поддержке обновлений операционных систем iOS и Android и так далее.
Поддержка обеспечивает бесперебойную работу приложения, а значит, и заботу о сотрудниках и клиентах. Мы устраняем ошибки в работе приложения, и вы можете быть уверены, что все бизнес-процессы работают как надо.
Поддержка приложения оценивается по часам. Вы платите за время, которое требуется на работу.
Если вы хотите соответствовать растущим ожиданиям пользователей и постоянно меняющимся рекомендациям мобильных платформ, надо регулярно обновлять приложение.
План развития приложения называется дорожной картой (Road Map). Такой план обычно составляется на год. Идеально, если у заказчика уже есть понимание, как будет развиваться приложение. Если такого понимания нет — ничего страшного, мы поможем разобраться.
Список задач, из которых состоит дорожная карта, называется бэклог. Бэклог обычно обновляют исходя из отзывов пользователей и данных аналитики.
Отзывы в сторах. С отзывами пользователей в сторах обязательно нужно работать. Но прежде, чем внедрять какую-то новую функцию или исправлять приложение по пожеланиям клиентов, нужно просчитать, как это повлияет на показатели эффективности. Желательно сразу просчитать это в деньгах.
Иногда (очень часто!) лучше проигнорировать просьбы пользователей ради того, чтобы сохранить простоту интерфейса и не зарыть главную функцию в тоннах сомнительных опций. Чтобы понять, как именно поступить, задайте себе всего один вопрос: Для какого процента аудитории действительно нужна новая фича?
Данные аналитики. Для начала можно использовать бесплатные системы аналитики в приложениях, например AppMetrica от Яндекса или Firebase Analytics от Google. Выдвините гипотезы, как можно улучшить те или иные важные для бизнеса показатели: вовлеченность, количество активных пользователей в день и в месяц, стоимость установки приложения. Внедрите изменения для части аудитории, измерьте результат, а после масштабируйте его или откатитесь назад. Затем повторите все еще раз, то есть работайте в рамках HADI-цикла постоянного улучшения.
Мы изучаем аналитику и определяем показатели, которые надо улучшить. После расставляем их в порядке значимости и начинаем работу. А еще постоянно мониторим конкурентов и включаем в дорожную карту лучшие практики. Часто заказчик не понимает, чем наполнить бэклог развития приложения. Мы поможем это сделать и обоснуем свои предложения.