Почему мы стремимся получить клиента на всю жизнь? Когда тебе доверяют техническую сторону продукта еще на самом раннем этапе, а потом год за годом вы растете вместе — это особое чувство.
Я поделюсь историей того, как на протяжении шести лет мы работаем с продуктом из Израиля по аренде недвижимости, который пришел к нам в статусе early stage и за эти годы вырос в уверенную и самостоятельную компанию.
Многие думают, что отношения длиной в шесть лет с клиентами могут начаться только с какой-то магии или счастливой случайности. На практике же все куда более приземленно. Нам поступил типовой запрос: «Нужна оценка проекта». И краткое описание того, что клиент ожидает от технической команды. Борьба была не на шутку: мы соревновались не только с Украиной, были и ребята из Беларуси и России, даже с Кипра.
UI клиент предоставлял со своей стороны, поэтому с нас была исключительно техническая часть: работы по фронтенду и бэкенду. Но, как потом оказалось, одним из решающих факторов стало то, что в нашей компании есть полный спектр услуг, начиная от сбора требований (BA) до DevOps, SEO и маркетинга, UX/UI.
Клиент также сам собеседовал кандидатов в команду. СТО со стороны клиента особое внимание обращал на soft skills: умение работать в команде, отзывчивость, заинтересованность в работе над продуктом, открытость к вызовам. При найме ребят в Artjoker мы тоже смотрим на эти качества, так что нужные люди быстро нашлись. Мы показали ряд наших специалистов, и практически всех их приняли.
Нашим важным преимуществом было и прозрачное описание процессов взаимодействия технической команды с клиентом (по сути, это типовая аутстаффинговая модель, с менеджментом на стороне заказчика). Наше видение совпало с видением клиента, и мы ударили по рукам.
Долгосрочные планы были амбициозными: не только сделать платформу для поиска недвижимости, но и создать компанию уровня Airbnb с огромным количеством своих решений, так что выбор стека был непростым и ответственным. СТО клиента провел исследование лучших технологий для стартапа. Они должны были соответствовать ряду критериев: гибкость, расширяемость, перспективность, сильное и развитое комьюнити.
Vue.js тогда только набирал обороты, Backbone.js и AngularJS уже морально устарели, а Angular 2 представлял собой еще очень сырую бету. А вот React уже занял отличные позиции. С Node.js похожая история — платформа отлично себя зарекомендовала для создания стартапов, где гибкость и скорость имеют решающее значение.
Так что мы решили использовать React для фронтенда и Node.js для бэкенда. В бэкенде также использовали MongoDB и Express, а вот дальше уже идут интересные архитектурные подходы, которые нужны были проекту.
Сперва это был просто монолит. Первым шагом были разделены бэкенд, фронтенд и админка. Дальше мы решили, что нужно идти по пути деления на сервисы, но со временем оказалось, что у них есть схожесть в повторяющихся элементах, так что решили сделать отдельный бойлерплейт, который дальше и стал основой.
Мы заложили базовую логику, которую каждый сервис расширяет по необходимости. Например, если нам нужно обновить версию MongoDB, то мы это делаем только в бойлерплейте, а остальные сервисы уже подтягивают эти изменения. Сам бойлерплейт идет уже как npm-пакет.
По итогу у нас есть следующие сервисы:
Что касается DevOps, то в 2016-м мы уже активно дружили с Docker и AWS. Тогда для нас вызовом стало все контейнезировать и настроить общение между сервисами. Для этого использовали ECS.
Поскольку изначально стек был подходящим, а мы в процессе постоянно улучшаем функционал и архитектуру, то у нас нет ощущения, что стек устарел. Единственное, что скоро уже пора будет делать, — это обновление версии React на фронтенде. В новых версиях сам React лучше работает, но его смена грозит переписыванием большого объема кода.
В начале было много подготовительной работы. Нужно было настроить всю инфраструктуру, спроектировать базу. Это требовало времени и ресурса. Но без этого нельзя стартовать, так как от правильной архитектуры и инфраструктуры зависит буквально все: сроки, качество, возможность сделать задуманное.
СТО на стороне клиента принимал все ключевые технические решения. Управление командой он тоже взял на себя. Хотя и я был вовлечен в курирование ребят по проекту, но если рассмотреть модель Scrum, то я был в роли скрам-мастера, а клиент — product owner.
В 2015 году методология Scrum в Украине была еще не так популярна, а мы в компании большинство проектов вели по Waterfall (каскадная модель, когда новый этап следует после завершения предыдущего). Поэтому для нас Scrum оказался тем еще челленджем. Я сразу же записался на курсы по получению сертификации скрам-мастера, мы начали внутренний тренинг по Scrum в компании. В общем, шли на опережение.
Забегая вперед: проект в итоге стал для нас эталоном того, как нужно организовывать стартапы и планировать свое развитие на ближайшие годы.
Так вот, над созданием MVP мы работали «четенько по скраму», а именно:
За первые полгода, которые как раз и делался MVP, клиент несколько раз приезжал в Харьков к команде. Для СТО было очень важно живое общение. Он проводил личные встречи с каждым членом команды, узнавал, как тот видит развитие проекта, и по итогам одной из таких бесед даже принял решение заменить одного из бойцов.
Не обходилось и без трудностей. Самое интересное началось, когда команда начала показывать много функциональности (ведь неделю за неделей мы усердно работали). Много времени занимали задачи по карте и функциям, связанным с поиском. Приходилось ломать голову, чтобы продумать все кейсы взаимодействия, которые нельзя просто так показать на прототипах.
Мы несколько раз летали к ребятам в гости на встречи и были этому очень рады, ведь можно было получить настоящий опыт в иностранной компании.
Конечно, все мы разные и особенностей полно. К примеру, команда из Израиля уходила на выходные в пятницу, а возвращалась в воскресенье. Мы решили, что не будем менять традиции, и все отдыхали в привычные для себя дни. Так что ребята подстраивались под нас и старались отвечать нам в пятницу.
Также мы были в курсе всех праздников в Израиле, и нам очень нравилось их обсуждать и интересоваться особенностями.
Очень интересными были для нас особенности быта в Израиле. Так как мы все-таки делаем сервис для продажи и аренды квартир, нам пришлось познать все нюансы строений, расположений комнат, санузлов и т.д.
Одним из интересных фактов оказалось наличие бомбоубежища практически в каждой квартире. Оно обычно находится в центре дома, чтобы максимально защитить жителей, находящихся внутри.
Еще из интересного: в Израиле есть такое понятие, как половина комнаты, то есть, в объявлении так и пишут: например, «2,5 комнаты». Всем внимательным, кто дочитал до этого места, предлагаю написать ваши предположения о том, что это значит, в комментариях.
Когда мы выкатили MVP, возникла необходимость работать еще и над продвижением сайта. Так как у нас есть целый отдел маркетинга, мы предложили свои услуги.
Нашими целями были:
Мы запустили контекстную рекламу в Google и Facebook. За 12 месяцев активной работы получили 398 579 просмотров квартир. Здесь мы подробно писали об этом кейсе.
Языки рекламных кампаний были такие: иврит, английский, французский, русский. Особенно было интересно настраивать контекстную рекламу на иврите, без знания языка. Привлекали носителей, куда уж без этого!
В это время интересно было наблюдать и за планами клиента. СТО регулярно проводил для команды презентации, в которых доносил цели, список новых фич или кардинальные изменения в них, а иногда даже в архитектуре приложения.
Такие повороты вполне нормальны для стартапа. Ведь только работая с живым рынком и собирая обратную связь, понимаешь, куда нужно двигаться. И не все гипотезы, которые уже запрограммированы, подтверждаются на практике. Нужно быть готовым многое переделывать.
Мы продолжаем работать над продуктом. За время его жизни было несколько редизайнов, глобально изменилась логика некоторых фич. Расскажу о ключевых функциях, которые мы добавляли или еще планируем добавить в проект:
Когда проект стал уверенно стоять на ногах, ждал очередной вызов — смена СТО. Так как он был одним из ключевых драйверов проекта, этот факт было принять нелегко. Основная техническая команда переживала этот период сложно — все-таки налаженная коммуникация была под угрозой.
Моей задачей было дать максимальную поддержку ребятам, сгладить стресс. Я много и подолгу общался с каждым индивидуально. Были тимбилдинги с пивом и пиццей, где все могли выговориться. Команда показала большую сплоченность и в работе, взяв на себя ответственность за те задачи, которые решал СТО.
Например, наш бэкенд-разработчик вырос просто на глазах в этот период и взял больше зон ответственности, в частности — деплой проекта и поддержку жизненно необходимой инфраструктуры.
Ключевой вывод, который мы сделали из этого опыта: когда из команды уходит драйвер, очень важно быстро взять лидерскую роль на себя, а также поддержать людей, показать им, что проект продолжается и впереди только победы.
If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…
