Что нужно знать о разработке сайта или приложения, чтобы зря не потратить время и деньги

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

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

---

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

С чем приходить к разработчикам

Работающий сайт — результат совместной работы заказчика и разработчика. Их зоны ответственности, грубо говоря, выглядят так:

• Заказчик определяет, ЗАЧЕМ делаем
• Разработчик решает, ЧТО и КАК делаем.

Зоны ответственности могут пересекаться. Например, на подготовительном этапе проекта (сбор и анализ информации) разработчик может помочь заказчику сформулировать задачи проекта (ЗАЧЕМ), а заказчик — поделиться существующими решениями, с которыми он встречался в своей нише (ЧТО).

Перед началом работы заказчику необходимо определить: какую именно проблему решит новый сайт или какую возможность он должен реализовать.

Если бизнес-задачу определить не удалось, проект начинать не нужно. Его реализация будет пустой тратой денег.

Удалось — можно начинать.

Как правильно поставить задачу

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

1. Для редизайна интернет-магазина. Цель: увеличить прибыль интернет-магазина за счет улучшения конверсии и увеличения среднего чека. Если вы владеете показателями своего магазина и средними показателями по рынку — конкретизируйте цель: Увеличить прибыль интернет-магазина за счет улучшения конверсии на мобильных устройствах с 0,7% до 2% и увеличения среднего чека на 10%.

Если не владеете точными цифрами, предложите разработчику проанализировать существующий сайт и найти точки роста. Некоторые команды делают бесплатный экспресс-анализ еще перед стартом проекта.

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

Например, если заявку с сайта обрабатывает ваш сотрудник, то правильной постановкой задачи будет увеличение конверсии из посетителя в заявку (лид), но не в покупателя.

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

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

3. Для посадочной страницы (лендинга). Задача посадочной страницы, как правило, — конвертировать посетителя в лид. Зная средние показатели по рынку, можно четко сформулировать задачу.

4. Для веб-приложения. Чаще всего компании используют веб-приложения для оптимизации бизнес-процессов. Это могут быть:

• Системы управления задачами и проектами

• CRM-системы

• Системы хранения и распределения данных.

В таких проектах заказчику достаточно описать проблему и сформулировать задачу на уровне бизнеса. Например: «Сейчас наши экспедиторы тратят в среднем 70 минут на поиск перевозчика. Мы хотим сократить время до 40 минут».

Кто должен готовить техническое задание

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

• Бизнес-требования
• Функциональные и нефункциональные требования
• Критерии оценки успешности. Эти критерии должны быть измеримы. Необходимо зафиксировать текущее состояние (70 минут на поиск перевозчика) и спрогнозировать целевое (45 минут на поиск перевозчика).

Иногда после проведения бизнес-анализа выясняется, что задача не может быть решена. В этом случае следует отказаться от продолжения проекта.

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

На практике 95% технических заданий, созданных заказчиками, полностью или частично идут в мусорку.

И десятки часов работы оказываются бесполезно потраченными. Вот почему так происходит:

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

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

• Если вы обращаетесь к неопытному разработчику. В этом случае техническое задание минимизирует ваши риски
• Разные этапы проекта будут выполняться разными командами. Здесь техническое задание позволит синхронизировать работу и определить зоны ответственности
• Если у вас есть опыт создания веб-проектов и четкое видение будущего сайта.

Справедливая стоимость

На этом этапе заказчику нужно выбрать решение, которое обеспечит ему наибольший ROI (процент возврата инвестиций). Например: можно инвестировать $ 1000 в разработку интернет-магазина, который конвертирует 1% посетителей в покупателей. А можно инвестировать $ 7000 в разработку интернет-магазина с конверсией в 2%. И необходимо рассчитать, оправдает ли дополнительный 1% конверсии инвестицию в $ 6000. Давайте разберемся, из чего же складывается стоимость разработки:

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

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

1. Менее $ 2000 — шаблонное решение по адаптации существующего готового решения: разработчик берет заготовку и затачивает ее под проект. Такой магазин содержит весь необходимый базовый функционал (каталог, корзина, процесс оформления заказа, возможность онлайн-оплаты), но не будет в полной мере адаптирован под особенности вашего бизнеса. Подобное решение подойдет молодому бизнесу, который не уверен, что интернет-магазин «выстрелит», или магазину с небольшим оборотом.

2. $ 6000–15 000 — индивидуальное решение. Разработчик собирает информацию о структуре ассортимента, используемых системах складского учета и CRM-системах, особенности доставки товаров. Формирует требования к решению и только потом создает сайт в полном соответствии с бизнес-процессами компании с упором на удобство пользователя и высокую конверсию.

Например, если покупатели магазина большинство покупок выполняют с мобильных устройств, то и процесс дизайна следует выстроить по модели «сначала мобильные» (mobile first), при которой дизайн будет в первую очередь создаваться для мобильных разрешений, а затем — десктопных. Такой подход обеспечит максимально удобный процесс покупок с мобильных устройств.

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

