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

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

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

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

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

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

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

Процесс аналитики в Fora Soft, image #2

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

Сроки

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

Деньги

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

Процесс

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

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

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

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

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

Результат

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

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

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

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

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

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

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

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

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

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

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

Вайрфреймы

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

  • Процессы