Пока мы заканчиваем последние приготовления к выпуску нашего ежегодного рейтинга лучших работодателей в ИТ, почитайте о том, как устроена жизнь в REG.RU — крупнейшем в СНГ хостинг-провайдере и регистраторе доменов. На наши вопросы о найме, команде, процессах и технологиях ответили руководитель отдела по работе с персоналом Екатерина Первушкина, ведущий менеджер по продукту Дмитрий Денискин и руководитель отдела разработки интерфейсов Сергей Ермаков.
Кстати, на Хабр Карьере сотрудники оценили REG.RU на 4,5 баллов из пяти.
Оценивайте и вы своих работодателей, чтобы поделиться со всеми, как там круто (или не очень круто) работается. Оценка останется анонимной и поможет сориентироваться тем, кто ищет работу в ИТ.
Навигация по статье:
О компании
REG.RU — это российский хостинг-провайдер и регистратор доменных имён, работающий на рынке России и Европы с 2006 года. На конец прошлого года Рег.ру обслуживает 3,3 миллиона доменов, а к их хостингу подключено 780 тысяч доменных имён. По рейтингу надёжности (Uptime) хостинг-услуги Рег.ру занимают первое место среди провайдеров Рунета.
Офисы компании расположены в Москве, Самаре, Кишинёве и представительства — ещё более чем в 30 городах России.
Сотрудники ценят REG.RU за комфортные условия труда, отличные отношения в коллективе и за то, что компания делает мир лучше! Вот подробная оценка компании за 2020 год, а вот — свежие вакансии на Хабр Карьере.
Про условия работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Екатерина: График зависит от специфики отдела: например, у клиентских служб начало и окончание рабочего дня чётко регламентировано — наша техническая поддержка на связи 24/7 (для ребят важно быть на связи в конкретное время). Там, где допускается гибкость — можно немного сдвинуть рабочее время в сторону своего комфорта, главное — укладываться в сроки, не выпадать из процессов и коммуникаций.
Переработки не приветствуются, но, конечно, случаются ситуации, в которых их не избежать. Например, годовая бухгалтерская отчётность или сдача проекта, когда «?подгорают»? сроки.
Дмитрий: У нас каждая команда сама определяет рабочий график. Так, в моей команде Облачных серверов мы проводим ежедневный созвон в 9:30 Мск, планируем активности на день — если нужно что-то обсудить, то обговариваем, во сколько удобно сделать созвон.
Далее каждый работает асинхронно, но мы находимся в едином чате в Discord, общаясь по рабочим и нерабочим вопросам. Если коллеге нужно на время уйти в оффлайн, то он предупреждает, что его не будет, например, пару часов. Затем сам сотрудник решает, когда отработать эти пару часов. Отношение к переработкам зависит от позиции. Обычно продакт-менеджеры загружены больше, чем сотрудники на других позициях. Я веду трекинг рабочего времени, и особенно высокой в этом году была загрузка весной и летом в связи с преобразованиями в компании.
В августе был опрос по переработкам, посмотрел тогда статистику и увидел, что за 7 месяцев 2020 года проработал, по сути, 8 месяцев или в часах — 135 чистых часов работы — это как январь или май. Но, в целом, в таком режиме нельзя работать на постоянной основе, легко выгореть.
Сергей: График относительно свободный, можно смещаться на несколько часов в удобную сторону. Главное — чтобы это не вызывало проблем в коммуникации.
К переработкам отношение простое: не приветствуются, но оплачиваются. Конечно, иногда они необходимы, но это всегда исключение из правил, отдых очень важен.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Екатерина: Рабочие места в офисах оборудованы всем необходимым для комфортной работы. За освещением на рабочих местах очень тщательно следит наш специалист по охране труда, и мы точно знаем, где сколько люксов.
Конечно, в офисе важны не только рабочие места, но и то, как можно отдохнуть в перерыве. Для этого у нас есть несколько оборудованных кухонь со всем необходимым, чтобы подкрепиться, включая кофемашины, снеки, фрукты и орехи. В каждом офисе есть своя фишка: в Самаре у нас комната отдыха с Xbox, турником и тренажёром «?Герман»? и даже душ. А в Москве — галерея картин современных художников. Ещё у каждого из наших офисов есть велопарковка.
Ну и, конечно, в компании, в которой более 50% сотрудников ещё до пандемии работали на удалёнке, есть программа компенсации оборудования, чтобы каждый мог прокачать своё рабочее место и приобрести не только мощный процессор, но и удобное ортопедическое кресло.
Есть ли возможность удалённой работы?
Екатерина: Конечно, в REG.RU традиционно работали ребята из разных городов. И даже те, кто периодически меняет своё место жительства. Но есть и такие позиции, где место имеет значение, например, инженеры ЦОД, которые, по понятным причинам, всегда должны быть в дата-центре.
Дмитрий: У нас работает более 500 человек. И если до пандемии удалённо работали 50%, то сейчас — 90%.
Какой социальный пакет получают сотрудники?
Екатерина: Самое классное — корпоративная программа компенсации внешнего обучения. Любой член команды может самостоятельно выбрать внешний курс и компенсировать его стоимость за счёт компании. Также сюда входит покупка профессиональной и бизнес-литературы.
Для тех, кто работает удалённо, у нас есть программа компенсации оборудования, которая позволяет покупать топовую технику на рынке и амортизировать её за счет компании.
Одна из самых востребованных программ до пандемии — оффлайн-встречи команд. Это программа предусмотрена для распределённых команд, которым необходимо в какой-то момент встретиться оффлайн и поштормить или, наоборот, подвести итоги периода. Компания организует трансфер, проживание и необходимые инструменты для таких встреч.
Ну и конечно, трудоустройство по ТК, белая зарплата.
Какие бонусы, премии и компенсации предусмотрены в компании?
Екатерина: В зависимости от команды и отдела, схемы мотивации различны. Так, в клиентских службах действует формат премирования за выполнение KPI, в продуктовых командах предусмотрен бонус за серьёзное достижение, а менеджерский состав премируется за счёт достижения финансовых показателей и достижения долгосрочных целей.
Сергей: В разработке есть оплата и компенсация обучения, льготные тарифы на наши услуги, возможность выкупить служебную технику на адекватных условиях, премии и иные поощрения за особые достижения.
Дмитрий: Возможность получить удобное оборудование для работы. Я, например, работаю на Macbook Pro 16. А ещё из годового фонда оплаты труда отдела ежегодно выделяется определённая сумма на самообразование сотрудников. Отдел распределяет эти деньги самостоятельно — можно посещать курсы или конференции.
Какие есть перспективы для образования и личного развития у сотрудников?
Екатерина: В нашей компании развита культура постоянного апгрейда своих знаний. Поэтому мы много внимания уделяем этому вопросу. Одна из наших ценностей — экспертность.
Специально под потребности ребят наши разработчики создали крутую собственную платформу для развития — Education REG.RU, на которой собраны курсы по софт-скиллз и не только. Наш КМБ («Курс молодого бойца») для новичков, библиотека с 500+ книгами, а также инструменты для оценки и планирования развития — Competency Review, Performance review и ИПР (индивидуальный план развития).
Наш корпоративный университет разрабатывает курсы и тренинги специально под потребности команды, а также помогает сотрудникам готовить хардовые курсы, чтобы все могли не только получать знания, но и делиться ими с коллегами.
Для тех, кому нужны специфические курсы — компания компенсирует до 100% стоимости обучения у внешних провайдеров.
Конечно, система развития не будет работать без регулярной обратной связи. Ещё совсем недавно кросс-функциональные команды получали меньше фидбека, чем им хотелось бы. Поэтому в компании появились чаптер-лиды — наставники ребят, который дают фидбек и мотивируют на новые свершения.
Дмитрий: Сотрудник строит план индивидуального развития совместно со своим руководителем и может самостоятельно определять, какие купить книги или какие курсы посетить.
Мы предпочитаем продвигать сотрудников внутри компании, нежели нанимать с рынка. Можно начать с позиции сотрудника технической поддержки и затем перейти в junior-разработчики в одну из продуктовых или сервисных команд.
Сотрудники объединяются в чаптеры — отделы специалистов определённого профиля. Например, чаптер бэкенда или в моём случае — чаптер продакт-менеджеров. Чаптеры самоорганизуются для повышения квалификации своих членов — компания рекомендует тратить 10% рабочего времени на обучение в рамках чаптеров. Подробнее о такой структуре в докладе моего коллеги Артура Нека: EduScrum для создания среды Менеджеров процесса.
Сергей: У каждого сотрудника есть личный бюджет, в рамках которого и по согласованию с руководителем можно закупать книги, проходить курсы, посещать конференции. Также в компании есть отдельное подразделение — Education REG.RU, которое разрабатывает собственные программы обучения и курсы для сотрудников.
Кроме того, многие наши отделы разделены на подотделы, чаптеры, не более 10 человек в каждом. Руководители таких мини-отделов, чаптер-лиды, фокусируются на развитии сотрудников, обсуждают с ними итоги перфоманс ревью, помогают им с индивидуальными планами развития и так далее.
Про найм
Во сколько этапов проходит найм и что на них ожидает соискателя?
Екатерина: Это зависит от вакансии и специфики отдела, в который мы ищем нового коллегу. Первый этап — всегда скрининг (созвон на 10-15 минут), на котором рекрутер синхронизируется с кандидатом по стеку технологий, выясняет мотивацию и ожидания, договаривается о встрече.
Далее у технических специалистов (админы, DevOps, тестировщики и т.д.) техническое задание, после выполнения которого мы проводим интервью с представителем команды, руководителем и HR. С разработчиками мы сразу проводим техническое интервью. Для линейных вакансий (менеджеры по продажам, юристы, бухгалтеры и проч.) есть этап интервью с руководителем и HR.
Сергей: Чаще всего найм проходит в 2-3 этапа. На первом рекрутеры общаются с кандидатом, проводят скрининг, могут запросить дополнительную информацию — например, примеры кода у разработчика, или попросить оценить свои знания и навыки по предложенной шкале.
Основное интервью обычно состоит из 2 частей, в первой HR-специалист уточнят у кандидата детали его опыта работы и анализирует софт-скилы. Вторая часть — профессиональная, будущий руководитель и/или коллеги задают кандидату вопросы по его специальности. И в третьей части уже мы рады ответить на любые вопросы.
Даёте ли вы тестовое задание кандидатам? Как оно устроено?
Екатерина: Там, где можно обойтись без ТЗ, мы выясняем все детали на техническом интервью — чтобы сократить процесс для себя и снизить временные затраты наших соискателей. Но, конечно, есть вакансии, на которых без него не обойтись, например, скорее всего, мы попросим выполнить тестовое задание дизайнеров и админов.
Также при приёме на вакансии в клиентский сервис есть несколько вопросов (о доменах, хостинге, серверах и т.д.), которые кандидат должен изучить самостоятельно — это важно не только для нас, но и для самоопределения самого человека: в КС часто приходят новички в IT и бывают ситуации, когда уже на этом этапе человек понимает, что ему неинтересно работать с этой информаций, и он корректирует свой поиск. Мы экономим время ему и себе.
Сергей: Необходимость выполнения тестового задания зависит от резюме кандидата. Например, если у кандидата есть примеры кода, достаточные для оценки его уровня, — тестовое ни к чему.
Как отличается подход к найму в зависимости от позиции и стека?
Екатерина: У нас в компании около 70 команд, каждая из которых выполняет свои задачи. От этого зависит и тактика подбора. Например, бэкенд-разработчиков мы предварительно просим прислать пример кода, и направляем нашим ребятам вместе с резюме для полноты картины.
На собеседовании присутствует два разработчика, которые обсуждают с кандидатом стек и задачи, и рекрутер, который общается по софтам. Для нас очень важно, чтобы не только кандидат подходил нам, но и мы подходили кандидату. Это особенно актуально в разработке, где кандидатам, помимо условий, важен стек и конкретные задачи.
Поэтому заключительный этап — всегда встреча для оффера, на которой ребята подробно рассказывают про функционал и отвечают на все вопросы будущего коллеги. Только если «?магия»? состоялась, мы и кандидат примем окончательное положительное решение.
Сергей: Очень широкий вопрос :) В целом вектор можно обозначить так: чем выше уровень кандидата, тем меньше вопросов по теории и небольших практических задач, и тем больше задач абстрактных, позволяющих порассуждать, предложить решение заданной проблемы.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Екатерина: Мы сразу сжигаем! (шутка). Если серьёзно — у нас есть определённый ДНК, совпадение в котором для нас важно. Одна фраза редко портит общее впечатление. Но тут важно вспомнить о том, что все наши проекты — командные, и даже если есть совпадение по стеку, но при этом есть свидетельство того, что кандидату некомфортно работать в команде, то мы не будем сотрудничать.
Сергей: Не припомню ни одного такого случая. Скорее всего, наши рекрутеры заботливо оберегают нас от неподходящих кандидатов.
Кого последнего вы уволили и почему?
Екатерина: Прежде чем принять такое решение, сотрудник получает фидбек и время на то, чтобы скорректировать работу. Если положительной динамики не случилось, то в том числе и потому, что сотруднику не подходит работа у нас. Договариваемся по комфортным срокам и расходимся.
Последнее такое увольнение произошло с сотрудником одного из наших офисов — человек не был готов развиваться в тех направлениях, которые есть в компании, на текущем месте достиг «?потолка»? и, конечно, это сказалось на отношении к работе: опоздания на встречи, перекладывание ответственности, затягивание сроков выполнения задач. В итоге несколько раз обменялись фидбеком, плавно передали дела и разошлись. После расставания остались в хороших отношениях, для нас это важно.
Конечно, жаль расставаться с людьми, которые зачастую проработали в компании долгий срок, но понимают, что нужно двигаться дальше. У нас много возможностей для развития внутри компании, и нормальная практика, когда человек меняет проект или даже направление работы. Но, к сожалению, бывает, что интересы человека нельзя реализовать внутри компании.
Сергей: Очень редкая ситуация. Но бывали случаи, когда сотрудник резко снижал производительность, по разным причинам. И если не удавалось найти взаимоприемлемый план по улучшению ситуации — наши пути расходились.
Как происходит онбординг нового сотрудника?
Екатерина: Онбординг начинается ещё до прихода нового сотрудника в компанию: сразу после оффера он получает welcome-письмо, в котором мы рассказываем не только о плане действий в первый день, но и наших традициях — это помогает снизить стресс ожидания неизвестности и знакомит с корпоративной культурой заранее.
Каждый новичок получает welcome pack с брендированными мелочами: футболкой, толстовкой, ручкой, блокнотом, шоппером, наклейками и, конечно же, кружкой :) Всё выдаётся в нашем классном фирменном рюкзаке. Мы любим свою корпоративную одежду и с удовольствием её носим. По ней нас узнают не только на профильных мероприятиях, но и просто в городских джунглях.
Конечно, онбординг — не только классный мерч, но и люди. Каждый рекрутер занимается адаптацией «?своего»? новичка: в течение первых месяцев мы проводим несколько регулярных встреч с сотрудником и его наставником, чтобы вовремя помочь в решении самых разных вопросов. Ну и, как понятно из предыдущего предложения, у каждого новичка обязательно есть наставник, который помогает адаптироваться быстрее.
Компания сильна своими традициями: каждый новичок пишет приветственное письмо, в котором немного рассказывает о себе, а команда получает возможность его поприветствовать. Ну и конечно, познакомиться поближе можно на корпоративных мероприятиях.
Сергей: У нас есть специальный курс («Курс молодого бойца»?) на внутренней образовательной платформе, который знакомит сотрудника со всеми подразделениями, с нашими ценностями, культурой. Также во всех отделах есть онбординг-инструкции, позволяющие проще разобраться в происходящем. Новому сотруднику активно помогает и команда, и его руководитель.
О команде
Какая методология разработки у вас используется и почему?
Дмитрий: В целом REG.RU использует гибкие методологии разработки продуктов. С точки зрения фреймворков, продуктовые команды обычно используют scrum с двухнедельными спринтами, а сервисные команды — kanban. Мы в команде Облачных серверов начинали со скрама, поскольку продукт был новый. Недавно перешли на канбан, потому что продукт вырос и появилось много операционки.
Сергей: У нас более 20 команд в разработке, методологии могут быть разными. Несколько команд использует Scrum, большая же часть использует канбан-метод или находится в процессе его адаптации.
Основное отличие Kanban от Scrum в том, что Scrum — революционный подход, который к тому же требует очень чёткого следования методологии. Канбан же — эволюционный, он подразумевает постоянные небольшие улучшения, позволяет начать с того процесса, который есть в команде на данный момент — и постепенно, через циклы обратной связи и с использованием статистических методов, добиться и оптимальной производительности, и предсказуемых сроков поставки, и самое главное — лучше подстроиться под потребности клиента или заказчика, предоставить ему лучший сервис.
Каковы размеры и структуры команд?
Дмитрий: В команде «Облачных серверов» 11 человек, включая владельца продукта и скрам-мастера. Но фактически это две мини-команды, которые сфокусированы на разных частях продукта — платформе и пользовательской панели.
Каждый специалист входит как в продуктовую команду, так и в чаптер — это сообщество специалистов определённого профиля. Например, чаптер бэкенд-разработчиков или в моём случае — чаптер продакт-менеджеров. В рамках чаптеров специалисты прокачивают собственные навыки или определяют, какие технологии стоит использовать компании.
Сергей: Почти все наши команды — кроссфункциональные, с бэкендерами, фронтендерами, тестировщиками, менеджерами процесса, дизайнерами и другими необходимыми команде специальностями. Размер редко превышает 10 человек.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Екатерина: У каждого направления свой набор требований для всех уровней. Как правило, это сочетание софт- и хард-скиллов.
Сергей: Степень самостоятельности, размер зоны ответственности, понимание бизнеса, ряд других софт-скилов. Также различаются требования по хард-скилам
Кто чаще возглавляет команды — продуктовый специалист или технический?
Екатерина: В гибких методологиях нет чётко выделенного лидера, а в командах разработки у нас применяются именно «?гибкие»? подходы.
Дмитрий: Продуктовые команды обычно построены по фреймворку скрам — есть владелец продукта, который определяет требования к продукту, скрам-мастер, который отвечает за эффективность процессов и команда разработки.
В сервисных командах вместо владельца продукта — service request manager, который помогает команде получить от заказчиков корректную задачу от заказчиков.
Но владелец продукта — не начальник для команды, это партнёры, которые делают продукт.
Сергей: В подавляющем большинстве команд это продуктовый специалист, который выполняет роль Product Owner или Service Request Manager.
Как часто люди меняют команды?
Екатерина: Достаточно часто, но если говорить о сроках, то проект длится примерно 1,5-2 года, после чего команда либо трансформируется, либо целиком направляется на другую задачу.
Кроме того, у нас гибкий подход, и если на проекте появилось много задач и команду нужно усилить — туда могут перевести кого-то из другой команды. Такие переходы происходят после как минимум нескольких месяцев работы сотрудника в текущей команде, ну и, конечно, переход не состоится без согласия сотрудника и обеих команд.
Дмитрий: Обычно это связано с изменением потребностей в разработке продукта, его закрытии или, напротив, открытии нового направления. Часто практикуется переход разработчиков из сервисных команд, обслуживающих всю компанию, в конкретную продуктовую команду, потому что сервисные команды взращивают junior-специалистов.
В свою очередь в сервисную команду сотрудники попадают, переходя с должности специалиста поддержки на должность разработчика.
Что важнее, софт-скиллы или хард-скиллы?
Екатерина: Важна балансная совокупность. Хард определяет уровень владения инструментами, а вот как человек будет его использовать и будет ли растить — это софты. Поэтому для нас важно попадание в REG.ДНК (важные для нас софт-скилы и ценности), от которого зависит успех сотрудника в дальнейшей работе.
Дмитрий: Для продакт-менеджера важна эмпатия и природное любопытство. Эти качества сложнее прокачиваются, нежели хард-скиллы.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Дмитрий: В целом наша работа подразумевает наличие созвонов. На это также влияет то, что помимо работы над своим продуктом, ты входишь в различные рабочие группы, центры финансовой отчётности или занимаешься обучением себя и коллег в рамках чаптера продакт-менеджеров.
Вот полный список наших регулярных встреч:
Ежедневно: ежедневный созвон с командой в 9:30 на 15 минут;
Еженедельно: созвон продуктового круга (45 минут);
Раз в 2 недели: ревью (30 минут), планирование спринта (до 1 часа) и ретроспектива (до 1,5 часов), созвон продуктового чаптера (30 минут), ревью других команд;
раз в месяц: созвон по результатам OKR по всей компании (4 часа);
раз в квартал: созвон по результатам центров финансовой ответственности по всей компании (4 часа).
Относительно нерегулярных встреч подходы простые:
каждая встреча должна иметь повестку;
после встречи участникам отправляется письмо с принятыми решениями.
Сергей: Ещё из подходов — мы стараемся не опаздывать, не отклоняться от повестки, не выходить за тайминг. При необходимости у нас есть возможность пригласить на встречу специалиста с опытом фасилитации.
Как вы боретесь с выгоранием сотрудников?
Екатерина: Лучший подход в этом случае — профилактика. У нас гибкий подход к рабочему времени, поэтому есть возможность совмещать работу с любыми увлечениями в рамках закона :) Работаем над тем, чтобы наши ребята вовремя «выныривали» из рабочего процесса и регулярно ходили в отпуска.
Раз в год мы проводим опрос по вовлечённости сотрудников, который позволяет определить зоны роста и проработать их в масштабе компании. Ну и конечно, каждый лидер регулярно проводит встречи со своими командами 1-to-1, на которых видны изменения настроения ребят. Все такие кейсы требует индивидуальной проработки: кому-то просто нужно отдохнуть, а кому-то сменить задачи или даже направление работы.
Дмитрий: Мы стараемся проводить ретроспективу после каждого спринта. В её рамках пытаемся понять, что идёт не так в наших процессах, в чём причина и как мы это можем изменить. Но, по моему опыту, бороться с уже сложившимся выгоранием сложно, в этом плане только сам сотрудник может вытаскивать себя из этого состояния. Поэтому важно принимать меры при первых признаках — перераспределять ответственность, убирать какие-то скучные операционные задачи, предложить сходить в отпуск или изменить какие-то рабочие привычки.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Сергей: На бэкенде мы используем в основном Perl (Catalyst и не только), Python (Django и не только), есть немного Node.js и PHP.
На фронтенде все команды используют Vue.js.
Что вы можете рассказать об архитектуре проектов?
Сергей: Мы находимся на пути от монолита к сервисной архитектуре, в настоящий момент у нас несколько десятков сервисов.
Какая у вас принята политика код-ревью?
Сергей: Код-ревью техлида или коллег обязательно в большинстве команд. Некоторые команды используют на практике парное программирование. При внесении правок в код, который сопровождает другая команда, нужно код-ревью от неё.
Как тестируется код?
Сергей: Все команды пишут unit-тесты как на бэкенде, так и на фронтенде. Есть интеграционные и API-тесты, их не очень много. Все важные сценарии покрыты e2e-тестами.
Во всех командах есть тестировщики, и помимо указанного выше, они проводят ручное и автоматизированное функциональное тестирование. И на последнем этапе соответствие требованиям проверяет заказчик задачи.
Как устроен процесс документации и ведения базы знаний на проектах?
Сергей: Техническая документация самого низкого уровня пишется в pod/jsdoc/docstring, более высокоуровневая — в формате маркдаун рядом с кодом. Документация автоматически собирается в централизованный интерфейс.
Бизнес-документация в основном хранится в Google Docs, там очень удобно её редактировать и обсуждать.
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Сергей: Нашему самому старому коду почти 15 лет. Разумеется, у нас заметное количество легаси. Процент сильно разнится от команды к команде, у многих команд проекты молодые, ещё не обросшие наследием.
Многие команды определяют для себя политики по техническим задачам — таким как возврат технического долга или рефакторинг. Считается нормой тратить на них 10-15%.
Оценивайте своих работодателей на Хабр Карьере, чтобы поделиться мнением с теми, кто ищет работу в ИТ! Ваша оценка останется анонимной.