Сегодня цифровые продукты конкурируют за внимание и деньги пользователей и покупателей, которые избалованы качественными цифровыми сервисами и приложениями. Крупные IT-корпорации, такие как Apple, Google, Facebook, Amazon, «Яндекс» задают высокий уровень стандартов качества своих приложений, поэтому для того, чтобы продукт смог занять достойное место среди цифровых сервисов, команде нужно очень сильно постараться и вложить серьезные ресурсы в проект.
Еще одна особенность цифровых продуктов в том, что они, равно как и требования к ним, быстро меняются и устаревают. В связи с этим становятся востребованными такие модели работы, которые отвечают требованиям по скорости изменений, их внедрению и выведению на рынок.
При подготовке к созданию цифрового продукта необходимо учитывать как требования потенциальных пользователей, так и заказчика. С одной стороны, продукт должен решать существующую задачу, потребность или проблему пользователя или компании, если продукт направлен на b2b-аудиторию. С другой стороны, он должен решать реально существующие задачи целевой аудитории таким образом, чтобы экономика проекта (Unit-экономика, метрики вовлеченности и Lifetime Value и другие показатели) отражали целесообразность его создания.
Еще один важный фактор, который оказывает колоссальное влияние на успех продукта – выстроенная коммуникация между членами команды. От нее зависит скорость выхода проекта на рынок, его качество, рентабельность и удовлетворенность пользователей.
4 ошибки компаний, которые пытаются донести IT-команде видение по цифровому продукту
1. Размытые требования к продукту
Часто заказчики выступают в режиме визионеров и авторов идеи продукта. Как правило, он имеет размытое очертание из-за того, что заказчик представляет продукт в целом. Однако для того, чтобы перейти от идеи к реализации, нужно провести серьезную работу по декомпозиции проекта на конкретные действия, которые позволят оценить продукт с точки зрения финансовых, человеческих и временных ресурсов. Поэтому размытые требования – частая ошибка на раннем этапе работы над продуктом. Однако если видение декомпозируется на более четкие детали, оно может стать точкой роста проекта.
2. Отсутствие в команде аналитика или попытка создать продукт без него
Аналитик или бизнес-аналитик может участвовать в команде проекта либо со стороны заказчика, либо со стороны IT-команды. Зачастую аналитик переводит пожелания клиента в конкретные задачи разработчиков при создании продукта. Часто эту функцию могут выполнять продакт-менеджеры или менеджеры проектов. Типичная ошибка – попытка сформулировать видение продукта и оценивать его сразу с разработчиками. Если аналитика нет, то в проекте, скорее всего, будут проблемы.
3. Разработка продукта по требованиям руководителей, а не потребителей
Еще одна частая ошибка – ситуация, когда цифровой продукт создается по требованиям заказчика разработки, а не пользователей конечного продукта. Это распространенная ошибка, в том числе заказчиков и клиентов с большим количеством ресурсов и денег. Как правило, такие проекты оказываются невостребованными на рынке. В некоторых случаях уровень востребованности оказывается ниже ожидаемого с точки зрения экономики и финансовой модели проекта.
4. Жесткие временные и финансовые рамки проекта
Суть ошибки заключается в том, что менеджмент, заказчики или руководство пытаются поставить проект в жесткие рамки по срокам, бюджету и конфигурации участников команды разработки, не понимая реального объема работ. Обычно если цифровой продукт идет по такому сценарию, в 99% случаев он выходит за границы бюджета и сроков из-за того, что нужно выполнить гораздо больше работы, чем предполагалось изначально.
В том случае, если проект вписывается в бюджет и сроки, как правило, он оказывается недоработан, потому что при разработке проекта команда четко придерживалась обозначенных финансовых и временных ограничений.
Основные риски при разработке цифрового продукта
Основные риски связаны с выходом за обозначенные заказчиком рамки в виде сроков, бюджета, качества и требуемого функционала. Избежать этих рисков можно при выстроенной коммуникации с командой разработки и при выборе оптимальной модели работы. В том случае, если в проекте много неизвестных, касающихся цифрового продукта, команде следует выбрать итеративный подход, когда работа над продуктом разбивается на мини-проекты, которые выполняются в обозримые сроки. Обычно это 1-2 недели или месяц. Затем команда анализирует итоги одной итерации и продолжает работу.
Если команда хочет поставить проект в рамки по бюджету, срокам и качеству, необходимо написать всю документацию заранее на старте проекта, чтобы разработчикам был четко понятен объем функционала, выполнение которого они берут на себя. В таком случае можно придерживаться модели фиксированного бюджета.
Основные правила коммуникации с командой разработки
Основной принцип коммуникации – регулярность встреч, которые могут проводиться онлайн в Skype, Zoom, Google Meet и на других платформах. В начале работы необходимо подготовить документацию с требованиями к продукту, из которой сформировать так называемую базу знаний проекта. Для организации базы знаний можно использовать приложения, предоставляющие такие компоненты, как базы данных, доски канбан, календари и напоминания (например, Notion).
В отличие от классической практики, когда формировалось большое техническое задание в виде объемного документа, работу с требованиями по цифровым продуктам целесообразно выстраивать в Notion в виде таблицы, календаря или канбан-доски. В этом случае техническое задание разбивается на десятки, сотни или тысячи требований, каждое из которых оформляется в отдельной карточке. В результате получается система карточек, таблиц или канбан-досок, в которых документируются требования к продукту, прикрепляются различные данные, ссылки и комментарии разработчиков. Все это позволяет работать с большим объемом требований, в том числе с версионностью, когда требования к продукту меняются.
При подготовке документации к цифровому продукту можно использовать как классические подходы к разработке программного обеспечения, так и более современные, «продуктовые» подходы.
Классические подходы, как правило, используются на стадии проектирования и тестирования программного обеспечения. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выявление потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификацию (документирование требований) и проверку правильности.
К продуктовым подходам можно отнести такие подходы, как Jobs-to-be-done, Customer Journey Mapping, Lean Canvas.
Jobs to be Done — это подход, который помогает понять, как и почему люди принимают решение о первой покупке продукта. Этот подход позволяет прогнозировать, какой продукт будет востребован на рынке, а какой — нет.
Customer Journey Mapping – «карта пути клиента», в которой описаны точки контакта потребителя с компанией, его эмоции, действия, проблемы, а также чего не хватает для того, чтобы воспользоваться продуктом.
Lean Canvas – это таблица из девяти блоков, которая позволяет сжать большой план запуска нового продукта до одной страницы. Таблица состоит из следующих блоков:
- Целевая аудитория.
- Проблема и альтернативные решения.
- Уникальная ценность продукта.
- Как продукт решит проблемы?
- Способы продвижения.
- Как продукт принесет доход?
- На что тратим деньги?
- Ключевые показатели.
- Скрытое преимущество.
Если команда начинает действовать в продуктовом подходе, дальше она разбивает масштабные задачи на несколько более мелких, которые прописываются в таск-менеджере – приложении для фиксации задач. По каждой задаче можно установить время на ее выполнение. Впоследствии задачи из таск-менеджера можно использовать для подготовки отчета для заказчика по работе над проектом.
Грамотный современный подход к коммуникации в проекте между заказчиком или клиентом и командой разработки является основой успеха разработки современного цифрового продукта и вывода его на рынок.
Читайте также:
Всегда полезно получить набор высококвалифицированных рекомендаций от разбирающегося в проблематике человека.