Колонки

«Пользователю не нужно прямо сейчас все, что задумано»: на чем сосредоточиться на старте разработки SaaS-продукта?

Колонки
Алексей Тактаров
Алексей Тактаров

Сооснователь Resume.io, один из создателей сообщества Code Hipsters

Ирина Печёрская

По словам Алексея Тактарова, сооснователя конструктора резюме Resume.io, можно увлеченно «пилить» продукт на кухне небольшой компанией друзей, нанять опытную команду из студии или взять одного-двух разработчиков в штат, но в любом случае встанет вопрос: какие функции включить в первую версию продукта, а какие — отложить до тех времен, когда и денег, и людей в проекте будет больше. 

В своей колонке Алексей Тактаров и Тихон Белоусько, сооснователь Resume.io, рассказали, какой путь в разработке SaaS-продукта прошли они. В их случае точка старта не студийная команда или штатные сотрудники — поначалу предприниматели делали проект своими силами: Алексей отвечал за разработку, а Тихон — за дизайн. 

Сейчас, спустя пять лет, в их продуктовой команде уже больше 20 человек, а летом 2021 года компанию купил американский холдинг Talent Inc. Большую роль в сделке сыграло то, как был написан код и подготовлена техническая документация.

«Пользователю не нужно прямо сейчас все, что задумано»: на чем сосредоточиться на старте разработки SaaS-продукта?

Первая итерация: пользователю не нужно прямо сейчас все то, что задумал основатель 

У нашего партнера, голландского предпринимателя Менно Олсторна, было четкое видение, какой стартап он хочет запустить: пользователь оплачивает подписку, получает доступ к десятку шаблонов резюме, а команда может в любой момент локализовать сервис под новую страну через административную панель. Более того, Менно даже сам нарисовал примерные интерфейсы с помощью Balsamiq, чтобы показать нам все от и до. 

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

 

Самая первая версия редактора, 2016 год

 

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

Дальше мы уговорили Менно остановиться только на одном, самом базовом, шаблоне резюме. Этого будет достаточно, чтобы проверить, закрывает ли продукт проблему пользователя. Он заходит в сервис, заполняет шаблон своими данными и нажимает на кнопку «Скачать» — на этом все.

А вот подписку, несмотря на упрощенную реализацию редактора резюме, мы запустили сразу. Делали это через Stripe — у них удобный SDK (software development kit, набор библиотек для реализации стандартных сценариев), и виджет оплаты на сайт подключается за 10 минут. Они сами занимаются валидацией формата карт, 3-D Secure — нам надо было только вставить код на сайт. 

Многим кажется, что просить оплату за сервис, который очевидно не идеален, периодически «падает» и не выглядит таким же аккуратным, как сервисы конкурентов, — стыдно. Мы так не считали — для нас в приоритете был быстрый time-to-market. Да, конверсия в оплату тогда получилась низкой, но гораздо важнее для нас было само ее наличие. Кстати, поддержку мобильных устройств мы тоже настроили сразу: пользователей, которым удобнее использовать сервис со смартфонов — большое количество, их нельзя было исключать.

 

Текущая версия редактора

 

Мы с Тихоном не анализировали аналоги и не полагались на прототипы Менно. Если бы пошли таким путем, то без конца бы застревали на разном функционале: «Почему они реализовали его именно так?». Мы же на каждом шаге спрашивали себя: «А каким конструктором резюме стали бы пользоваться сами?». 

Просто представьте, что вы клиент и заходите на сайт своего сервиса — какую кнопку вы первым делом будете искать? Этот подход мы использовали и в других проектах. Очевидно, он не самый профессиональный, но идеально работает для создания MVP. 

Еще одно предложение, которое мы отсекли — возможность приостановить подписку в один клик. Если бы мы взялись реализовывать эту фичу, то запуск пришлось бы отложить минимум на месяц. Гораздо быстрее было оформить текстовый блок «Вы не хотите пользоваться нашим продуктом? Напишите нам, мы поставим подписку на паузу» и поместить его на сайт. 

Вместе с этим отложили на следующие итерацию все контентные составляющие: email-рассылку и блог. Человек приходит в сервис, чтобы решить свою проблему. А узнать планы по обновлению продукта или получить инструкцию, как им пользоваться, при желании можно все тем же способом — написав сообщение в поддержку. Конечно, такое решение разумно только при небольшом количестве клиентов — иначе вам придется брать отдельного человека, чтобы разбирать почту.  

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

 

Дальнейшее развитие: как настроить процессы и какие функции продукта взять в приоритет 

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

Далее мы стали анализировать запросы в поддержку: какие повторяются чаще всего? Их и стали автоматизировать. Например, сделали так, чтобы пользователь мог сам оформить возврат. За все пять лет, что мы работаем, только сейчас нам понадобились дополнительные люди в команду support — до этого со всеми запросами справлялся один человек.

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

Сам процесс работы мы настроили так, чтобы сторонний человек мог легко влиться и разобраться в продукте. Это важно и для онбординга новых сотрудников, и для последующей продажи компании. Мы использовали трекер задач, проводили code review, внимательно писали readme-файл и выводили принципы для дизайн-системы, еще когда продуктовая команда состояла только из нас двоих. 

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

 

Пример того, как мы организуем базу знаний

 

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

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

 

Пара статей из блога

 

Сложности: с какими стоп-факторами мы столкнулись на масштабе

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

План работ разбили на этапы: руководствовались принципом «одна миграция за раз», чтобы снизить риски. Мы хостились в нескольких дата-центрах одновременно в течении двух-трех месяцев. Сначала подготовили код, чтобы его можно было деплоить на несколько машин сразу, затем этот код развернули в новом дата-центре и в текущем — трафик разделили между ними. 

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

Путь развития инфраструктуры можно показать так: ты начинаешь с дорогих решений, которые скрывают от тебя детали и позволяют быстро деплоить код. Обычно это PaaS — Platform as a Service, вроде Heroku, или fly.io, или Vercel. Дальше двигаешься по мере роста в облачные провайдеры AWS, Azure или Google Cloud. 

Они сложнее в конфигурации, нужно заниматься поддержкой, но на нагрузках можно сэкономить. На следующем уровне: строишь свой дата-центр — так делают компании, у которых 1000+ сотрудников. Далеко не всегда это решение оправдано.

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

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

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

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

Причина для этого была в том, что над open source автор работал не full-time, и иногда большие изменения занимали слишком много времени. К тому же половина нашего кода — «обертка» над библиотекой, специфичная для шаблонов резюме. И ее мы не могли выложить в открытый доступ. 

 

Как выстроить процесс: быстро делаем MVP и находим первых пользователей, а потом — замедляемся

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

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

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

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

Фото на обложке: dotshock/shutterstock.com

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Почему комплексный SaaS-продукт принесет бизнесу больше прибыли, чем узкоспециализированный
  2. 2 Корпоративные SaaS-платформы: что это и как помогут бизнесу в турбулентное время
  3. 3 Что такое SaaS простым языком и как облегчить внедрение таких сервисов
  4. 4 Погода мешает дяде Вазгену оплатить ваш сервис
  5. 5 Откуда взялись «облака» и какими они бывают?
AgroCode Hub
Последние новости, актуальные события и нетворкинг в AgroTech-комьюнити — AgroCode Hub
Присоединяйся!

ВОЗМОЖНОСТИ

20 октября 2021

20 октября 2021

20 октября 2021