Путь от молодого стартапа до технологической компании, которая делает высоконагруженные проекты в сфере недвижимости

    На вопросы отвечал Павел Зыков, СТО DomClick.ru

    ДомКлику скоро 5 лет. Давайте немного вспомним историю и заодно познакомимся. Компания была основана в 2015 году. Ты помнишь день, с которого все начиналось?

    Еще как помню. Я входил в число основателей, поэтому помню все в мельчайших деталях – как собеседовали первых людей, как в августе 2015 года сняли первый офис на улице Рабочая, который устраивал нас по цене, несмотря на то, что подоконники кабинетов всегда были в пыли от проходящих рядом поездов. Сейчас, сидя в максимально комфортном Agile Home в 2 минутах от ст. метро Кутузовская, с теплотой вспоминаем о тех временах, когда два интернет — провайдера в здании считалось нашим уникальным преимуществом.

    image

    Как стартовали разработку?

    Пять лет назад сложно было сделать гибкую структуру разработки, т.к. работающих примеров в России практически не было, да и у нас не было опыта, поэтому модель управления производством придумывали сами. И, кстати, придумали. В 2016 году начали измерения показателя Т2М по командам. Потом бросили, т.к. зачем измерять то, что у тебя всегда не превышает 2 недели. Это сейчас scrum с разными доработками — это стандарт, в 2015 году было совсем не так. Практически везде были «водопады» с разной степенью закостенелости процессов.

    Что касается выбора технологий. Мы начинали писать бэкэнд на Java, т.к выросли из банка, а всем известно, что банки просто обожают этот язык. В 2016 году начали целенаправленно формировать экспертизу по Python, т.к. понимали, что у нас, с одной стороны, пока нет хайлоада, а с другой – стоять с другими корпоративными монстрами в очередь за джавистами не хотелось. Когда решили добавить чуть больше производительности – добавили к бэкэнду Go. Еще годом позже изучали американский проект по краудфандингу ипотеки, решение которого было на Ruby. Пришлось взять себе одного рубиста, который чуть позже собрал полноценную большую команду. Итого на текущий момент у нас в бэкэнде Python, Kotlin/Java, Go, Ruby. На фронтэнде доминант у нас React. Также используем Angular и Vue.js для понятных нам проектов.

    image
    График тренда языков в ДомКлик

    Расскажи про основные направления деятельности компании, о чем они?

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

    Сейчас у нас 7 основных направлений:


    image
    Classified объектов недвижимости – это наша витрина объявлений. К слову, до открытия компании у нас бизнес-план был ориентирован на classified, но буквально сразу после старта нас осенило, что нужно начинать с ипотеки.

    image
    Омниканальная ипотека, которая базируется на принципе «в любом удобном для тебя канале подай заявку на ипотеку или получи обслуживание по действующей ипотеке». Это ключевое и сложное направление, на котором трудится много талантливых людей. Процесс ипотеки действительно очень сложный и ты осознаешь масштаб проблем и ограничений, только когда работаешь внутри, тем более с нашими объемами выдач.

    image
    Неипотечная сделка – проведение сделки купли-продажи недвижимости под ключ, если клиент не нуждается в заемных средствах (ипотеке).

    image
    Безопасные расчеты – это по своей сути виртуальная ячейка для сделки между покупателем и продавцом. Весьма удобный способ безналичного взаиморасчета за объект без дополнительных посещений банка.

    image
    Регистрация сделки. Услуга позволяет клиентам зарегистрировать переход права собственности на готовый объект недвижимости без посещения Росреестра или Многофункционального центра предоставления государственных и муниципальных услуг (МФЦ).

    image
    Оценка недвижимости. Мы сотрудничаем с оценочными компаниями по всей России по убер-модели. Т.е. делаем подготовку и передачу в банк отчета об оценке быстро и удобно. Как для клиента, так и для самой оценочной компании.

    image
    Мы так же проверяем документы по сделке и оцениваем риски. Этот продукт называется «гарантия сделки».


    Наверняка за эти пять лет был ряд переломных моментов, которые сделал Домклик таким, какой он есть сейчас. Поделишься деталями?

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

    В 2017 мы взялись за повышение эффективности продуктовой разработки и сделали фокус на изменение структуры команд. Убрали роли QA, PM, аналитиков, scrum — мастеров, оставили роли РО, CJE, Инженеров – только тех, которые создают added value. В моей философии продукт невозможно сделать без 2 людей — владельца продукта (РО), который знает, что делать, и инженера, который, собственно, создает. Остальные роли существуют и-за несовершенства процесса разработки и недостаточной автоматизации.

    Кстати, когда ребята из IT-сферы узнают что в ДомКлике нет тестировщиков, удивляются. Расскажи, что дало решение убрать эту роль из процесса?

    Если подумать, то у нас вся компания – тестировщики. Это для нас роль и ответственность, а не отдельная специальность. Убирая отдельный отдел QA, мы решали простую проблему – ответственность за качество несет вся команда, а не специально выделенные люди, которых становилось больше и процесс тестирования релизов становился дольше. Ребята из QA пытались писать автотесты, но, как показала практика, у них это не получилось, т.к. в этой профессии есть случайные люди, у которых нет даже базового инженерного образования. При всем уважении к настоящим профессионалам своего дела, коих действительно мало. Мы не сдавались, запускали курс обучения разработке, в итоге которого конверсия в обученных была всего около 7%. Большинство, кстати, просто не хотело учиться и покидало компанию. Поэтому провели реорганизацию следующим образом – директор направления разработки отвечает за все, что происходит с его системой – за разработку, тестирование и сопровождение на проде. И дали директорам выбор в развитии команды: хочешь, бери ручных тестировщиков, хочешь – бери разработчиков и учи их писать автотесты. Все выбрали второе. Поэтому теперь за качество отвечает вся команда, которая ведет разработку конкретной системы. В итоге в компании у нас есть всего 1 QA Lead, который отвечает за развитие собственного инструмента UI–тестирования и ставит процесс приемки в командах, где это необходимо. Я думаю, что как-нибудь подробно расскажу про систему разработки в Домклике, наберется на отдельную статью.

    Сейчас во всем ДомКлике более 700 людей. Как менялась и адаптировалась с ростом команды модель управления?

    Это очень хороший и правильный вопрос, над которым не все задумываются. С ростом команды БЕЗУСЛОВНО меняется модель управления. До 100 человек она одна, больше 100 человек – уже другая. Когда команда до сотни, ты знаешь каждого в лицо, 90% ты помнишь как зовут, принимаешь участие практически во всех собеседованиях и очень часто пересекаешься почти с каждым членом команды. Держишь все потоки «на кончиках пальцев». На второй сотне уже, к большому сожалению, не так, это становится уже физически невозможно. Поэтому мы внутри выстроили правильную, на мой взгляд, структуру – у меня 20 человек в непосредственном подчинении, у моих «минус 1» также. При такой модели мы уделяем время каждому инженеру, при этом встречи сугубо личные, чтобы была возможность побеседовать не только о прогрессе задач, но также с глазу на глаз обсудить любую проблему. И конечно, процессы, дэшборбы, KPI’s – без фанатизма, но они есть.

    Вернемся к этапам становления компании такой, какая она есть сейчас. Что было после реструктуризации команд?

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

    Исторически так повелось, что наша команда состоит из двух частей – ООО «Центр недвижимости от Сбербанка» и подразделения ПАО «Сбербанк». После того, как мы переделали всю нашу архитектуру, следующим крайне важным периодом стало становление компании ДомКлик и части Сбербанка, занимающихся ипотекой, как единой команды с единой моделью управления и унификацией многих процессов. Несмотря на разные юридические лица, мы одна большая семья.

    image

    2020 год стал для нас годом интересных инженерных решений – мы перевели на PWA все мобильные приложения, кроме основного приложения ДомКлик. Завезли всех на единый деплой (свой деплой), теперь прикручиваем цивилизованную канарейку. Экспериментируем с Ignite, делаем единый кластер для всей компании и другие интересные решения, о которых я не могу пока что говорить. Подписывайтесь, ставьте лайк и следите за статьями в этом блоге. 


    Назови правила, которых ты придерживаешься в принятии решений.

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



    1. Решение на цифрах, а не на эмоциях или симпатиях к конкретным людям.
    2. У каждого решения должен быть added value.
    3. Помни, кто твой клиент.
    4. Сложные проблемы не решаются просто. Первое решение, которое тебе пришло в голову на сложную проблему, скорее всего, неверное. Возьми паузу и еще раз подумай.
    5. Не решай проблему тем же способом, которым она возникла.

    Ну и подводя итоги, как думаешь, по шкале от молодого горячего стартапа до серьезной государственной структуры, где сейчас находится ДомКлик?

    По 10-балльной шкале от до молодого горячего стартапа до серьезной структуры, ДомКлик сейчас по продуктовой работе и IT change находится на пятерке. Не 0, т.к. у нас есть дизайн-система, core-сервисы, понятный стек, который накладывает ограничения. Нельзя просто так взять и cделать на бутстрапе приложение с красными круглыми кнопками и бэкендом на кложуре да еще и вывести это все в продакшн. Времена, когда было можно, уже, к счастью, прошли.

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

    Мы born – digital компания, поэтому буквально в течение дня проверили профили доступов и пошли на удаленку под ответственность руководителей. Отправляли прежде всего тех, кто сам хочет. В такой ситуации важна социальная ответственность компании перед каждым сотрудником. Кто-то, естественно, остался в офисе и будет до последнего, например, я. Но у меня работа такая.
    ДомКлик
    Место силы

    Комментарии 11

      +1
      Если подумать, то у нас вся компания – тестировщики.

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

        Хотя с другой стороны, если люди уходили и не хотели обучаться… то похоже что в процессах действительно что то не так.

        Сама статья сухая… все ждал интересных тех подробностей, но нет… Причину написания поста не совсем понял…
          –1
          Не нужно быть семи пядей во лбу, чтобы предположить их потребности, так как это вполне себе обычный проект с SPA-сайтом и мобильными приложениями. В таком проекте QA отдел просто необходим, выгода от него очевидна. Впрочем, я встречал небольшие проекты, где тестировали топ-менеджеры. Забавно смотрелось.
            0
            Ну вот мы и предположили ) Более того, с большой вероятностью, большинство разработчиков с вами согласны, даже те, кто работает у них самих но…

            Итого на текущий момент у нас в бэкэнде Python, Kotlin/Java, Go, Ruby. На фронтэнде доминант у нас React. (+ что то на ангуляре)


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

            И возможно теперь вы согласитесь, это экономически более выгодно. А просто содержать целые отделы ради «правильности» подхода не целесообразно.
              0
              Не сочтите за обиду, но Вы тоже в QA не понимаете. QA нужен только для Frontend, для Backend напишут тесты сами разработчики.
              Стэк вполне типичный, бывает и гораздо разнообразней.
          +2
          Без ручных тестировщиков разработчик начинает трепетнее относится к работоспособности своего компонента (будь то бэкэнд или фронтэнд), так как в случае возникновения ошибок обвинить кого-то кроме как себя не остается. Такая организация естественным способом заставляет разработчика больше думать о тестировании, точнее об автотестировании — разработчик начинает больше покрывать свой компонент тестами.

          Я соглашусь, что QA специалист может быть весьма полезен в тестировании комплексно всей системы, например, для проверки корректности бизнес-процессов, которые начинают протекать в системе, составленной из множества компонент.
            0
            К сожалению, Ваши познания о QA весьма примитивны. QA ведь не для того, чтобы приставить manual tester для каждого разработчика, чтобы разгрузить его от тестирования.

            Задач у QA-отдела по сути несколько:
            1) Не пропустить в релиз сырой продукт. Хороший QA стоит дешевле разработчика, а тестирует продукт в разы лучше.
            2) Проверять и расписывать кейсы, поступающие от пользователей в процессе работы с продуктом.
            3) Готовить сопровождение по продукту — тулзы для тестов, различные окружения, документацию, что весьма ценно для разработчиков, так как экономит их время.
          0
          А какие приложения перевели на PWA и почему (у вас на сайте не нашел)? Что вообще думаете по поводу перспективы PWA-приложений?
            0
            PWA — некорректное название в статье. Речь идет скорее про гибриды, т.к. Apple не дают полную поддержку pwa, все равно приходится делать обертки из, допустим, cordova. Есть 1 полноценное гибридное приложение (бизнес — логика на вебе и сервис воркерах). Дистрибуцируется через внутренний магазин, 10 000 пользователей. Полет более чем нормальный. Лично я верю в PWA и прочие технологии, т.к. писать один и тот же код 3 раза (Веб, IOS, Android)- архитектурный антипаттерн.
            +1
            Интересненько
              0
              Сейчас во всем ДомКлике более 700 людей.

              Сколько из них разработчиков?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое