Продолжаем знакомить вас с интересными компаниями на Хабр Карьере. Сегодня в выпуске — компания SiFOX, которая разрабатывает и запускает ИТ-продукты для операторов связи на рынках РФ, Африки и Южной Америки. О том, как всё устроено в Сайфокс нам рассказали Сергей Мацнев (директор проектного офиса) и Станислав Локалин (VP of Engineering).
В этом году сотрудники поставили SiFOX очень хорошую оценку на Хабр Карьере — 4,78 баллов из пяти. Дальше напишем об оценке чуть подробнее.
Кстати, вы можете оценить свою компанию и поделиться мнением о ней с теми, кто сейчас ищет работу. Можно ругать, можно хвалить, главное — оценивать честно!
Содержание выпуска
О компании
SiFOX занимается разработкой, внедрением и эксплуатацией различных сервисов и платформ для мобильных операторов связи. Продукты компании — голосовая почта, запись разговоров, решения для борьбы со спамом. Есть и те, что решают задачи самого оператора и не касаются конечных пользователей, например системы мониторинга и аналитики данных.
У Сайфокс небольшая команда — чуть более 50 человек, но их продукты и решения затрагивают сотни миллионов абонентов по всему миру. В арсенале компании собственная команда разработки, опыт работы более 10 лет, финансирование и, главное, желание создавать востребованные IT-решения. Ребята работают как в офисе, так и удаленно из Москвы и Сан-Франциско.
В 2021 году компания получила среднюю оценку в 4,78 баллов и поднялась в нашем Рейтинге с прошлогоднего 23-го на 20 место. Особенно ценными качествами SiFOX как работодателя сотрудники отметили интересные задачи, современные технологии и то, что она делает мир лучше. Посмотрите на оценку в деталях за этот и прошлый год и почитайте комменты сотрудников в профиле компании на Хабр Карьере.
Об условиях работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Сергей: Еще до пандемии наша команда была распределенной. Ребята работали из разных городов и даже стран, что оставило отпечаток, в первую очередь, на график: диапазон часовых поясов у нас от Тюмени до Сан-Франциско (это больше 12 часов). Эти два города, на самом деле, — крайность, а сотрудники оттуда почти не пересекаются, и обычно приходится учитывать разницу всего в пару часов. Помимо часовых поясов особенностью можно считать то, что нам важнее результат, чем время, проведенное на рабочем месте (тем более, что оно обычно дома), поэтому все работают в комфортном для себя графике. Если вдруг на каком-то участке мы видим, что результат не удается получить без переработки команды, то это повод для изменений: либо меняются планы и перераспределяются задачи, либо расширяется команда, а может быть и то, и другое. Если переработок не избежать — действуем по Трудовому кодексу РФ.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Сергей: Хоть и большая часть команды работает удалённо, офис у нас все же есть, и не один: помимо Москвы у нас есть офисы в Найроби и Рио, поэтому если кто-то захочет снять там квартиру и работать из офиса — welcome. Я бывал только в офисах в Москве и Найроби, и мне они оба нравятся: окна в пол, достаточно искусственного света, прекрасный вид (с 57 этажа в «Сити» в Москве или на прекрасный сад в Найроби), внутри есть все необходимое для работы, переговоров и отдыха. Так что, если хотите сбежать из дома от удаленки, то условия для этого прекрасные.
Есть ли возможность удаленной работы?
Сергей: Возможность удаленной работы была у нас всегда, а в 2020 году мы поняли, что можно работать полностью удаленно всей команде, в том числе и менеджменту компании. Наш СЕО уже успел пожить в Турции, сейчас работает в офисе в Найроби и никто не знает, куда он поедет дальше. А некоторые ребята перебрались в условия, в которых никогда не решились бы остаться надолго, если были бы привязаны к офису.
Какой социальный пакет получают сотрудники?
Сергей: Как и почти везде у нас есть ДМС, также предусмотрены программы по предоставлению оборудования для работы и возможность софинансирования платного обучения.
Какие есть перспективы для образования и личного развития у сотрудников?
Сергей: Обучение мы софинансируем, а не оплачиваем полностью. Не из жадности, а из убеждения в том, что такой подход позволяет, во-первых, выбрать только самые необходимые курсы, а во-вторых, получить от них максимум эффекта. Только участвуя в обучении своими деньгами (пусть и относительно небольшими) сотрудник подойдет к нему максимально ответственно.
Помимо внешних курсов активно занимаемся образованием друг друга: многие наши сотрудники обладают уникальной экспертизой в своих областях и готовы активно делиться ей с коллегами. Мы проводим вебинары по самым разным темам: от менеджмента до архитектуры. В них может принять участие (как спикер или слушатель) любой член команды.
Разумеется, существует и развитие на рабочем месте: каждый сотрудник может взять на себя более сложные задачи, развиваться в той или иной технологии и так далее. Стараемся это поощрять и находить наставников в разных направлениях.
Мы также поощряем участие в профессиональных сообществах и публикации в профильных изданиях. Для увлеченных своим делом людей это прекрасная возможность заниматься любимым делом чуть шире и расти профессионально. А ещё такая деятельность способствует обмену знаниями, привлечению новых идей и повышению узнаваемости нашей компании.
О найме
Во сколько этапов проходит найм и что на них ожидает соискателя?
Сергей: Детали могут отличаться для отдельных особенно критичных ролей в команде, но в общем найм состоит из «двух с половиной» этапов. Первая половина — это интервью с HR, его проходят почти все, чье резюме показалось нам интересным.
После этого следует собеседование с нанимающим менеджером, и это основной этап. Это классическое интервью, на котором менеджер и кандидат знакомятся друг с другом, менеджер рассказывает про компанию и позицию, кандидат рассказывает о себе. В ходе диалога с нашей стороны проверяются различные навыки и компетенции, важные для конкретной позиции, уточняются разные детали из предыдущего опыта и так далее.
Третий этап — собеседование с СЕО. Звучит неожиданно, но размеры нашей команды пока позволяют руководителю компании уделять время общению с кандидатами, тем более, что они попадают к нему, по сути, на утверждение. В ходе этого разговора проводится оценка кандидата на соответствие ценностям нашей компании. Для нас важно, чтобы мы были «на одной волне» с каждым сотрудником, чтобы у всех было общее представление о том, что такое хорошо, а что такое плохо. После одобрения кандидата со стороны СЕО мы готовим оффер, и дальше начинается уже процесс онбординга.
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Станислав: У нас есть тестовые задания для разработчиков, девопсов и тестировщиков. Их задача — показать, что кандидат способен работать с нужными нам технологиями, насколько хорошо он с ними знаком, как эффективно он способен искать информацию из открытых источников. Это полезно и для кандидата — позволяет ему оценить особенности наших задач. Задание не очень сложное, но время на него потратить все же придется. Если уделять ему всё свое время — то около двух дней. Но мы рассчитываем, что с учетом загрузки на основной работе и бытовых дел, кандидат выдаст результат через две-три недели. Сами задачи могут быть разных уровней сложности в зависимости от позиции, на которую претендует кандидат. Мы регулярно собираем обратную связь о наших заданиях, чтобы максимально адаптировать их под те цели, которые должны решать.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Сергей: Совершенно точно мы не продолжим общение с кандидатом, по общению с которым будет видно, что у него нет мотивации на результат, нет уважения к коллективу и нет интереса к работе. У нас было несколько таких людей на собеседованиях: по ним сразу было видно, что по складу мышления они совершенно точно не впишутся в нашу команду.
Кого последнего вы уволили и почему?
Сергей: Все наши увольнения обычно связаны с оптимизацией: когда понимаем, что у нас нет объема задач, чтобы обеспечить всех, приходится расставаться с некоторыми из членов команды. В последнее время у нас это довольно сложно представить, но около года назад не взлетел масштабный проект, в котором планировалось много интерфейсов, поэтому невостребованными остались некоторые члены команды по разработке фронтенда. Пытались придумать, где их можно еще задействовать и в итоге кого-то удалось сохранить. Здесь важно быть честными с сотрудниками: для них ведь отсутствие интересных задач это тоже застой в развитии и карьере, поэтому обе стороны заинтересованы в поиске новых путей.
Как происходит онбординг нового сотрудника?
Сергей: Каждый новый сотрудник в первый же день подписывает документы, получает все пропуска и доступы, технику (если нужно), а также знакомится с ответственным за его онбординг. Задача такого ответственного — познакомить новичка с командой (причем не только с той, где ему предстоит работать), добавить во все чаты и переписки, рассказать про процессы, самостоятельно или с привлечением коллег погрузить в особенности нашей продуктовой линейки. И, разумеется, обозначить его зону ответственности, задачи, цели на ближайшее время и все, что связано с его непосредственной работой.
Мы проводим регулярные неформальные мероприятия в масштабах всей компании, и это тоже помогает новичкам быстрее почувствовать себя частью команды, особенно в условиях удаленной работы. С новичком также проводятся регулярные встречи один на один с руководителем, чтобы обсудить всевозможные вопросы о работе, личном развитии, целях и так далее. Каждый сотрудник нашей компании, включая CEO или сооснователей, всегда доступны для контакта. Все мероприятия проходят с участием всех руководителей, это позволяет минимизировать вероятность информационного вакуум в первую очередь для новичков.
Есть и интересная традиция: в числе прочего есть общий чат для всех сотрудников, куда после добавления новичок пишет приветственное письмо с описанием интересных деталей о своей предыдущей карьере, увлечениях и всем, что посчитает нужным. Коллеги нашли таким образом довольно много пересечений, общих тем для обсуждения, общих знакомых.
О команде
Какая методология разработки у вас используется и почему?
Сергей: У нас есть несколько типов проектов, для каждого из которых используем разные подходы. Я не могу однозначно причислить их к той или иной методологии, потому что в реальной жизни в чистом виде редко кто следует им досконально. Но можно сказать, что проекты по внедрению наших продуктов имеют много общего с waterfall, а разработка работает по спринтам.
Станислав: Разработка ведется итерационно: у нас есть общий бэклог по каждому направлению, и отдельные задачи из него распределяются по спринтам. Это позволяет гораздо раньше получать всесторонний фидбек о том, насколько мы приближаемся к конечной дате получения результата и на правильном ли мы пути. А заказчики этих задач благодаря этому гораздо лучше понимают перспективы выполнения своих запросов. Этот подход начал применяться не так давно и уже показывает хорошие результаты, в том числе в части планирования.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Станислав: Официального распределения по такого рода грейдам у нас нет, но тот или иной опыт есть у всех сотрудников технической команды, то есть можно сказать, что все разработчики у нас по уровню не ниже мидла. Для нас очень важно понимание разработчиками деталей работы наших продуктов, которые довольно специфичны, поэтому дополнительным мерилом самостоятельности и уровня задач, которые можно доверить сотруднику, для нас является срок работы в компании. Опять же, опыт взаимодействия с человеком за более длительный промежуток времени дает больше понимания о том, какие задачи этот сотрудник может решать с разной степенью уверенности.
Кто чаще возглавляет команды — продуктовый специалист или технический?
Станислав: У нас нет продуктовых команд в общепринятом понимании, когда есть продукт, продакт менеджер, группа разработчиков, аналитик, тестировщик и далее по списку, и они годами практически изолированно занимаются этим продуктом. Наши продукты создаются и развиваются нелинейно, поэтому команды собираются под отдельные проекты: провести пилот, разработать новую фичу, внедрить продукт новому оператору, сделать рефакторинг и т. д. Такие проекты можно разделить на две большие группы: внедрение существующего решения (как правило, с небольшими доработками) и создание чего-то нового.
В случае проектов внедрения, команду возглавляет проджект-менеджер, который формулирует и распределяет задачи, следит за сроками и отвечает перед внешним заказчиком.
В случае с созидательными проектами все несколько сложнее. В них участвуют и продакт, который формулирует требования, и проджект, который отвечает за внедрение разрабатываемого решения (новые продукты мы делаем сразу вместе с первым заказчиком), и техлид, который обычно является и архитектором решения. В такой конфигурации лидерство размывается и часто зависит от конкретных персоналий, которые занимаются проектом. Но техлид, в первую очередь, руководит технической командой, а менеджеры решают вопросы другого плана.
Как часто люди меняют команды?
Станислав: Распределение технических специалистов по командам устроено так: разработчики занимаются отдельными модулями наших платформ и продуктов. Какие-то разработки для этих модулей могут в разное время потребоваться для разных проектов, поэтому разработчики могут работать то в одной, то в другой команде, а иногда и в нескольких одновременно. Иногда связка разработчик-модуль меняется: это происходит, когда человеку банально надоело работать на этом участке, либо он разработал какой-то новый модуль и по нему очень большой объем работ — тогда времени на остальные не хватает, и эти связки перераспределяются. К тому же, нам важна взаимозаменяемость, поэтому иногда такая ротация делается специально. Обычно это происходит с появлением новых людей в компании. Как часто — посчитать сложно, по моим ощущениям в среднем работой над одним модулем человек занимается где-то полтора года.
Что важнее, софт-скиллы или хард-скиллы?
Станислав: Для разработчиков — хард скиллы однозначно важнее, поскольку их основная задача — заниматься разработкой, и именно ее качество первично, на что напрямую влияет знание сотрудником технологий и умение их применять. Хотя это и не отменяет важности софт скиллов — они важны для корректной коммуникации, поиска наилучшего решения той или иной задачи и планирования совместной работы. Для менеджеров ситуация может отличаться, хотя и для них хард-скиллы играют очень заметную роль в работе в нашей компании — у нас каждый неплохо подкован в тех технологиях, с которыми мы работаем, хотя и не участвует непосредственно в разработке.
Как вы боретесь с выгоранием сотрудников?
Станислав: вообще, такого диагноза у нас никому не ставили и каких-то однозначных симптомов выгорания у сотрудников не наблюдается. Думаю, это связано с профилактикой: одна из разделяемых всеми в компании ценностей — важность комфортных условий работы. Это выражается во многих деталях, например, в уважении к work-life balance, каких-то командных мероприятиях и поощрении сотрудников в их развитии, в том числе в части повседневных задач.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Станислав: Из основных языков Erlang / OTP, есть приложения на Ruby и Java. Что касается фреймворков, то наши продукты основаны на работе с протоколами голосовой связи на сетях мобильных операторов, поэтому многие технологии, так или иначе, связаны с ними: Kamailio, openSIPS, библиотеки по работе с SMPP. Из более общеприменимых технологий используем HAProxy, Ansible, PostgreSQL, RabbitMQ, Kafka, Cowboy, GAN.
Какая у вас принята политика код-ревью?
Станислав: На данном этапе развития компании код-ревью у нас есть, а политики нет: каждый исполнитель принимает решение о необходимости ревью сам и может попросить кого-то из коллег за ним проверить. Мы доверяем коллегам — они достаточно профессиональны, чтобы оценить, в какой момент они уверены в своей работе, а когда нужна проверка.
Как тестируется код?
Станислав: как раз сейчас мы активно занимаемся разработкой разных автотестов, но нужно понимать специфику продуктов нашей компании. Для части задач нам куда важнее провести нагрузочные тесты, поэтому больше внимания уделяется им. Где-то тесты никак нельзя (либо очень дорого) провести без участия инфраструктуры оператора, а где-то самый эффективный путь — он же самый простой, то есть достаточно проверить работу конечного сервиса руками. Сейчас одна из основных задач — привнести систему в эту область. Департамент QA должен вовлекаться в проект в самом начале, чтобы в полной мере понимать, какое тестирование в какой момент работы над проектом может потребоваться и своевременно описать все тест-кейсы.
Как устроен процесс документации и ведения базы знаний на проектах?
Станислав: Этот процесс тоже в стадии строительства — соответствующее подразделение в компании появилось совсем недавно. Но мы подошли к критической точке, когда без единого для компании документооборота жить больше нельзя. Поэтому сейчас уделяем вопросам его организации очень большое внимание. В перспективе аналитики и технические писатели будут участвовать на всех этапах проектов и сразу готовить все необходимые документы, инструкции и описания.
Оценивайте своих работодателей на Хабр Карьере и рассказывайте о вашем опыте работы с ними: что было круто, а что — не очень. Ваша оценка останется анонимной и поможет определиться тем, кто ищет работу в ИТ.
