Как выстроить работу продакшена, чтобы не платить дважды — опыт Ailove

Спойлер: начинаем с бизнес-задач

Меня зовут Мила, я веду проекты в команде web-production Ailove. Мне обычно достаются сложные задачи: я разбираюсь с бизнес-задачами клиента, собираю команду разработки и модерации, настраиваю процессы.

Последние три месяца мы с коллегами наблюдаем, как растет спрос на разработку: одни переходят в онлайн, другие мигрируют из Instagram (признан экстремистским и запрещен в РФ) и разрабатывают ботов, а третьи оптимизирует затраты на программистов в горизонте 3+ лет. В связи с этим ко мне пришла команда PR и попросила рассказать, зачем нужен продакшен и какие сейчас есть тренды. А также ответить на наиболее часто встречающиеся вопросы.

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

Продакшен ― продолжение стратегии бренда

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

Автоматизировать процессы можно по-разному. Например:

― табачная компания для продвижения использует сайт с большим каталогом игр. Пользователи туда приходят (в том числе) ради бесплатных хорошо проработанных игрушек. И готовы пройти сложную регистрацию, чтобы играть без риска потерять деньги или подцепить вирус. Бренду это дает долгий контакт с пользователем и возможность контакта со своим потребителем. У такого сайта продуктовые задачи: он нужен, чтобы люди провели на нем максимум времени, потому что их привлекли качественные игры. Разработчики должны позаботиться о том, чтобы играть было удобно ― kpi разработки этого сайта мало отличается от kpi разработки компьютерных игр.

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

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

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

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

Чтобы не тратить деньги зря, разработке нужны ответы вот на эти вопросы:
1. Какие задачи человек решит с помощью сайта?
2. Как он решит эти задачи?
3. Какой это человек, с какого девайса и из какой точки мира он заходит (это про ЦА и соцдем)?
4. Какой путь проделает перед тем, как оказаться на сайте/в приложении, и какие действия произойдут после использования сайта или приложения (заказал еду в приложении доставки, приезжает еда)?

Ответы нужно найти для каждого сегмента пользователей:
― тех, кто пришел на сайт посмотреть рецепт/прочитать статью;
― тех, кто пришел посмотреть продукты и то, где он может их купить по акции;
― seo-команды, которая пришла внести метатеги;
― трейд-маркетолога, который сверяет продукты с актуальной линейкой.

И так для каждого активного пользователя (сайта в этом случае. В разработке для этого используется термин actor, т.е. активный пользователь программы). По сути, нам нужна выдержка из CJM, касающаяся нашего блока работ.

И тут часто появляется типовая проблема ― у маркетолога есть только такие данные:

ЦА

• Женщины, 18-45, города миллионники
• Москвичи с доходом 90 т.р. и выше
• Маша, 30 лет, замужем, двое маленьких детей. Живет в Москве, читает новости, сортирует мусор.

CJM
Заказывает продукты и всё необходимое с доставкой на дом на семью из 4 человек.

JTBD
Быть хорошей мамой, тратить мало времени на рутину и чтобы дети были сыты, чисты и здоровы.

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

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

Важно держать в голове, что сайты при этом могут быть ориентированы на разные цели:
- на трафик из поисковых систем (например, сайты с рецептами от производителя специй),
- на сценарии использования продукта (Алиса «Яндекса»),
- быть частью экосистемы (например, Okko и другие сайты «Сбера» часто используют решения, которые выгодны не сервису, а экосистеме). Ярким примером тут будет Gmail ― это дорогой сервис, который не столько приносит деньги, сколько образует саму экосистему.

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

Как выбирать метрики и показатели

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

Что это означает на практике:

― маркетплейсам важны сделки: поездки в такси, забронированные ночи в отелях.

― магазинам важен средний чек и количество заказов.

― тем, кто монетизирует трафик рекламой, от авто.ру и «Летидора» до Facebook (признан экстремистским и запрещен в РФ), важна активность пользователей в день/месяц: DAU, MAU, среднее время использования сайта или приложения.

― для экосистем («Яндекс», «Сбер», Google) важен LTV (lifetime value), пожизненная ценность клиентов — доход с привлеченного пользователя за всю историю взаимоотношений с ним. Показатель учитывает активность пользователей в кросс-сервисных сценариях. Именно он показывает окупаемость сервисов вроде Gmail.

Разные метрики нужны на разных этапах жизни проекта. Для MVP важно определить саму готовность к покупке и понять объем рынка. Чем больше транзакций, тем важнее рост базы и возвращаемость клиентов. Дальше на первый план выходят метрики активности, среднего чека, повторных продаж и пожизненной ценности.

Определившись с метрикой, детализируем маршрут. Выбираем гипотезы: как именно мы добьемся роста, например, количества броней номеров в отеле? Перепишем текст? Упростим интерфейс? Построим партнерскую программу? Как будем собирать обратную связь? И что именно нужно бизнесу?

Чего хочет бизнес?

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

Деньги. Сколько мы хотим сэкономить/заработать на сайте?

Например, ИТ-компания, которая продавала энтерпрайз-решения для нишевого бизнеса, решила сделать SAAS-версию и продавать подписки. Если энтерпрайз-клиентов было 5, вложения в маркетинг, разработку и продвижение станут инвестицией. Окупится она или нет, зависит от успешности продукта. Быстрой окупаемости не будет, это важно понимать сразу.

Сайты и приложения ― средство автоматизации продаж. Если продаж мало, на автоматизацию можно потратить больше денег, чем ожидается прибыли.

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

Есть и обратные кейсы: продаж много, они держатся на сайте, и от этого строятся сценарии разработки. Последнее время так работают, например, «Вкусвилл» или X5. Тут в оптимизацию вкладываются огромные деньги, и окупаются они быстро.

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