3. От $ 15 000 — технически сложные решения. Как правило, это работа с большим объемом данных и нетиповые интеграции со сторонними системами.

Как определить ROI до начала проекта

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

Рассмотрим на примере. Ниже — цифры интернет-магазина до редизайна.

Значения в примере правдивы в процентном выражении. Денежное выражение выдумано с целью сохранения коммерческой тайны.

• Средний чек — $ 40
• Себестоимость (включает налоги) — $ 20 (маржа — 50%)
• Количество покупок в месяц — 225
• Количество посетителей в месяц — 15 000
• Средняя стоимость доставки — $ 2.

Продвигаемся через контекстную рекламу:

• Средняя стоимость клика (CPC) — $ 0,1
• Расходы на контекст в месяц — $ 0,1 * 15 000 — $ 1500.

Постоянные затраты в месяц — $ 2000 (аренда — $ 300, бухгалтерия + банк — $ 100, зарплата директора и менеджера — $ 1600).

Прибыль = ($ 40 * 50%) * 225 — $ 2 * 225 (доставка) — $ 1500 (реклама) — $ 2000 (постоянные затраты) = $ 550.

Что может сделать в этой ситуации разработчик?

Разработчик НЕ может влиять на:	Разработчик может влиять на:
Себестоимость товара	Средний чек
Среднюю стоимость доставки	Количество покупок
Постоянные затраты	Количество посетителей (если разработчик занимается продвижением магазина)
	Стоимость привлечения посетителя (если разработчик занимается продвижением магазина)

Рассмотрим ситуацию, в которой разработчик не участвует в продвижении. В первую очередь разработчик анализирует статистику существующего магазина и ищет возможности улучшения показателей. Например: CR (конверсия посетителя в покупателя): 225 (количество покупок) / 15 000 (количество посетителей) * 100% = 1,5%.

Посмотрим на сегментацию по типам устройств:

• Мобильные — 7500 посетителей (45 покупок). CR = 45 / 7500 (50% от 15 000) * 100% = 0,6%
• Десктопные — 7500 посетителей (180 покупок). CR = 180 / 7500 (50% от 15 000) * 100% = 2,4%.

Разработчик разбивает CR на шаги и ищет проблемные места:

• Мобильные устройства: кладут товар в корзину — 75 (промежуточная конверсия — 1%). Из них покупают — 45 (60%). То есть 40% — брошенные корзины. CR = 7500 * 0,01 * 0,6 / 7500 * 100% = 0,6%
• Десктопные устройства: кладут товар в корзину — 225 (промежуточная конверсия — 3%). Из них покупают — 180 (80%). 20% — брошенные корзины. CR = 7500 * 0,03 * 0,8 / 7500 * 100% = 2,4%.

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

• Кладут товар в корзину на всех типах устройств — 4%
• Брошенные корзины на всех типах устройств — 15%
• Средний чек — $ 44 (+ 10% к показателю старого сайта).

Так новый сайт повлиял на прибыль:

• CR мобильных устройств = 7500 * 0,04 * 0,85 / 7500 = 3,4%
• CR десктопных устройств = 7500 * 0,04 * 0,85 / 7500 = 3,4%.

Количество покупателей = 15 000 * 3,4% = 510.

Прибыль = ($ 44 * 50%) * 510 — $ 2 * 510 (доставка) — $ 1500 (реклама) — $ 2000 (постоянные затраты) = $ 6700.

Приведенные цифры не являются идеальным расчетом ROI. В нем необходимо было бы учесть LTV, расходы на удержание клиентов и так далее. Он лишь показывает, что при формировании бюджета на разработку необходимо учесть «дивиденды», которые она принесет.

Команда заказчика и роли участников

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

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

Совещание шестерых людей для обсуждения дизайна главной страницы сайта — это избегание ответственности.

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

Мы можем дать несколько советов по созданию эффективной команды:

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

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

Коммуникация с командой разработчиков

1. Совместная работа. Работа над проектом требует вовлечения заказчика на первых этапах: подготовительном, бизнес-анализа (если он присутствует в проекте) и дизайна. На этапах программирования разработчик, как правило, уходит в свободное плавание, и заказчик может переключиться на другие задачи.

2. Общение на равных. Позиция клиента «я плачу деньги, я — прав» губительна для проекта. Так вы заставите разработчика выключить голову и механически двигать руками по указанию. Часть команд разработчиков в такой ситуации выходят из проекта, часть остаются и создают продукт, который удовлетворяет ваши дизайнерские амбиции. Постарайтесь влиять только на те решения, которые относятся к вашему бизнесу и затрагивают бренд. Остальное доверьте разработчику.

3. Каналы. Четко проговорите и пропишите каналы, которые вы будете использовать для общения по проекту. Разделите каналы для быстрого общения и для принятия важных решений. Быстрые вопросы решайте по телефону или через мессенджер. Важные решения фиксируйте в электронной почте. Возможно, к ним вам придется вернуться в будущем.

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

