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

Обновлено: 20.05.2024

15 топ-менеджеров , которые вывели свои компании на лидирующие позиции в рейтинге ESG.

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

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

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

Какие тренды проявились в онлайне

Мобильный трафик безоговорочно преобладает

По данным SlickJump, в 2020 году он достиг 80% в рунете. Это окончательно оторвало пользователей от привычных десктопов и заменило традиционные приложения на их веб-аналоги.

Упростилось и ускорилось изменение IT-продуктов

Веб-сервисы, в отличие от традиционного ПО, позволяют вносить доработки так, чтобы все пользователи автоматически получали последнюю версию, не скачивая обновления. Это дает возможность быстро менять функционал IT-продуктов, добавлять и тестировать новые функции.

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

Изменились бизнес-модели целых отраслей

Компании запускают онлайн-каналы продвижения или полностью переходят в интернет.

Онлайн увеличил конкуренцию в бизнесе

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

Итого: конкуренция усиливается, а цикл обновления и жизни продукта сокращается.

И что это меняет?

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

1) Подход с первоначальным проектированием всего продукта не обеспечивает необходимых скорости и гибкости.

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

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

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

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

Поэтому мы включили в цикл нашей работы этапы проработки продукта. Парадокс, но выйти на рынок можно быстрее, если на старте, еще до составления ТЗ, дополнительно пройти шесть шагов. Именно так работают Agile-команды: движение короткими итерациями и конкретные результаты каждого этапа. Ниже мы проиллюстрируем эти шаги (и допущенные ошибки) на примере нашего собственного продукта.

Шаг 1. Видение продукта

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

В результате получится концепция, которая состоит из трех разделов:

Product Vision — развернутое описание продукта.
Product Roadmap — дорожная карта по разработке.
Market Requirements Document — рыночные требования: как продукт будет выглядеть и работать.

Пример

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

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

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

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

Шаг 2. Аналитика

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

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

Пример

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

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

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

Шаг 3. Генерация идей

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

список идей, отсортированный по значимости и данным Market Requirements Document. При отборе часто приходится опираться на интуицию;
при необходимости — изменения в Vision и Roadmap.

Пример

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

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

Шаг 4. Проверка гипотез

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

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

Если отработать процесс один-два раза, потом на этот этап будет уходить минимум времени.

Пример

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

Шаг 5. Формализация требований

На этом этапе составляют список функциональных требований к продукту — Product Requirements Document. Получится подробное описание функционала с кучей разных фич.

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

Пример

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

Шаг 6. Выделение MVP

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

На этом этапе выделяют:

описание рамок MVP (сценарии использования продукта, user stories — краткие требования к системе, написанные языком пользователя, а также функционал для первой итерации);
список метрик для оценки результатов.

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

Пример

Мы разработали MVP экспертной платформы с минимальным функционалом:

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

Клиент заполняет форму записи на консультацию.
Заявка попадает в Б24 к администратору платформы.
Он уточняет запрос и при необходимости помогает выбрать эксперта.
Согласует стоимость и время консультации с обеими сторонами.
Генерирует и отправляет клиенту ссылку на оплату.
После завершения консультации сумма за вычетом комиссии платформы перечисляется эксперту.

Наши факапы: что мы не учли и к чему это привело

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

Выделить время и собрать проектную команду

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

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

Тратить меньше ресурсов на работу с экспертами

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

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

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

Условно роли можно распределить между пятью функциональными направлениями

Управление цифровой трансформацией предусматривает роли лидеров цифровой трансформации — драйверов изменений, проводников политики цифровизации, которые руководят оптимизацией, реинжинирингом процессов, проектированием и созданием новых цифровых услуг и продуктов в системе государственного управления.

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

Руководитель по работе с данными (CDO)
Координирует процессы управления и использования данных, отвечает за обеспечение руководства качественными и полными данными для принятия управленческих решений.

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

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

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

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

Инженер данных
Участвует в создании аналитической платформы и прочих аналитических продуктов, обеспечивает разработку и поддержку ETL-процессов, управляет проектированием, созданием, тестированием и обслуживанием системы управления данными.

Исследователь данных (Data Scientist)
Извлекает из массива данных полезную информацию, строит алгоритмы обработки этих данных и автоматизирует процессы, подкрепляя свою работу научными обоснованиями.

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

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

Процессный аналитик
Проводит анализ, проектирование, оптимизацию, автоматизацию, внедрение, регламентирование и контроль процессов в организации.

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

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

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

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

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

