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

В этом выпуске мы расскажем о компании «СИГМА», которая разрабатывает IT-решения для цифровизации энергетики и ЖКХ. Предприятие входит в топ-3 крупнейших поставщиков IT-решений для ТЭК и топ-30 крупнейших ИТ-компаний РФ, разрабатывает и внедряет решения для поддержки работы всех сегментов энергетики: производства электроэнергии, её распределения и сбыта, управления бизнес-процессами и обеспечения информационной безопасности. СИГМА — один из лидеров импортозамещения в энергетике: в Реестр российского ПО включено уже 28 решений, разработанных в компании. 

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

→ про оценку компаний

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

О работе и корпоративной жизни в СИГМЕ нам подробно рассказали:

Денис Павлов,

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

Павел Тагиев,

руководитель направления сопровождения корпоративных информационных систем (1С)

Александр Гурьянов,

начальник отдела комплексных решений

Мартин Сигуткин,

начальник управления поддержки бизнес-приложений

Лариса Шевченко,

руководитель отдела по подбору и адаптации персонала

О компании

Публичная оценка компании на «Хабр Карьере» по итогам 2023 года — 4,27 из 5. Сотрудники особенно ценят СИГМУ за комфортные условия труда, вклад в окружающий мир и хорошие отношения с коллегами. Подробнее посмотреть оценки и почитать отзывы сотрудников можно в профиле компании на «Хабр Карьере».

Об условиях работы

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

Мартин Сигуткин: Стандарт — 5/2 с началом рабочего дня в 9:30 и окончанием в 18:00. Есть дежурные специалисты с графиком 2/2. Начало рабочего дня может быть плавающим, всё зависит от договоренностей между сотрудником и руководителем, характера работы и ситуации на проектах. Если ты «жаворонок» и в офисе стабильно с 6 утра, то и уходи с работы раньше. Если ты «сова» и хочешь задерживаться, приходи позже. Главное, чтобы это не сказывалось работе. Переработки случаются на значимых этапах проектов, но не носят постоянный характер.

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

Лариса Шевченко: Наши офисы находятся в 12 городах России в современных бизнес-центрах. Оборудованное рабочее место, техника, корпоративная канцелярия предоставляются каждому сотруднику, а для новичков у нас подготовлен стильный велком-пак. В офисах есть как помещения типа опенспейс, так и отдельные кабинеты, а также комфортабельные кухни и уютные комнаты отдыха. Комнаты отдыха оборудованы по-разному: есть спортивные уголки, массажные кресла, игровые зоны.

Мартин Сигуткин: Рабочее место собирается и тестируется до первого рабочего дня сотрудника. На своём примере могу сказать, что компания лояльна к последователям учения о корреляции продуктивности человека с числом, диагональю и разрешением установленных у него мониторов, поэтому если заранее сообщить, что у вас мультимониторность, вам всё установят.

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

Лариса Шевченко: В СИГМЕ есть три формата работы: офис, гибрид или удалёнка. Какой формат предпочтительнее, зависит от должности. Есть сотрудники, которые могут выполнять рабочие задачи полностью удалённо, а некоторым в силу специфики работы требуется периодическое или постоянное присутствие в офисе. 

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

Лариса Шевченко: Каждому сотруднику после прохождения испытательного срока оформляется расширенный полис ДМС со стоматологией, диспансеризацией, психологической поддержкой и страховкой для путешествий. Он позволяет получать помощь в ведущих медучреждениях России. У нас работает и программа «Приведи друга»: если по рекомендации сотрудника в СИГМУ устроился и прошёл испытательный срок новый специалист, рекомендатель получает денежный бонус. Также сотрудники могут пользоваться сервисом корпоративных скидок BestBenefits.

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

Лариса Шевченко: В нашей компании можно получать новые знания не только на практике, но и на профильных курсах. У сотрудников есть возможность за счёт компании пройти обучение по своему направлению для повышения квалификации. Также в СИГМЕ активно развивается собственная база знаний и курсы по хард- и софт-скиллам. По желанию сотрудника для него могут подготовить индивидуальный план развития. Кроме того, коллегам доступен сервис корпоративной библиотеки со множеством полезных книг об IT, работе в команде и саморазвитии. За счёт компании эксперты могут выступать на профильных конференциях, делиться опытом СИГМЫ и знакомиться с практиками других компаний.