Итеративный подход к разработке

Перед началом работ выберите с разработчиком методологию ведения проекта. Все методологии можно разделить на 2 категории:

• Методологии, основанные на плане (plan-driven). Это объемный подготовительный этап и детальная проработка технического задания. Классическим примером является водопадная модель управления проектами.
• Методологии, основанные на изменениях (change-driven). Эти методологии предполагают поэтапное создание и запуск продукта с постоянной ретроспективой и быстрой реакцией на изменения. Наиболее известные методологии — Scrum и Kanban.

Ниже — сводная таблица, которая поможет выбрать более удобную для вас методологию:

	Plan-driven	Change-driven
Техническая документация	Высокая степень детализации требований к создаваемому продукту.	Низкая степень детализации. Иногда составляется постфактум.
Бюджет проекта	Бюджет формируется до старта проекта; включает риски.	Бюджет формируется на итерацию.
Управление изменениями	Изменения вносятся в разработанный продукт.	Изменения вносятся по ходу разработки после каждой итерации. Являются двигателем проекта.
Коммуникация с заказчиком	Высокий уровень формализованности. Отклонения от изначально согласованных требований документируются и официально согласовываются сторонами.	Неформальное общение.

Не следует стремиться к 100%-ному соответствию методологии. Можно совмещать отдельные свойства и правила. Например, если вы взяли за основу Scrum, необязательно двигаться одинаковыми двухнедельными итерациями. Выберите периоды, которые подходят вашему проекту. Под каждый спринт (так в Scrum называется шаг проекта) можно написать подробное техническое задание и сформировать бюджет. Таким образом, проект совместит свойства и водопадной методологии, и Scrum.

Итеративность разработки

Пошаговое движение так важно для разработки, потому что дает возможность как можно раньше найти ошибку. Исправление ошибки на этапе дизайна стоит 1 условный рубль, на этапе фронт-енд-программирования (верстки) — 3 рубля, на этапе бэк-енд-программирования — 7. На какие шаги мы рекомендуем разбить разработку:

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

2. Дизайн. На этом этапе страницы приобретают конечный вид. Дизайн страниц также следует делать последовательно, начиная с главной. При работе над несложными проектами можно ограничиться дизайном только для «десктопного» разрешения и дополнительной страницей с набором элементов мобильного интерфейса: меню, галереей, хедером и футером. В этом случае адаптацию дизайна под мобильные разрешения выполнит фронт-енд-разработчик. В проектах со сложным интерфейсом, в которых изменение дизайна не сводится к масштабированию и изменению положения элементов, следует сделать дизайн и для «десктопного», и для «мобильного» разрешений. Если веб-сайт ориентирован на «мобильную» аудиторию, то сначала следует построить дизайн для «мобильных» разрешений, а уже потом адаптировать его под бОльшие экраны.

3. Программирование. При работе компетентной команды вовлечение заказчика на этапах фронт-енд (HTML-верстка) и бэк-енд-программирования не требуется. Команда разработчика тестирует свою работу поэтапно.

4. Тестирование. Помимо функционального тестирования следует оценить, насколько продукт будет удобным в использовании — провести юзабилити-тестирование. Так вы узнаете, насколько продукт удобен в использовании.

Что делать после запуска

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

Недочеты следует устранять по модели «изучаем» -> (создаем -> тестируем -> вносим изменения, пока тест не покажет положительный результат) -> внедряем.

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

• Конверсии из посетителя в покупателя
• Брошенные корзины
• Выполнение целевых действий (кликов по ссылкам, отправку форм)
• Количество посетителей
• Время, проведенное на сайте (страницах)
• Показатель отказов.

Подытожим

1. Перед началом проекта ответьте на вопрос: «Какую проблему он решит или какую возможность позволит реализовать?» Если смогли ответить — вступайте в проект.

2. Не создавайте техническое задание, а подробно опишите задачу проекта. При возможности выразите ее в цифрах. Используйте знания о поведении ваших покупателей в офлайне. Перенесите их в онлайн с учетом контекста.

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

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

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

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

5. Выберите правильного разработчика и общайтесь с ним на равных. Доверяйте. Не действуйте с позиции «я клиент». Разработчик отплатит заинтересованностью и погружением в проект и, вероятно, предвосхитит ваши ожидания.

6. Расскажите разработчику о компании и продукте. Самостоятельно или при помощи копирайтера подготовьте контент. Разработчик вокруг него построит дизайн.

7. Какую бы методологию проекта вы ни выбрали, действуйте итеративно. Так вы сможете сэкономить и время, и бюджет. Исправление ошибки на более поздних этапах обходится в разы дороже.

8. Запуск проекта — только начало. Анализируйте поведение посетителей и улучшайте интерфейс, пока не достигнете высоких показателей конверсии. Затем зафиксируйте нормальные показатели и предпринимайте действия в случае отклонения от них.