Наша рубрика «Где работать в ИТ» — это интервью с интересными айти-компаниями, в которых они детально рассказывают о своей внутренней кухне: от условий работы до тестирования кода. Мы задаем компаниям вопросы, публикуем ответы и разбавляем их фотками, чтобы вы смогли посмотреть на внутренние процессы со всех сторон.

Сегодня герой рубрики — компания IBS, специализирующаяся на разработке, тестировании и кастомизации ПО, аутсорсинге ИТ-систем, консалтинге и системной интеграции в сфере хостинга ИТ-инфраструктуры. 

Также в этих выпусках мы рассказываем об оценках компаний на Хабр Карьере, чтобы вы были в курсе, за что их любят (или нет?) сотрудники. А если вы оцените своего работодателя, это поможет тем, кто сейчас ищет работу в айти. 

→ оценить работодателя

Содержание выпуска

• О компании

• Условия работы

• О найме

• О команде

• О технологиях

Кто отвечал на вопросы

Обо всех процессах в IBS нам подробно рассказали:

Валентин Халмухамедов

Заместитель директора департамента разработки

Таисия Бикулич

Рекрутинг-партнер дивизиона разработки и тестирования

Александра Войновская

Директор по персоналу дивизиона разработки и тестирования

Маргарита Пласкеева

Директор центра развития корпоративной культуры

О компании

IBS — это ИТ-сервисная российская компания, которая занимается разработкой ИТ-систем для бизнеса. Она предоставляет услуги в области управления данными, анализа и моделирования, разработки, тестирования и сопровождения ПО. А также создает вычислительные центры и СХД.

В компании работает более трех тысяч сотрудников — инженеров, архитекторов, аналитиков, программистов и консультантов. Головной офис IBS находится в Москве, а офисы разработки и обслуживания клиентов — в Санкт-Петербурге, Нижнем Новгороде, Белгороде, Перми, Пензе, Ульяновске, Уфе, Барнауле, Вологде, Новосибирске и Ижевске.

На Хабр Карьере сотрудники оценили IBS на 4,33 из 5, особо отметив комфортные условия труда, отношения с коллегами и карьерный рост.  Детально изучить оценки и почитать комментарии сотрудников можно в профиле IBS на Хабр Карьере.

Условия работы

Какой в вашей компании сложился рабочий график и какое отношение к переработкам?

Валентин Халмухамедов: Общепринятым для всей группы компаний IBS считается рабочее время с 10 ч. до 19 ч., при этом на уровне проектных команд или отдельных подразделений могут быть установлены свои правила. Кроме того, сотрудник может договориться со своим руководителем об индивидуальном графике. Например, попросить меньше рабочих часов или дней в неделю, зафиксировать нестандартное время начала и окончания рабочего дня. Последнее особенно актуально для территориально распределенных команд, в которых иногда работают сотрудники из разных часовых поясов.

При подключении к команде сотрудник договаривается с тимлидом и руководителем проекта об обязательных встречах, статусах, интервалах доступности. Обычно это завязано на daily-митинги, планерки, режим работы аналитиков или показы заказчику — зависит от роли в команде (разработчик, аналитик, тестировщик, DevOps) и выполняемых задач.

Мы внимательно относимся к переработкам: это не только способ закрыть долги или «затащить» показ/релиз, но и верный способ «пережечь» сотрудника. Поэтому в случае частых переработок помогаем сотрудникам выстроить загрузку: перераспределить задачи, подобрать более гибкий график, согласовать отпуск или отгулы. 

Какие бытовые условия ждут нового сотрудника на рабочем месте?

Маргарита Пласкеева: Офисы IBS открыты в 11 городах: Москве, Барнауле, Белгороде, Ижевске, Нижнем Новгороде, Пензе, Перми, Санкт-Петербурге, Ульяновске, Уфе и Новосибирске. Как правило, это локации в центре города или недалеко от центра, чтобы было удобно добираться как на собственной машине, так и на общественном транспорте. 

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

