Технологии
«Нам нужен новый сайт» — не аргумент: как защитить проект и согласовать бюджет
Инициатива разработать новый сайт может казаться очевидной, но для защиты проекта этого недостаточно. Нужны данные, которые покажут, что именно не работает в текущем решении, какие варианты изменений есть и по каким показателям можно будет оценить результат. Разберём, где взять эти данные и как собрать из них аргументы для согласования бюджета.
Сначала определите, зачем нужны изменения
Если текущий сайт перестал справляться со своими задачами, это ещё не означает, что его обязательно нужно разрабатывать заново. Сначала нужно понять, какие именно проблемы есть сейчас и насколько они влияют на бизнес.
Где-то достаточно переработать отдельный пользовательский сценарий, страницу или интеграцию. В других случаях ограничения текущего решения затрагивают сразу несколько важных задач, и тогда уже имеет смысл рассматривать серьёзную переработку или новый сайт.
Поэтому обоснование разработки сайта должно отвечать на несколько вопросов: что не работает сейчас, чем это подтверждается, какие варианты решения есть и почему один из них предпочтительнее остальных. После этого можно переходить к объёму работ и бюджету.
Разберитесь, какие задачи должен решать сайт
Перед тем как оценивать текущий сайт, нужно понять, зачем он вообще нужен бизнесу. Кто пользуется сайтом, зачем приходит и какие действия ему важно совершить.
Для одного сайта ключевая задача — помочь найти услугу и оставить заявку. Для другого — выбрать продукт, сравнить варианты, зарегистрироваться, забронировать, скачать документацию или получить нужную информацию без обращения к менеджеру.
Полезно отдельно проверить, предусмотрены ли эти сценарии на текущем сайте вообще. Иногда проблема не в сложностях внутри пользовательского сценария, а в том, что нужный сценарий на сайте вообще не предусмотрен. Например, сайт подробно рассказывает о компании, но не помогает выбрать подходящую услугу или не даёт понятного следующего шага.
Посмотрите данные веб-аналитики
Разложите ключевые пользовательские пути на этапы и посмотрите воронку: сколько людей приходит на сайт, сколько переходит к следующему шагу, начинает целевое действие и завершает его.
Так можно найти места, где возникает заметный отток. Трафик на раздел может быть высоким, но до регистрации доходит небольшая часть посетителей. Или форму начинают заполнять многие, а отправляют единицы.
Перед выводами нужно проверить, что именно фиксирует аналитика. Клик по кнопке, открытие формы и её отправка — разные действия. В Яндекс Метрике для них могут использоваться разные цели, а значит, показатель нельзя автоматически трактовать как количество заявок, пока не проверено условие его фиксации.
Стоит сравнивать и разные сегменты: мобильные и десктопные устройства, источники трафика, новых и возвращающихся пользователей. Проблема может проявляться только в одном из них.
Если для сайта важен органический поиск, дополнительные данные даёт Яндекс Вебмастер. В нём можно посмотреть запросы, показы, клики и CTR, а также анализировать данные в разрезе URL. Это помогает понять, по каким задачам пользователи уже находят сайт в поиске и какие страницы получают трафик.
Посмотрите, как пользователи проходят путь
Одних цифр недостаточно: аналитика показывает, где возникло затруднение, но не всегда объясняет, почему.
Записи пользовательских сессий и карты кликов помогают увидеть, где человек возвращается назад, долго ищет нужный элемент, несколько раз пытается нажать на одну и ту же область или прекращает действие. Вебвизор Яндекс Метрики позволяет анализировать действия посетителей во время сессии и отдельно изучать нужные сегменты.
Однако, такие наблюдения не стоит сразу принимать за готовый диагноз. Они скорее дают гипотезу о причине, которую нужно проверить другими способами.
Проведите пользовательские интервью
Пользовательские интервью помогают понять не только что человек сделал на сайте, но и почему он поступил именно так. Вопрос «нравится ли вам сайт?» здесь почти бесполезен. Гораздо информативнее попросить человека решить конкретную задачу.
- найти нужную услугу;
- выбрать подходящий вариант;
- разобраться в условиях;
- выполнить целевой действие;
- рассказать, где появились вопросы или сомнения;
Так можно обнаружить то, что не видно в цифрах: непонятные формулировки, отсутствие важной информации, неочевидную навигацию, недоверие к отдельным элементам или нужный пользователю путь, который на сайте вообще не предусмотрен.
Соберите обратную связь от сотрудников
Полезный источник информации — сотрудники, которые регулярно общаются с клиентами: продажи, поддержка, сервис, маркетинг. Стоит узнать, какие вопросы им приходится объяснять чаще всего, где люди ошибаются и какую информацию не могут найти самостоятельно.
Если один и тот же вопрос регулярно приходится разбирать менеджеру, стоит проверить, может ли сайт решить эту задачу без его участия. Но сам факт обращения ещё не доказывает проблему интерфейса: причина может быть в продукте, условиях или самом процессе.
Изучите отзывы и внешние площадки
Отзывы могут показать повторяющиеся ожидания и затруднения: чего людям не хватает, какие условия они не понимают, где ожидания расходятся с фактическим опытом.
Но жалоба на цену, качество услуги или работу сотрудников не становится автоматически аргументом против сайта. Сначала нужно установить связь с цифровым сценарием.
Например, если пользователи регулярно пишут, что не понимали состав услуги до обращения, стоит проверить, как эта информация представлена на сайте. Если же претензия относится к качеству самой услуги, новый интерфейс проблему не решит.
Оцените, соответствует ли дизайн задачам и бренду
Внешний вид сайта тоже может быть аргументом в пользу изменений, но формулировки «дизайн устарел» недостаточно. Нужно показать, в чём именно проблема и на что она влияет.
Например, компания изменила позиционирование, вышла в другой ценовой сегмент или стала работать с новой аудиторией, а сайт по-прежнему передаёт прежний образ бренда. Тогда разрыв виден уже не только внутри интерфейса, но и между сайтом и другими точками контакта с клиентом.
Дизайн может мешать и решению практических задач: важные элементы теряются в визуальной иерархии, интерфейс перегружен, на смартфоне сложно читать контент или выполнять целевые действия.
Такие проблемы лучше подтверждать не субъективной оценкой «выглядит несовременно», а пользовательскими интервью, анализом поведения, актуальными материалами бренда и сравнением с сопоставимыми компаниями.
В результате исследования должно быть понятно, какие аудитории приходят на сайт, какие задачи они решают, какие пути для этого нужны, где они сейчас работают плохо или отсутствуют и какими данными это подтверждается.
В DIGITAL SECTOR похожую логику использовали при подготовке проекта для компании из сферы услуг. На стадии пресейла специалисты анализировали отзывы клиентов на внешних площадках, сравнивали одинаковые пользовательские пути на сайтах конкурентов и изучали данные об этапах, на которых пользователи прекращали действие в мобильном приложении. Данные приложения использовали только как дополнительный ориентир: выводы по нему не считали автоматически справедливыми для сайта.
Проверьте, что именно подтверждают собранные данные
После исследования уже есть конкретные наблюдения: где пользователи прерывают действие, чего им не хватает на сайте, какие вопросы они задают и какие проблемы повторяются в нескольких источниках. Теперь нужно понять, какие выводы из этих данных действительно следуют.
Допустим, аналитика показывает, что значительная часть пользователей не доходит до отправки заявки. Пользовательские интервью при этом подтверждают, что на этом этапе людям не хватает информации об условиях. Тогда уже есть основания говорить о конкретном затруднении.
Если известен только высокий отток, а его причина не установлена, вывод «форма слишком длинная» или «интерфейс неудобный» остаётся гипотезой. Человек может уйти из-за цены, непонятных условий, отсутствия нужной информации, технической ошибки или по другой причине.
Поэтому результаты исследования полезно разделить на несколько уровней:
- что подтверждено данными — например, на определённом этапе воронки есть заметный отток;
- что предполагаем о причине — например, пользователю не хватает информации для принятия решения;
- что можно изменить — например, перестроить страницу или отдельный пользовательский путь;
- как проверить результат — например, сравнить долю пользователей, которые проходят этот этап до и после изменений.
Так из исследования получается не список претензий к текущему сайту, а основа для выбора решения: видно, где проблема подтверждена, где ещё нужна проверка и какое изменение имеет смысл рассматривать.
Посмотрите, как те же задачи решают конкуренты
Когда проблемные места определены, полезно посмотреть, как похожие задачи решают другие компании. Цель такого анализа — не скопировать чужой сайт, а увидеть альтернативные подходы.
Сравнивать лучше одинаковые пользовательские пути: как человек выбирает услугу, где получает информацию об условиях, сколько шагов проходит до заявки или бронирования, что видит на мобильном устройстве.
Для анализа стоит выбрать несколько действительно сопоставимых компаний и пройти на их сайтах один и тот же путь. Наблюдения удобно фиксировать в таблице и дополнять скриншотами: какие шаги есть, где размещена ключевая информация, какие действия предлагаются пользователю и чем этот подход отличается от текущего сайта.
При этом по открытому сайту нельзя узнать реальную конверсию, выручку или доказать, что конкретное решение работает лучше. Поэтому формула «у конкурента сделано так — значит, и нам нужно так же» не работает. Корректный вывод другой: на рынке есть ещё один способ решить эту задачу, и его стоит проверить применительно к своим пользователям, данным и ограничениям.
Так анализ конкурентов дополняет внутреннее исследование и помогает найти решения, которые раньше могли не рассматриваться.
Сравните варианты изменений
Когда проблемы подтверждены и понятны возможные способы их решения, можно сравнивать варианты. Новый сайт — только один из них.
Если проблема локальная, может быть достаточно точечной доработки: изменить отдельную страницу, форму, интеграцию или пользовательский путь. Если ограничения затрагивают сразу несколько важных задач, может понадобиться серьёзная переработка текущего решения.
Новый сайт имеет смысл рассматривать, если существующее решение уже не даёт нормально реализовать необходимые сценарии или дальнейшие доработки становятся слишком сложными и затратными.
Для каждого варианта стоит зафиксировать:
- какую проблему он решает;
- какой объём работ предполагает;
- какие ограничения и риски остаются;
- по каким показателям можно будет проверить результат.
Полезно отдельно рассмотреть и вариант «ничего не менять». У него тоже есть последствия: сохраняются выявленные ограничения, затраты на поддержку и проблемы в пользовательских путях. Это позволяет сравнивать не «новый сайт против нулевых затрат», а несколько реальных сценариев.
Сколько стоит ещё год ничего не менять
В отдельной статье DIGITAL SECTOR разобрали, из чего складывается стоимость отсрочки модернизации и когда перенос изменений действительно оправдан.
Читать →
Посчитайте экономику проекта
После того как варианты определены, их нужно сравнить не только по объёму работ. Для защиты бюджета проекта один из главных вопросов — экономика: сколько компания вложит, какие текущие потери или затраты сможет сократить и за счёт чего проект вообще может дать результат.
Если последствия текущих проблем можно измерить, их уже можно включать в расчёт.
Оцените стоимость текущих проблем
Для каждой подтверждённой проблемы стоит задать вопрос: во что она обходится бизнесу сейчас?
Это могут быть:
- потерянные заявки или бронирования на определённом этапе воронки;
- дополнительные обращения в продажи или поддержку;
- время сотрудников на ручные операции;
- стоимость регулярных доработок и поддержки текущего решения;
- расходы на сторонние сервисы, которые приходится использовать из-за ограничений сайта;
- затраты на исправление ошибок или работу с несколькими несвязанными системами.
Не всё получится сразу перевести в деньги. Но даже если известен только объём потерянных действий или трудозатраты, это уже база для дальнейшей оценки.
Если известно, сколько пользователей ежемесячно доходит до определённого этапа воронки и сколько из них прекращает действие, можно оценить масштаб проблемы. Но нельзя автоматически считать весь этот отток потерянной выручкой: не каждый ушедший пользователь обязательно завершил бы покупку или заявку после изменений.
Считайте не только стоимость разработки
Цена договора с подрядчиком — ещё не полная стоимость проекта. В расчёт могут входить:
- аналитика и проектирование;
- дизайн и разработка;
- интеграции;
- перенос и подготовка контента;
- инфраструктура и лицензии;
- тестирование;
- работа сотрудников заказчика;
- обучение;
- дальнейшая техническая поддержка и развитие.
Это особенно заметно при сравнении вариантов. Точечная доработка требует меньшего бюджета на старте, но может сохранить часть текущих ограничений и последующих расходов. Новый сайт потребует больших первоначальных вложений, зато в некоторых случаях позволяет убрать ограничения, из-за которых компания постоянно тратится на обходные решения.
Поэтому сравнивать стоит полную стоимость вариантов, а не только цену разработки.
Покажите, откуда должен появиться эффект
Экономический эффект нужно связать с конкретным изменением.
Сейчас: пользователи часто прекращают бронирование на одном из этапов.
Изменение: устраняются подтверждённые препятствия в этом пользовательском пути.
Что проверяем: изменилась ли доля людей, которые завершают бронирование.
Экономический показатель: дополнительное количество завершённых бронирований и связанная с ними выручка.
Другой пример:
Сейчас: менеджеры регулярно отвечают на типовые вопросы, потому что нужной информации нет на сайте.
Изменение: пользователь получает эту информацию самостоятельно.
Что проверяем: сократилось ли число соответствующих обращений.
Экономический показатель: изменение трудозатрат на обработку типовых запросов.
Так видна причинно-следственная связь между затратами на проект и потенциальным результатом. Фраза «новый сайт повысит продажи» такой связи не показывает.
Рассчитайте несколько сценариев
Точный результат будущего проекта до запуска неизвестен. Поэтому вместо одной красивой цифры полезнее показать несколько сценариев — например, консервативный, базовый и оптимистичный.
Допустим, на одном из этапов воронки ежемесячно прекращают действие 1 000 пользователей. Это условный пример, а не отраслевой показатель. В расчёте можно посмотреть, что произойдёт, если после изменений этот отток сократится на 5, 10 или 15%. Затем оценить, сколько дополнительных целевых действий это даст и как может повлиять на экономический результат.
Все допущения должны быть видны. Тогда обсуждается не обещание «проект принесёт Xмиллионов рублей», а условия, при которых определённый результат возможен.
Сравните проект с вариантом «ничего не менять»
Экономику нового сайта полезно рассматривать не только через будущий доход, но и через стоимость сохранения текущего решения.
Если проект отложить, могут сохраниться затраты на поддержку старой системы, временные доработки, ручные процессы или сторонние сервисы. Поэтому варианты лучше сравнивать на одном горизонте — например, двух или трёх лет.
| Сценарий | Первоначальные затраты | Дальнейшие расходы | Что меняется | Как оценивать результат |
|---|---|---|---|---|
| Ничего не менять | минимальные | поддержка текущего решения | выявленные ограничения сохраняются | расходы и показатели остаются базой для сравнения |
| Точечные доработки | ниже | возможны следующие доработки | решается часть проблем | по показателям изменённых участков |
| Серьёзная переработка | средние | зависят от текущего решения | меняется несколько связанных участков | по ключевым пользовательским и бизнес-показателям |
| Новый сайт | выше | поддержка и развитие нового решения | пересматриваются основные пользовательские пути и ограничения | по заранее выбранным показателям проекта |
Такой подход помогает провести оценку эффективности сайта и будущего проекта не по одной цифре, а по совокупности затрат, ограничений и измеримых результатов.
При расчётах важно по-прежнему разделять факты, оценки и гипотезы. Текущие расходы или число обращений могут быть известны точно. Стоимость проекта — оцениваться диапазоном. А будущий рост конверсии до запуска остаётся предположением.
Соберите обоснование в короткую и понятную структуру
После исследования, сравнения вариантов и расчёта экономики основные аргументы уже собраны. Теперь их нужно представить так, чтобы человек, который не погружён в детали проекта, мог быстро понять, что предлагается и почему.
Не стоит переносить в презентацию всё исследование. Лучше оставить информацию, которая влияет на решение.
- Что происходит сейчас. Какие задачи должен решать сайт, какие аудитории им пользуются и где обнаружены проблемы.
- Чем эти проблемы подтверждаются. Веб-аналитика, пользовательские интервью, обратная связь от сотрудников, отзывы, анализ поведения и другие источники.
- Какие последствия есть у текущего решения. Где возникают потери, лишние трудозатраты, ограничения или дополнительные расходы.
- Какие варианты изменений рассматривались. Точечные доработки, серьёзная переработка, новый сайт или сохранение текущего решения.
- Почему выбран конкретный вариант. Какие проблемы он решает, какие ограничения снимает и какие риски остаются.
- Сколько это стоит. Бюджет проекта, дополнительные расходы на внедрение и эксплуатацию, стоимость альтернативных вариантов.
- Какой эффект ожидается. За счёт каких изменений он должен появиться, какие допущения используются и по каким показателям его будут проверять.
- Что нужно согласовать сейчас. Например, выбранный вариант развития, бюджет или переход к следующему этапу проекта.
Так защита проекта строится вокруг последовательного обоснования: от текущей ситуации и подтверждённых проблем — к вариантам, экономике и измеримому результату.
Когда проект согласован, требования нужно зафиксировать
В отдельном материале разбираем, как перейти от бизнес-задачи к требованиям к будущей веб-системе и не пытаться заранее писать техническое задание на языке разработчиков.
Читать →
Если для проекта нужна внешняя команда
Разбираем, что проверять при выборе подрядчика для сложной заказной разработки кроме цены, технологий и портфолио.
Читать →
Обосновывать нужно не новый сайт, а решение задачи
Для согласования проекта важно показать, что именно требуется изменить, чем это подтверждается, сколько будет стоить выбранный вариант и как потом проверить результат. Тогда обсуждается не абстрактная идея нового сайта, а решение конкретных задач бизнеса.
Если нужно оценить текущее состояние сайта и подготовить аргументы для проекта, специалисты DIGITAL SECTOR помогут собрать исходные данные и определить возможные варианты изменений.
Согласен