Герой сегодняшнего выпуска — ИТ-компания Lad, системный интегратор из Нижнего Новгорода. В этом году ребята впервые получили оценку и попали в наш рейтинг компаний. Сотрудники оценили Lad на 4,5 из пяти, особо отметив современные технологии, комфортные условия труда и отношения в коллективе.
Чтобы узнать обо всем подробнее, мы расспросили Романа Андронова (заместитель генерального директора Lad) и Максима Теричева (технический лидер Центра разработки Lad). Они рассказали нам о жизни компании, о найме и адаптации новых сотрудников, о технологиях и о том, что коллективное пение — самое лучшее средство от выгорания.
Lad — IT-компания и системный интегратор из Нижнего Новгорода. Занимается внедрением, доработкой и поддержкой клиентских проектов. Компания работает с клиентами из производства, строительства, торговли, атомной промышленности. А ещё ребята разрабатывают собственные проекты: веб-сервисы, приложения для мобильных платформ и IT-экосистемы. В компании работает около 500 сотрудников.
Вот оценка компании Lad в деталях, а почитать комментарии сотрудников можно здесь.
Об условиях работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Роман Андронов: У нас принят гибридный рабочий график. Он формируется лидом и командой, исходя из целей и задач, а также учитывая личную ситуацию сотрудника. Если у работника есть дети, он далеко живет от офиса или проходит дополнительное обучение в вузе или на курсах, то мы идем навстречу и формируем удобный индивидуальный график.
В целом, в у нас гибкое начало дня, большая часть сотрудников работает с 8:00 или 9:00, но есть и те, кто начинает рабочий день с 7:00. Работники без преград берут административные на один-два дня. Хотя это не всегда удобно компании, мы с пониманием относимся к таким случаям. Без проблем отпускаем работников на несколько часов в течение рабочего дня по личным делам.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Роман: Мы обеспечиваем нового сотрудника техникой для офиса или удаленной работы. У нас есть специалисты, которые трудоустраиваются сразу на дистанционный формат, прописанный в договоре. Каждый получает от компании ноутбук или стационарный компьютер, гарнитуру, мышку, приветственный welcome-pack с мерчом: кружкой, блокнотом, носками, стикерами и разными развлекательными аксессуарами.
Стандарт техники продуман под конкретные задачи подразделений. Но мы решили, что было бы здорово дать сотруднику возможность самому выбрать себе компьютер, и включили в корпоративный пакет программу субсидирования покупки ноутбука. Компания готова компенсировать стоимость ноутбука каждому сотруднику по личным предпочтениям, причем выделяемая сумма покрывает приобретение техники высокого сегмента. В течение трех лет работы на компанию сотрудник получает полную компенсацию за купленный компьютер.
Формат офисов, мебель, техника также подбираются под решаемые задачи и в каждом подразделении есть свои особенности. Финансовой службе нужны классические столы, а командам разработки — современные бенч-системы.
Формат помещений тоже разнообразный и многофункциональный. У нас есть опенспейсы на 30-50 рабочих мест, офисы на 5-10 сотрудников, кабинетная система. Мы создали комплекс переговорных комнат и учебных классов на разное число участников (от 4 до 35), которые бронируются через Google-календарь. Недавно запустили большой образовательный комплекс, состоящий из учебного класса, коворкинга, который трансформируется в переговорную комнату, лаунж-зоны и собственной кухни с зоной для кофе-брейков.
Мы обустроили для работников две столовые с мягкими диванами, кофемашинами и чайными столиками. Ребята могут хранить в холодильниках обеды и продукты в течение рабочей недели, не оставляя на выходные из соображений чистоты и порядка.
Во всех офисах предусмотрены грин-зоны отдыха и стоят кофемашины (да-да, мы понимаем, что сейчас эпоха общечеловеческой любви к кофе и не игнорируем желания команды).
Есть ли возможность удаленной работы?
Роман: С весны 2020 год на удаленке работает около 80% наших сотрудников. И, судя по всему, такой формат взаимодействия сохранится в будущем. Мы планируем постепенно уходить от закрепленных рабочих мест и переформатировать офисы в коворкинги.
Какой социальный пакет получают сотрудники?
Роман: Мы в прошлом году запустили пилот по ДМС, в котором участвовали все желающие, но после анкетирования сотрудников и анализа статистических данных сервиса, который предоставлял услугу, поняли, что деньги расходуются крайне неэффективно и отказались от ДМС. Решили организовывать локальные корпоративные предложения — например, скидки в стоматологическую клинику.
Ежегодно организуем бесплатную вакцинацию от гриппа. Оплачиваем спортивные активности и экипировку: участие в забегах, аренду зала для футбольной команды, участие в ИТ-спартакиаде и региональной киберспартакиаде, которая, кстати, в этом году проходила впервые, и мы ее выиграли.
Организуем регулярные корпоративы в подразделениях и один большой праздник на Новый Год — для всей компании. Подарки дарим сотрудникам на день рождения компании, в честь появления новорожденных, детям на 1 сентября, Новый Год, и даже делаем детский новогодний корпоратив.
Мы поощряем обучение. Если сотрудник хочет пройти курсы повышения квалификации и может обосновать их необходимость, а еще лучше обучить потом новым знаниям своих коллег — оплачиваем эти активности. Сотрудники занимаются на курсах английского языка с корпоративной скидкой. Мы закупаем книги в корпоративную библиотеку, в которой сейчас порядка 200 книг. Дарим мерч за активную позицию: организацию и участие во внутренних митапах, в отраслевых конференциях и выставках.
А еще, на день рождения сотрудника компания дарит оплачиваемый выходной день или небольшую денежную сумму по выбору именинника.
Какие бонусы, премии и компенсации предусмотрены в компании?
Роман: Топ-менеджмент ежеквартально получает часть от прибыли компании. В каждом подразделении своя система оплаты и KPI, но практически везде есть квартальные премии. Регулярно запускаем проекты по геймификации с премиальным фондом.
Какие есть перспективы для образования и личного развития у сотрудников?
Роман: Абсолютно каждый сотрудник имеет возможность инициировать собственное обучение по согласованию со своим руководителем. Как правило, компания оплачивает 50% стоимости обучения. Если затем сотрудник организовал передачу полученных знаний коллегам или внедрил что-то, то компания возвращает ему 50%, которые он потратил. Если обучение организуется по инициативе компании, то оно всегда бесплатно. Сейчас у нас момент запущено бесплатное полуторогодовалое обучение 72 лидеров компании по soft skills.
На старте джуниор-разработчику выделяется ментор, который ведет его первые несколько месяцев. Ментор отвечает за развитие новичка, на нем лежит ответственность, чтобы новый сотрудник успешно прошел испытательный срок. Задача в том, чтобы по итогам испытательного срока компания была довольна результатами специалиста, а самому новичку было комфортно работать.
Два раза в год у нас проходит ассессмент, на котором мы оцениваем как soft, так и hard skills, строим индивидуальную траекторию профессионального развития сотрудника. При этом учитываем потребности проектов, общие технологические тренды и личные предпочтения разработчика.
О найме
Во сколько этапов проходит найм и что на них ожидает соискателя?
Роман: Мы выстраиваем динамичный процесс в найме, и он состоит из двух этапов. Сначала пишем кандидату в Телеграмм (реже на почту), задаем несколько вопросов и выявляем его интерес. Если обнаруживаем необходимый уровень заинтересованности в вакансии, то приглашаем на встречу. Интервью проводим в Zoom или Google-meet. На встрече присутствует эйчар, тимлид и техлид. Рассказываем про компанию, проекты и продукты, спрашиваем кандидата о его опыте, пожеланиях в развитии, обязательно проверяем на предметные знания. Обычно интервью длится около полутора часов. Если кандидат нас устраивает, составляем оффер и отправляем через мессенджер или на почту. Дальше будущего работника ожидает оформление в отделе кадров, велком-пак, общение со специалистом по адаптации, знакомство с коллегами и 12-месячный онбординг.
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Максим Теричев: Техническое задание мы даем редко, только если есть сомнения. Чаще это бывает, когда ищем начинающих специалистов. Обязательно проводим техническое собеседование. Оно схоже с технологией ассессмента и устроено таким образом, что позволяет достаточно полно увидеть и понять технические навыки. Благодаря такой встрече мы четко понимаем, на какой ступени развития находится специалист.
В нашей практике были истории, когда техническое задание кандидат выполнил не самостоятельно. Считаем, это трата времени: как нашего, так и специалиста. Поэтому мы повышаем навыки наших интервьюеров, чтобы они могли провести качественную оценку в рамках собеседования.
Как отличается подход к найму в зависимости от позиции и стека?
Максим: От уровня специалиста зависит кто будет оценивать его навыки и наши ожидания. Для каждого уровня техническое собеседование устроено по-разному. От джуниор-разработчика мы ждем базовые знания технологий и предлагаем решить несколько небольших задачек прямо на собеседовании. От высококвалифицированных специалистов — ответы на открытые вопросы и хорошие взвешенные размышления по теме разговора.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Максим: Вычеркнем кандидата, если поймем, что этот человек способен идти по головам.
Кого последнего вы уволили и почему?
Максим: Недавно уволили разработчика, человек очень сильно «выгорел». Мы 1,5 года пытались исправить ситуацию и помочь ему вернуться в рабочее русло, но не получилось. У нас не принято увольнять людей, мы стараемся найти им место и интересный функционал, если чувствуем, что сотруднику стоит временно или на постоянной основе поменять функционал. Мы переводили этого специалиста на другой проект, проводили встречи и разговоры 1:1, но это не помогло… Допускаем, что здесь есть и часть нашей вины, но, с нашей точки зрения, мы предприняли все попытки вывести его на нужную нам производительность.
Как происходит онбординг нового сотрудника?
Роман: У нас есть специальный сотрудник — менеджер по адаптации, который встречает всех новичков, вручает welcome-pack, помогает в оформлении, проводит экскурсию по офису, показывает сервисы, на которых мы работаем, дает всю необходимую информацию о правилах и нормах компании и знакомит с командой. Планируем внедрить приложение, которое будет носителем необходимой информации для новичка.
В команде нового сотрудника встречает ментор, он с технической точки зрения рассказывает о проекте, в котором будет работать этот сотрудник, о коммуникациях внутри коллектива и о задачах на ближайшее время. Дальше адаптацией занимается эйчар: вместе с руководителем прорабатывает ИПР нового сотрудника. Регулярно проводим встречи: по итогам первой недели, месяца, двух месяцев, по окончании испытательного срока, по прошествии 6 и 12 месяцев. Кроме этого, сотрудник после первого месяца проходит welcome-тренинг, на котором ближе знакомится с первыми лицами компании, с другими новичками и компанией.
О команде
Какая методология разработки у вас используется и почему?
Максим: У нас Agile. Водопад (и иже с ним) на тех рынках, для которых мы разрабатываем, — слишком неповоротливая конструкция. Для проектов на поддержке используем Kanban, для новых проектов — Scrum, ну или точнее ScrumBut. Например, не всегда по итогам спринта рождается инкремент, или можем запросто задеплоить готовый функционал в середине спринта.
Для работы команд, которые по числу участников не подходят для скрама, разбиваем людей на подкоманды на один или несколько спринтов, и ведем их в течение спринта отдельно, хотя демо и планирование все равно общие. Работы проджектам значительно прибавляется, но зато проект движется с нужной скоростью и разработчики фокусируются на том, что для них действительно важно.
Каковы размеры и структуры команд?
Максим: Команды разные, от 5 до 30 человек. Структура плоская. У нас нет тимлидов, потому что, как правило, тимлид — это хороший разработчик, которого зачем-то нагрузили административной работой. У нас есть отдельный техлид проекта (иногда части проекта — бэкенда или фронтенда) и проджекты, которые берут на себя административную работу. В нашей структуре есть продакт-оунер или команда продакт-оунеров, которые определяют, что делать в будущих спринтах.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Максим: Тут нужно сразу сказать, что осмысленно мы к этому процессу начали подходить где-то год-полтора назад, и еще не до конца докрутили в нем все, что нам бы хотелось. В целом сейчас мы пересматриваем грейды раз в полгода (в апреле и сентябре) и подходим к этому с трех сторон:
Мы разработали список того, чем, по нашему мнению, положено заниматься разработчику на том или ином уровне. Например, один из пунктов для хорошего джуна — он ДОЛЖЕН задавать много вопросов (мы специально фокусируем на этом внимание, чтобы снять у людей блок на этот счет). Для мидла важно участвовать в командном code review и менторить джунов. Для сеньора — участвовать в проработке архитектуры и отвечать на вопросы. Разумеется, это только примеры и список для каждого уровня достаточно большой. Перед ассессментом техлиды направлений оценивают каждого из своих разработчиков по этому списку.
Проджекты заполняют анкеты по каждому из разработчиков в их командах, где дают оценку по десяти важным для нас критериям, от надежности и скорости выполнения задач до командной работы, и того, насколько сотрудник положительно влияет на атмосферу в коллективе.
Лиды гильдий или техлиды смежных проектов проводят техническое интервью разработчика, на котором мы проверяем его фактические знания.
Ну, и, получив информацию по всем трем пунктам, мы собираемся с лидами гильдий и техлидами направлений и проставляем разработчикам новые грейды.
Кто чаще возглавляет команды — продуктовый специалист или технический?
Максим: Обычно это все-таки симбиоз этих двух людей. Их доли в управлении чаще зависят от их софт-скиллов и пожеланий. В каких-то командах продакт просто передает бэклог техлидам и проджектам, и они уже дальше сами ведут работу. В других — продакт очень близок к команде и держит руку на пульсе, а техлид подключается по мере необходимости для проработки сложных вопросов.
Как часто люди меняют команды?
Максим: Не часто, это единичные случаи. Переводим, когда того требует проект или возникают потребности в ресурсах. Еще смена команды может быть пожеланием сотрудника, если он хочет заниматься другими технологиями и открыто заявляет о своем интересе.
Что важнее, софт-скиллы или хард-скиллы?
Максим: Однозначно софт. Сейчас не эра разработки на ассемблере. Если бы мы кодили на ассемблере, то нам важны были бы хард-скиллы, поскольку ставка в этом случае делается на математические навыки. Но хорошие софт-скилы (желание развиваться, мышление) в большей степени влияют на продуктивность. Время, когда один разработчик вытаскивает весь проект, ушло. Мы работаем командой, а без развитых софт-скиллов это очень сложно.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Максим: Помимо обычных планирований спринта / дейликов / демо / ретроспектив, у нас есть практика ежемесячных собраний для всех сотрудников компании. На них мы рассказываем о новых продуктах, результатах работы существующих проектов и направлений, открытых вакансиях, возможностях карьерного роста, бенефитах для сотрудников. На встречах выделяем время на вопросы сотрудников.
Кроме этого, у нас есть практика собрания гильдий: раз в неделю все разработчики гильдии (бэкенд, фронтенд, мобильная разработка), собираются, обсуждают технические вопросы и всячески делятся опытом.
Как вы боретесь с выгоранием сотрудников?
Максим: Мы поем :) Да-да, если ощущаем, что команда устала и пора отдохнуть, то берем гитары и устраиваем «Акустик Сейшн». Кроме того, бывают обычные выездные посиделки с пивом и пиццой. Сейчас из-за эпидемиологической ситуации это сделать сложнее, но мы не унываем и задумываемся о немногочисленной встрече с соблюдением дистанции. Для тех, кто не поёт есть альтернатива — игры в настолки. Проводим встречи один на один, это очень помогает сотруднику рассказать о трудностях, поговорить по душам с лидером. Есть и ещё несколько правил, которых мы стараемся придерживаться.
Мы не «грубим» с переработками. Где-то год назад, в самом начале ковидной истории, была необходимость в жестких кранчах, но сейчас мы снова вернулись в штатный режим и переработки на наших проектах — очень редкое исключение.
Мы не против, если разработчик хочет попробовать себя в чем-то другом. Благо единый язык позволяет нам относительно безболезненно переводить людей между фронтом / бэком / мобильной разработкой при их желании. Разумеется, продвинутый фронт-разработчик не станет сразу полноценным бэком и наоборот, но для нас важно, чтобы люди занимались именно тем, чем им нравится.
Мы следим за отпусками и активно мотивируем людей уходить на отдых.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Максим: На проектах основной язык — TypeScript. Это позволяет нам выстраивать единообразную траекторию обучения на начальном этапе и дает возможность легко проводить ротацию сотрудников при их желании. На TypeScript пишем и бэк, и фронт, и мобильные приложения. Два основных бэк-фреймворка — Hapi и Nest. На фронте —- React. На мобильных приложениях — React Native. В качестве основной базы данных для большинства проектов используем PostgreSQL.
Что вы можете рассказать об архитектуре проектов?
Максим: Чаще всего это микросервисы, которые общаются между собой через NATS или RabbitMQ. Также в копилке есть пара решений на Kafka. Но есть и монолиты. Обычно это проекты на начальной стадии развития, когда все может стремительно меняться. Сейчас стараемся почетче бить монолиты на модули, чтобы потом можно было малой кровью выносить модули в отдельные сервисы. Для этого начали плотно использовать шаблонизаторы и генераторы кода, например Hygen.
Какая у вас принята политика код-ревью?
Максим: Сильно зависит от проекта, но, в основном, код-ревью делают два человека, причем один из них должен быть экспертом в этой области проекта.
Как тестируется код?
Максим: С юнит-тестами все сложно. У нас достаточно сильный отдел QA, который отлавливает львиную долю багов. На части проектов внедряем BDD и автоматическое интеграционное тестирование. В целом бэк значительно лучше покрыт тестами, чем фронт и мобильная часть.
Насчет ручного тестирования — процесс может немного отличаться от проекта к проекту, но в целом он примерно такой:
После выполнения задачи сотрудник передает ее в QA, и QA тестируют ее на дев-контуре.
Собранный релиз едет в стейдж, где QA плотно прогоняют все собранные в релизе задачи, а также проводят экспресс-тестирование всего остального функционала (как бы чего не сломалось).
После релиза на прод QA проводит экспресс-тестирование всего сервиса, чтобы убедиться что релиз прошел штатно.
Как устроен процесс документации и ведения базы знаний на проектах?
Максим: Когда команда 10-15 человек, над документами особо не задумываешься, но когда она вырастает до 80, этот вопрос встает ребром. За последний год наша команда разработки увеличилась в 2,5 раза, и сейчас мы начали структурировать и систематизировать работу с документацией. Формируем гильдию технических писателей. По ведению документации есть два основных направления:
Есть уже достаточно устоявшийся шаблон онбординга проекта. В нем собирается основная информация по проекту, какие модули есть в проекте, что где лежит, кто за что отвечает, как ведется разработка, как проводится деплой. Обычно это документ страниц на 30, который мы выдаем новым разработчикам на ознакомление. Сейчас мы формируем такие документы для каждого проекта.
При необходимости техлиды или сами разработчики размещают запрос, что неплохо было бы задокументировать еще вот эту штуку. Формируется структура документа, назначаются ответственные за каждую часть и технические писатели аккуратно вынимают информацию из голов ответственных и размещают ее в нашей базе знаний.
Документацию, как и работу с задачами, ведем в YouTrack.
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Максим: С учетом нашего быстрого роста, легаси-кода пока не так уж много. Есть некоторые сложности в мобильной разработке в связи с обновлением React Native и совместимости библиотек. В целом, мы гораздо больше пишем нового кода, чем поддерживаем легаси. Но если разработчик объявляет, что нужно зарефакторить ту или иную часть, продакт и техлид решают насколько это может быть важно для проекта и при необходимости ставят задачу в бэклог.
Мы используем файлы cookies. Это необходимо для анализа трафика и корректной работы сайта. Продолжая работу с сайтом, вы подтверждаете свое согласие на применение этих технологий.
кейсы
компетенции
решения
карьера
блог
о нас
контакты
бренд
связаться