Пространства для отдыха, конечно, есть во всех офисах, но самое большое и современное — то, что мы между собой называем частью «офиса будущего» — все же первым появится в Москве. С московского центра у нас вообще начинаются многие внутренние проекты — так уж вышло, что в головном офисе работает самая большая команда (почти треть всей компании), поэтому на ней и тестируем все улучшения. А потом масштабируем на офисы в других городах.

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

Большинство сотрудников работает на корпоративной технике Dell, Lenovo, а с недавних пор — и на оборудовании собственного производства IBS, ноутбуках «Сила». Но мы не запрещаем и использование личных ноутбуков (обычно это выбирают те, кто работает на технике Apple), лишь бы были соблюдены все правила безопасности и использовалось лицензионное ПО. Мы не ограничиваем сотрудников в количестве техники, это наши основные инструменты работы. Поэтому, если кому-то из ребят нужны два ноутбука или несколько мониторов, например, или другое оборудование, его всегда можно заказать у администратора подразделения. 

 Есть ли возможность удаленной работы? 

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

А в прошлом году IBS создала совершенно особенный центр, в котором работают только дистанционные сотрудники из 70 городов. Все они работают в штате и пользуются практически всеми возможностями и сервисами, которые есть у сотрудников в физическом офисе: участвуют в корпоративных мероприятиях, могут проходить обучение на корпоративных курсах, заказывать технику для работы с доставкой прямо на дом и много чего еще. Если человек хочет работать в IBS и при этом жить в родном городе, где нет нашего офиса, — не проблема! Уже сегодня 10% нашей компании — это дистанционные сотрудники. И их количество только растет. Для нас не важно, где написан код, если он рабочий.   

Какой социальный пакет получают сотрудники? 

Маргарита, Таисия Бикулич: У нас есть ДМС со стоматологией, специальные условия на программы ДМС для родственников сотрудников, страхование жизни, туристические страховки, психологическая помощь. Особенно мы гордимся нашей уникальной корпоративной программой онкострахования, подобных нет ни в одной другой компании. Мы сотрудничаем с передовыми клиниками России, Европы и Израиля. Эту программу 5 лет назад мы разработали вместе с нашим страховым партнером и сейчас можем смело утверждать, что все это было не зря. Программа востребована, и ее результаты очевидны. 

Ежегодно во всех центрах IBS мы организуем вакцинацию для сотрудников. Сначала мы прививали только от гриппа, а теперь и против COVID-19. После вакцинации сотрудник может взять отгул. Кстати, есть еще одна удобная опция для сотрудников, связанная со здоровьем. Она называется «День без больничного»: 3 дня в году сотрудник может взять для восстановления здоровья без оформления больничного листа, просто поставив в корпоративной системе отметку о своем отсутствии с использованием опции «День без больничного». Кроме того, в компании два раза в год проходят «Недели здоровья», во время которых сотрудники могут пройти чек-ап, проверить свое физическое и ментальное здоровье с помощью приглашенных специалистов.

У нас много корпоративных мероприятий: день рождения компании, ежегодный семейный фестиваль Family Day, новогодняя ярмарка, кибертурниры, неделя «Pro Добро», ежегодный фотоконкурс. Кроме того, отдельные подразделения постоянно устраивают собственные праздники и тимбилдинги. На 1 сентября и Новый год вот уже много лет мы традиционно дарим подарки детям всех сотрудников.

Во всех региональных центрах IBS есть спортивные клубы: беговой, футбольный, волейбольный, йога. 

Для сотрудников действуют специальные банковские программы. 

Кроме того, у IBS много компаний-партнеров, которые регулярно разрабатывают спецпредложения для наших сотрудников. Например, Prime Zone, Skillbox, GeekBrains, «Радио Арзамас», Skyeng. 

Какие бонусы, премии и компенсации предусмотрены в компании?

Валентин, Маргарита: Для проектных команд предусмотрены бонусы по итогам реализованного проекта. Для линейного руководства есть также годовые бонусы. Кроме того, у разных подразделений компании есть свои бонусные программы и принципы премирования сотрудников. 

