Меня зовут Илья Китанин, я более 7 лет руковожу разработкой в различных компаниях, сейчас — в Преакселераторе ФРИИ. В этой статье я расскажу, как с помощью HADI-циклов и Теории ограничений Голдратта (TOC) мы смогли вырастить ключевые показатели сервиса Cofoundit в 7 раз за 3 месяца и продолжаем активно расти сейчас. В этом материале — кейсы применения методологии ФРИИ, грабли, которые мы прошли, и необходимый минимум теории.
Cofoundit — это внутренний стартап ФРИИ для подбора сотрудников и сооснователей в команду, где стартапы и кандидаты могут быстро найти друг друга и вместе побежать к международной компании.
Я с моей коллегой Юлей Копыловой начали заниматься этим сервисом 15 марта этого года. Сервис существовал уже полгода, но значимых результатов не показывал. И перед нами стояла задача до 1 июля доказать состоятельность сервиса. Для этого необходимо было кратно увеличить количество закрытых вакансий в месяц, а также ускорить этот процесс.
Как это обычно бывает, перед нами стояло несколько ограничений:
- Сроки: как я писал выше, надо было успеть показать результат к 1 июля.
- Время: я и Юля продолжили выполнять наши основные задачи, а сервисом занимались только в свободное время. Я руководил разработкой, а Юля выполняла обязанности аккаунт-менеджера.
- Бюджет на разработку был знатно ограничен.
Дано: что из себя представлял сервис, когда мы взялись за него
Механика была следующая:
Стартап заполнял анкету Преакселератора и в блоке «Команда» создавал вакансию.
Примеры вопросов анкеты для стартапа
Потом шла автоматическая проверка на минимальные требования (что у стартапа есть прототип, и спрос на продукт проверен) — и заявка отправлялась на ручную модерацию Юле. Только когда модерация проходила успешно, вакансия создавалась и становилась доступной для подбора кандидатов.
Со стороны кандидата путь был чуть проще: он заполнял небольшую анкету, где отвечал на несколько вопросов и прикреплял своё резюме. После этого он видел не более 5 вакансий, каждой из которых он мог отказать (нажать «не интересно») или заинтересоваться (лайкнуть), после этого выбрать предполагаемое время встречи. Стартапу при этом уходило письмо, что им заинтересовался кандидат.
Стартап назначал встречу и уже после встречи решал, продолжается ли их с кандидатом общение, и в каком формате — начали работать вместе (произошел match, вакансия закрылась), кандидат получил тестовое задание, или стартап назначил вторую встречу.
При такой механике ключевые показатели сервиса были недостаточно хороши:
- 11 закрытых вакансий в квартал;
- Среднее время до первой заинтересованности кандидатом (лайка) — 48 дней.
Решение: инструмент HADI-циклов и методология ТОС для быстрого тестирования и приоритизации гипотез
Посмотрев на стоящие перед нами цели и ограничения, мы решили использовать инструмент HADI-циклов, по которому работают стартапы Акселератора ФРИИ.
HADI-циклы — это очень простая методика проверки гипотез, которая состоит из 4 этапов:
- Постановка Гипотезы,
- Действия по её реализации,
- Сбор данных о качестве работы гипотезы,
- Выводы о результате работы гипотезы, могут включать некоторые следующие гипотезы.
Самое главное тут — тестировать как можно больше различных гипотез как можно быстрее. Если даже гипотеза не сработала — ничего страшного, важно быстро от неё отказаться и начать тестировать новые.
Сложность здесь — определить, какие гипотезы стоит тестировать первыми. Для приоритизации гипотез мы решили использовать часть Теории Ограничений Голдратта (ТОС), связанную с определением узких мест. Для понимания этой методологии в Акселераторе стартапам рекомендуют к прочтению книгу Голдратта «Цель».
ТОС — также достаточно простая методология, для повышения пропускной способности системы (=повышения результативности какого-либо процесса) по ней необходимо:
- Найти «узкое место» — ограничение системы, на котором «застревает» процесс производства (или какой-то иной), т.е. накапливаются задачи,
- Решить, как максимально использовать «мощность» этого ограничения,
- Подчинить систему этому решению (=сделать так, чтобы «мощность» ограничения не простаивала),
- Расширить ограничение,
- Если ограничение устранено, вернуться к шагу 1. Если необходимо еще расширить — к шагу 4.
Мы использовали именно эти 2 методологии, так как HADI-циклы идеально подходят для быстрого роста показателей, а TOC помогает определиться с тем, какую именно гипотезу тестировать в первую очередь.
Для начала мы решили определить ограничения или «узкие места» системы, для этого подняли и проанализировали всю статистику, которая на тот момент собиралась (оказалось, что и тут у нас были ограничения).
И сразу увидели 2 «узких места», где срезается конверсия.
- Стартапы хорошо отвечают на лайки кандидатов только первые 5 дней после публикации вакансии, а дальше отвечают в 2,5 раза хуже.
- Кандидаты хорошо открывают письма с переподбором (=похожими вакансиями), но очень редко переходят в профили стартапов после просмотра этих писем.
Гипотеза 1. По 1-ой проблеме мы решили выкидывать из подбора те стартапы, которые не отвечают кандидатам более двух недель. Нам сразу хотелось сделать красивое решение, где мы сможем часть стартапов выделить в отдельный сегмент и автоматически отправлять им письма, мотивирующие их вернуться в систему. Но наша цель была БЫСТРО протестировать гипотезу — и в лучших традициях MVP мы просто убрали часть проектов из подборки. Реализацию дополнительного функционала отложили до момента, когда уже проверим, сработала гипотеза или нет — увеличилась ли конверсия в ответы кандидатам после наших действий.
Гипотеза 2. По 2-ой проблеме мы не знали причину и решили заставить кандидатов переходить из письма в систему (где мы сможем узнать, какие именно стартапы он просмотрел и т.д.), чтобы собрать больше статистики. Мы убрали из писем описания проектов и предложили пользователю перейти в систему, чтобы их посмотреть.
Было
Стало
Таким образом получили первые две гипотезы на проверку.
Гипотеза 3. Также добавили 3-ю гипотезу — убрать механизм премодерации, это должно было высвободить время Юли, которая занималась ручным просмотром проектов, и ускорить попадание вакансий в подбор. В результате стартапам не нужно будет ожидать проверки, а время от момента создания вакансии до начала подбора сократится от 2-3 дней до 4 часов.
Пока шла разработка по этим трем гипотезам, нам надо было придумать новые — для непрерывной работы над продуктом, чтобы не простаивала разработка. При этом желательно, чтобы новые гипотезы не пересекались с предыдущими — влияли на другие метрики.
Гипотеза 4. Мы решили сделать «безопасную задачу», которая никак не может повлиять на метрики предыдущих гипотез, — расширить статистику с расчетом на то, что она позволит нам в будущем быстрее и лучше проверять гипотезы. Мы добавили в аналитику информацию о том, смотрел ли кандидат вакансию и когда именно. Тем самым мы смогли разбить конверсию из подобранных вакансий в «лайки» на две:
1) из подобранных — в просмотренные,
2) из просмотренных — в «лайки».
Эту задачу сложно назвать гипотезой по HADI, но она была необходима нам для построения следующих гипотез.
Гипотеза 5. Добавить мотивацию стартапам выставлять статус, что они работают с кандидатом. Мы решили добавить в письмо по итогам собеседования «бонус»: стартапы, которые выставили в профиле статус, что они работают с кандидатом, получат бесплатную 3-х недельную программу по развитию бизнеса. Это должно было увеличить количество закрытых вакансий в системе — до этого приходилось дополнительно обзванивать стартапы и выставлять статусы вручную.
Гипотеза 6. И мы не смогли удержаться и добавили гипотезу, также влияющую на скорость получения лайка стартапом: присылать кандидатам повторные подборки вакансий не 1 раз в неделю, а 2. Тем самым хотели увеличить количество лайков в неделю, а также ускорить этот процесс.
Наши первые гипотезы показали очень хороший результат, улучшения были даже лучше, чем мы ожидали. Количество лайков в неделю выросло на 45%, конверсия во встречи — на 60%.
Приоритизация гипотез с помощью «плеча» метрик
Мы тестировали довольно много гипотез, и нам требовался более понятный и надежный инструмент для их приоритизации — закончились очевидные «узкие места», которые надо улучшать в первую очередь, и требовался более системный подход к определению «узких мест» и выбору гипотез для тестирования.
Мы вспомнили об основном инструменте Акселератора для приоритизации гипотез — это расчет unit-экономики и «плеча» метрик. Чтобы определить, на какой показатель эффективнее всего влиять при тестировании гипотез, на основе текущих данных прогнозируется изменение показателей системы при влиянии на каждую метрику.
Для этого мы построили «карту возможного будущего» — таблицу, которая прогнозирует изменение главного для нас параметра при росте каждой из конверсий перехода кандидата по воронке до значения, в которое мы верим.
Мы посчитали, что главным для нас параметром является количество новых кандидатов, необходимых для одного закрытия вакансии, посчитали показатели сервиса на тот момент, построили формулы и получили следующую таблицу:
Из таблицы мы увидели, что наиболее важными в тот момент показателями для нас были конверсия в match (закрытие вакансии) и конверсия в анкету, — они должны принести максимальный эффект. Мы начали работать над гипотезами, влияющими на эти параметры.
Для тестирования гипотез на постоянной основе нам надо было придумать удобный инструментарий для их ведения. Спустя несколько итераций мы пришли к следующему формату:
- Описываем гипотезу, которую хотим проверить.
- Действие — как именно мы хотим её проверить.
- Метрика, на которую хотим повлиять.
- Ожидаемый эффект по росту данной метрики.
- Планируемая дата релиза (чтобы не тестировать гипотезы, влияющие на одну и ту же метрику, параллельно).
- Фактическая дата реализации — старта тестирования гипотезы.
- Дата, когда посчитаем эффект (устанавливается исходя из необходимого количества данных и времени на их сбор, также нужна, чтобы не тестировать гипотезы, влияющие на одну и ту же метрику, параллельно).
- Полученный эффект (как изменилась метрика в результате).
- Следующие шаги — здесь пишем о том, какие выводы сделали по итогу проверки гипотезы.
Результат: семикратный рост количества совпадений — ключевого показателя
В итоге за 3 месяца мы протестировали 22 гипотезы (больше не смогли из-за ограничений в бюджете разработки), что является очень неплохим показателем.
4 из них были настоящим прорывом, только 1 ухудшила показатели системы, а остальные дали относительно небольшой рост. Это позволило улучшить показатели до:
И к 1 июля мы смогли доказать ценность сервиса для Фонда и продолжить развивать его, сильно снизив градус напряжения и заметно уменьшив все ограничения. Перед нами перестал маячить дедлайн, с Юли сняли другие задачи и согласовали новый бюджет на разработку.
Что мы делали не так — выводы
В процессе работы над проектом мы совершили 3 ошибки, от которых хотим предостеречь другие стартапы:
1. Не хотели отказываться от неподтвержденных гипотез
У нас была гипотеза, которую мы очень любили.
Раньше кандидат при заполнении анкеты прикреплял своё резюме — и только потом мог посмотреть стартапы с открытыми вакансиями.
Мы предположили, что если убрать шаг прикрепления резюме из анкеты и запрашивать его у кандидата уже после того, как он заинтересовался стартапом, то кандидаты будут охотнее прикреплять резюме. Но вышло с точностью до наоборот: конверсия в заполнение резюме знатно упала.
Тем не менее, гипотеза была нам очень дорога, и мы не были готовы от неё так просто отказаться. Мы начали копать внутрь данных и убеждать себя, что кандидаты начали оставлять более качественные резюме. Находить причины, почему падение конверсии тут для нас не критично, придумывать, как мы можем жить с этим.
Всё это был самообман — в сентябре мы наконец вернули резюме обратно. На это решение мы потратили 3 месяца. 3 месяца, Карл! То есть наш сервис хуже работал целый квартал.
2. Не декомпозировали гипотезы
У нас было предположение, что подогревающие письма в разные моменты жизненного пути кандидата и стартапа в сервисе помогут увеличить конверсию на всех этапах. Это действительно оказалось так, но в чем же ошибка?
Мы на самом деле тестировали несколько гипотез в рамках одной. Каждое отдельное письмо — это гипотеза.
Чтобы начать проверку этой гипотезы, мы потратили почти месяц: неделю искали с Юлей время для двухчасовой встречи, 3-4 дня готовили ТЗ и сами письма, а еще полторы недели разработчики реализовывали функционал отправки писем по событию.
Если бы мы тестировали отдельно каждое письмо, то смогли бы получить первый результат уже через 2 дня после постановки гипотезы. И точно узнать, какое письмо сработало, какое нет, и почему. Поэтому несмотря на то, что гипотеза сработала и показала неплохой прирост показателей, считать её однозначно успешной нельзя. Если бы мы чуть аккуратнее подошли к процессу — вероятно, получили бы больший рост и быстрее.
3. Тестировали связанные гипотезы, которые влияют на один и тот же показатель
Мы были уверены, что этого не делаем. Когда мы добавляли мотивацию с помощью 3-х недельной программы по развитию бизнеса, конверсия в закрытие вакансии сильно возросла. Потом мы методично уменьшали стоимость мотивации для нас, пока не убрали её совсем. При этом конверсия не падала!
Мы аккуратно разобрали статистику и выяснили, что гипотеза «Убрать неактивные стартапы из подбора» повлияла и на конверсию в закрытие вакансии (match) — остались более мотивированные команды, и они не только чаще отвечали лайкнувшим их кандидатам, но и выставляли статусы после встречи.
Резюмируя:
- HADI-циклы — эффективный инструмент для развития бизнеса!
- Тестируйте гипотезы как можно быстрее, для приоритизации можно использовать инструмент измерения «плеча» метрики.
- Не допускайте наших ошибок:
a. Будьте решительны с неподтвержденными гипотезами,
b. Декомпозируйте гипотезы,
c. Не тестируйте связанные гипотезы, влияющие на одну метрику.
