Сегодня в рубрике «Где работать в ИТ» расскажем вам о компании GigAnt, которая занимается развитием сервиса для временных сотрудников в ритейле и общепите и работает с топ-10 ритейлеров России. Компания быстро выросла и в декабре прошлого года получила инвестиции от Авито.
В этом году сотрудники оценили работодательские качества GigAnt на 4,79 из пяти. Ребята занимают пятое место в нашем рейтинге среди компаний со штатом от 100 до 1000 человек. О том, как всё устроено в Гиганте нам рассказали эйчар-менеджер Ольга Бессонова, продакт Игорь Фалин, лид разработки Яков Макаров и технический писатель Николай Красильников.
Оценивайте своих работодателей на Хабр Карьере и помогите ИТ-сообществу узнать, как вам там работается.
Навигация по выпуску
О компании
GigAnt — это Убер для «синих воротничков». Сервис соединяет людей, ищущих удобную подработку, с компаниями, которым нужны надежные исполнители временной работы. Основанная в 2019 году компания сейчас сотрудничает с такими лидерами рынка, как «Вкусвилл», Лента, Дикси, Spar и др. Сервис уже работает в Москве, Санкт-Петербурге, Новосибирске, Твери и Ульяновске и география присутствия продолжает расширяться.
На Хабр Карьере сотрудники оценили GigAnt на 4,79 из пяти, особо отметив интересные задачи, карьерный рост и то, что компания делает мир лучше. Посмотрите оценки и комменты в профиле Гигант на Хабр Карьере.
Кстати, ребята сейчас активно набирают себе разработчиков, аналитиков и тестировщиков! Взгляните на их открытые вакансии, может вам что-то придется по вкусу.
Об условиях работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Ольга Бессонова: Мы работаем по гибридному графику: в офисе и удаленно. Ребята пару раз в неделю встречаются в офисе (можно и удаленно) для синхронизации по важным и текущим вопросам, есть летучки, но у каждой команды они проходят по-разному. Есть те, кто проводит их каждый день утром по полчаса, в основном это команда HRM и мобильной разработки. Переработок у нас нет, так как все четко формируют свой график в зависимости от задач проекта.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Ольга: У нас просторный офис в Санкт-Петербурге в современном БЦ «Leader Tower» на 140-метровой высоте 40 этажа с потрясающим панорамным видом. По организации пространства — это open space со стеклянными перегородками и свободной рассадкой. Есть закрепленные рабочие места у тех сотрудников, кто постоянно работает в офисе. Мебель — эргономичные кресла, небольшие столы с розетками. Есть переговорная, столовая, зона для отдыха и любимый аквариум с акулами.
Есть ли возможность удаленной работы?
Ольга: Да, конечно, у нас многие сотрудники сейчас работают удаленно, например, у нас есть ребята в Сочи, Екатеринбурге, Москве или везде и сразу.
Какой социальный пакет получают сотрудники?
Ольга: Мы предоставляем все социальные гарантии в соответствии с ТК РФ. Зарплатный проект в «Альфа-банке», дополнительные выходные в случае плохого самочувствия, юридическая и финансовая помощь в сложных ситуациях. ДМС пока нет, но его подключение планируется в ближайшее время.
Какие бонусы, премии и компенсации предусмотрены в компании?
Ольга: Сегодня огромного списка бонусов и «плюшек» мы пока не можем предоставить, однако это связано не с отсутствием желания, а с нашей молодостью. Мы стремимся полностью покрывать потребности наших ребят — рабочие и развлекательные поездки в Москву, участие в профильных конференциях, премии самым крутым и всего по мелочи уже есть, но на этом мы точно не останавливаемся.
Какие есть перспективы для образования и личного развития у сотрудников?
Ольга: Помимо того, что в команде большое количество специалистов с интересным опытом, которые готовы и жаждут делиться знаниями, есть возможность вертикального развития: к примеру, технический писатель год назад уже сейчас может интегрироваться на продакт-менеджера, а помощник руководителя стать бизнес-аналитиком. И это все благодаря активному росту команды и сервиса.
Ну и само собой, этой вертикальное развитие подкрепляется предоставлением компанией возможности участия в конференциях, прохождения различных курсов, которые в совокупности позволят добрать требуемые компетенции и знания.
О найме
Во сколько этапов проходит найм и что на них ожидает соискателя?
Ольга: Первый этап — это беседа с эйчаром. Мы смотрим, насколько релевантен опыт, знакомим с компанией, проектом, задачами. Выясняем ожидания кандидата. Второй этап — техническое интервью, где проверяем теоретические и практические знания. Третий этап — тестовое задание (опционально).
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Ольга: В тестовых заданиях мы в первую очередь хотим оценить не погруженность в технологию, а подход и особенности мышления кандидатов. Однако тестовое требуется не всегда — бывают случаи, когда и без него понятно — это наш человек!
Как отличается подход к найму в зависимости от позиции и стека?
Ольга: Различия начинаются на самом входе — разработчиков, аналитиков или менеджеров мы подбираем на разных площадках и в разных комьюнити.
Далее, в зависимости от стека и позиции, может отличаться и количество проходимых этапов — собеседований, тестов. Как и отличается состав наших коллег, которых мы привлекаем к подбору подходящих кандидатов.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Ольга: «За орду!» — шутка :) На самом деле, списка стоп-фраз у меня нет, но из недавних собеседований — есть кандидаты, которые отвечают вопросом на вопрос, например:
— Каким проектом вы больше всего гордитесь?
— Вы мое резюме читали? Там есть ссылки.
Кого последнего вы уволили и почему?
Ольга: Не поверите, но увольнений у нас пока не было, даже тех, которые «по собственному желанию». Да и вообще, IT-команду покидает только один сотрудник из своих личных соображений, при этом оставаясь с нами на аутсорсинге.
Как происходит онбординг нового сотрудника?
Ольга: Онбординг ложится на плечи непосредственного руководителя при поддержке со стороны HR. Перед выходом нового сотрудника, помимо офисной и бумажной подготовки, внутри команды выбирается наставник, который помогает с адаптацией и погружением в продукт и инструменты. Сам процесс хронологически разделен на три этапа, по итогам которого собирается фидбэк и с новичка, и с наставника, и с руководителя, дабы уловить хоть малейший возможный дискомфорт и устранить его причину.
О команде
Какая методология разработки у вас используется и почему?
Игорь Фалин: Основополагающая методология у нас Agile. Если говорить именно про фреймворки, которые используем, то это смесь Kanban и Scrum, или Scrumban. Все задачи собираются и приоритезируются согласно дорожной карте — мы не бьем на четкие спринты и работаем в цикле постоянной выкладки: задача выполняется, мы ее реализуем, затем цикл повторяется. Это позволяет нам быстро обкатывать новый функционал, получать обратную связь и дорабатывать наш продукт. При этом мы не исключаем перехода на более «плавный ход» — к примеру, тем же спринтам — при масштабировании команды в несколько раз.
Каковы размеры и структуры команд?
Игорь: Наш IT-департамент разделен на три полноценные команды, плотно взаимодействующие между собой. Это Команда HRM, Команда Мобильного приложения и Команда Личного кабинета.
Каждая из команд укомплектована таким образом, чтобы имелась возможность обособленной разработки. На примере Личного кабинета расскажу про состав команды — продакт-менеджер, бизнес-аналитики, аналитики и data-инженеры, главный инженер, backend и frontend-разработчики, тестировщики, UX/UI, технический писатель и Devops-инженер. Последние трое принимают участие в разработке сразу нескольких продуктов.
При этом на верхнем уровне менеджеры IT-команд являются составными частями вертикальных бизнес-команд — вот такой живой организм получается, жизнь которого позволяет быть уверенными в том, что любая крупная фича или доработка не станет неприятным сюрпризом для других частей продукта.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Игорь: У нас пока нет четкой градации. Сейчас внутри команды мы делим ребят по компетенциям и уровню погружения в продукт. В зависимости от этого кто-то из разработчиков работает только над task-задачами, а другие — участвуют в ревью и декомпозиции задач, а порой и помогают с бизнес-логикой.
Кто чаще возглавляет команды — продуктовый специалист или технический?
Игорь: Тут, наверное, надо разграничить два варианта: команда целиком и feature-команды. В первом случае руководство скорее ложится на продуктовую часть — это Product-менеджер и техлид. Во втором, при разработке каких-то важных и больших штук, уже главные технические специалисты перехватывают бразды для ускорения процесса и решения продуктовой задачи. В общем и целом, у нас получается гармония продукта и техники!
Как часто люди меняют команды?
Игорь: Так как мы существуем сравнительно недавно, то команды не меняются. Те, кто являются менеджерами в продуктовой команде, могут друг друга подменять в чем-то. Это не узконаправленные специалисты и они могут покрывать пул задач, связанных как с бизнесом, так и с разработкой. Разработчик может заниматься базой знаний и управлять задачами, так как он уже погрузился в это. В технической команде специалисты могут переходить на другие направления, например, у нас есть разработчики, которые из HRM ушли в мобильную разработку. Также есть и те ребята, которые взяли на себя управленческие задачи, при этом зная, что если им придется это не по душе, то можно все откатить обратно.
Что важнее, софт-скиллы или хард-скиллы?
Игорь: Если смотреть с технической стороны, нам очень важны хард-скиллы, но, если человек не обладает хотя бы базовыми софт-скилами, то с таким человеком будет сложно. Мы в компании при подборе новых кадров ориентируемся на четыре софт-скилла:
Инициативность: сотрудник не только приходит сделать свою работу хорошо, он пытается улучшить продукт своими знаниями, предлагает решения проблем.
Ответственность: здесь каждый член команды готов нести ответственность за принятые им решения и понимает, что каждое из них отражается на продукте.
Работа на результат: готов совершенствовать свои знания и продукт.
Позиция Win-Win: Сотруднику интересно реализовывать проекты и достигать цели, а компания «не мешает» и всецело поощряет.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Игорь: Некоторые стандарты мы взяли из Scrum. Например, стендапы по 15 минут на направление: утром встречаются HRM-команда и команда мобильного приложения (состав незначительно отличается, так как пока что много людей задействовано на обоих проектах). Мы отмечаем моменты, по которым необходимо собрать Adhoc-встречи. Также есть ретро, на которых разбираем прошедший квартал или большой этап разработки и выявляем слабые места для их дальнейшей проработки. Ну и наконец, демо-дни — бизнес рассказывает про то, чего мы добились компанией и куда мы движемся.
В будущем, при расширении команды, набор митингов сохранится. Возможно, несколько поменяется формат, однако пока каждое наше очное общение оказывает только положительный эффект на разработку.
Как вы боретесь с выгоранием сотрудников?
Игорь: У нас сведены к минимуму факторы выгорания. У нас по большей части только осмысленные задачи и все понимают, зачем они их выполняют. Мы стараемся дать больше свободы в планировании своих задач. Конечно, мы ставим приоритеты, но, если, например, кому-то нужно взять день на отдых или по другим обстоятельствам, конечно, мы его предоставляем. Всегда есть возможность сдвинуть график. И мы не поддерживаем постоянное давление и постановку сложных задач, мы ко всему подходим с пониманием.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Яков Макаров: Для баз данных мы используем PostgreSQL, потому что это надежная система с достаточной производительностью. Бэкенд пишем на PHP, от команды к команде версия отличается — это либо 7.4, либо 8.0, в планах перейти на 8 версию. Мы используем везде фреймворк Symfony и нам сейчас как раз нужны люди с экспертизой в Symfony. Сервисы, требующие параллельного исполнения и которые должны очень быстро работать мы пишем на Go.
Веб интерфейс написан на Vue с TypeScript. Vue показал себя как удобное средство для разработки. Сознательно был выбран TypeScript, потому что строгая типизация позволяет отлавливать большое количество багов и значительно упрощает внесение правок. Для мобильной разработки у нас используется Flutter, его мы выбрали потому что одна команда разработчиков может сразу делать приложение, релизить его и под Android и под iOS.
Наши аналитики используют Python. Он также используется для подготовки данных.
Что вы можете рассказать об архитектуре проектов?
Игорь: Она постоянно меняется. Изначально это был MVP, построенный на Google-таблицах. Сейчас же мы используем облачную инфраструктуру, в частности, Яндекс.Облако, в которой развертываем проекты, состоящие из взаимодействующих между собой контейнеров. Подробно описать архитектуру без приведения графических материалов кажется нереальным, поэтому ограничусь таким кратким ответом.
Какая у вас принята политика код-ревью?
Игорь: Сейчас из-за небольшого количества разработчиков, у нас ревью проводят сами же разработчики. У нас есть условие, чтобы были Unit-тесты и правильно закоммитченные комментарии.
Сейчас код-ревью проводят несколько самых опытных разработчиков. При этом есть условие попадания кода на ревью: написанные Unit-тесты и правильно зафиксированные комментарии. Возможно в будущем подход будет меняться, но на данный момент придерживаемся принципа «просто = хорошо».
Как тестируется код?
Яков: На данный момент у нас пишутся Unit-тесты и происходит ручное тестирование. Юнит-тесты гоняются каждый раз при коммитах в репозитории, дальше тестировщик проверяет ветку с реализованной функциональностью и затем реализованная функциональность попадает в мастер, где уже в мастере, перед релизом происходит очередное ручное финальное тестирование. После этого функциональность попадает в продакшн и становится доступна пользователям. В этом направлении мы сейчас продолжаем развиваться. В планах у нас добавить автотесты с использованием Selenium.
Кроме этого, мы планируем учитывать покрытие кода тестами, чтобы тестировщики при ручном тестировании особое внимание обращали на тестирование функциональности, которое не покрыто автотестами. В ближайшее время мы также будем внедрять системы PHPUnit и Behat — это по сути фундамент, фреймворки, на базе которых мы будем развивать свои собственные решения.
Как устроен процесс документации и ведения базы знаний на проектах?
Николай Красильников: В документировании на проектах можно выделить два ключевых процесса: техническое описание продуктов и документация API. Техническое описание продуктов предназначено для сохранения всех знаний о продукте, что упрощает разработку, онбординг новых сотрудников и многие другие процессы. Обновление функционала, добавление новых, устранение багов и другие работы документируются параллельно с их выкаткой в production.
На этапе декомпозиции задачи и передачи ее в development заводится отдельный task на технического писателя, в рамках которого последний добавляет правки или создает новые страницы в документации. Инструмент документирования — Notion. Благодаря настроенным интеграциям между инструментами разработки, документация включает в себя автоматически обновляемые UI-киты и бизнес-процессы, связанные с функционалом, а также элементы кода и ссылки на трекер задач.
Документирование API происходит непосредственно разработчиком. Инструмент: Postman. Однако сейчас мы уже подключаем Swagger, поэтому через неделю-две мой ответ изменится кардинально :)
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Игорь: Так как коду у нас чуть больше года, то про это говорить еще рано.
Оценивайте своих работодателей на Хабр Карьере и делитесь мнением о них с теми, кто сейчас ищет работу в ИТ. Это анонимно.