У нас есть премия за преподавательскую и наставническую работу внутри компании от корпоративного образовательного проекта «Среда развития», реферальные карьерные программы. 

Какие есть перспективы для образования и личного развития у сотрудников?

Маргарита, Таисия: В IBS уже много лет работает образовательный центр «Среда развития». Эта команда организует различные образовательные мероприятия для сотрудников и стажеров компании: от небольших обучающих курсов до фундаментальных программ уровня MBA. Кстати, более 80 сотрудников IBS являются преподавателями «Среды развития». Все они эксперты из различных сфер, и вместе с нашими методологами они разрабатывают для коллег обучающие курсы и программы, проводят вебинары, лекции, мастер-классы. У нас также есть лекторий «Биржа знаний», куда мы приглашаем интересных спикеров (как из числа сотрудников, так и сторонних экспертов) поделиться своей экспертизой. 

Есть программы для прокачивания навыков переговоров, клуб спикеров, курс по развитию базовых управленческих навыков, школа руководителей проектов, лидерские программы. Кроме того, в IBS есть большая электронная и бумажная библиотеки, которые постоянно пополняются. Электронное собрание открыто для всех сотрудников, а стеллажи с бумажными книгами и вовсе просто установлены в разных частях офиса (в коридорах, кафе, атриумах, опенспейсах) — можно в любое время взять любую книгу и вернуть, когда будет удобно.

С каждым сотрудником мы определяем вектор развития и составляем план обучения. Обязательно разделяем рост по hard и soft скиллам, всегда развиваем оба направления, но в зависимости от вектора можем делать упор на одно из них. Большая часть наших руководителей и ведущих экспертов выросла внутри IBS из Junior-специалистов, и это для нас важный показатель. 

Ну и конечно, сотрудники могут изучать языки. Еженедельно проходят встречи разговорного клуба английского языка Speak & Play. Присоединиться к ним могут все желающие, независимо от уровня владения языком. Встречи клуба ведет native speaker. Кроме того, для сотрудников IBS, их родственников и друзей действуют специальные предложения от наших партнерских языковых школ.

О найме 

Во сколько этапов проходит найм и что на них ожидает соискателя?

Валентин: В зависимости от проекта и специализации может быть разное количество этапов, в среднем каждый кандидат проходит от двух до трех. Это встреча с рекрутером, интервью с непосредственным руководителем, руководителем проекта и командой. Знакомство с рекрутером и интервью с руководителем занимают 1-1,5 часа. Остальные этапы длятся 15-20 минут. После этого мы принимаем решение — высылаем официальный оффер или отказываем. Даже если специалист нам не подходит, мы стараемся дать конструктивные советы по развитию в интересном ему направлении. 

Даете ли вы тестовое задание кандидатам? Как оно устроено?

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

Как происходит онбординг?

Маргарита, Александра: Новичка подключают к информационным системам и сервисам — и начинают знакомить с компанией. Первый рабочий день сотрудника начинается с welcome-встречи с HR-менеджером, на которой специалисту рассказывают о компании и о том, как будет строиться его жизнь и работа в команде. В течение испытательного срока организуется еще несколько встреч, которые помогают новому сотруднику освоиться и узнать все, что необходимо о его подразделении, проектах, познакомиться с ключевыми лицами. На таких встречах, помимо HR-менеджера, как правило присутствует кто-то из опытных IT-сотрудников компании, который может поделиться с новичком своим опытом работы в IBS. Цель такого общения — снять возможные вопросы на этапе онбординга и сделать адаптацию максимально комфортной.

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

О команде

Какая методология разработки у вас используется и почему?

Валентин: Мы разработали и применяем свою собственную методологию. По большей части в ней используются подходы SCRUM: работаем двухнедельными спринтами, проводим daily, демо, ретро, используем сторипоинты по усмотрению команды и тимлида. При этом большая часть наших проектов имеет фиксированные сроки, бюджеты и DoD (Definition of Done). Поэтому руководитель проекта ведет общий план работ в таких инструментах, как MS Project, JIRA Structure, BigPicture, и с его подачи проект ведется по водопадной модели.

