Цели в начале разработки: как избежать провала проекта
Сроки горят, бюджет испаряется, а конечный продукт не оправдывает ожиданий. Почему вообще проекты проваливаются? Если копнуть глубже, зачастую оказывается, что ключевая причина провала — отсутствие четко сформулированных целей на старте. Давайте разберем, почему постановка целей — это не просто модный термин, а важный этап, который определяет успех продукта.
Привет! Я Вениамин Мустафин, директор по развитию компании fuse8. Мы строим свою экспертизу на создании цифровых продуктов для бизнеса и делимся наработками через контент. На мой взгляд, продуктовое проектирование — часть проекта настолько же важная, как и разработка. Одно без другого существовать не может. Поэтому в этой и других будущих статьях хочу рассказать о процессах, предшествующих разработке и делающих ее прозрачнее для заказчиков и команды. В прошлой статье говорил про USM — заходите почитать :)
Клиент, знает, чего хочет, но этого недостаточно
Когда клиент приходит к команде разработки, он уже проделал немалую работу. В его голове есть образ конечного продукта, а иногда даже цели и метрики, которых он хочет достичь. Клиент может описывать это через функциональные требования: «хочу, чтобы в продукте был кабинет поставщика, который умеет вот это и вот то» или «нужно приложение, в котором можно будет оформлять заявки на банковские продукты».
Команда разработки, видя такой «список покупок», часто считает, что клиент — эксперт в своем бизнесе, поэтому можно следовать этим требованиям буквально. Но на практике, если команда разработки не вовлечена в обсуждение целей, ее работа сводится к выполнению задач по принципу «сделай то, что сказано». И тут команда превращается в группу исполнителей, а не партнеров. В результате создается продукт, который «работает по ТЗ», но не обязательно помогает бизнесу.
По-настоящему сильная команда разработки не просто «выполняет задачи», а работает на достижение целей продукта. Чтобы это стало возможным, с самого начала погружаем команду в стратегические цели, помогаем видеть продукт целиком и даем почву для проверки гипотез. Так получается не только решать задачи, но и генерировать идеи для улучшения продукта. Это и отличает команду исполнителей от команды создателей.
Почему цели важнее списка фич?
Фокус на результате, а не на задачах
Представьте, что вы запускаете сервис для банка. Можно сказать: «Сделайте кредитный калькулятор», а можно поставить цель: «Увеличить количество заполненных анкет на сайте в два раза». В первом случае команда просто выполняет задачу, не углубляясь в суть. Во втором — она фокусируется на результате и начинает предлагать решения, которые действительно помогут достичь цели. Разница в уровне погружения — колоссальная.
Приоритеты определяются целями
В разработке всегда наступает момент, когда становится понятно, что выполнить всё задуманное в срок невозможно. Если нет целей, задачи, которые придуманы без привязки к чему-либо, могут быть мертворожденными. Начинается хаос: что отложить, а что сделать? Кто-то решает это на основе интуиции, но это плохая валидация. Цели и метрики нужны, чтобы вычленить главное. Иначе начинается субъективизация — разные ЛПРы говорят: «Ну вот это уж точно надо внедрить», и у каждого «вот это» разное. При наличии оформленных целей, проще решить, какие задачи критичны для достижения успеха, а какие можно отложить или вовсе убрать.
Ответственность делится между клиентом и командой
Когда работа идет без целей, клиент остается единственным ответственным за результат. Он диктует задачи, и команда просто их выполняет. Но если цели зафиксированы и разработчики понимают, как их достичь, они становятся партнерами клиента. Ответственность за успех разделяется, и это — залог сильной и мотивированной команды, а в дальнейшем — успешного продукта.
Цена незафиксированных целей: как потратить время впустую
Имаджинируем: университетская администрация решила модернизировать свою систему для онлайн-зачислений студентов. Фокус работы следующий: «Обновить личный кабинет абитуриента и добавить новые функции.» Клиент передает команде список желаемых изменений, среди которых — «встроить калькулятор баллов» и «обновить интерфейс загрузки документов.»
Что произошло
Команда берет макеты и текстовые описания, начиная работу. Аналитик погружается в разработку калькулятора баллов — это был самый подробно описанный элемент. На это уходит несколько дней: описание логики работы, уточнение формул и проектирование интерфейса.
Но когда аналитик возвращается к клиенту за уточнениями, звучит неожиданное:
«Калькулятор — это хорошо, но это не срочно. Сейчас абитуриенты жалуются на проблемы с загрузкой документов. Нам нужно срочно это исправить.»
Результат стараний
Команда потратила несколько дней на проработку задачи, которая не была ключевой для успеха продукта. А всё потому, что приоритеты не были выявлены до начала работы. Клиент, ожидая помощи от команды, не сформулировал цели, а команда приняла список задач как данность, не задав уточняющих вопросов.
Как стоило сделать
Ответственность за формулировку целей лежит и на команде. Не нужно ждать, что клиент сам определит, что важно. Вместо этого команда должна провести обсуждение с заказчиком, выяснив:
Что сейчас вызывает наибольшие сложности у пользователей?
Каковы основные жалобы или пожелания?
Какие задачи критичны сейчас?
Какие из них можно отложить на потом?
Если бы команда задала эти вопросы, стало бы ясно, что главная проблема — это неудобный процесс загрузки документов. Калькулятор баллов, хотя и полезен, можно проработать на следующем этапе.
Чему это нас учит?
Формулирование целей в продукте — процесс общий, где одинаково вовлечены должны быть и заказчик, и исполнитель. В интересах второго максимально полно «вытянуть» из заказчика ожидания, чтобы эффективно приоритезировать задачи.
Кроме того, когда цели продукта формируются сообща, мы укрепляем доверие и движемся в сторону максимально прозрачной с обеих сторон коммуникации. Это важно. Ну, и как бонус — не тратим время и ресурсы впустую.
Как определить цели проекта и уйти от пунктов в списке покупок
Базовый ответ на этот вопрос: формулируйте по SMART. Правильная цель должна быть конкретна, измерима, достижима, релевантна и привязана ко времени. Но эти характеристики не всегда получается применить в полном объеме и сразу. Поэтому рассмотрим на понятных примерах, как неоформленные цели можно преобразовать в «правильные».
Банковская сфера
Продукт: Мобильное приложение.
Клиент приходит с запросом: «Нужно приложение, чтобы пользователи могли управлять своими счетами и кредитами». Это классический пример списка покупок. Команда разработчиков, следуя указаниям, делает базовую функциональность. Однако спустя месяцы использования аналитика показывает, что приложение не помогает увеличить объем активных пользователей.
Сравните это с подходом, основанным на целях:
Цель: Увеличить долю активных пользователей на 20% за 6 месяцев.
С таким ориентиром команда понимает, что важно сосредоточиться, например, на удобстве пользовательского интерфейса, автоматизации напоминаний и кэшбэк-программах, которые стимулируют использование приложения.
Образовательные платформы
Продукт: Платформа онлайн образования.
Клиент говорит: «Нужна платформа с видеоуроками, тестами и сертификатами». Команда реализует все пожелания, но результаты разочаровывают: студенты бросают курс, не доходя до середины. Почему?
Цель не была поставлена. Если бы фокус был на достижении завершения курса минимум 70% участников, подойти к задаче можно было бы иначе: проработать геймификацию, мотивационные рассылки и персонализированную поддержку.
Ритейл и e-commerce
Продукт: Онлайн магазин.
Клиент просит: «Создайте функциональность фильтров, корзины и оплаты». Готовый продукт работает, но трафик не конвертируется в продажи. Почему?
С целью «Увеличить коэффициент конверсии на 15%» команда изначально проанализировала бы путь пользователя, акцентировала внимание на удобстве поиска товаров, рекомендательных системах и оформлении процесса оплаты, чтобы убрать все «узкие места».
Как ставить цели: инструменты и подходы
Теперь, когда с важностью целей всё ясно, поговорим о том, как их правильно сформулировать. Вот несколько инструментов, которые помогают на старте:
Понимание задачи (ПЗ)
Это базовый уровень фиксации целей. ПЗ помогает структурировать запрос клиента и понять, как он пришел к своему видению.Карта влияний
Этот инструмент связывает цели бизнеса и функции продукта. Она помогает выделить, какие задачи действительно важны для достижения целей, а какие можно отложить. Карта влияний отлично работает, когда у клиента уже есть общее понимание, что нужно делать.Карта гипотез
Подходит для проектов, где непонятно, с чего начать. Она помогает генерировать гипотезы и задачи, а также увязывать их с реальными потребностями пользователей. Если карта влияний ориентирована на бизнес, то карта гипотез погружает в пользовательский опыт и помогает создавать что-то действительно полезное.
Алгоритм постановки целей
Определите главную бизнес-цель (увеличить доход, повысить лояльность, привлечь новых клиентов).
Разбейте цель на измеримые метрики (рост на X%, конверсия Y%).
Свяжите метрики с задачами через карту влияний.
Используйте карту гипотез для поиска нестандартных решений.
Заключение: как начать правильно
Поймите, зачем создается продукт, как он должен помочь бизнесу и какие метрики будут показывать, что вы на верном пути. Фиксируйте цели, проверяйте их актуальность и используйте инструменты вроде карты влияний и карты гипотез. Это не только увеличит шансы на успех, но и сделает процесс разработки осмысленным и вдохновляющим.
Запомните: правильно поставленная цель — это уже полдела.
