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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#web #mobile #разработка #analytics #аналитика #design #аутсорс