Особенность нашей методологии заключается в точках соприкосновения и настроенных интеграциях, синхронизациях между видением руководителя проекта (сроки, бюджет) и тимлида (спринты, гибкость). В ней также зафиксированы лучшие практики работы с требованиями, планирования работ, написания кода, ведения Git. На этой методологии мы проводим обучение и воспитываем джунов. Сотрудникам не приходится в очередной раз искать ответы на вопросы о том, как устроены процессы, как правильно работать в JIRA, Confluence, Git (Bitbucket), инструментах CI/CD (Jenkins, OpenShift), QA.

 Каковы размеры и структуры команд?

Валентин: Как правило, над проектом работает команда из 10 человек. Бывает и меньше. Тут мы придерживаемся «правила двух пицц». В команду входят разработчики, аналитики, тестировщики, DevOps, UX/UI-дизайнер (при необходимости), руководитель проектов и тимлид. К слову, разработку мы ведем обязательно с помощью тимлидов. Это главный интерфейс команды для руководителя проекта. В конечном счете РП может и не знать, что делают или где территориально находятся разработчики или аналитики. Главное — чтобы это знал тимлид. 

По каким критериям вы разбиваете разработчиков на джунов, мидлов и сеньоров?

Валентин: У нас есть разработанная и общедоступная матрица компетенций. В ней есть и скиллсеты — список требуемых и желательных компетенций на том или ином уровне для разных профилей (разработка бэкенд, фронтенд, аналитика, DevOps и т.д). Эта же матрица используется в рамках регулярных Performance Review для принятия решения о повышении специалиста до следующего уровня. Но матрица  — это только один из инструментов оценки. Еще мы принимаем во внимание такие критерии, как обратная связь, личностный профиль, пожелания самого сотрудника. Решение о переходах между грейдами принимает непосредственный руководитель после разговора с сотрудником.

Кто чаще возглавляет команды — продуктовый специалист или технический?

Валентин: Команду разработки возглавляет тимлид разработки, который вырастает из «технаря» (разработчик, системный инженер, тестировщик). Организационные вопросы управления проектами берет на себя руководитель проекта, который обычно вырастает из аналитика, архитектора, администратора проекта.

Как часто люди меняют команды?

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

Что важнее, софт-скиллы или хард-скиллы?

Валентин: Техническим экспертам важнее хард скиллы, управленцам больше софт. Но при этом мы всегда стараемся развивать сотрудников органично. Например, в плане развития разработчиков указываем цель личностного роста. Это может быть обучение или личное достижение на проекте (инициатива в области наставничества, например). С управленческим персоналом мы действуем аналогично: всегда погружаем их в «технику» — мы ведь IT-компания.

Как много собраний у вас проводится? Есть ли особые подходы к ним?

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

Как вы боретесь с выгоранием сотрудников?

Валентин, Таисия: Мы регулярно мониторим состояние сотрудников и продвигаем культуру обратной связи в команде. Этим занимаются их непосредственные руководители, тимлиды, руководители проектов и HR-менеджеры. Помимо обратной связи от самого сотрудника (во время которой он может и не сказать о выгорании), мы смотрим на загруженность: пиковые режимы всей команды перед показами, овертаймы и выходы в выходные, конфликты в команде, негативные события в личной жизни. Это позволяет нам прогнозировать и предотвращать выгорание.

В таких случаях отпуска, отгулы, ротации, перераспределение задач (снижение загрузки, повышение разнообразности, задачи нового типа) — все идет в работу. Обычно решение представляет собой комплексный подход: в части проектных задач, времени для отдыха и отвлечения, мониторинга и поддержки руководителя и HR, корректировки целей развития. Если все это не помогло, можем предложить сотруднику длительный отпуск, выводим ему замену. 

О технологиях

Какие языки, фреймворки и библиотеки используются на проекте?