Денис Павлов: Передача экспертности опытных коллег и внешнее образование. Мне компания оплачивала участие в конференциях (OffZone, PHD), закупала на наш отдел подписку на специализированный сайт с курсами по ИБ. Коллегам из отдела оплачивали курсы от CyberEd (по анализу защищенности мобильных приложений, по тестированию на проникновение), участие в других конференциях (например, «БеКон»).

О найме

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

Лариса Шевченко: Сначала с кандидатом связывается HR-менеджер, чаще всего это телефонный звонок. Следующий этап — очное или видеособеседование с непосредственным руководителем. Возможен этап с тестовым заданием, но оно даётся не по всем направлениям. Можем также запросить примеры выполненных задач, портфолио или ccылку на аккаунт кандидата в GitHub. По итогам всех этапов принимается решение, делать ли оффер.

Это общая последовательность, она может меняться в зависимости от специфики департамента, в который мы ищем специалиста. Бывает, что собеседование проходит сразу с несколькими руководителями (например, руководителем отдела и РП или РП и тимлидом) или сначала идет техническое интервью, а потом собеседование с командой проекта.

От чего зависит, получит ли кандидат тестовое задание? Что в него входит?

Лариса Шевченко: Наличие и особенности тестового задания отличаются в зависимости от позиции, на которую рассматривается кандидат. Для разработчиков это может быть код-ревью, для аналитиков — подготовка бизнес-схемы или работа в Excel. На выполнение тестового дается определённый срок, который мы оговариваем с кандидатом заранее. Бывают и задания, которые необходимо сделать на этапе собеседования с техническим специалистом.

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

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

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

Лариса Шевченко: В связи с требованиями информационной безопасности у нас нет возможности сотрудничать со специалистами, которые хотят работать, находясь за рубежом.

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

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

Лариса Шевченко: За каждым новичком закреплён свой HR, который сопровождает его первые три месяца. Рассказывает необходимую информацию о компании, проводит экскурсию по офису, знакомит с коллегами. Также за сотрудником закреплён куратор. Он составляет новичку план на испытательный срок и контролирует сроки выполнения задач. За время испытательного срока HR проводит несколько встреч с новым сотрудником, его наставником и руководителем, где они обсуждают текущие результаты работы, вопросы, которые возникают у новичка, его впечатления. В первые дни новички проходят welcome-курс, где собрана полезная информация о правилах работы, истории, ценностях и корпоративных бонусах СИГМЫ.

Также наши HR-специалисты проводят для новых сотрудников welcome-встречу в игровом формате. Её участники выступают в роли ученых, которые прилетели исследовать новую планету — СИГМУ. Каждый участник в ходе игры попадает в разные ситуации, которые помогают в таком необычном формате познакомиться с компанией, её миссией и ценностями, а также дают ему возможность рассказать о себе, своих увлечениях и целях.

Добавлю, что процесс адаптации мы автоматизировали на корпоративном портале. Период онбординга проходит комфортно как для новых сотрудников, так и для руководителей и кураторов, всё необходимое под рукой: задачи на период испытательного срока, информация о руководителе, наставнике, HR.

О проекте

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

Павел Тагиев: Наша команда использует гибридную методологию разработки, сочетающую элементы Agile и Waterfall. Такой подход позволяет эффективно планировать этапы работы, контролировать процесс разработки, гибко реагировать на изменения в требованиях и условиях рынка. Ввиду масштабов наших заказчиков больший уклон идёт в сторону Waterfall, чтобы обеспечивать контроль над процессом разработки и эффективно управлять рисками на ранних стадиях проекта.

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

Павел Тагиев: Размер команды варьируется от 10 до 40 человек. Структура может быть разной. Например, иерархической, где есть чёткое разделение ролей и обязанностей. Или же более гибкой, где специалисты могут выполнять несколько ролей в зависимости от потребностей проекта. Но общий принцип единый:

• Руководитель проекта (РП) — отвечает за планирование, координацию и контроль выполнения задач.
  

• Функциональный архитектор — определяет структуру и функциональность системы. Он разрабатывает архитектурный план с описанием основных компонентов системы и их взаимодействием.
  

• Технический архитектор — эксперт, который занимается выбором решений для реализации проекта. Также отвечает за безопасность и надёжность системы.
  

• Аналитики — специалисты, которые собирают и анализируют требования к системе. Они также помогают разработчикам понять, как реализовать эти требования.
  

• Программисты — разработчики, которые творят чудо.

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

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

Александр Гурьянов: В этом вопросе нам помогает периодическая оценка навыков сотрудников. Для каждой должности есть перечень необходимых скиллов, именно их наличие у разработчика оценивает руководитель на техническом интервью-аттестации. По инициативе руководителя или самого сотрудника ему может быть предложен индивидуальный план развития (ИПР). ИПР составляется с учётом пожеланий разработчика и потребностей проекта, в котором он задействован. Туда могут быть включены такие задачи, как изучение новых технологий, чтение профессиональной литературы и так далее. По завершении ИПР проводится аттестация разработчика. На основе её результатов и обратной связи от коллег сотрудника принимается решение об изменении его должности, повышении заработной платы. На этом этапе мы обновляем (либо оставляем текущий) грейд сотрудника, с которым он остается до следующей аттестации.

Павел Тагиев: Здесь важен практический опыт специалиста, чем он занимался на предыдущих проектах, какие задачи и с помощью каких технологий решал. Также оценивается масштаб этих проектов. Ещё смотрим на имеющиеся сертификаты.

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

Лариса Шевченко: Для таких специалистов, как аналитики и разработчики, на первом месте, безусловно, харды. Для руководителей преимущественно важны управленческие качества.

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

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

Мартин Сигуткин: Это не является распространённой практикой, но такие смены есть. Мы стремимся к долгосрочному привлечению людей на проекты. Но если человек хочет сменить проект или его компетенции и навыки срочно нужны на другом проекте, это нормально.

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

Лариса Шевченко: Зависит от команды — у одних ежедневные утренние митинги, а у других собрания раз в неделю. Если говорить про мой отдел, у нас есть еженедельная планерка, также раз в две недели я встречаюсь со своими сотрудниками в формате one-to-one. Такие встречи помогают лучше понять эмоциональное состояние сотрудника, какие задачи даются ему хорошо, а что вызывает сложности, как лучше перераспределить нагрузку,  и т.д.

Мартин Сигуткин: Стараемся минимизировать число встреч. По умолчанию у каждой встречи должна быть повестка и протокол. Протокол обязательно отправляется участникам встречи в почту или закрепляется в базе знаний. За продуктивность каждой встречи отвечает её организатор.

В целом встречи можно разделить на несколько типов:

1. «Я нажал и всё пропало» — экстренные ВКС при форс-мажорах по любым причинам. На них обязательно приходят все, кто имеет отношение к проблеме и может что-то делать для её решения. Такие ВКС случаются редко и проводятся без формальностей. Цель одна — любой ценой закрыть вопрос.

2. «Регламентный синк» — планирование, ретроспективы, ревью по проекту раз в 1-2 недели. Проводятся с фиксацией обсуждения, участвует состав, который определит команда.

3. «Понятно, что ничего не понятно» — различные R&D и нестандартные задачи. Проходят в формате брейнштормов и попыток декомпозиции задач.

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

Лариса Шевченко: Сотрудников могут перенаправить с одного проекта на другой, чтобы разнообразить его деятельность. Либо сменить пул задач, предоставить возможности для развития. Недавно благодаря организационным изменениям в нашей компании внутри отделов появились новые группы, а в них — свои руководители. Это был дополнительный стимул для сотрудников, которые хотели развиваться и получить руководящие позиции. В некоторых случаях, если человек устал, ему помогает отпуск. У нас недавно даже был такой пример. Сотрудник устал и хотел уволиться, но ему предложили пойти в отпуск. Отдохнув, он передумал увольняться :).