Чья ноша тяжелее? И что случится, если один из Атлантов опустит руки?

Product Manager vs Project Manager

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

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

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

Основные обязанности менеджера продукта и менеджера проекта

Product Manager

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

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

Глобальная стратегия продукта
Выпуск релизов
Идеи и инициативы
Распределение приоритетов
Вопросы, связанные с прибылью и убытками
Исследования рынка
Конкурентная среда

Project Manager

Менеджер проекта обычно меньше ориентируются на конкретные цели продукта. Его главная ответственность — это сам проект. Project manager получает инициативы и функции продукта для разработки и утверждения таймлайна. В его ответственности — риски, потенциальные ограничения, ресурсы и масштаб задач.

Руководители проектов отвечают за:

Релизы
Ресурсы для проекта
Обновления и статусы
Бюджет проекта
Командное сотрудничество
Разрешение текущих проблем в рамках проекта

Кто важнее в иерархии компании?

Оба. И это иллюстрирует картинка с Атлантами. Если в вашей компании есть обе позиции, то у вас полный порядок с организационной структурой. Как понять, кто из менеджеров важнее?
Задайте себе два вопроса:

Может ли команда эффективно работать и получать результаты без менеджера продукта?
Что произойдет, если руководитель проекта покинет команду?

Инструменты и сервисы для менеджеров продуктов и менеджеров проектов

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

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

ПО для управления продуктами

Программное обеспечение для управления продуктами служит для отслеживания требований, документирования видения продукта, стратегии, определения приоритетов.

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

Управление бэклогом — еще одны функция, которую должен предлагать инструмент для управления продуктом. Визуализировать приоритетные задачи можно, например, с помощью графического отображения Backlog priority chart. Инструмент помогает оптимизировать приоритеты продуктов, определяя важные и менее важные задачи.

ПО для управления проектами

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

После того, как вы получите “зеленый свет”, чтобы начать проект, вы можете планировать все свои действия по разработке с помощью любой платформы для управления проектами.
PM-сервисы помогают фиксировать и совместно использовать задачи и подзадачи, сроки, необходимые активы и взаимодействие между членами команды.

Hygger предлагает полноценные возможности для менеджеров проектов от удобных Kanban и Scrum досок до отслеживания времени и отчетности по проектам.

Имидж профессионалов IT сферы в массовой культуре кардинально изменился за последние годы. Абсурдные стереотипы ушли в прошлое, а программисты стали настоящей элитой 2010-х.

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

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

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

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

Бизнес-аналитик

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

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

Но между целями клиента и функциями приложения лежит целая пропасть. Следовательно, бизнес-аналитик (сокращенно БA) должен точно определить, что хочет заказчик и что ему нужно.

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

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

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

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

Менеджер проекта

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

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

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

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

UI/UX дизайнер

Это тот человек, от которого идет большая часть креативности в проекте. Главная ответственность UI/UX дизайнера заключается в создании приятного интерфейса и отличного пользовательского опыта.

Дизайнер использует вайрфреймы, созданные клиентом или бизнес-аналитиком, чтобы “нарисовать” мокапы и создать дизайн интерфейса мобильного приложения (UI) согласно действующим гайдлайнам и трендам. Он также планирует пользовательский опыт, который сделает продукт удобным для использования.

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

Клиенту удобно видеть модель приложения, а программистам прототип просто необходим, чтобы написать код. Это как дизайн-проект комнаты для профессионалов, которые будут её декорировать — необходимо видеть, что должно получиться в результате работы. Наши дизайнеры в Smartum Pro также предоставляют графические элементы для магазинов приложений, мокапы и логотипы.

Разработчики/программисты

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

Существуют различные уровни в команде разработчиков программного обеспечения, включающие junior, middle и senior уровни, которые зависят от опыта работы и уровня экспертизы.

Программисты также имеют различные области экспертизы, они пишут на различных языках и работают с различными платформами. Поэтому и существует такое “разнообразие” разработчиков, вовлеченных в один проект. Например, стандартный проект разработки мобильного приложения требует участия как минимум Android, iOS и backend-разработчиков.

QA (Quality Assurance) специалисты необходимы для каждого процесса разработки и обеспечения высокого качества продукта. Они тестируют его, проходят через все приложение и определяют баги и ошибки с последующим предоставлением отчета команде разработки, которая проводит их исправление.

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

Специалист по маркетингу

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

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

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

Суммируя все вышесказанное, стоит отметить то, что команда разработки программного обеспечения — это не только программисты.

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

Читайте также: