Устойчивое развитие веб- и мобильных сервисов: что это и почему его нельзя останавливать

Разработка и запуск проекта — это лишь первый этап его существования. За ним следуют поддержка и развитие. Если развития нет — в скором времени проекта тоже может не стать.

Любой веб-сервис — это сайт, но не любой сайт является веб-сервисом.

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

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

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

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

При этом важно учитывать разницу между развитием функционала и поддержкой.

Развитие функционала часто строится по методологии HADI-циклов. HADI — это метод исследования, который включает в себя четыре этапа: формулирование гипотезы (H), действие (A), сбор данных (D), выводы (I).

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

Действие. На этапе разработки нового функционала создается минимально жизнеспособный продукт — MVP. Например, в карточку товара рядом с кнопкой «Добавить в корзину» можно поставить еще одну — «Оформить заказ в 1 клик».

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

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

При работе над проектом недостаточно просто разработать стратегию, составить список гипотез и пойти их проверять. Важно понимать, какая из задач находится в приоритете. Это помогут сделать две методологии — RICE и ICE.

В RICE оцениваются четыре фактора:

• охват (R) — количество людей, которых коснется продукт;
• влияние (I) — насколько положительно нововведение повлияет на клиентов;
• уверенность в оценке (C) — процентное значение того, насколько вы убеждены в ценности продукта;
• трудозатраты (E) — оценка того, сколько времени и сил уйдет на реализацию.

В ICE фактора всего три: влияние (I), уверенность в оценке (C), легкость (E) — насколько легко будет реализовать стратегию.

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

По опыту агентства IBRUSH, стоит обращать внимание на два основных ресурса.

Деньги. В отрыве от конкретного сервиса невозможно сказать, сколько денег понадобится на его развитие. Например, условная «Яндекс Еда» или «Самокат» тратят неприлично много, но для них стратегия опережающего развития важнее денег. Им не так важна операционная прибыль, но они постоянно находятся в инфополе.

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

Команда. Для развития сервиса нужны:

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

При этом развивать сервис можно в двух форматах — командой инхаус или на аутсорсе.

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

Если говорить о прикладных методологиях и инструментах, которые мы сейчас используем на стороне маркетинга и разработки веб-сервисов, я выделяю пять:

• agile-подход и недельные спринты;
• разработка MVP и улучшение итерациями;
• mobile first;
• А/Б тестирование гипотез, тут важны корректные метрики, конечно;
• исследования аудитории.

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

Или возьмем популярный meal-kit-сервис доставки продуктов с рецептами «Ужин дома», который постоянно наращивает аудиторию и лояльных покупателей. Ниже на иллюстрации видно, насколько изменился сервис за несколько лет. Даже такие мелкие изменения, как подсказки адреса в поле при оформлении заказа улучшают конверсию.

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

Развитие сервиса — это постоянное улучшение и расширение его возможностей.

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

Эффективно развивать функционал сервиса позволяет методология HADI, а также методологии приоритизации задач — RICE и ICE.