Мы затеяли рубрику «Где работать в ИТ», чтобы рассказывать вам о том, как устроена внутренняя кухня крутых IT-компаний: как они нанимают новых сотрудников, где и на чём работают, чем кормят на обед, кто ревьюит код. Герой сегодняшнего выпуска — компания FunBox. Ребята имеют все шансы попасть в наш рейтинг лучших ИТ-работодателей в этом году, их оценка на Хабр Карьере сейчас — 4,5 баллов из пяти. Как работается в компании нам подробно рассказал Сергей Аверьянов, техдир FunBox.
На Хабр Карьере, кстати, вы можете анонимно оценить своего работодателя и ваше мнение поможет тем, кто ищет работу. Можно ругать, можно хвалить, главное — оценивать честно!
→ оценить работодателя
Навигация по статье:
Немного о FunBox
Про условия работы
Про найм в FunBox
О команде
О технологиях
Немного о FunBox
Компания разрабатывает продукты для мобильных операторов: интерактивные и финансовые сервисы, геосервисы, A2P-платформы и многое другое.
По мнению сотрудников, самые лучшие качества в FunBox — комфортные условия работы, отличные отношения с коллегами и социальный пакет. Смотрите сами, это оценка компании в 2020 году.
Про условия работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Наша компания существует уже более 10 лет и за это время мы поняли, что одна из основных составляющих успеха — рабочий процесс, который организован разумно и понятно. Мы руководствуемся принципом ритмичной, стабильной работы над задачами в официально отведенное для этого время.
С каждым разработчиком мы обговариваем удобный режим работы, которого стараемся придерживаться. Так как работа над задачами организована через Jira и чаще всего не требует постоянного интерактивного взаимодействия, разница во времени и часовых поясах не вызывает затруднений. Нескольких часов общего рабочего времени у разных членов команды достаточно, чтобы обсудить всё, что нужно.
Переработки мы рассматриваем как ответ на что-то экстраординарное: аварию или внезапно и неподконтрольно изменившиеся внешние обстоятельства, а в целом относимся к ним негативно. Мы понимаем, что частые переработки снижают работоспособность и бесполезны: то, что сделано в выходные и по ночам, компенсируется худшим темпом работы после, а от постоянных сверхусилий разработчики выгорают и увольняются. Те единичные переработки, которые все же случаются, мы учитываем и оплачиваем в двойном размере. В этом мы следуем ТК РФ.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
У нас несколько офисов: в Ульяновске, Казани и Москве. Мы стараемся сделать рабочее пространство максимально комфортным — с удобной рассадкой, переговорками, зонами отдыха, налаженной вентиляцией и продуманным освещением. Наше главное правило — комфорт офиса определяется минимумом из комфортов его частей. Можно организовать классную зону отдыха, но забывать следить за мылом в диспенсерах и салфетками на кухне. Про красоту все забудут, а от мыла будут постоянно молча расстраиваться.
Рабочее пространство мы обустраиваем поэтапно: от базовых потребностей к более сложным. Для начала:
Тепло — комфортная температура и климат-контроль;
Свет — нормальная освещенность, качественные источники, своевременная замена ламп;
Воздух — контроль CO2, приточка, проветривание;
Вода — идеально чистые санузлы, кухня и наличие расходников 24/7;
Еда — напитки/снэки/сладости, которые есть всегда.
Затем мы заботимся о комфорте рабочего места. Это удобная рассадка, не слишком большие кабинеты, личное пространство, отсутствие шума и внешних раздражителей, переговорки для обсуждений и созвонов. А уже в финале думаем про развлечения, дизайнерское оформление и нестандартные вещи. К тому же некоторые развлечения в офисе работают больше в минус: настольный хоккей или велотренажер будут популярны от силы неделю, а потом станут подставкой для чая и вешалкой, причем игры в настольный хоккей будут только раздражать тех, кто в него не играет.
Наведение и поддержание порядка — отдельная функция отдельного человека, который заботится об офисе и собирает пожелания коллег. Благодаря его работе проблемы быстро устраняются и больше не повторяются.
Реальность 2020 года заставила нас внести коррективы в работу офисов. Весной мы перевели всех на удаленный режим работы (об этом была статья в нашем блоге), а в начале осени сделали посещение офиса свободным, по желанию, и усилили санитарные меры.
Есть ли возможность удалённой работы?
Практически по любой из наших технических вакансий возможна удаленная работа с официальным трудоустройством. Удаленно не получится работать, если есть очевидная привязка к территории, — это должности офис-менеджера, инженера для работы в дата-центрах и им подобные. Наши процессы ориентированы на сотрудников и заточены на асинхронное взаимодействие, не требующее быть постоянно на связи. Большая часть команды — разработчики из разных уголков России от Калининграда до Южно-Сахалинска.
Какой социальный пакет получают сотрудники?
Наш соцпакет включает:
ДМС;
Программу покупки компьютерной техники — компания оплатит половину стоимости;
Курсы иностранных языков в офисах или удаленно (сейчас — только удаленно);
Оплату профессиональной литературы, курсов и участия в конференциях.
Какие бонусы, премии и компенсации предусмотрены в компании?
Мы считаем, что явное всегда лучше неявного: правильнее платить рыночную зарплату, чем пытаться экономить и бороться с текучкой компенсациями и соцпакетом. Наша система оплаты труда проста, понятна и предсказуема. Например, в целом мы против переработок, но, если они случаются, мы обязательно оплачиваем их в двойном размере. Важные события в жизни коллег — день рождения, свадьбу, рождение ребенка — мы отмечаем сувенирами.
Какие есть перспективы для образования и личного развития у сотрудников?
За годы работы мы научились работать с коллегами разного уровня, как с начинающими, так и с опытными. По многим нашим вакансиям мы готовы брать новичков без опыта коммерческой разработки или специалистов с родственным нашему стеком разработки. Мы готовы в процессе работы обучить всему необходимому, познакомить с нашими инструментами и правилами. Многие коллеги, которые когда-то пришли к нам неопытными младшими разработчиками, теперь руководят большими командами и разрабатывают сложные продукты.
Про найм в FunBox
Во сколько этапов проходит найм и что на них ожидает соискателя?
Мы считаем, что процесс найма должен быть гуманным, без лишних усложнений. Тем, кто хочет у нас работать, необходимо выполнить тестовое задание и пройти небольшое техническое собеседование.
Сложные HR-процедуры с пятью раундами собеседования, бесконечные анкеты, безосновательное собеседование со службой безопасности, полиграф и так далее в компании, которая не является гигантом вроде Майкрософта, Гугла или Яндекса, нам кажутся странными. Кандидата, особенно начинающего, можно оценить по нескольким десяткам минут собеседования и по тестовому заданию.
Кстати, сейчас мы ищем Erlang/Elixir-разработчика и будем рады откликам!
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Для нас тестовое задание — это хороший способ оценить уровень кандидата и его подход к работе. Кандидатам мы предлагаем несколько вопросов и задания.
Часто случаются дискуссии о том, стоит ли делать тестовое бесплатно, потому что кандидат тратит своё время, которое стоит денег. Мы считаем, что тестовое — это обоюдное движение навстречу друг другу. С одной стороны, работодатель тратит время на общение с кандидатом и проверку задания, с другой стороны, кандидат тратит время на выполнение тестового. Если мы говорим про кандидата с репутацией, с многолетним стажем, про которого все знают, такому человеку тестовое, очевидно, не нужно, так как за него говорит его репутация, и обычно достаточно небольшой беседы, так как к нему всегда выстраивается очередь из работодателей. Если же речь идёт о начинающем специалисте, то сделать тестовое в его же интересах, потому что среди начинающих работодатель выберет того, кто лучше себя показал.
Мы стараемся предлагать разумные по сложности и очевидно некоммерческие тестовые задания, чтобы у кандидата не возникало подозрений, что результаты его труда могут использоваться позже без его согласия.
Как отличается подход к найму в зависимости от позиции и стека?
Если мы приглашаем на работу новичка совсем без опыта работы или, наоборот, специалиста с солидной репутацией, этап тестового задания можно пропустить. Для некоторых вакансий, например для системных администраторов, их нет вообще. Сами задания различаются сущностно в зависимости от стека, но процедура найма при этом одинакова. Знание основ, ответственный подход и здоровый перфекционизм для нас важнее знания конкретных технологий.
Кого последнего вы уволили и почему?
К сожалению, были вынуждены расстаться с начинающим Python-разработчиком, не прошедшим испытательный срок. У нас такое случается, хоть и редко. Любое увольнение мы стараемся проводить не одномоментно: с теми, кто, как нам кажется, не справляется с работой, мы несколько раз беседуем, указываем на недочеты, даем советы по их исправлению и спрашиваем, чем можем помочь. Если это не помогает, то с сотрудником мы расстаемся, стараясь сделать это на дружеской ноте.
Как происходит онбординг нового сотрудника?
Каждого новичка мы прикрепляем к команде, в которой ему предстоит работать. Помимо руководителя, который сопровождает новичка в первые дни работы, у нового сотрудника есть доступ к базе знаний с информацией не только о проектах и коде, но и об общих регламентах и инструкциях. Например, в раздел HR мы добавляем ответы на самые важные организационные вопросы: что делать в первый рабочий день, как оформить отпуск, поехать в командировку, получить справки и другие. Это экономит время HR-отдела и делает процессы прозрачными.
О команде
Какая методология разработки у вас используется и почему?
Мы используем адаптированную под свои потребности каскадную модель разработки. Как правило, одна команда разработки занимается несколькими тематически связанными проектами и продуктами, поэтому мы ведем их в виде параллельных активностей. При этом у каждого участника процесса есть приоритезированный список задач, позволяющий в каждый момент времени делать что-то одно.
Над одной продуктовой задачей могут одновременно работать разные люди: кто-то делает верстку, кто-то реализует API, кто-то готовит документацию. Поэтому мы стараемся избегать понятия «статус продуктовой задачи» и не углубляемся в микроменеджмент, предпочитая говорить о степени готовности задачи и планируемых сроках завершения.
Каковы размеры и структуры команд?
Обычно команда разработки включает в себя от 2 до 7 человек. Туда входят специалисты тех технологий и стеков, которые представлены в проекте.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Помимо таких очевидных вещей, как технический уровень, мы обращаем внимание на способность к самостоятельной работе над задачами, способность к продуктивным контактам со смежными командами и на навыки общения.
Кто чаще возглавляет команды — продуктовый специалист или технический?
В любом проекте у нас есть две независимые ветви власти: управленческая и техническая. Управленческая в лице менеджеров и аналитиков отвечает за первоначальные требования, контакты с заказчиком и презентацию ему результатов работы. Команды разработки занимаются технической стороной и реализацией бизнес-функциональности.
Наличие «интерфейса» общения между частями команды и регламенты работы над задачами позволяют с одной стороны избежать монополии и однобокого ведения проекта, а с другой — хаоса и непредсказуемости.
Как часто люди меняют команды?
Довольно редко. Мы стараемся распределять проекты по командам так, чтобы разработчики не стали заложниками одной технологии, а сами команды не превратились в конвейер для однотипных задач.
Что важнее, софт-скиллы или хард-скиллы?
Распространено заблуждение, что инженеры и разработчики замкнуты и нелюдимы. Многие говорят: «Я не люблю общаться, я интроверт, поэтому я стану разработчиком». На начальном этапе это возможно, но хорошего разработчика в том числе отличает то, что он умеет общаться. Чем сложнее работа, чем больше зона ответственности, чем выше квалификация и зарплата, тем большую роль играет общение. Если хочется изолироваться в бункере и просто делать задачи, такую работу найти, скорее всего, можно, но мало где нужен гений, который в одиночку, без контакта с командой будет что-то изобретать. Навык общения важен и над ним нужно работать.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
С самого начала мы осознанно отказались от практик, которые требуют частых и обязательных собраний, так как они с течением времени имеют тенденцию становиться бесполезными и приводить всех в уныние. Все продуктовые активности мы ведем в виде задач в Jira, а документацию храним в базе знаний. Это помогает свести количество собраний к разумному минимуму. Когда собрание необходимо, мы его проводим, предварительно определившись с повесткой. По завершении все участники получают резюме митинга, чтобы избежать разного понимания достигнутых договоренностей.
Как вы боретесь с выгоранием сотрудников?
Мы стараемся разнообразить задачи внутри команды. Сотрудники, которые показывают хорошие результаты, становятся со временем руководителями команд или структурных подразделений, получая новый, более высокоуровневый круг задач. Чтобы команды не варились в собственном соку, для обмена опытом мы проводим регулярные митапы и серии докладов, которые выкладываем на нашем ютуб-канале.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Elixir, Erlang, Ruby/Ruby on Rails, Python/ Django, Kotlin, JS/React, Swift, Java, Go.
Какая у вас принята политика код-ревью?
Мы считаем код-ревью важной частью работы над проектом. Помимо очевидного повышения качества кода, кросс-ревью задач внутри команды помогает разработчикам лучше понять проект, набраться опыта и увидеть хорошие паттерны разработки.
Как тестируется код?
Весь созданный код должен быть покрыт тестами, в том числе и интеграционными. Для автоматизации тестирования мы пользуемся системами CI.
Как устроен процесс документации и ведения базы знаний на проектах?
Чтобы избежать ситуации, когда есть задачи и нет документации, мы договорились хранить в нашей вики все результаты обсуждений, обмена техзаданиями с заказчиком и все спецификации на программные интерфейсы. Внутри команды у нас действует договоренность о том, что после завершения работы над задачей должна остаться проектная документация, которая описывает бизнес-функциональность. Все важное должно записываться так, чтобы было понятно каждому коллеге.
Мы подготовили шаблон для создания нового проекта, который содержит стандартные разделы. Каждый раз менеджер начинает проект не с пустого листа и пустой вики, а с уже проверенной на практике древовидной структуры с основными разделами. Плюс заполняется паспорт проекта, в котором указываются сводная информация и основные параметры: участники проекта, ссылки на ресурсы дизайна, фронтенда и бэкенда.
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Мы считаем рефакторинг частью рабочего процесса. Нормально, что для выполнения определенной задачи нужно не только создать что-то новое, но и обновить старое, приведя его к поддерживаемому и понятному виду. Если считать рефакторинг досадной помехой с неочевидной пользой, любой проект рано или поздно станет невозможно развивать. При этом мы стараемся избегать и другой крайности: затевать рефакторинг ради рефакторинга, когда он не порожден никакой бизнес-задачей.
Оценивайте своих работодателей на Хабр Карьере, а в комментах к статье предлагайте компании, которые хотели бы увидеть в следующих выпусках нашей рубрики.
→ оценить работодателя