Избавиться от человеческого фактора на том или ином участке

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

Выиграть каннских львов

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

А теперь немного откатимся к началу: какие вопросы мы чаще всего задаем на старте и почему нам сложно на них ответить, не зная бизнес клиента?

Mobile first или Desktop first?

Спойлер: user first

А что, собственно, делать? С чего начинать проектирование?

Для начала нужно узнать, кто тут у нас юзер и какой набор технических решений ему подойдет. И (например) понять, что сайт не нужен вообще.  

Если мы делаем новый сайт для уже знакомой аудитории, заходим в Google Analytics  или «Яндекс.Метрику», смотрим отчет по устройствам и определяем, какой тип устройств для нас важен.

Клиенту, у которого 80% трафика приходит с мобильных устройств, для сайта мы предложим подход mobile first. Но, кроме того, сайт у него контентный, а бюджет ограниченный. Поэтому мы делаем сайт и pwa-версию вместо мобильного приложения. Получается примерно в 5 раз дешевле.

А есть другой клиент, b2b. К нему 70% клиентов приходят с десктопа из разных стран, и все эти люди пользуются разными браузерами. И экраны у них разных размеров. Тут надо больше сосредоточиться на том, чтобы работал CDN (штука, которая кэширует контент и быстро загружает его для пользователей независимо от их географического положения).

Очень важно смотреть на погрешности сбора данных, чтобы не уйти в ошибку выжившего и замкнутый круг («Прыщи на лице ― нет секса ― прыщи на лице ― замкнутый круг!»(с)) Здесь нам помогает команда BI: они смотрят конкурентов, проводят кастдевы, пересматривают UX, CJM. Возвращаясь к началу, мы уточняем бизнес-процессы клиента.

Как выбрать CMS? Делать свой сайт или брать готовое решение?

Выбираем по текущему уровню цифровизации.

1. Дешёвые шаблоны готовых решений, где разработка включается минимально.

Если нам нужно просто дать какой-то текст, картинки/видео и форму обратной связи, подойдут конструкторы. Кроме того, они эффективны для тестирования гипотез уже сложившегося бизнеса, так как это просто, быстро и дешево. Tilda, Wix, Ucoz, Umi и другие, их очень много. Я люблю «Тильду».

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

2. Готовые решения, где разработка адаптирует сборку под вас.

Если вам нужен типовой, но персонализированный под вас дизайн, у вас есть задача синхронизировать CMS со внутренней IT-системой или использовать сторонние автоматизированные сервисы (API), лучше подойдет единый пакет CMS + Framework и монолитная конструкция сайта.

Примеры: Drupal, WordPress, Битрикс и Adobe Experience Manager (AEM) или Adobe Commerce (бывш. Adobe Magento); раньше популярных было значительно больше ― Joomla, Typo3 и т.д.)

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

3. Нетиповые решения для работы с данными уже или шире стандартных. Разработка глубоко погружается в бизнес-процессы клиента.

Иногда рентабельнее разработать решение под себя.

Это нужно:
― для персонализированных выборок (например, предлагать корма для животных в зависимости от возраста питомца),
― для сервисов записи, если нет информационной системы (например, для фитнес-клуба или больницы),
―  если есть потребность усилить безопасность из-за частых атак/взломов.

Такое решение необходимо, когда есть потребность в регулярном обмене данными (например? для записи пациентов в больницу, отправки персонализированных уведомлений и рассылок покупателям и т.п.). Тогда можно:
— выбрать готовую информационную систему/сrm, выбрать готовую cms и связать их по api/ настроить обмен json или другими файлами (тогда возвращаемся к п.2.);
— написать под свои задачи по управлению данными бэкэнд, если их немного и они не планируют масштабироваться до предложений готовых решений;
— написать под свои задачи CMS.

Хорошее решение — API Backend + Frontend + административная панель или CMS. Собираем набор из нескольких приложений: одно отвечает за отображение картинки пользователю и выполняется в его браузере, другое исполняется на сервере и работает с данными, базой, CRM и поставляет данные для первого. Для удобства управления снабжается административной панелью или CMS.

Типичный пример такого стека ― Vue.JS + Laravel + OctoberCMS, или Angular + Django + Django CMS. Так как тут нет монолитной конструкции, набор подбирается по конкретным нуждам каждого бизнеса.

Собственное решение (своя разработка) в подавляющем большинстве случаев — дольше, сложнее, дороже и имеет большее число недокументированных особенностей работы системы и дефектов (и особенности, и дефекты часто называют “багами”, хотя это и не совсем верно). У собственного решения обычно ниже интенсивность разработки и беднее документация. Но иногда два ее плюса способны перекрыть все минусы: это гибкость (то есть можно реализовать любые потребности бизнеса, даже необычные) и бизнес-надёжность — аренда может закончиться, контракт не продлиться, партнёр закрыть или продать бизнес, а собственность компании останется с ней.

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

Для IT-проектов, бизнес которых полностью онлайн (Okko, IVI, Lamoda, OZON и других), используют сразу несколько фреймворков, собственные фреймворки и т.д. Их строят внутри IT-компании. Агентство в этом случае нанимать не советуем.

Когда мы выберем техстек, вариантов CMS останется буквально 1-5. И можно будет сравнить.

Критерии те же:

• Ответы на те самые вопросы об использовании сайта, где actor ― команда контент-менеджеров, администраторов и модераторов: какие задачи человек решит с помощью сайта, как он решит эти задачи, какой это человек, с какого девайса он придет, из какой точки мира, как он окажется на сайте/в приложении.

• Бюджет: CMS могут быть платными и бесплатными, с разной стоимостью программной поддержки.