Каждый год мы на Хабр Карьере (ходим в баню) выпускаем рейтинг ИТ-компаний по мнению их сотрудников — они оценивают всё, начиная с уровня зарплат, заканчивая ощущением, что компания делает мир лучше. Пока мы собираем данные для рейтинга 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 и хочется узнать о ней еще что-то — задавайте вопросы в комментах, мы позовем кого-нибудь из ребят отвечать.
ссылка на оригинал статьи https://habr.com/ru/company/habr_career/blog/521590/
Добавить комментарий