Мнение автора может не совпадать с мнением редакции
Иерархия процессов
Несмотря на внешнюю схожесть и даже некоторую шаблонность проектов, заметим, что каждый из них персонализируется. Где-то, ради сокращения сроков и будет рациональнее объединить этапы, где-то, напротив, целесообразнее пройти каждый из них максимально тщательно.
В целом же, разработка мобильных приложений подразумевает следующий порядок действий:
Продуктовая аналитика.
Спецификация и вайрфреймы.
Оценка и планирование.
Дизайн.
Программирование.
Тестирование.
Запуск.
Далее рассмотрим более подробный путь приложения от проверки работоспособности идеи до финала — передачи клиенту и публикации в магазине приложений.
Продуктовая аналитика
У заказчика, как правило, есть идея продукта и видение того, какие функции он содержит, какие задачи решает и кем будет востребован. Однако для начала работы этого недостаточно, нужен всесторонний анализ потенциала приложения с последующей систематизацией данных.
Задачи этапа:
сегментировать целевую аудиторию (ЦА);
определить популярные модели взаимодействия пользователей с аналогичными сервисами;
изучить конкурентоспособность продукта;
сформулировать уникальное торговое предложение (УТП);
построить гипотезы, объясняющие мотивы поведения посетителей;
Метрики, используемые в поиске данных, отличаются в зависимости от ниши, к которой относится продукт и задач, решаемых с его помощью. Игнорировать этот момент не стоит, так как неверные критерии отслеживания дают неточную выборку.
Сбор и систематизация информации, предваряющие процесс разработки — важный этап. Качественно проведенная продуктовая аналитика значительно облегчает адаптацию продукта к потребностям ЦА, в итоге сокращая смету и время, затраченное на внедрение мобильного приложения.
Срок исполнения этапа зависят от масштаба, предметной области и бизнес-целей проекта. В среднем аналитика занимает около месяца или 100 часов работы.
Спецификация и вайрфреймы
Задача этапа — сформулировать подробные технические требования к функциональности и дизайну мобильного приложения. Целью является донести до команды разработчиков четкое понимание плана реализации проекта.
Спецификация — дорожная карта, содержащая требования к программному продукту. Документ служит базой для формулировки и фиксации общих, понятных заинтересованным сторонам тезисов, функций и нагрузок программного обеспечения.
Хотя детали спецификации могут меняться вместе с новой задачей, «ядро» требований остается постоянным. Его составляющие:
введение — цели, термины, представление ЦА, масштаб проекта;
описание — видение и функциональность программы, детальная классификация пользователей, операционная среда, стандарты, предположения и зависимости;
требования к внешним интерфейсам — пользовательскому (UX), программному, оборудования и коммуникаций;
нефункциональные требования — производительность, конфиденциальность данных и безопасность системы, критерии качества продукта;
прочее — глоссарий, каталог моделей процессов, перечень базовых задач.
В отличие от технического задания спецификация не описывает технику достижения результатов, а лишь указывает критерии реализации проекта, оставляя выбор инструментов и решений на усмотрение разработчика.
Важно: описание всех сущностей, сценариев и требований должно быть максимально точным, исключающим двусмысленность, понятным любому, кого касается данный документ.