Мартин Сигуткин: Минимизируем фактор «работа в стол», стараемся всем специалистам давать понимание, какой вклад их часть работы внесёт в общее дело. Негатив от заказчиков не пропускаем к техническим специалистам, а грамотно фильтруем через менеджмент, оставляя только рациональную часть. Следим за объёмами задач в командах и их распределением, а также чтобы сотрудники вовремя ходили в отпуск. Если у человека перегруз рутиной, разгружаем его и меняем вектор работы. Бывает избыток творческих задач без конкретной постановки и вводных, тогда стараемся накинуть чего-то попроще и понятнее. Если у сотрудника ступор перед грандиозной и длительной активностью, помогаем декомпозировать её.

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

И в заключение — о технологиях

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

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

• Бэкенд: Go, C#, Java, PHP

• Фронтенд: JavaScript (React, Angular, Vue.js)

• Мобильная разработка: Kotlin, Kotlin Multiplatform, Dart, Flutter, Swift, Qt, C++

Для наших проектов также активно применяются такие технологии, как Kubernetes, Docker, PostgreSQL, MongoDB, Kafka, RabbitMQ, ActiveMQ, ELK, Prometheus, Grafana, S3, OpenAPI и многие другие. Выбор конкретных инструментов всегда зависит от задач и требований проекта.

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

Александр Гурьянов: В рамках бэкенда мы используем микросервисную архитектуру, а в мобильных приложениях отдаем предпочтение многомодульному подходу. Наша компания специализируется на цифровизации электроэнергетики, за годы работы в этом направлении мы создали множество сервисов, компонентов и библиотек, которые стали основой таких платформ, как «СИГМА:Алькор» и не только. Эти элементы служат строительными блоками для всех наших систем. На этапах проектирования и разработки мы заранее учитываем, что этот код будет использоваться повторно, и оформляем его как часть нашей платформы. На «Алькоре», например, мы разработали несколько мобильных приложений для сотрудников электростанций, сетевых компаний. Об одном из проектов я рассказывал в нашем блоге на Хабре. 

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

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

Денис Павлов: Со своей стороны стараемся обеспечивать security код-ревью.

Павел Тагиев: Каждый разработчик — художник, который создаёт свои шедевры. Но чтобы картина стала по-настоящему великолепной, она должна пройти через руки опытного куратора. Куратор ищет не только ошибки и недочёты, но и скрытые смыслы, тайные послания и шутки. Художника, конечно, легко обидеть, но регламент есть регламент.

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

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

Денис Павлов: Написали об этом целую статью на Хабре.

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

Александр Гурьянов: Мы используем Confluence для ведения документации. Аналитики, следуя принятому в командах процессу, сначала фиксируют требования в Confluence, а затем создают задачи в Jira, добавляя ссылки на соответствующие статьи в Confluence. Остальные проектные детали оформляются там же. Что касается технической документации, она хранится как в Confluence (общая часть), так и в GitLab (персонально для репозитория). Сейчас мы рассматриваем возможность унификации процесса с помощью единого подхода на основе AsciiDoc и Antora. Документацию API ведем по спецификации OpenAPI, используем автоматическую генерацию (Swagger, RapiDoc).

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

Александр Гурьянов: Количество такого кода разнится от проекта к проекту. Конечно, мы стремимся к его минимизации. К сожалению, с учетом специфики заказной разработки не всегда получается уделять этому много времени. Рефакторинг кода может занимать до 20% времени разработчика на проекте. Тем не менее создание общей компонентной базы помогает нам значительно ускорить обновление устаревшего кода.

Как реагируете на сообщения пользователей о багах и просьбы по улучшению сервисов/продуктов? 

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

Мартин Сигуткин: Проводим интереснейшее расследование для понимания, что нужно исправить, чтобы закрыть задачу. И, конечно, радуемся, когда новое решение показывает свою работоспособность. Критика от пользователей — это очень сильная обратная связь, она не всегда технически грамотна, но даёт самое лучшее понимание, что «болит» у пользователя.