Концепция IT-продукта. Зачем она нужна, и как мы ее разрабатываем

Концепция IT-продукта. Зачем она нужна, и как мы ее разрабатываем

В одной из наших статей мы уже писали про цели и преимущества бизнес-анализа. В новой серии материалов мы подробно опишем этапы и особенности его проведения. Сегодня начнем с рассказа про разработку концепции IT-продукта. 

О чем эта статья

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

Основные характеристики концепции IT-продукта

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

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

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

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

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

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

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

Как составить концепцию продукта

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

На следующих схемах мы проиллюстрировали как Canvas использовалась при разработке системы управления заявками (см. подробное описание ниже).

Процесс составления концепции продукта проходит следующие этапы:

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

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

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

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

Расчет доходов и расходов. Еще одним важным этапом является анализ потенциальных доходов и расходов от реализации проекта. Эта часть создания концепции полностью лежит на плечах заказчика и не влияет на команду разработки.  

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

Влияние заказчика на реализацию проекта на примере разработки системы управления заявками

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

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

Проблема. После сбора требований становится понятно, что сложность процесса для заказчика — это наличие большого количества шагов (каждый шаг для действия одного лица в процессе согласования и исполнения задачи). С точки зрения системы процесс простой, но имеет много шагов, что на разработку не влияет. В этом случае принимается решение не реализовывать BPMN-движок, потому что он требует выбора стороннего ПО, интеграции с ним, либо разработки собственного, что значительно увеличивает сроки и стоимость проекта.

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

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

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