Как мы оцениваем услугу аналитики и дизайна проектов

Неудивительно, что заказчики беспокоятся о будущем проектов: рынок переполнен приложениями, многие из которых не добьются даже небольшого успеха. В 2019 году пользователи загрузили на устройства 204 миллиарда приложений. Вряд ли все из установленных программ так популярны, как топовые и известные миллионам пользователей: Instagram, WhatsApp, Facebook, Tik Tok. Сотни проектов почти сразу исчезают из сторов, хотя на них потрачены миллионы.

Чтобы понять, удастся ли реализовать новое приложение и во сколько обойдётся его разработка, нужно произвести его оценку. Это касается аналитики, дизайна, разработки и других работ, которые будут выполнены при создании продукта. Оценка стоимости и временных затрат позволяет клиенту правильно выбрать подрядчика.

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

Какие типы оценок у нас используются

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

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

Мы используем два основных типа оценки аналитики и дизайна и два подхода к проведению работы.

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

Оценка аналитики

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

Для получения грубой оценки на предпроектный анализ достаточно иметь четко сформулированные бизнес-цели проекта. Чтобы получить «точную» оценку на предпроектный анализ понадобится:

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

Если же клиент понимает общее направление работы над продуктом лишь на уровне идеи, и даже верхнеуровневых требований к ПО нет, наша оценка на предпроектный анализ будет грубой. Её целью будет не детализация требований, а их определение. Границы проекта прояснятся в полной мере лишь при разработке документации.

Для оценки аналитики, выполняемой при Agile-подходе, нужен документ Vision (Видение), подтвержденный клиентом. Также нужно понимать размер команды проекта, его примерные границы, порядок распределения задач по аналитике и предполагаемый объем документации.

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

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

Оценка от экранов

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

# Простые

Состоят из одного-двух заполняемых полей, предполагают малую вариативную составляющую и малое число альтернативных сценариев. Пример — простая авторизация.

# Средние

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

# Сложные

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

Если экран кажется сложнее (например, дашборд с вариативностью), его при оценке «разбивают» на несколько экранов, либо оценивают, как модуль.

Оценка от модулей

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

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

Оценка дизайна

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

Для более точной оценки на основе предпроектного анализа понадобится больше информации:

1. наши кейсы, подтвержденные клиентом, либо ТЗ, которое описывает функционал по нотациям Babok
2. четкое понимание приоритетов разработки фич, платформ и разрешений экранов у команды и клиента
3. понимание у команды, для каких частей системы нужно разработать полноценный дизайн, а для каких — вайрфреймы
4. представление о том, будут ли использоваться в работе наши прототипы и их описания, подтвержденные клиентом, либо прототипы, разработанные UX специалистом со стороны клиента (в рамках требований Material design или iOS guidelines).

Чтобы создать дизайн проекта во время разработки ПО (в рамках Agile-подхода), команде потребуется документ Vision, подтвержденный клиентом. Мы уточняем предполагаемый объем задач, исходя из основных факторов: целевые платформы, разрешения экранов, адаптивность, необходимость дизайна для альтернативных сценариев. С учетом понимания бизнес-требований клиента определяем состав команды проекта и нагрузку.

При Agile-подходе обычно делается грубая оценка по крупным верхнеуровневым блокам. Размер чека, который команда получает в запланированный срок (например, раз в месяц) зависит от выработанных часов, а часы дизайнера — от объёма работы в указанный период.

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

Со стороны клиента стейкхолдерами обычно выступают собственники, руководители, акционеры, либо продакт-менеджер или другой сотрудник, ответственный за продукт внутри компании-заказчика. От IT-компании: разработчики, проджект-менеджеры, QA-специалисты.

Стейкхолдеры проекта помогают прояснить список, структуру, состав и качества требуемых артефактов. А чтобы разговор был предметным, и было легче понять, о каких артефактах идет речь, мы используем шаблоны и смысловые блоки, например, Роли-кейсы или Описание прототипов.

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

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

Заключение

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

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

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

Часто для подготовки оценки заданной детальности не хватает описания фактов. Нужна ли приложению интеграция с платежным сервисом? Планируется реализация под планшеты? Своевременный ответ на подобные вопросы повышает качество и глубину оценки и направляет нашу работу.

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

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