Где работать в ИТ в 2020: Modesco
Каждый год мы на Хабр Карьере (ходим в баню) выпускаем рейтинг ИТ-компаний по мнению их сотрудников — они оценивают всё, начиная с уровня зарплат, заканчивая ощущением, что компания делает мир лучше. Пока мы собираем данные для рейтинга 2020, почитайте о том, как все устроено в компании Modesco. В прошлогоднем рейтинге ребята показали отличный результат — 4,9 баллов из пяти.
Кстати, вы можете оценить свою компанию и поделиться мнением о ней с теми, кто сейчас ищет работу. Можно ругать, можно хвалить, главное — оценивать честно!
→ оценить компанию
В Modesco с нами поговорили: эйчар Марина Колядина, тимлид Андрей Харьковский и проджект-менеджер Никита Камышников. Они рассказали о том, чего ожидать, если вы захотите работать в их команде.
Рассказ получился объёмный, вот ссылки на разделы для удобного чтения:
О Modesco
Компания занимается развитием пяти собственных интернет-сервисов.
Telderi — площадка купли-продажи сайтов и доменов, а также групп Вконтакте, YouTube, Telegram и Дзен каналов, страниц в Instagram.
Text.ru — одна из крупнейших русскоязычных бирж копирайтинга и рерайтинга и бесплатный сервис по проверке уникальности текстов.
Unitpay — платежный агрегатор для малого и среднего бизнеса.
Socpublic — сервис микрозаданий.
Keys.so — инструмент аналитики конкурентов и подбора семантики.
По мнению сотрудников, самые лучшие качества в Modesco — возможность для профессионального роста и отличный менеджмент. Вот их подробная оценка в 2019 году:
Об условиях работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Марина (эйчар): Мы работаем по 7 часов эффективного времени в день. Время начала рабочего дня каждый выбирает для себя сам, но без крайностей: в диапазоне с 8.00 до 10.00 (хотя есть пара сотрудников, начинающих работу в 7 утра и уходящих домой около 15). Время фиксируется программно. Если есть важные дела и необходимость отлучиться на полдня — это не проблема, всегда можно компенсировать эти часы в другой день. Если хочется взять выходной среди рабочей недели, можно отработать лишние 7 часов в другие дни и, предупредив руководителя, отдохнуть. Жёстко фиксированный график только у специалистов поддержки, работающих в режиме 2/2.
В целом, наше отношение к переработкам негативное, все мы знаем, что они ведут к быстрому выгоранию, снижают продуктивность и ухудшают настроение сотрудников. В нашей практике были случаи, когда разработчики искали работу и приходили на собеседование именно из-за перенапряжения и работы сверх нормы, поощряемой прошлым руководством.
Андрей (тимлид): Чтобы избегать переработок, мы используем ряд правил и постоянно внедряем новые технологии. Например, у нас запрещены релизы в пятницу и за час до конца рабочего дня разработчика, который писал публикуемую функциональность. В PHPStorm у всех программистов подключены 2–3 плагина (зависит от проекта), которые помогают соблюдать принятые в компании стандарты разработки.
Одна из наших целей в данный момент — полноценный CI/CD, с деплоем, незаметным для пользователей. Но для этого ещё очень много всего нужно сделать. С недавнего времени мы стали менять нашу методологию разработки, внедряя всё больше элементов скрама.
Конечно, наши сервисы живые и сложные, мы часто добавляем много нового и полностью исключить работу вне графика не можем: атаки хакеров, внезапные скачки нагрузки, крупные ночные релизы. Ошибки и неверные решения тоже никто не отменял. Поэтому, если переработки случаются, они всегда оплачиваются. А если авария произошла ночью или в выходной день — в двойном размере.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Марина: Наши офисы очень разные. Например, воронежский оформлен в современном стиле, а волгоградский более уютный, с домашней атмосферой, настолько, что некоторые сотрудники ходят по офису в тапочках (как в Хабре — прим. ред.). Но различия не отменяют подход к максимальному комфорту сотрудников: кабинеты просторные, рассадка позволяет иметь личное пространство — никто не смотрит тебе в монитор, на стены можно повесить любимые постеры, есть возможность выбрать наиболее удобное кресло, у нас их несколько видов.
Конечно же, современный компьютер, достаточный чтобы разворачивать проекты, плюс второй монитор у разработчиков. Кухня со всем необходимым (кофемашина — must have). В офисе всегда можно перекусить, и это не только сладкое, но и творожки, сыры, овощи. А по четвергам традиционно радуем сотрудников бутербродами. Также в офисе есть чем заняться на перерывах: кикер, дартс, PlayStation.
Есть ли возможность удаленной работы?
Марина: Сейчас есть. После вынужденного карантина мы приняли решение пересмотреть наши взгляды на формирование команды (ранее принимали сотрудников исключительно в офис) и сделали возможным удаленную занятость для технических специалистов, оставив все же некоторые условия. Для новичков это поездка к нам в офис на испытательный срок, а также недельные командировки раз в квартал. Нам важно, чтобы сотрудник вживую познакомился с коллегами и на деле увидел наши корпоративные принципы, так сказать, впитал дух команды. Да и погружение в проект проходит гораздо быстрее, если работаешь бок о бок со старожилами.
Такие командировки мы полностью оплачиваем, и понимая, что испытательный срок может длиться до 3 месяцев, готовы оплатить дополнительно пару поездок домой, чтобы повидаться с родными.
Для «местных» сотрудников мы предложили режим «полуудалённой» работы — теперь можно работать из дома, но посещать офис хотя бы 5 дней в месяц. К слову, мы вышли с удаленной работы 7 сентября и пока такой возможностью никто не воспользовался — уж очень мы офисные:)
До какой должности может дорасти разработчик и какой уровень жизни он сможет себе позволить на этом месте?
Андрей: Для разработчиков у нас установлена классическая система грейдирования: Junior — Middle — Senior. Между грейдами есть аттестация в виде устного экзамена, а внутри грейда — вилки, дающие возможность расти в зарплате за счёт роста личной продуктивности. Есть и другая ветвь развития, параллельная грейду сеньора — развиваться как руководитель, тимлид.
Мы не ведём найм джуниоров. Но наши сотрудники на других технических должностях (например, вебмастера) имеют возможность перейти на позицию джуниор-разработчика. Для этого потребуется пройти испытательный срок на этой должности под присмотром опытного наставника и сдать аттестацию.
Что касается зарплат: мы ориентируемся на российский рынок и предлагаем такие же зарплаты, какие московские компании платят удалёнщикам. В результате, уровень жизни нашего разработчика выше среднего уровня жизни по Волгограду — он может себе позволить автомобиль C-класса, собственное жилье, отпуск за границей пару раз в год и комфортное воспитание двоих-троих детей (у нас есть пример в виде многодетного отца :)
Какой социальный пакет получают сотрудники?
Марина: Мы придерживаемся условий ТК, стараясь усовершенствовать некоторые пункты. Оформляем с первого дня работы — никаких неофициальных стажировок, оплачиваем 28 дней отпуска в год, покрывая 100% заработка за этот период и больничные.
Сейчас у нас нет ДМС, мы идем от обратного — предпочитаем поддерживать здоровый дух, доплачивая тем, кто занимается спортом. Но не отрицаем, что будем внедрять такой бонус в будущем и уже рассматривали варианты корпоративного медицинского страхования. Кроме того, в случае недомогания всегда можно пару дней поболеть дома без больничного листа — эти дни мы оплатим также, как и при его наличии.
Какие бонусы, премии и компенсации предусмотрены в компании?
Марина: Мы долго экспериментировали с мотивацией, пробовали и полностью окладную систему, и квартальные премии, основанные на прибыли проекта, но максимально комфортной оказалась текущая схема.
Для рядовых сотрудников премии составляют меньшую часть дохода (основная часть — окладная) и в зависимости от должности варьируются от 1 до 15 тыс. руб. У каждого есть своя вилка и при составлении ежемесячного отчета о работе сотрудник сам заявляет, на какую премию претендует. Чтобы получить максимальную для себя сумму, не достаточно просто хорошо выполнять свои функции, надо сделать что-то непривычное, получить какой-то весомый результат, придумать и реализовать какую-то крутую фичу. Конечно, есть разные сотрудники — кто-то склонен преумножать свои заслуги, кто-то наоборот слишком скромен, поэтому итоговый размер премии всегда обсуждается и утверждается с ПМом.
Если говорить про менеджеров, то они получают премию в зависимости от чистой прибыли проекта, которая выплачивается раз в 3 месяца.
Ряд бонусов предоставляется всем сотрудникам или отдельным категориям.
Всем компенсируем внешнее обучение в рамках должности: это могут быть курсы английского, профильная конференция или мастер-класс. Причем чем дольше работает сотрудник, тем больше становится выделяемая на обучение сумма.
Постоянно обновляем библиотеку по заявкам сотрудников.
Проводим корпоративы за счет компании: как ежемесячные посиделки в офисе, так и ежеквартальный выезд за его пределы (на турбазу, в кафе, в батутный парк). Поздравляем сотрудников с личными праздниками, новым годом и дарим подарки от компании. И, конечно же, стараемся удивлять и делать небольшие приятности на другие праздники, например, на день программиста или Хеллоуин.
Сотрудникам, работающим с клиентами, предоставляем сотовый телефон и оплачиваем связь. Мамочкам в декрете ежемесячно перечисляем денежный бонус.
Какие есть перспективы для образования и личного развития у сотрудников?
Марина: Мы обеими руками за то, чтобы наши ребята развивались, но тут, как говорится, бо́льшую роль играет желание сотрудников, мы лишь создаем условия для этого.
Помимо библиотеки и компенсации внешнего обучения, мы способствуем вертикальному росту (он возможен на большинстве наших должностей), а также можем предложить горизонтальное перемещение на другую должность или в другой проект.
Из последних кейсов — трансформация специалиста отдела поддержки пользователей одного проекта в менеджера по развитию другого. Сотрудница сама проявила интерес, предложила несколько идей, успешно их реализовала и получила желаемую должность и прибавку к зарплате.
О найме в Modesco
Во сколько этапов проходит найм и что на них ожидает соискателя?
Марина: Найм проходит всего в два этапа: собеседование с эйчаром и техническим руководителем и собеседование с руководителем холдинга. Если кандидат не против записать на видео первый этап, то второй скорее всего пройдёт заочно.
Андрей: На техническом собеседовании я задаю общетеоретические вопросы и разбираю интересные кейсы из практики кандидата. Цель разбора кейсов — понять, чем кандидат увлечён в рамках работы, в чём силён, какой реальный опыт имеет, как действует в конкретных ситуациях, как принимает решения и как оценивает их последствия. Иногда кандидаты очень немногословны, поэтому моя задача — разговорить собеседника, найти интересные ему темы. Эйчар же смотрит на то, насколько кандидат разделяет принципы работы в компании, оценивает его софт-скиллы и отвечает на все не технические вопросы кандидата.
Марина: Раньше на собеседовании присутствовал и ПМ, как непосредственный руководитель разработчика, но сейчас мы отказались от такой практики, дабы не смущать кандидатов толпой интервьюеров.
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Андрей: Тестовых заданий мы не даём. Раньше была такая практика, но пользы не принесла, и мы от неё отказались. Нам достаточно технического собеседования, которое порой может длиться до 1,5 часов. Плюс у кандидата есть испытательный срок, чтобы проявить себя.
Как отличается подход к найму в зависимости от позиции и стека?
Андрей: В зависимости от того, на какой уровень приходит сотрудник, более пристальное внимание на собеседовании уделяется разным скиллам. Если это начинающий специалист, то несомненно пристальнее смотрим на софт: обучаемость и системность мышления будут главными критериями. Если человек приходит на позицию мидла/сеньора или руководителя, то обязательно должны быть мощные хард-скиллы, ведь он должен быть авторитетом, человеком, который всегда подскажет. Поэтому бо́льшая часть вопросов будет направлена на выяснение степени экспертности.
По каждой должности и грейду у нас есть профили компетенций, в том числе профессиональные, соответственно, отличается и набор вопросов к соискателю. Кроме них, я готовлюсь к каждому собеседованию отдельно — изучаю заявленный опыт, примеры кода и фиксирую, о чем хочу узнать дополнительно.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Никита (проджект): «Чем занимается ваша компания?» — странно, когда человек приходит на собеседование, не узнав ничего о нас. Сразу понимаю, что ему не важно где и как работать, скорее всего интерес только в деньгах. Ещё есть фраза «Я и так всё знаю» — здорово, но очень сомнительно в нашем стремительно меняющемся мире. По всей вероятности, кандидат не сможет вписаться в нашу культуру поисков и тестирования новых решений, гипотез и технологий.
Андрей: Некоторые кандидаты заявляют, что знают ООП (SOLID, SCRUM, Git — подставьте любую модную аббревиатуру), но потом не могут ответь на вопрос «что такое инкапсуляция?» или «что значит single responsibility?» и т. п. Это сразу заставляет усомниться в достоверности всех предыдущих и последующих ответов.
Кого последнего вы уволили и почему?
Андрей: Последним мы уволили разработчика, причём случилось это спустя пару недель после найма. Причина — потеря доверия. Работал медленно, давал плохую обратную связь ПМу, а в результате выяснилось, что он использовал рабочее время не по назначению (банально смотрел мультики и ютуб на работе).
Как происходит онбординг нового сотрудника?
Марина: В первый рабочий день я встречаю новичка и знакомлю лично со всеми коллегами, показываю офис, рабочее место, рассказываю где можно пообедать и т. д.
Первую неделю рабочий день сотрудника начинается с выполнения мини-заданий, которые занимают в среднем около получаса и позволяют познакомиться со всеми используемыми программами, официальными и негласными правилами. Задания варьируются от «съешь печеньку» до «изучи такой-то документ».
Если говорить о тех. части, в первые дни работы тимлид проводит небольшой ликбез по техническим аспектам, а также прикрепляет новичку куратора (чаще всего это старший специалист на проекте или сам тимлид), который погружает сотрудника в проект и отвечает на все возникающие вопросы.
О команде
Какая методология разработки у вас используется и почему?
Андрей: Методология разработки у нас гибкая, сформированная из опыта работы нашей команды, приправленная, на наш взгляд, самыми удачными аспектами из многих популярных методологий. Причём, некоторые процессы для разных команд могут различаться: зависит от характера проекта и структуры команды.
С приходом самоизоляции мы сместились ближе к SCRUM: у нас есть каждодневные стендапы, недельные циклы разработки и двухнедельные циклы релизов (любая фича неделю разрабатывается и ещё неделю тестируется, чинится, дорабатывается, готовится к релизу). Если на разработку нужно больше недели мы делим задачу на этапы, либо прибегаем к «фичекату». Год разбит на кварталы, в каждом — свои квартальные задачи.
Мы считаем, что любая методология хороша, когда ты удачно адаптировал её под себя, поэтому не спешим реализовывать методологии строго в соответствии с учебником, а примеряем их на наш 17-летний опыт.
Каковы размеры и структуры команд?
Андрей: Поскольку я работаю в волгоградском офисе, расскажу про наши команды (в воронежском офисе один большой проект и структура более сложная). Любой из 4 проектов возглавляет менеджер проекта. За поддержку и сбор жалоб от клиентов отвечают несколько саппортов. 2–4 разработчика сопровождают проект. Один системный администратор и один тимлид работают на всех сервисах. Плюс, команда системных администраторов на аутсорсе поддерживают проекты в режиме 24/7.
Но у каждого проекта своя специфика, поэтому где-то помимо вышеперечисленных сотрудников есть вебмастер, где-то — менеджер по работе с клиентами, где-то маркетологи или трафик-менеджеры. В целом, каждый наш сервис обслуживают от 3 до 12 человек.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Андрей: У нас есть список компетенций: знаний, навыков, и ответственностей. Прежде чем перейти в новый грейд, нужно им соответствовать. Есть список тем, которые эти знания и навыки освещают. По этим темам проводятся и собеседования, и аттестации. Что касается ответственности, от всех разработчиков мы требуем качественной обратной связи: мидлы несут ответственность за себя и свои решения, сеньоры — за всю команду, особенно за джуниоров.
Кто чаще возглавляет команды: продуктовый специалист или технический?
Марина: Линейным руководителем команды разработчиков является менеджер проекта — продуктовый специалист. Хотя отмечу, что каждый наш ПМ имеет хороший технический бэкграунд — почти у всех техническое образование и опыт работы вебмастером, разработчиком и т. п. А вот функциональное руководство осуществляет тимлид. Впрочем, все знают, что конечное слово всегда за ПМом.
Как часто люди меняют команды?
Андрей: Перемещение сотрудников между проектами внутри холдинга происходит не часто, в среднем раз в год. У нас все очень динамично — проекты растут, иногда появляются новые. Вакансии есть всегда. В этом вопросе мы стараемся прислушиваться к желанием разработчиков. Если человек не стремится сменить проект, мы будем сохранять за ним рабочее место столько, сколько это позволяет бизнес (пять лет на одном проекте — есть и такие кейсы в нашем опыте). Не редко разработчики сами просят о переходе: появляется желание поработать с другим набором технологий или с другими специалистами, просто пощупать что-то новое.
Что важнее: софт-скиллы или хард-скиллы?
Никита: Важнее всего баланс. Какой бы мощный не был специалист, если он не может находить общий язык с коллегами по команде и коллективу в целом, дистанцируется и противопоставляет себя сложившейся корпоративной культуре, сработаться с ним будет невозможно. Даже крутому разработчику можем отказать из-за неприемлемых личных качеств. И наоборот: если человек — сама коммуникабельность и душа компании, но со своими непосредственными обязанностями не справляется (или не справится, если речь о кандидате), то нам не по пути.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Никита: Собрания с командой разработки в формате скрам-митинга (что сделано/что планируется сделать/есть ли какие-то затруднения) проходят ежедневно. Раз в неделю совещания имеют более расширенный формат и включают обсуждение пула задач на следующую неделю с оценкой значимости в рамках последовательности Фибоначчи от 1 до 13.
Марина: Раз в квартал проходит общее мероприятие холдинга, на котором ПМы и руководители направлений презентуют достижения и провалы прошедшего периода и делятся планами своего проекта/отдела на будущий. Последним всегда выступает руководитель холдинга и рассказывает о глобальных изменениях, затрагивающих всю компанию и новых планах развития.
Каждый раз мы с нетерпением ждём квартальной презентации: это интересно и весело, можно узнать много нового и важного о проектах, над которыми ты не работаешь. Такие собрания позволяют находиться в одном информационном поле и не терять связь с сотрудниками других офисов
Как вы боретесь с выгоранием сотрудников?
Андрей: Ищем причины (в основном, в личных беседах), у всех они разные:
устал и пора в отпуск;
надоели однотипные задачи, нужно сменить вектор работы, например, с аналитических на более механические, где действуешь больше на автомате или наоборот;
не хватает развития в технологиях, время сменить проект или внедрить на проект свежую технологию, о которой давно размышляли;
не хватает признания — значит требуется значимая задача, которая будет отдельно отмечена руководством;
не нашёл своё место в коллективе, не считает себя частью команды — на любом ближайшем корпоративе нужно показать сотруднику, что ему рады, его любят и ценят;
И так далее, причин много. Для каждой причины есть своё решение. Главное — вовремя поймать момент и не доводить человека до мыслей об увольнении.
О применяемых технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Андрей: Их очень много, целый зоопарк. Наши проекты очень разные по функционалу и все имеют продолжительную историю. Набор технологий складывался в каждом проекте независимо, в силу многих причин: задач, требований и навыков команды. Основа бэкенд-разработки — PHP и Symfony, но так же много кода на Yii. Есть и другие фреймворки и демоны на Node.js. Со стороны фронтенда проекты тоже разные: React, Vue.js, Angular, просто jQuery.
Что вы можете рассказать об архитектуре проектов?
Андрей: С архитектурой всё не менее разнообразно. Большинство проектов имеют многосерверную сервис-ориентированную архитектуру (SOA). Разные сервера отвечают за разный функционал внутри проектов. Также, внутри проекта могут сосуществовать несколько хранилищ. Базы данных: MariaDB, PostgreSQL, ClickHouse и MongoDB. Для кеширования: Memcahed и Redis. RabbitMQ — в качестве брокера сообщений. Для обмена данными между серверами, сервисами и клиентами, кроме HTTP, используются WebSocket-соединения, XML-RPC и Unix-сокеты. Мы стараемся держать баланс: исключать лишние инструменты, но не загонять себя в строгие рамки единой технологии. Разные инструменты заточены под разные задачи, мы это понимаем и активно пользуемся.
Какая у вас принята политика код-ревью?
Андрей: Код-ревью — обязательный этап, даже если в коммите изменилась одна строка. Разработчики проверяют пулл-реквесты друг друга перед слиянием функциональной ветки в develop. Круговая порука внутри проекта: ты проверяешь код одного разработчика, другой разработчик проверяет тебя. При этом, уровень разработчика не учитывается: джун может проверять сеньора.
Ревью позволяет нам избегать глупых ошибок и опечаток, связанных с проблемой замыливания взора разработчика. Кроме того, помогает поддерживать общий стиль разработки, дополнительно защищает от нарушения стандартов. Ревью — это ещё и дополнительный канал обмена опытом, улучшает знание проекта разработчиком, косвенно снижает знаменитый bus factor.
Мы не используем код-ревью для отслеживания качества работы, но я могу участвовать в ревью, чтобы оценить навыки специалиста на испытательном сроке.
Как тестируется код?
Андрей: Тестирование кода у нас, как асфальт в Волгограде — местами и немного :) Для регрессионного тестирования API используем Postman. Для нагрузочного — JMeter. Немного кода покрыто PHPUnit. К сожалению, очень много легаси, который сложно и нерентабельно полностью покрыть Unit-тестами. Тестирование новых функциональностей проводим комплексно: сначала тестируют сами разработчики, потом ПМ или команда тех.поддержки. Сейчас активно ищем специалиста на должность QA-инженера для покрытия всего ключевого функционала автотестами.
Как устроен процесс документации и ведения базы знаний на проектах?
Андрей: В первую очередь, мы подробно комментируем свой и чужой код. Кроме того, важную техническую и бизнесовую логику работы сервисов разработчики и ПМы вносят в Confluence. Серверную документацию ведёт команда системных администраторов. Отдельная документация активно поддерживается для сотрудников тех.поддержки пользователей.
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Андрей: Из предыдущих ответов можно заметить, что мы далеки от лучших современных практик разработки. Такова специфика бизнеса: Modesco покупает проекты и развивает их. Естественно, проекты в момент покупки уже имеют сложившуюся архитектуру, стек технологий и много кода. В таком случае, заменить всё плохое и старое на всё хорошее и современное — титаническая задача.
Собственно, легаси-кода много. Немного рефакторинга присутствует почти в каждой задаче. Есть негласное правило: если на рефакторинг требуется потратить плюс один день — можно смело включать его в задачу, если больше дня — под изменения создаётся отдельная задача и выделяется время. Из двух-трёх разработчиков на проекте, одновременно только один решает задачу чистого рефакторинга (остальные работают над багами и функциональностями).
Такое количество legacy пугает многих разработчиков. Зато это даёт нам разнообразный, сильный и интересный опыт разработки. Благодаря этому опыту, в сотрудниках отдела разработки мы уверены, как в крутых специалистах, способных на любые изменения и свершения.
Мы всегда предлагаем смотреть на устаревший или плохой код с двумя установками/
Понять и простить. Не всегда знаешь, какие внешние факторы заставили предыдущего разработчика принять конкретное решение, поэтому не имеешь право его осуждать. Но понимание этих факторов поможет лучше понять всю систему.
На очевидно плохом коде проще всего проявить себя: что бы ты ни написал — код становится лучше.
Оценивайте своих работодателей на Хабр Карьере, а если понравилась компания Modesco и хочется узнать о ней еще что-то — задавайте вопросы в комментах, мы позовем кого-нибудь из ребят отвечать.
→ оценить работодателя
