На IT-рынке есть тысячи компаний с разным уровнем инженерной культуры и подходом к работе с программистами. При выходе на работу в новую компанию можно попасть не в классную команду, которая развивает и любит своих разработчиков, а в место с низкой инженерной культурой и токсичной атмосферой. Поэтому мы подробно рассказываем, как устроена работа программистов у наших компаний-партнеров, чем они занимаются, как прокачивают свои навыки, какие задачи решают и где отдыхают — чтобы вы точно понимали, куда стоит устраиваться на работу.
- История и структура компании
- Как устроена работа над проектами
- Как устроена разработка: технологии и инженерные практики
- Организация процесса и стандарты
- Тестирование и дедлайны
- Trampoline-митапы и публичная активность
- Кого мы нанимаем и как
- Условия, компенсации, бонусы
История и структура компании
История JetRockets начинается в 2010 году, когда будущие основатели — Игорь Александров и Алексей Солилин, работали вместе как фрилансеры. Позже к ним присоединилась Наташа Каминская. В конце 2012 года мы зарегистрировали домен jetrockets.ru и наняли первого сотрудника Юлию Егорову, которая работает в компании и сейчас.
На сегодняшний день в компании работает 55 человек. При этом у нас никогда не было цели строить корпорацию с организационной иерархией, отделами, руководителями отделов и начальниками начальников — до сих пор мы общаемся легко и на равных.
Как устроена работа над проектами
Мы выделяем автономные команды по проектам, каждая из которых работает независимо от других разработчиков и направлений. В таких командах смешиваются специалисты разного профиля — они полностью отвечают за систему, которую сами и разрабатывают: от проектирования до обслуживания и эксплуатации
При этом каждая команда сама выбирает методологии и формирует весь процессы работы. Единственный критерий и условие — максимальная выгода для проекта.
Так выглядит традиционный для JetRockets состав команды для проекта:
- Проджект-менеджер
- Тимлид
- Техлид
- 1-3 бэкенд-разработчика
- 1-3 фронтенд-разработчика
- Тестировщик.
Если команде не хватает компетенций, она инициирует запрос к руководству компании, например, о необходимости усиления команды еще одним специалистом. Все команды общаются между собой и перенимают опыт друг у друга — каждый сотрудник понимает, какое место его команда занимает в организации, как цели команд связаны друг с другом, чем занимаются его коллеги. Таким образом, мы остаемся в рамках небольших «организаций», но внутри одной компании.
Мы не навязываем людям правила и процессы, но взамен требуем самостоятельно отвечать за принятие решений. Наши сотрудники могут работать там, где считают нужным: дома, в кафе, в такси, хоть в аэропорту. Но есть и возможность работать в одном из трех наших офисов: основной центр разработки находится в Твери, также есть небольшой офис в Ростове-на-Дону и в Нью-Йорке.
Как устроена разработка: технологии и инженерные практики
Наша цель — помочь клиентам достичь лучших результатов, и разработка софта — всего лишь один из инструментов. Бывают разные кейсы, но почти всегда у нас в приоритете скорость поставки результатов нашей работы для клиента. Поэтому мы не стесняемся использовать самые простые и «скучные» решения. Здесь нам очень важно пояснить, что «скучное» ≠ «плохое» — просто мы за прагматичный подход.
Мы не выбираем интересную технологию только для того, чтобы сделать работу более увлекательной, или потому что ее все обсуждают. Используем в основном устоявшиеся технологии и подходы, такие как:
- Ruby, Ruby on Rails
- PostgreSQL, Redis
- React/Redux
- GraphQL
- CI/CD.
Мы стараемся выбирать хорошо поддерживаемые инструменты и языки, но у нас нет правила, согласно которому все должны использовать только эти технологии. Мы выбираем инструмент исходя из задачи. Например, когда клиенту нужно было разработать Embedded Widget, мы взяли Svelte и остались очень довольны.
Организация процесса и стандарты
Мы всегда изучаем бизнес-процессы заказчика, цели и задачи проекта, пользовательские роли и сценарии, требования к безопасности. При этом никогда не пишем подробных технических заданий, потому что наш опыт показывает — это не работает и все будет сильно меняться в процессе работы.
У нас нет единого текстового редактора или IDE — каждый выбирает сам, где ему комфортней писать код. Есть сотрудники, которые используют VIM, VsCode, RubyMine. Но общий стиль кода для нас — маст-хэв, поэтому на всех проектах настроены автоматические линтеры, также во внутренней Wiki есть отдельная папка со стайл-гайдами для основного стека, чтобы можно было посмотреть плохие и хорошие примеры. В корпоративном Slack есть канал #study, куда мы часто пишем или инициируем общие созвоны, чтобы обсудить что-нибудь техническое.
Наша разработка почти всегда начинается с проектирования автоматизации. DevOps-инженер настраивает процессы непрерывной интеграции и доставки, проектирует инфраструктуру, которая соответствует целям проекта и обеспечивает гибкость и масштабируемость.
Всегда есть как минимум три среды:
- Development
- Staging
- Production.
Есть проекты, где сред больше, например, добавляется Integration.
То же самое касается процессов, Scrum, Kanban, v-model или lean — все зависит от проекта и выбора команды. Хоть мы и предпочитаем частые небольшие релизы, но бывает по-разному.
Тестирование и дедлайны
Мы не диджитал-агентство, поэтому не гонимся за дедлайнами, но все равно — стараемся исполнять обещания. Если оценили проект плохо, нужно максимально быстро это понять и вместе с клиентом принять решение, как быть со сроками.
Использовать Test-driven development (TDD) или нет — опять же выбор каждого, но при код-ревью, если нет тестов, вас практически всегда попросят их написать. Код-ревью проводят все — это один из способов передачи знаний и обмена опытом.
Мы заботимся о качестве финального продукта и репутации наших клиентов, поэтому уделяем особое внимание тестированию. Каждую команду сопровождают QA-специалист, это помогает обеспечить нормальный процесс разработки. Тестировщики участвуют не только в финальной стадии разработки фичи — зачастую они лучше всех знают, в каких местах есть сложности в проекте, поэтому стараются максимально рано включиться в процесс, например, на этапе оценки, чтобы иметь возможность предвидеть узкие места.
У нас нет дизайнеров в штате, обычно клиенты приходят с готовым дизайном или своим дизайнером, который помогает нам прорабатывать макеты страниц системы и осуществляет надзор при разработке.
Trampoline-митапы и публичная активность
Мы точно не самая публичная компания на рынке, но по мере возможности стараемся заниматься разными вещами в этом направлении.
Несколько раз мы были спикерами на Ruby Russia — главной российской конференции по Ruby, принимали участие в нескольких подкастах, например, были у Самата в Запуск завтра, а Игорь Александров (СТО JetRockets) читает курс «Программная инженерия» в Тверском Государственном Университете на факультете ПМиК (прикладная математика и кибернетика).
Одна из самых интересных наших инициатив – Trampoline-митапы: ежемесячные встречи, на которых выступают практикующие разработчики. Мы собираемся и обмениваемся опытом каждый последний четверг месяца. У митапов нет коммерческой составляющей. Никаких входных билетов для участников и никаких гонораров для спикеров. Мы хотим проводить мероприятия в регионах, чтобы у всех был равный доступ к качественной информации и крутой экспертизе.
Мы также поддерживаем разные локальные тверские сообщества. Долгое время центр современной культуры «Рельсы» проводил свои мероприятия у нас в офисе, пока они не открыли свое прекрасное пространство в центре города, также у нас отличная коллаборация с лекторием «Живое слово» — они помогают нам в организационных моментах Trampoline-митапов.
Кого мы нанимаем и как
Мы всегда рады как опытному разработчику, так и талантливому новичку, который хочет расти в команде с опытными наставниками.
Скорее всего вы подходите нам, если демонстрируете проактивный подход к работе: самостоятельно организовываете работу, находите нужную информацию, предлагаете пути решения возникающих проблем.
Читайте также: Это снова я, резиновая уточка: что такое метод Фейнмана и почему с его помощью так просто изучать программирование
Процесс найма состоит из трёх этапов:
Анкета с хорошим, но кратким рассказом о себе. Мы просим кандидата рассказать об опыте, достижениях, пет-проекте (если он есть), просим привести примеры хорошего Open Source кода, на который он равняется, и объяснить — почему. Можно ознакомиться подробней и откликнуться, все анкеты находятся в общем доступе:
- Бэкенд-разработка
- Фронтенд-разработка
- PM
- Тестирование.
Если нам нравится, как кандидат представил себя, то приглашаем его на собеседование по Zoom с CTO и членами команды. Оно проходит в формате знакомства, где мы рассказываем подробнее о JetRockets и даем возможность задать интересующие вопросы. Конечно, есть часть, где мы говорим о технической составляющей, спрашиваем про хобби, интересы и увлечения кандидата.
Если останутся сомнения, то пришлем задание для самостоятельной работы часа на четыре. Мы дадим обратную связь, и, если задание сделано хорошо, возможность сделать работу над ошибками.
Условия, компенсации, бонусы
Мы гордимся тем, что обеспечиваем полную прозрачность. Это важная часть нашей культуры. На всех уровнях и во всех аспектах работы необходимо говорить правду. Например, нельзя скрывать допущенную на этапе проектирования или разработки ошибку — это может потянуть за собой трудности в дальнейшей работе и репутационные риски. Ошибку нужно описать, спокойно обсудить и исправить — даже если это будет стоить для компании дополнительных часов.
JetRockets — это компания, поэтому мы никогда не нанимаем сотрудников на проект, а трудоустраиваем официально в компанию с белой заработной платой. Мы гордимся тем, что еще не было ни одного увольнения из-за того, что какой-то проект закрылся.
Мы компенсируем сотрудникам 50% от стоимости образовательных курсов, например, на английский язык, на курсы Хекслета, покупку книг, посещение конференций и других профильных мероприятий.
Ежегодно мы выделяем бюджет на общий бонус. Берем какой-то процент от заработанного компанией за календарный год и распределяем эту сумму между всеми сотрудниками. Размер бонуса зависит не от должности, а от проработанного времени в компании.
Мы считаем, что нет хороших или плохих компаний — ну или почти нет. Просто разным людям подходят разного типа компании. Не стоит идти работать к нам, если вы:
- Хотите иметь четкие регламенты, описанные процессы, иметь прозрачную систему KPI, грейдов. Лучше выберите большую корпорацию, вам будет там комфортней.
- Хотите участвовать и побеждать в разных рейтингах и конкурсах.
- Пишете код и считаете, что бизнес ничего не понимает, а главное — это ваш хороший код.
- Мечтаете делать красивые и при этом технически не очень сложные лендинги.
- Не умеете самостоятельно организовывать работу.
Каждый, кто начинает свой путь в IT, задает вопрос: «Что мне стоит учить?». Мы в JetRockets уверены только в одном — учите английский, он точно пригодится.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
