Строительство дома начинается с закладки фундамента. Неважно, из какого материала его построят, и в какой цвет выкрасят, фундамент должен правильно распределить нагрузку на грунт. Это то, с чего всё начинается, и что потенциально может стать причиной досрочного разрушения дома.
Очень похоже на роль аналитики при разработке IT-продукта. Стоит её провести некачественно, и посыпется всё: сроки, бюджеты, системные требования, ожидания vs реальность. Основательно проведенная аналитика в IT, как надежный фундамент, ведет к разработке востребованного продукта.
В этой статье наша команда расскажет, в чем ценность аналитики в сфере IT на разных этапах создания продуктов, и как она напрямую влияет на длительность, стоимость и качество разработки.
Зачем нужна аналитика IT проектов и какие возникают проблемы если ее пропустить
Клиенты не всегда понимают, для чего нужна аналитика на проектах, зачем за неё платить, и что она в принципе дает при разработке. Опытных аналитиков это не удивляет. У заказчика может не быть технического бэкграунда, представления о том, что дает этот этап разработки. Особенно, если клиент обратился к разработчикам впервые и еще не знает, что необходимо учитывать при запуске MVP-версии продукта, как работать с бэклогом функциональностей и концепцией развития проекта.
Допустим, компания обратилась к разработчикам за созданием сайта, но решила сэкономить на аналитике и не стала её заказывать, как услугу:
Проект запущен в работу. Дизайнер начинает заниматься созданием элементов интерфейса на основе пожеланий клиента. К работе на проекте приступает разработчик. Изучив макеты, он вдруг понимает, что в дизайне отображается фронтенд, а как происходит взаимодействие с бэком, непонятно. В макетах не учтены многие технические ограничения и пользовательские сценарии, заранее оговоренные требования клиента.
Начинаются проблемы. Нужно не только переделать дизайн, но и подождать, пока его согласуют, а затем повторно вернуться к разработке. Сроки сдвигаются, часть уже готовой работы летит в помойку, бюджет проекта растет. Клиенту неприятно, тратятся и его время, и нервы. А как легко было это не допустить!
Notamedia подключает аналитиков к работе на каждом из этапов разработки. Почему это важно: идеи и функциональности, заложенные в проект на старте, не должны потеряться при реализации. Аналитики отслеживают, сохранилась ли правильная логика взаимодействия между экранами, учтены ли все пользовательские сценарии, не потерялось ли понимание бизнес-целей.
Мы считаем максимально важным помнить о клиентоориентированности в ходе разработки. Проекты создаются не для того, чтобы потратить бюджет заказчика и время разработчиков, а чтобы найти решение под самые острые запросы целевой аудитории и предоставить лучший клиентский опыт.
Работа аналитиков на проекте начинается с дискавери
При запуске любого проекта важно проводить фазу дискавери — предпроектную аналитику. Она позволяет сформировать глубокое понимание целевого рынка, специфики отрасли, бизнес-целей клиента, однозначно понять требования к продукту и выявить потребности целевой аудитории. Фаза дискавери соединяет глобальное (задачи, стоящие перед компанией клиента) с локальным (поведение пользователя системы).
«На этапе предпроектного анализа клиент и команда разработки должны определить все системные требования и пожелания, исследовать рынок, на котором появится продукт, выявить потребности целевой аудитории, задачи бизнеса и установить рамки продукта.
Если пропустить или недооценить эту работу, велика вероятность, что между клиентом и командой разработки возникнет недопонимание по списку задач на проекте. Разработчики могут промахнуться с итоговой оценкой, что приведет к потенциальному срыву бюджета и срока релиза».
Иван Мрачко, аналитик Notamedia.Agency
На этапе предпроектного анализа команда должна сформировать глубокое понимание ожиданий клиента и пользователей проекта. А клиент получает техническое предложение, которое разработано с учетом потребностей бизнеса, его пожеланий и требований к программному продукту.
На этапе дискавери команда Notamedia:
1) Описание бизнес-модели включает в себя анализ и схематичное описание всех взаимосвязанных бизнес-процессов компании (от УТП и потребителей до финансов, канала сбыта и инфраструктуры). Показывает, что, кому и как продает клиент, и насколько это выгодно.
2) Концепция продукта позволяет создать видение продукта и согласовать его, разложить все вводные данные, получить рамки продукта и разделить его на этапы, оценить сроки и стоимость. Она отвечает на вопрос, а может ли команда в принципе сделать то, о чем попросил клиент. В концепции фиксируются все требования бизнеса, включая нефункциональные. Для каждого проекта формируется своя уникальная концепция. Чаще всего она выглядит, как функциональное описание. Этого достаточно, если нет результатов продуктовых исследований, не проводился конкурентный анализ, сбор гипотез и т.д.
3) CJM — это наглядная схема взаимодействия пользователя с продуктом. Представляет собой визуализированный опыт пользователя с учетом его настроения, целей и мотивов на пути получения результата в сочетании со всеми каналами и точками взаимодействия с продуктом. CJM позволяет понять узкие места в продукте, потенциальные проблемы и найти решения.
Это комплексная работа по исследованию пользовательского опыта, результатом которой становится правильно выстроенный клиентский путь. При подготовке CJM аналитики внимательно изучают отдельные сегменты целевой аудитории, создавая индивидуальные “портреты” пользователей.
4) User Stories — это описание функциональных требований к системе и критериев приёмки системы. Это коротко сформулированные намерения, рассказывающие, что система делает для пользователя. Они объясняют роль пользователя, его действия в системе, потребности, и как они закрываются. User Stories помогает посмотреть на систему целиком, выявить слабые стороны и реализовать продукт, как задумано изначально. Во время тестирования User Stories могут использоваться QA-инженерами для проверки продукта.
5) User Flow выглядит, как схематическое изображение экранов продукта и переходов между ними, показывающее сценарии взаимодействия с интерфейсом. Это понятная последовательность действий от шага к шагу, которую выполнит пользователь, чтобы достигнуть значимую цель на сайте или в приложении. User Flow помогает разработчикам сфокусироваться на создании интуитивно понятного интерфейса, который решает стоящие задачи.
6) Глубинное интервью — качественный метод исследования, предполагающий интервью с представителями целевой аудитории или пользователями решений, которые предлагают конкуренты. Позволяет лучше понять проблемы, ожидания, хотелки, запросы людей, для которых создается новый продукт. Благодаря глубинным интервью можно узнать не только отношение пользователя к тому или иному продукту, но и его прошлый пользовательский опыт, интересы и мотивацию. Это помогает разработать такое решение, которое привлекает целевую аудиторию.
7) Конкурентное исследование проводится, чтобы изучить решения конкурентов, определить их сильные и слабые стороны и выявить, чего не хватает пользователям. Можно закрыть эти потребности, предложив рынку новый продукт. В рамках конкурентного исследования существующие предложения анализируются и с технической точки зрения, и с концептуальной.
8) Пользовательские опросы позволяют проанализировать эффективность и юзабилити продукта, выявить потенциальные проблемы и возможности развития. Благодаря пользовательским опросам можно выявить, какой процент пользователей сталкивается с проблемами, получить количественные данные об их интересах и предпочтениях и проверить гипотезы, которые появились по итогам качественных исследований.
9) Backlog продукта — список рабочих задач для разработчиков, в котором содержатся приоритеты и сроки внедрения различных функциональностей. Бэклог составляется на основе road map и требований из него. Он показывает, с чего стартовать, и куда далее развивать продукт. Например, на этапе создания MVP в бэклог закладывается первичное наполнение продукта и его функции.
10) Другие методы исследований. Также при проведении фазы дискавери команда может проводить другие дополнительные методы исследований, как качественные, так и количественные. Это и фокус-группы, и айтрекинг, и A/B тестирование, и наблюдения, и другие типы исследований.
Чем полезно проведение фазы дискавери на проекте:
Некоторым клиентам кажется, что фаза дискавери усложняет разработку и повышает бюджет проекта. Но это не так: при этом подходе часть работ по аналитике проводится на первоначальном этапе, а не в ходе разработки. Как следствие, с самого начала разработки проекта команда глубже понимает стоящие задачи и выполняет их более эффективно.
Как Notamedia работает на этапе дискавери? Рассказываем на примере одного из проектов
Во время этапа предпроектной аналитики команда разработки организовала исследование решений конкурентов. Мы изучали их продукты, оценивая их сильные и слабые стороны и ключевые особенности. Далее была организована серия глубинных интервью с пользователями существующего продукта от нашего клиента. Эти интервью позволили выявить боли, ожидания и проблемы целевой аудитории. Благодаря этому за основу УТП было взято то, чего хотят пользователи.
Мы провели количественное исследование в формате опросов по пользовательской базе. Оно позволило понять, как часто у пользователей возникают проблемы, и правильно ли мы составили список гипотез о решении.
Этот подход позволил нам определить список потребностей и ожиданий целевой аудитории, о которых наш клиент не знал, или его представление отличалось от реальной картины.
На основе результатов количественных исследований мы создали бэклог со списком функциональностей, которые нужно добавить в продукт. Далее мы приоретизировали этот список. Наиболее приоритетные функции будут реализованы первыми, остальные — постепенно, по мере развития решения.
Работа аналитиков отражается на прототипах и разработке
Во время этапа проектирования команда проектирует прототип интерфейса приложения или сайта на основе информации, собранной аналитиками на фазе дискавери. Клиенту демонстрируется логика интерфейса будущего приложения.
Команда Notamedia на этом этапе показывает заказчику высокодетализированные черно-белые интерфейсы будущей системы. Согласование прототипов в этом формате помогает обсудить логику и структуру будущего продукта с клиентом, не отвлекаясь на визуальные составляющие.
Так что на одном предпроектном анализе участие аналитика в разработке не заканчивается, он вовлечен во все оставшиеся этапы.
Изменения на этапе аналитики внести легче, но они влияют на судьбу проекта
Работа аналитика в IT помогает соединить требования бизнеса с пожеланиями пользователей и корректно отразить их при разработке сайтов и приложений. Проведение аналитики обеспечивает однозначное понимание, что надо разработать, кем и как это будет использоваться и в каком контексте. В этом плане аналитик похож на переводчика. Только он переводит не зарубежные тексты, а пожелания клиентов на язык разработки программных решений.
Хотя изменения на этапе аналитики внести легче и менее проблемно, чем на других этапах разработки, это может повлиять на весь проект целиком: от его видения до сроков, бюджета и образа реализации.
Итак, кто такой аналитик в IT сфере? Это человек, чья работа позволяет получить наглядную концепцию по проекту, протестировать бизнес-идеи и подумать о будущем проекта. А самое главное — снизить риск ошибок при его разработке.
Команда Notamedia рекомендует клиентам максимально серьезно относиться к проведению аналитики и плотно взаимодействовать с разработчиками на этом этапе. Мы работаем на рынке уже 19-й год и по опыту заказчиков и коллег знаем, к чему приводит ее отсутствие.
Аналитика продукта нужна и потому, что лучше вовремя скорректировать его концепцию и планы развития, отказаться от лишних наворотов или поменять список функций, чем прийти к этому, когда продукт пора выводить на рынок, а бюджет исчерпан.
Очень похоже на роль аналитики при разработке IT-продукта. Стоит её провести некачественно, и посыпется всё: сроки, бюджеты, системные требования, ожидания vs реальность. Основательно проведенная аналитика в IT, как надежный фундамент, ведет к разработке востребованного продукта.
В этой статье наша команда расскажет, в чем ценность аналитики в сфере IT на разных этапах создания продуктов, и как она напрямую влияет на длительность, стоимость и качество разработки.
Зачем нужна аналитика IT проектов и какие возникают проблемы если ее пропустить
Клиенты не всегда понимают, для чего нужна аналитика на проектах, зачем за неё платить, и что она в принципе дает при разработке. Опытных аналитиков это не удивляет. У заказчика может не быть технического бэкграунда, представления о том, что дает этот этап разработки. Особенно, если клиент обратился к разработчикам впервые и еще не знает, что необходимо учитывать при запуске MVP-версии продукта, как работать с бэклогом функциональностей и концепцией развития проекта.
Допустим, компания обратилась к разработчикам за созданием сайта, но решила сэкономить на аналитике и не стала её заказывать, как услугу:
Проект запущен в работу. Дизайнер начинает заниматься созданием элементов интерфейса на основе пожеланий клиента. К работе на проекте приступает разработчик. Изучив макеты, он вдруг понимает, что в дизайне отображается фронтенд, а как происходит взаимодействие с бэком, непонятно. В макетах не учтены многие технические ограничения и пользовательские сценарии, заранее оговоренные требования клиента.
Начинаются проблемы. Нужно не только переделать дизайн, но и подождать, пока его согласуют, а затем повторно вернуться к разработке. Сроки сдвигаются, часть уже готовой работы летит в помойку, бюджет проекта растет. Клиенту неприятно, тратятся и его время, и нервы. А как легко было это не допустить!
Такой этап, как аналитика в IT, длится недолго, предполагает небольшой (но очень важный) объем работ, а стоит для клиента на порядок дешевле, чем дизайн и разработка продукта.
Однако это не мешает тому, что в IT аналитика отражается на каждом из этапов создания решения. Работа аналитиков позволяет разработать IT-продукт, который отвечает всем требованиям и пожеланиям клиента, соответствует его бизнес-целям и учитывает интересы, проблемы и ожидания целевой аудитории.Notamedia подключает аналитиков к работе на каждом из этапов разработки. Почему это важно: идеи и функциональности, заложенные в проект на старте, не должны потеряться при реализации. Аналитики отслеживают, сохранилась ли правильная логика взаимодействия между экранами, учтены ли все пользовательские сценарии, не потерялось ли понимание бизнес-целей.
Мы считаем максимально важным помнить о клиентоориентированности в ходе разработки. Проекты создаются не для того, чтобы потратить бюджет заказчика и время разработчиков, а чтобы найти решение под самые острые запросы целевой аудитории и предоставить лучший клиентский опыт.
Работа аналитиков на проекте начинается с дискавери
При запуске любого проекта важно проводить фазу дискавери — предпроектную аналитику. Она позволяет сформировать глубокое понимание целевого рынка, специфики отрасли, бизнес-целей клиента, однозначно понять требования к продукту и выявить потребности целевой аудитории. Фаза дискавери соединяет глобальное (задачи, стоящие перед компанией клиента) с локальным (поведение пользователя системы).
«На этапе предпроектного анализа клиент и команда разработки должны определить все системные требования и пожелания, исследовать рынок, на котором появится продукт, выявить потребности целевой аудитории, задачи бизнеса и установить рамки продукта.
Если пропустить или недооценить эту работу, велика вероятность, что между клиентом и командой разработки возникнет недопонимание по списку задач на проекте. Разработчики могут промахнуться с итоговой оценкой, что приведет к потенциальному срыву бюджета и срока релиза».
Иван Мрачко, аналитик Notamedia.Agency
На этапе предпроектного анализа команда должна сформировать глубокое понимание ожиданий клиента и пользователей проекта. А клиент получает техническое предложение, которое разработано с учетом потребностей бизнеса, его пожеланий и требований к программному продукту.
На этапе дискавери команда Notamedia:
- подготавливает план выполнения задач в рамках проекта,
- фиксирует, какой список работ и за какое время будет сделан,
- определяет цели, проблемы, ожидание пользователей,
- проясняет, в каких контекстах будет происходить использование продукта,
- исследует, какие аналогичные решения есть на профильном рынке.
1) Описание бизнес-модели включает в себя анализ и схематичное описание всех взаимосвязанных бизнес-процессов компании (от УТП и потребителей до финансов, канала сбыта и инфраструктуры). Показывает, что, кому и как продает клиент, и насколько это выгодно.
2) Концепция продукта позволяет создать видение продукта и согласовать его, разложить все вводные данные, получить рамки продукта и разделить его на этапы, оценить сроки и стоимость. Она отвечает на вопрос, а может ли команда в принципе сделать то, о чем попросил клиент. В концепции фиксируются все требования бизнеса, включая нефункциональные. Для каждого проекта формируется своя уникальная концепция. Чаще всего она выглядит, как функциональное описание. Этого достаточно, если нет результатов продуктовых исследований, не проводился конкурентный анализ, сбор гипотез и т.д.
3) CJM — это наглядная схема взаимодействия пользователя с продуктом. Представляет собой визуализированный опыт пользователя с учетом его настроения, целей и мотивов на пути получения результата в сочетании со всеми каналами и точками взаимодействия с продуктом. CJM позволяет понять узкие места в продукте, потенциальные проблемы и найти решения.
Это комплексная работа по исследованию пользовательского опыта, результатом которой становится правильно выстроенный клиентский путь. При подготовке CJM аналитики внимательно изучают отдельные сегменты целевой аудитории, создавая индивидуальные “портреты” пользователей.
4) User Stories — это описание функциональных требований к системе и критериев приёмки системы. Это коротко сформулированные намерения, рассказывающие, что система делает для пользователя. Они объясняют роль пользователя, его действия в системе, потребности, и как они закрываются. User Stories помогает посмотреть на систему целиком, выявить слабые стороны и реализовать продукт, как задумано изначально. Во время тестирования User Stories могут использоваться QA-инженерами для проверки продукта.
5) User Flow выглядит, как схематическое изображение экранов продукта и переходов между ними, показывающее сценарии взаимодействия с интерфейсом. Это понятная последовательность действий от шага к шагу, которую выполнит пользователь, чтобы достигнуть значимую цель на сайте или в приложении. User Flow помогает разработчикам сфокусироваться на создании интуитивно понятного интерфейса, который решает стоящие задачи.
6) Глубинное интервью — качественный метод исследования, предполагающий интервью с представителями целевой аудитории или пользователями решений, которые предлагают конкуренты. Позволяет лучше понять проблемы, ожидания, хотелки, запросы людей, для которых создается новый продукт. Благодаря глубинным интервью можно узнать не только отношение пользователя к тому или иному продукту, но и его прошлый пользовательский опыт, интересы и мотивацию. Это помогает разработать такое решение, которое привлекает целевую аудиторию.
7) Конкурентное исследование проводится, чтобы изучить решения конкурентов, определить их сильные и слабые стороны и выявить, чего не хватает пользователям. Можно закрыть эти потребности, предложив рынку новый продукт. В рамках конкурентного исследования существующие предложения анализируются и с технической точки зрения, и с концептуальной.
8) Пользовательские опросы позволяют проанализировать эффективность и юзабилити продукта, выявить потенциальные проблемы и возможности развития. Благодаря пользовательским опросам можно выявить, какой процент пользователей сталкивается с проблемами, получить количественные данные об их интересах и предпочтениях и проверить гипотезы, которые появились по итогам качественных исследований.
9) Backlog продукта — список рабочих задач для разработчиков, в котором содержатся приоритеты и сроки внедрения различных функциональностей. Бэклог составляется на основе road map и требований из него. Он показывает, с чего стартовать, и куда далее развивать продукт. Например, на этапе создания MVP в бэклог закладывается первичное наполнение продукта и его функции.
10) Другие методы исследований. Также при проведении фазы дискавери команда может проводить другие дополнительные методы исследований, как качественные, так и количественные. Это и фокус-группы, и айтрекинг, и A/B тестирование, и наблюдения, и другие типы исследований.
Чем полезно проведение фазы дискавери на проекте:
- Мы выявляем аспекты продукта, которые не учитывались первоначально, и проверяем концепцию на основе анализа данных по проекту.
- Через исследование конкурентов и их решений можно глубоко понять боли и ожидания целевой аудитории.
- Можно сократить возможный объем правок и изменений при разработке и существенно сэкономить бюджет клиента.
- Удается объединить бизнес-цели клиента и интересы пользователей.
- Проект получает детальное техническое описание, появляется возможность более реалистично оценить сроки и бюджет на разработку.
- Заказчик и команда разработки приходят к общему пониманию того, как будет устроен, и какой внешний вид будет иметь продукт, и с какими целями он создается.
Часто клиенты обращаются в digital-агентства с документами, содержащими недостаточно информации о том, что им нужно от разработчиков и зачем.
Особенно это касается бизнес-целей и общего понимания, какой продукт должен появиться на рынке, и чем он будет отличаться от существующих. При проведении дискавери аналитики выясняют: что нужно бизнесу, какие у него реальные цели, и что поможет добиться их исполнения.Некоторым клиентам кажется, что фаза дискавери усложняет разработку и повышает бюджет проекта. Но это не так: при этом подходе часть работ по аналитике проводится на первоначальном этапе, а не в ходе разработки. Как следствие, с самого начала разработки проекта команда глубже понимает стоящие задачи и выполняет их более эффективно.
Как Notamedia работает на этапе дискавери? Рассказываем на примере одного из проектов
Во время этапа предпроектной аналитики команда разработки организовала исследование решений конкурентов. Мы изучали их продукты, оценивая их сильные и слабые стороны и ключевые особенности. Далее была организована серия глубинных интервью с пользователями существующего продукта от нашего клиента. Эти интервью позволили выявить боли, ожидания и проблемы целевой аудитории. Благодаря этому за основу УТП было взято то, чего хотят пользователи.
Мы провели количественное исследование в формате опросов по пользовательской базе. Оно позволило понять, как часто у пользователей возникают проблемы, и правильно ли мы составили список гипотез о решении.
Этот подход позволил нам определить список потребностей и ожиданий целевой аудитории, о которых наш клиент не знал, или его представление отличалось от реальной картины.
На основе результатов количественных исследований мы создали бэклог со списком функциональностей, которые нужно добавить в продукт. Далее мы приоретизировали этот список. Наиболее приоритетные функции будут реализованы первыми, остальные — постепенно, по мере развития решения.
Работа аналитиков отражается на прототипах и разработке
Во время этапа проектирования команда проектирует прототип интерфейса приложения или сайта на основе информации, собранной аналитиками на фазе дискавери. Клиенту демонстрируется логика интерфейса будущего приложения.
Команда Notamedia на этом этапе показывает заказчику высокодетализированные черно-белые интерфейсы будущей системы. Согласование прототипов в этом формате помогает обсудить логику и структуру будущего продукта с клиентом, не отвлекаясь на визуальные составляющие.
В ходе проектирования команда продумывает процессы взаимодействия пользователя и нового продукта на основе сформированных аналитиками артефактов (концепция, user flow, CJM, user stories и т.д.).
Во время проведения этапов разработки дизайна, верстки и написания кода аналитики тоже участвуют в рабочих процессах. Задачи аналитика в команде it проекта на этих этапах — отследить, насколько соблюдаются предварительно согласованные системные требования к продукту, проверить его соответствие бизнес-целям клиента.Так что на одном предпроектном анализе участие аналитика в разработке не заканчивается, он вовлечен во все оставшиеся этапы.
Изменения на этапе аналитики внести легче, но они влияют на судьбу проекта
Работа аналитика в IT помогает соединить требования бизнеса с пожеланиями пользователей и корректно отразить их при разработке сайтов и приложений. Проведение аналитики обеспечивает однозначное понимание, что надо разработать, кем и как это будет использоваться и в каком контексте. В этом плане аналитик похож на переводчика. Только он переводит не зарубежные тексты, а пожелания клиентов на язык разработки программных решений.
Хотя изменения на этапе аналитики внести легче и менее проблемно, чем на других этапах разработки, это может повлиять на весь проект целиком: от его видения до сроков, бюджета и образа реализации.
Итак, кто такой аналитик в IT сфере? Это человек, чья работа позволяет получить наглядную концепцию по проекту, протестировать бизнес-идеи и подумать о будущем проекта. А самое главное — снизить риск ошибок при его разработке.
Команда Notamedia рекомендует клиентам максимально серьезно относиться к проведению аналитики и плотно взаимодействовать с разработчиками на этом этапе. Мы работаем на рынке уже 19-й год и по опыту заказчиков и коллег знаем, к чему приводит ее отсутствие.
Аналитика продукта нужна и потому, что лучше вовремя скорректировать его концепцию и планы развития, отказаться от лишних наворотов или поменять список функций, чем прийти к этому, когда продукт пора выводить на рынок, а бюджет исчерпан.