Как работает аналитика в Fora Soft

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

От идеи до MLP (Minimum Loveable Product)

Разработка продукта обычно проходит по определённому процессу, состоящему из этапов, через которые компания проходит, создавая концепцию:

• концепция продукта (генерация идеи)
• исследования (проверка продукта гарантирует, что вы создаёте то, за что люди готовы платить, и не тратите время, деньги и силы на идею, которая им не нужна)
• планирование проекта
• прототипы
• дизайн
• разработка
• тесты
• запуск на рынок

А если кажется, что идея уже отточена? Зачем тогда нужна аналитика?

Согласно исследованиям Info Tech, нечёткие и расплывчатые требования — причина 70% провальных проектов по разработке программного обеспечения. Это ведёт к финансовым потерям, потере времени и сил, а также разочарованию участников. Ниже мы подробно разберём все возможные последствия. Эти проблемы можно избежать, если с самого начала проекта тесно сотрудничать с аналитиком и применять лучшие практики.

Возможные последствия пропуска этапа анализа

Вот список возможных трудностей, с которыми вы можете столкнуться, если пропустите аналитический этап разработки программного обеспечения:

Сроки

• невозможность логично выстроить процесс разработки: нет понимания, что на что опирается
• появление дополнительных функций и, как следствие, перенос релиза
• сложность прогнозирования следующих релизов и планирования долгосрочного развития продукта

Деньги

• переделка функционала и пустая трата часов
• сильные изменения в первичной оценке
• невозможность трезво оценить затраты на разработку без декомпозиции требований (может показаться, что задача займёт два дня, а потом вылезают подводные камни — и работа тянется уже две недели)

Процесс

• “простой” членов команды (могут быть сняты с проекта, и тогда придётся ждать новых)
• отсутствие нужного специалиста в команде (потому что изначально не было требований к определённой функциональности)
• задачи (некоторые требуют параллельной разработки, и на определённом этапе чего-то не хватает)
• постоянное залатывание дыр вместо построения целостной картины

Взаимоотношения

• с клиентом
• внутри команды

Документация

• разное видение продукта у заказчика и команды
• отсутствие чёткой документации (информация разбросана, хранится не в одном месте, часто дополняется и уточняется в переписке и на звонках)

Результат

• выбор более затратного функционала вместо простых и элегантных решений
• слабости в архитектуре проекта
• логические дыры, противоречия (отсутствует проверка на первичные несостыковки)

Подготовительный этап

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

Прежде всего рассмотрим исходные требования, поймём ваше видение и концепцию продукта. Далее аналитик проведёт исследование:

• Целевой аудитории и её боли
• Конкурентов
• Лучших практик в отрасли

Это поможет найти уникальные торговые предложения. УТП описывает, чем ваша компания выделяется на рынке: какую ценность вы даёте и какую проблему решаете. Хорошее УТП чётко формулирует ваше главное преимущество — то, чего нет у конкурентов, — и именно это делает вас особенными.

Анализ требований

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

Нефункциональные требования: Это ограничения по качеству, которые система должна соблюдать в соответствии с контрактом проекта. Их приоритет или степень важности зависит от конкретного проекта. Их также называют неповеденческими требованиями.

Функциональные требования: Это требования, которые конечный пользователь напрямую запрашивает как основные возможности системы. Они описывают входные данные, которые должны поступать в систему, операции, которые нужно выполнить, и ожидаемый результат. В отличие от нефункциональных требований, это критерии, заданные пользователем, которые сразу видны в готовом продукте.

Функциональные требования формулируются в виде пользовательских историй — кратких описаний потребностей, составленных с точки зрения конкретного пользователя продукта. Все истории объединяются в эпики. Далее важно добиться максимальной пользы при минимальных затратах — для этого задачи ранжируют по приоритетам.

Вайрфреймы

После нескольких итераций и уточнения требований мы подготовим вайрфрейм.

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

На этом этапе аналитик изучает лучшие практики UX-индустрии и ищет УТП. Для мобильных продуктов мы опираемся на руководства Apple Human Interface Guidelines и Google Material Design. Они созданы, чтобы ускорить решение задач пользователей. Эти руководства описывают принципы навигации и взаимодействия, компоненты интерфейса и их стили, используемую типографику и иконки, цветовую палитру и многое другое. Кроме того, поскольку большинство описанных элементов уже реализовано в коде, разработчику не нужно создавать их с нуля.

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

Тестирование

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

• Полнота. Набор требований считается полным, если все его основные части присутствуют и каждый элемент логически завершён.
• Однозначность. Каждый компонент должен быть чётко и ясно сформулирован, чтобы допускать только одну интерпретацию. Требование должно быть понятным и легко читаемым.
• Последовательность. Требования не должны противоречить друг другу или вайрфрейму.
• Валидность. Требования должны соответствовать ожиданиям и потребностям конечного пользователя.
• Выполнимость. Сценарии должны быть выполнимыми.
• Тестируемость. Мы должны иметь возможность создавать экономически обоснованные и удобные в использовании тесты для каждого требования, чтобы подтвердить, что продукт соответствует заявленной функциональности, производительности и действующим стандартам. Это означает, что каждое требование должно быть измеримым, а тестирование — проводиться в подходящих условиях.

Тестирование требований — проверенный способ избежать проблем на этапе разработки. Именно на этом этапе начинается непрерывное тестирование, чтобы обеспечить нужное качество продукта и минимизировать бизнес-риски. Лучше выявить все скрытые риски на аналитической стадии, чем во время разработки программного обеспечения.

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

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

• Концепция

• Обновлённый логотип, если у вас нет своего

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

• UI основных экранов приложения или платформы — экран 1 и экран 2.

Пример можно посмотреть по ссылке.

Это заключительный этап аналитического процесса. После него у вас будет полное и чёткое представление о проекте, и вы будете полностью готовы к разработке. На следующем шаге вы получите оценку от нашего менеджера по продажам.

Заключение

Чем лучше команда понимает общую картину, тем качественнее получится конечный продукт. Очень важно, чтобы между командой и заказчиком были прочные отношения и глубокое взаимопонимание — именно это в полной мере обеспечивает аналитик. Оценки стоимости и сроков, которые дают разработчики, будут настолько точными, насколько чётко сформулированы требования. После завершения аналитической работы можно давать оценку с погрешностью ±10%. Это позволяет эффективнее управлять затратами, контролировать сроки и достигать бизнес-целей.

Так что, если хотите пообщаться с нашими аналитиками и получить вайрфрейм, не стесняйтесь связаться с нами. Мы созвонимся, обсудим проект и в течение недели бесплатно предоставим оценку стоимости и первичную аналитику вашего продукта.