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

Привет! Я Вениамин Мустафин, директор по развитию компании fuse8. Мы строим свою экспертизу на создании цифровых продуктов для бизнеса и делимся наработками через контент. На мой взгляд, продуктовое проектирование – часть проекта настолько же важная, как и разработка. Одно без другого существовать не может. Поэтому в этой и других будущих статьях хочу рассказать о процессах, предшествующих разработке и делающих ее прозрачнее для заказчиков и команды. В прошлой статье говорил про USM – заходите почитать :)

Клиент, знает, чего хочет, но этого недостаточно

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

Команда разработки, видя такой «список покупок», часто считает, что клиент – эксперт в своем бизнесе, поэтому можно следовать этим требованиям буквально. Но на практике, если команда разработки не вовлечена в обсуждение целей, ее работа сводится к выполнению задач по принципу «сделай то, что сказано». И тут команда превращается в группу исполнителей, а не партнеров. В результате создается продукт, который «работает по ТЗ», но не обязательно помогает бизнесу.

По-настоящему сильная команда разработки не просто «выполняет задачи», а работает на достижение целей продукта. Чтобы это стало возможным, с самого начала погружаем команду в стратегические цели, помогаем видеть продукт целиком и даем почву для проверки гипотез. Так получается не только решать задачи, но и генерировать идеи для улучшения продукта. Это и отличает команду исполнителей от команды создателей.

Почему цели важнее списка фич?

Фокус на результате, а не на задачах

Представьте, что вы запускаете сервис для банка. Можно сказать: «Сделайте кредитный калькулятор», а можно поставить цель: «Увеличить количество заполненных анкет на сайте в два раза». В первом случае команда просто выполняет задачу, не углубляясь в суть. Во втором – она фокусируется на результате и начинает предлагать решения, которые действительно помогут достичь цели. Разница в уровне погружения – колоссальная.

Приоритеты определяются целями

В разработке всегда наступает момент, когда становится понятно, что выполнить всё задуманное в срок невозможно. Если нет целей, задачи, которые придуманы без привязки к чему-либо, могут быть мертворожденными. Начинается хаос: что отложить, а что сделать? Кто-то решает это на основе интуиции, но это плохая валидация. Цели и метрики нужны, чтобы вычленить главное. Иначе начинается субъективизация – разные ЛПРы говорят: «Ну вот это уж точно надо внедрить», и у каждого «вот это» разное. При наличии оформленных целей, проще решить, какие задачи критичны для достижения успеха, а какие можно отложить или вовсе убрать.

Ответственность делится между клиентом и командой

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

Цена незафиксированных целей: как потратить время впустую

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

Что произошло

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

Но когда аналитик возвращается к клиенту за уточнениями, звучит неожиданное:

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

Результат стараний

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

Как стоило сделать

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

• Что сейчас вызывает наибольшие сложности у пользователей?

• Каковы основные жалобы или пожелания?

• Какие задачи критичны сейчас?

• Какие из них можно отложить на потом?

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

Чему это нас учит?

Формулирование целей в продукте – процесс общий, где одинаково вовлечены должны быть и заказчик, и исполнитель. В интересах второго максимально полно «вытянуть» из заказчика ожидания, чтобы эффективно приоритезировать задачи. 

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

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

Базовый ответ на этот вопрос: формулируйте по SMART. Правильная цель должна быть конкретна, измерима, достижима, релевантна и привязана ко времени. Но эти характеристики не всегда получается применить в полном объеме и сразу. Поэтому рассмотрим на понятных примерах, как неоформленные цели можно преобразовать в «правильные».

Банковская сфера

Продукт: Мобильное приложение.

Клиент приходит с запросом: «Нужно приложение, чтобы пользователи могли управлять своими счетами и кредитами». Это классический пример списка покупок. Команда разработчиков, следуя указаниям, делает базовую функциональность. Однако спустя месяцы использования аналитика показывает, что приложение не помогает увеличить объем активных пользователей.

Сравните это с подходом, основанным на целях:

Цель: Увеличить долю активных пользователей на 20% за 6 месяцев.

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

Образовательные платформы

Продукт: Платформа онлайн образования.

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

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

Ритейл и e-commerce

Продукт: Онлайн магазин.

Клиент просит: «Создайте функциональность фильтров, корзины и оплаты». Готовый продукт работает, но трафик не конвертируется в продажи. Почему?

С целью «Увеличить коэффициент конверсии на 15%» команда изначально проанализировала бы путь пользователя, акцентировала внимание на удобстве поиска товаров, рекомендательных системах и оформлении процесса оплаты, чтобы убрать все «узкие места».

Как ставить цели: инструменты и подходы

Теперь, когда с важностью целей всё ясно, поговорим о том, как их правильно сформулировать. Вот несколько инструментов, которые помогают на старте:

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

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

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

Алгоритм постановки целей

1. Определите главную бизнес-цель (увеличить доход, повысить лояльность, привлечь новых клиентов).

2. Разбейте цель на измеримые метрики (рост на X%, конверсия Y%).

3. Свяжите метрики с задачами через карту влияний.

4. Используйте карту гипотез для поиска нестандартных решений.

Заключение: как начать правильно

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

Запомните: правильно поставленная цель – это уже полдела.