Валентин: У нас очень много проектов и везде есть своя специфика, чаще всего она связана с существующей экосистемой заказчика. Есть зафиксированный технологический стек, который мы стараемся применять на проектах. Это набор технологий и библиотек, разделенных по направлениям (back-end, front-end, хранилища SQL, хранилища NoSQL, ETL, большие данные, распределенные вычисления, журналирование, мониторинг и другие).

Вот некоторые технологии из стека: JS, TS, React, Redux, MobX, Material-UI, Npm, Webpack, Java, Spring, Hibernate, библиотеки Apache, .Net, c#, Postgre, NiFi, MinIO, Apache Hadoop, Hive, Docker, OpenShift, ELK, Grafana и многое другое. Все они регулярно проходят архитектурное ревью и актуализируются. Наш стек включает только актуальные и проверенные технологии, так что заказчик прислушивается и часто готов идти нам навстречу.  

Что вы можете рассказать об архитектуре проектов?

Валентин: Это зависит от проекта. Чаще это микросервисная архитектура с Kafka или Rabbit в роли брокера. Почти всегда есть: REST API (документируем через OpenAPI в Swagger), SQL хранилище (обычно Postgre), фронт на React. Это такой «набор джентльмена» на любом современном проекте. А вот дальше начинается специфика: использование микрофронта в Webpack 5, Аpache NiFi для ETL и т.д.

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

Какая у вас принята политика код-ревью?

Валентин: Код-ревью является обязательным на всех проектах. Даже там, где разработчик один — в таком случае мы прибегаем к кросс-ревью разработчиками или тимлидами с других проектов. Код-ревью проводим в BitBucket как обязательный шаг до мерджа. В укомплектованных командах всегда ставим минимальное количество ревьюеров, обычно их двое. Причем один из них обязательно тимлид, а второй должен быть уровнем не ниже разработчика, чей код проверяется. Правила код-ревью стандартные: мы выделяем 20 пунктов, которым надо следовать. Они зафиксированы в нашей методологии управления разработкой и включают как общие требования (размеры файлов, комментарии, соблюдение принципов ООП), так и детальные (корректные алгоритмы, использование библиотек и сервисов).

Как тестируется код?

Валентин: У нас одна из крупнейших на рынке практик тестирования, и все работы по этим задачам выстроены максимально эффективно. На всех проектах обязательно функциональное тестирование. Обычно это делают тестировщики либо руками, либо через автоматические сценарии. К слову, для написания сценариев мы используем свои разработанные продукты: «Кайман» и «Хамелеон». Они автоматизируют создание, запуск, мониторинг исполнения функциональных и нагрузочных тестов. На ряде проектов также пишем модульные тесты. Особенно там, где есть жесткие требования заказчика. На одном из текущих проектов, например, есть требование Code Coverage 80%. По результатам всех тестов формируются отчеты о тестировании и качестве продукта/системы/инкремента.

Как устроен процесс документации и ведения базы знаний на проектах?

Валентин: Проектная база знаний является обязательной. Ее ведение описано в нашей методологии управления разработкой. Используем Atlassian Confluence, интегрированный с JIRA. Структура базы знаний всегда одинаковая и представляет собой иерархию, где на верхнем уровне расположены организационная информация, функциональные требования, разработка, управление релизами и т. д. В Confluence аналитики фиксируют постановки и привязывают их к соответствующим задачам в JIRA. Все требования ведутся с использованием плагина Requirement Yogi. Он позволяет структурировать требования, кодировать их, следить за полнотой, версионировать. В общем, это прозрачная система для всех, включая разработчиков.

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Валентин: У нас редко бывает легаси — 80% проектов мы разрабатываем с нуля и легаси вообще нет. Но есть и проекты с легаси. Пока что не было проблем с его перенятием, ведением, рефакторингом. Конечно, стараемся скорее покрыть код тестами (если это еще не сделано), чтобы изменения проводились как можно безопаснее.

Оценивайте компании на Хабр Карьере и делитесь мнением о них с теми, кто сейчас ищет работу в ИТ. Это анонимно.

→ оценить работодателя