От продуктовых фич к техническим деталям: как с ростом компании сместились наши приоритеты в разработке

Привет! Это Орловецкая Наталья, я отвечаю за развитие сайта застройщика Level Group. Рассказываю, как мы за 7 лет дошли от стартапа к топ-3 застройщику, как при этом сместились наши приоритеты в разработке и причем здесь аудит.

Level Group — одна из самых быстрорастущих компаний на рынке недвижимости. Мы начинали в 2016 году с одного жилого комплекса Level Кутузовский, сейчас в портфеле уже 20 проектов классов делюкс, бизнес и комфорт.

С 2019 года выручка компании выросла в семь раз, объём портфеля проектов — в 2,5 раза. Я пришла в компанию в 2018 году, когда текущая команда готовилась к запуску MVP сайта. Он должен был успевать за ростом компании.

Для начала расскажу, какие особенности рынка недвижимости влияют на разработку сайта застройщика.

Каждый товар уникален

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

Клиенты покупают исходя из УТП продукта, а не удобства сайта

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

Я с этим утверждением не согласна. Но тем не менее для нас первостепенно донести продуктовые фичи самих ЖК, а не конкурировать за счёт прикольных фишек на сайте.

Сложно выработать шаблонные решения

Поскольку каждый ЖК уникален, на новых объектах постоянно появляются новые особенности. Например, недавно появились таунхаусы. Их нужно продавать не так как квартиры, следовательно, необходимо переделывать фильтры поиска под них.

Большинство покупателей — новички

Для большинства клиентов опыт взаимодействия с нами оказывается первым. Если покупка и повторится в будущем, то не в ближайшие 5-10 лет.

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

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

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

Я пришла в компанию в 2018 году: в 2019 году мы запустили MVP. В нём были лишь самые необходимые для застройщика фичи: главная, страницы двух ЖК, фильтр квартир, ход строительства, раздел о компании, контакты, новости, акции, расчёт ипотеки и рассрочки, вакансии.

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

Правило №1. Делаем только фичи, влияющие на продажи

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

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

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

В итоге при выборе между фичей, которая влияет на продажи не напрямую, и той, которая делает это явно, мы выбираем второе.

Правило №2. Фичи должны окупаться не дольше года

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

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

Пример: в рамках развития личного кабинета брокеров есть две ключевых задачи:

Потенциально окупиться могут обе фичи.

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

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

Правило №3. Сначала запускаем фичи, а потом доводим их до 100% готовности

20% усилий дают 80% результата, поэтому мы максимально быстро запускаем MVP для проверки гипотез.

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

За два месяца мы реализовали две фичи: отказались от подписания договора бронирования на бумаге — перенесли всё в онлайн и сделали возможность записи на онлайн-консультации в zoom.

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

Когда на сайте было мало функций, добавление каждой фичи давало сильный буст. Теперь новые фичи не дают такого мощного роста, который хотелось бы.

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

В итоге мы начали искать новые точки роста, которые лежат в плоскости «вглубь», а не «вширь».

Мы определили для себя следующие зоны роста — параметры, которые мы можем улучшить так, чтобы это принесло эффект.

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

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

Детали того, чем отличается хороший аудит от плохого, читайте в статье KTS.

После аудита я вынесла для себя следующие моменты:

SLA нужен не только по технической поддержке, но и по качеству кода

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

Ещё желательно, чтобы на стороне заказчика был человек, который смотрит на код и знает его.

Важно периодически проводить повторный аудит

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

Это можно сравнить с медленно развивающейся простудой: понять, в какой именно момент нужно начинать пить антибиотики тяжело. Поход к врачу может помочь объективно определить стадию развития болезни и назначить лечение.

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

Важно форсировать агентство на обсуждение вариантов технической реализации задач

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

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

Необходимо попутно проводить рефакторинг кода при доработке старых фич

При высоких темпах роста самый оптимальный процесс поддержания кодовой базы в нормальном состоянии — попутное исправление проблем вместе с изменением кода в исправляемом разделе.

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

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

Кроме production и development серверов необходим Stage, а также динамические окружения

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

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

Схема работы со stage сервером

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

Схема работы с динамическими окружениями

Регулярные код-ревью и использование линтеров

Практика код-ревью (проверки кода) коллегами-разработчиками нужна для решения двух задач:

Проведение технических спринтов

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

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

Важно заранее закладывать бюджеты на регулярные технические спринты. Мы решили проводить его раз в квартал.

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

***

Кстати, у нас сейчас много открытых вакансий в команду сайта — ищите здесь. Буду ждать ваши резюме:)