«Любая технология должна делать жизнь пользователя легче, все остальное нужно быстро „убивать“». Как стартапам создавать инновации

У Беларуси высокий потенциал в R&D (Research & Development, научно-исследовательские и опытно-конструкторские работы). Для запуска технологических стартапов в стране есть талантливые IT-кадры и экосистема. Но ключевую роль в развитии новых компаний сегодня играет технологическая база. Сооснователь и директор по IT сервиса кикшеринга Whoosh Егор Баяндин, рассказал «Про бизнес», как его компания перешла в фазу быстрого роста благодаря R&D, и подсказал, как создавать новые фичи, а также откуда брать идеи для привлечения клиента.

---

— Классический цикл R&D включает в себя создание гипотез, их тестирование, реализацию и повторное тестирование на пользователях. Сама схема работает одинаково почти во всех отраслях, но внутри каждого из этапов есть своя специфика.

Сложности производства

Продолжительность цикла R&D разнится в зависимости от типа продукта: материальный, который можно «потрогать», или IT-разработка, существующая только виртуально. У первого цикл, как правило, длиннее, ведь недостаточно просто обновить мобильное приложение, — нужно произвести новые элементы или детали и установить их на все устройства.

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

Диалог с местными властями

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

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

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

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

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

Быстро провалиться — быстро победить

В классическом R&D за этапом создания гипотез следует A/B-тестирование — эксперимент, который позволяет выявить, какая из двух прорабатываемых версий лучшая. Но если рынок и сам продукт находятся в фазе активного роста, стадия тестирования может выпадать из цикла. В такие моменты зачастую скорость разработки важнее, поэтому A/B-тесты во многих случаях лучше заменить на методы «fail fast» и «quick wins». Суть этого подхода в следующем: вместо того, чтобы тратить много времени на проверку нескольких гипотез, лучше сделать что-то небольшое, что даст вам преимущество уже сейчас и значительно улучшит параметры продукта. Затем отслеживать, востребован ли новый функционал у пользователей, правильно ли он работает. Доработать некоторые параметры можно уже «в полях», когда решение внедрено. А если окажется, что обновление пользователям неинтересно, — его можно быстро убрать.

Любую новую идею лучше обсуждать с менеджерами по продукту. Это позволяет проверить, имеет ли ваша гипотеза смысл для развития сервиса. В любом R&D важно понять, как новый функционал будет встраиваться в реальный пользовательский опыт — поэтому технологическая команда всегда должна работать с остальными командами, в том числе операционной и отвечающей за развитие сервиса как продукта. Если продуктовый отдел одобрил идею, начинается ее комплексный анализ: оценивается сложность реализации, экономический эффект, риски и многие другие факторы. Уже после этого можно делать выводы: стоит ли использовать метод quick wins — или требуется полноценное тестирование.

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

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

Генерация идей

Идеи по разработке новых функций не приходят из ниоткуда: почти всегда у них есть свое обоснование. Рассмотрим основные источники гипотез, которые достаточно типичны для любого R&D — это аналитика, пользовательский и личный опыт.

Аналитика

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

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

Пользовательский опыт

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

Собственный пользовательский опыт

Пожалуй, это не самый частый источник генерации идей в R&D, но он играет большую роль. Если сотрудники сами пользуются продуктом, многие недостатки и достоинства очевидны им как клиентам.

Мы часто получаем идеи из разных регионов нашего присутствия — нередко местные команды внедряют свои ноу-хау и делятся ими со всей компанией.

Резюме для стартапов

В целом технологическим стартапам можно посоветовать 5 правил:

• Старайтесь сразу по максимуму оснастить ваш продукт, чтобы минимизировать необходимость технического обновления в будущем.
• Не тратьте время на A/B-тесты на этапе роста продукта: выбирайте оптимальное решение, тестируйте с клиентами и уже на практике смотрите, что можно улучшить.
• Все идеи должны быть согласованы с вашей собственной операционной командой, а нововведения, для которых еще не существует «правил игры», необходимо обсуждать с властями.
• Обмен опытом между представителями регионов и подразделений — хороший драйвер развития продукта.
• Источников идей для стартаперов много: анализ рынка и международного опыта, мониторинг конкурентов, адаптация решений из смежных отраслей. Важно, чтобы все эти идеи подтверждали свою эффективность на практике. Нет смысла развивать технологии ради технологий: они должны служить улучшению пользовательского опыта и развитию продукта.