Привет, Хабр! На связи DevRel-команда inDrive. Мы прошли путь от стартапа из Якутии до компании с продуктом, которым пользуются в 47 странах мира. В процессе мы поняли важность culture fit — насколько хорошо вписывается разработчик в инженерную культуру компании. Мы представили её в виде пирамиды по аналогии с пирамидой Маслоу.
Уровни пирамиды разделены в соответствии с потребностями инженера на работе и проиллюстрированы примерами из нашего опыта. В основе пирамиды — комфортное рабочее окружение, на вершине — самоактуализация на конференциях.
1-й уровень. Комфорт и безопасность
![«Хочу ли я тут работать?» «Хочу ли я тут работать?»](https://habrastorage.org/getpro/habr/upload_files/fc1/af5/565/fc1af55651786c393409097190a77afc.png)
Как и у Маслоу, в основании пирамиды самые базовые потребности — комфорт и безопасность. Инженер оценивает компанию и решает, подходит ли она ему.
Контакт на собеседовании. Здесь происходит первый контакт инженера с культурой компании. О ней можно судить уже по характеру собеседования: по теплоте в общении с соискателем, пониманию его уровня, адекватности вопросов. Если на этом этапе инженера что-то оттолкнёт, дальнейшей его истории в компании не случится.
Мы поработали над подходом к собеседованиям, чтобы инженеры не испытывали стресс. Например, у нас нет практики закидывать соискателей нелепыми вопросами — например, «Кем ты видишь себя через пять лет?» и ему подобными. Уделяем внимание характеру общения, стараемся, чтобы беседа была на равных. Как между живыми людьми, а не между сотрудником и корпорацией.
Условия труда. От компании зависит, получится ли работать в привычных условиях или придётся подстраиваться, мириться с неудобствами. И сможет ли она помочь инженеру влиться в новую команду.
Простая ситуация: инженер удалёнку не хочет, а офис компании — в другом городе или стране. Уже на этом этапе разработчик видит, что они с компанией не совпадают: нужно или отказаться от вакансии, или переезжать. Релокация — это тяжело и тревожно. Но в компании могут быть инструменты, которые снимут с инженера часть проблем, — например, релокационные пакеты, помощь с переездом, страховкой.
У нас есть и офисы — на Кипре и в Казахстане, — и удалёнка. Тем, кто релоцируется, помогаем с финансами на первое время, документами, перевозкой вещей. Также у нас есть программа «Офис без границ» для временно выезжающих в другие города и страны: инженеры, которые трудятся в компании больше года, могут до шести месяцев работать удалённо из любой точки мира. Ещё неочевидный момент инженерной культуры в таких условиях — время встреч. Проводим их в те периоды, когда удобно инженерам из всех офисов разработки.
Адаптация. Инженер уже стал сотрудником компании, но ему ещё нужно освоиться. Исчерпывающая документация, гайды, практики наставничества и другие инструменты онбординга сокращают этот процесс. Например, в inDrive фронтенд-разработчикам помогает освоиться монорепозиторий. А у бэкенд-разработчиков в некоторых командах используют парное программирование.
В inDrive онбординг обычно длится три дня, затем следует период адаптации — 1–2 месяца, в зависимости от команды и роли новичка. У нас есть много welcome-встреч, чтобы инженеру было легче знакомиться с нашей разработкой и культурой. Сотрудники команд People & Culture и IT Infrastructure & Security проводят встречи, посвящённые компании в целом: её целям, структуре, ценностям, основным внутренним процессам и так далее.
Отдельно проходят технические встречи: сотрудники платформы из соответствующего сообщества погружают в контекст проекта, а команда Process & Practice — в процессы разработки. Раз в квартал проходит встреча новичков с CTO, SVP of Engineering и всеми хедами разработки в формате All-Hands, а иногда и с CEO компании. Эти встречи собирают всех новичков, пришедших в компанию с момента предыдущих встреч.
Освоиться помогают и наставники. Поначалу новичку помогает адаптироваться бадди — человек из команды, куда онбордится инженер. После у разработчика появляется другой наставник — ментор, обычно это кто-то из руководителей направления. К ментору можно обратиться, чтобы прокачать свою экспертизу, менеджерские скиллы, публичные выступления и другие навыки.
Отношения с коллективом. Инженеру комфортно в здоровых рабочих отношениях с окружающими. Многое зависит от людей, но культура может задавать стандарты, которые направят инженера в правильное русло. Кодексы, манифесты, правила — задокументированные или негласные, но принятые в компании.
В inDrive отношения и общение регулирует этический кодекс. Под запретом харрасмент, буллинг, токсичность. Общаемся на равных: все друг с другом на «ты». Если между сотрудниками возникают конфликты, не оставляем их тлеть — привлекаем дивизион People & Culture, а если не помогло, то и комитет по этике.
Неформальная жизнь — тоже часть культуры компании. Клубы по интересам, спортивные команды — это есть у многих. Наша особенность — акцент на активные виды спорта. Можем послать людей на соревнования за счёт компании (например, на марафон) или помочь группе коллег собраться для поездки в горы или на море посёрфить.
2-й уровень. Потребность принадлежности
![«Где моё место тут?» «Где моё место тут?»](https://habrastorage.org/getpro/habr/upload_files/181/73e/4a8/18173e4a84d7e8e6990ed7fff804a5df.png)
Инженер становится частью команды. На этом уровне ему важно следующее.
Понимание роли в команде и компании, ответственности. По мере роста компании становится сложнее поддерживать темп разработки. Поэтому модели управления разработкой могут меняться, усложняться. Инженер должен понимать иерархию, перед кем и за что он отвечает.
У inDrive был опыт существования в разных структурах, по мере роста мы их меняли, когда структуры переставали подходить. Начинали с waterfall — в западных компаниях её также называют технологической моделью: были отделы, задачи путешествовали по ним до продакшена, ответственность за разработку лежала на тимлидах. Эта модель хорошо подходит для стартапов и небольших компаний, и поначалу нас тоже устраивала.
Затем компания выросла, разработка замедлилась, и мы совершили переход к матричной модели с кросс-функциональными командами. Каждая такая команда способна сама разработать и запустить продукт, проверить гипотезу. О причинах и деталях перехода можно почитать в нашей статье.
Со временем скорость разработки снова начала падать, и в 2022 году мы перешли к продуктовой модели управления. В этой модели тоже есть кросс-функциональные команды, но они существуют не по отдельности, а объединены в более крупные образования — кластеры, по 3–8 команд в каждом. Команды кластера занимаются определёнными направлениями бизнеса, в каждом есть свои Engineering Director и Head of Product. Они вдвоём принимают ключевые решения и отвечают за технологии и развитие продукта. У разработчиков внутри кросс-функциональных команд больше свободы, но больше и ответственности.
Понимание, чего от него и его команды ждёт компания. Задача, которую инженер делает в команде, лишь кусочек картины. Инженер может не знать её контекста: зачем она нужна, как связана с задачами других команд, как её будут оценивать. Эти вопросы снимают прозрачность планирования и оценки работы в компании — когда инженер видит всю картину и чёткие ориентиры.
В случае inDrive для этого служит OKR: мы проводим встречи со всеми командами раз в квартал. Планирование проходит в несколько этапов. Вначале руководители команд и техлиды представляют контексты, которые команды должны учесть. Затем команды проводят мозговые штурмы и генерируют гипотезы, которые помогут достичь нужных OKR. Причём в процессе могут участвовать как команды этих продуктов, так и другие сотрудники компании, у которых есть идеи.
Гипотезы приоритезируют, оценивают их жизнеспособность и добавляют в продуктовые планы. После команды делятся своими планами с руководством, другими командами и сотрудниками, получают от них обратную связь. Так встречи OKR позволяют всем видеть полную картину планов команд и компании на ближайший квартал.
Мы также разработали дерево метрик, оно показывает командам связи бизнес-метрик и их продуктов. Так команды видят своё влияние на цели компании.
Обратная связь о своей работе. Когда разработчик получает обратную связь, он чувствует важность своего труда, внимание со стороны коллег и руководства.
В inDrive развита культура открытой обратной связи: каждый в любой момент может дать конструктивную обратную связь кому угодно. А для массового сбора обратной связи сразу по всем инженерам и менеджерам в компании есть процесс ежеквартального перфоманс-ревью.
![Иногда обратная связь бывает спонтанная. Иногда обратная связь бывает спонтанная.](https://habrastorage.org/getpro/habr/upload_files/497/6b6/cb4/4976b6cb4b374963ec0b2ea2ab13f218.png)
![Иногда — в форме опроса. Иногда — в форме опроса.](https://habrastorage.org/getpro/habr/upload_files/6b0/0bb/f24/6b00bbf24040cf7bea0deedb7b9ad5c9.png)
3-й уровень. Потребность в гармонии и порядке
![«Как я тут буду работать?» «Как я тут буду работать?»](https://habrastorage.org/getpro/habr/upload_files/08b/051/c16/08b051c165c2a77519ba6d048132e978.png)
Инженеру важно, чтобы процессы помогали ему кодить, а не мешали. Здесь становятся важными следующие параметры.
Методология. Она определяет, как команды ставят и решают задачи, в какие процессы будет вовлечён инженер. При этом компания не только выбирает и внедряет методологию, но и адаптирует её под свои процессы.
Например, в inDrive мы используем подходы гибкой разработки, тестируем методы и инструменты, лучшие варианты собираем в собственный фреймворк. У команд, в зависимости от их контекста, есть выбор: работать по спринтам или с потоком задач. Выравнивание между командами проходит на внутренних событиях кластера, встречах-синхронизациях вокруг общих программ и во время OKR-планирования.
В наших командах бывают дискавери- и деливери-спринты, в обоих процессах участвует вся команда, включая разработчиков. Ещё у нас существует пре-деливери-процесс для подготовки задач к разработке. Используем и свои инструменты. Например, систем-ревью с участием стейкхолдеров — они смотрят на результат спринта и дают обратную связь. Или техинсайт, где платформенные команды делятся результатами, достижениями и фокусами со спринтов и итераций за месяц».
![](https://habrastorage.org/getpro/habr/upload_files/9b0/dbf/e06/9b0dbfe0689b838e7447803ea10f9807.jpg)
Дарья Балбенова
Agile Coach, процессы и практики
Мы проводим дискавери-синки на всю компанию. Они открытые, кто угодно может прийти, хотя обычно участвуют продакты, дизайнеры-аналитики, иногда приходят и представители бизнеса. Внутри направлений проходят свои дискавери-синки, они менее официальные, участники на них свободно комментируют, обсуждают идеи, цели и другие детали.
![](https://habrastorage.org/getpro/habr/upload_files/eef/50f/d5c/eef50fd5c620869d0ee208d00c2b5fa8.jpg)
Григорий Гаршин
Head of Product
Регламенты. Упорядочивают процессы, задают границы действий разработчиков. Иногда разработчикам регламенты мешают — тем, кто предпочитает свободу творчества без рамок. Для других регламенты — ориентиры, вносящие порядок в разработку. Подход к регламентам зависит и от стадии развития компании: в стартапе их может не быть вовсе, в большой компании они нужны, чтобы не возник хаос. Мы поддерживаем дух стартапа в компании и стараемся давать больше свободы инженерам, но регламенты есть — при наших размерах они необходимы.
Кстати, восприятие регламентов — вещь относительная. Мы сталкивались с тем, что в inDrive одни новички жаловались на суровые регламенты нашей компании, другие же считали, что регламенты у нас не проработаны и процессы не выстроены.
Коммьюнити в компании, практики код-ревью. Они помогают разработчику находить и исправлять ошибки, перенимать опыт других коллег, делают его код лучше.
Например, iOS-сообщество inDrive проводит еженедельные встречи и постепенно уходит от broadcast-формата, когда один вещает, а остальные слушают. Человек может записаться в агенду встречи и сказать: «У меня болит», и после общего обсуждения это приведёт к тому, что что-то изменится.
Понятная и актуальная документация к коду. Она позволяет разработчику в любой момент вникнуть в код, написанный до него, и сделать свой код понятным для других инженеров в компании. Бывает, что вопросы документации в компании не продуманы, её составляют как придётся, не систематизируют, оставляют на потом. Инженеру, пришедшему в такую компанию, будет нелегко.
Мы тоже столкнулись с этой проблемой. inDrive быстро рос, поначалу мы пренебрегали гигиеной документации, теперь приходится заниматься техдолгом.
Мы пересмотрели подход к технической документации — используем подход Docs-as-Code, написали свой удобный сервис Documentary Platform для отображения данных и документации. Сама документация ведётся командами в репозиториях GitHub рядом с кодом с использованием легковесного языка разметки Markdown и актуализируется синхронно с реализацией новой функциональности. Documentary Platform отображает все необходимые данные из репозитория: документацию из Markdown-файлов, API, зависимости между сервисами, PlantUML- и Mermaid-диаграммы, GraphSQL, proto-файлы. Каждый может разместить пост на любую техническую тему в блоге платформы.
![](https://habrastorage.org/getpro/habr/upload_files/7f1/0a4/51a/7f10a451af06574091416594deeb2022.jpg)
Анна Гончарова
Technical Writer
4-й уровень. Потребность в самосовершенствовании
![«Как я могу расти?» «Как я могу расти?»](https://habrastorage.org/getpro/habr/upload_files/b7e/8e4/a0d/b7e8e4a0d2bfa822d52b9f085361b74c.png)
Инженер заинтересован в своей эволюции как специалиста, и для роста ему нужно прокачивать скиллы. Для той или иной должности ему могут потребоваться разные компетенции. И не всегда инженер точно знает, куда расти, какие скиллы качать.
Компания с развитой инженерной культурой поддерживает разработчика в прокачке скиллов и создании комфортных условий для этого. Разработчику могут помочь определиться с компетенциями для определённого карьерного трека, подобрать и оплатить сторонние курсы, подписки на конференции. В некоторых компаниях есть и свои готовые курсы, практики приглашения тренеров.
К помощи в обучении мы пришли давно и собрали много своих курсов и обучающих материалов на платформе Academy Ocean, если нет нужного — оплачиваем внешнее обучение. Ещё мы разработали систему грейдов, чтобы инженер мог видеть, какие скиллы нужны для продвижения по его карьерному треку.
Не реже раза в год департамент информационной безопасности (ИБ) вместе с партнерами проводит для команд разработки соревнования CTF, где участвуют команды из сильных IT-компаний. Обычно такие соревнования проводят среди ИБ-специалистов, но мы считаем, что разработчикам полезно взглянуть на свои системы под другим углом и прочувствовать реальность киберугроз.
![](https://habrastorage.org/getpro/habr/upload_files/2a4/0e0/417/2a40e04177762d7835226db1a23e4aea.jpg)
Денис Рыбин
Application Security Lead
Обмен опытом внутри компании. Источником полезных знаний могут быть и коллеги. Разработчики придумывают новые решения задач, которые пригодятся и другим командам. Компания может стимулировать этот процесс — организовывать встречи, распространять статьи инженеров через внутренние каналы. Мы проводим подобные мероприятия регулярно: раз в неделю разработчики обмениваются опытом создания полезных фич, раз в квартал своими достижениями делятся хеды разработки, а ещё организовываем ежеквартальные хакатоны.
Пока в компании десятки инженеров, для решения системных проблем хватает лидов. Но в больших компаниях с сотнями инженеров нужны новые роли — деврелов и дев-адвокатов. Дев-адвокат — это высокая ступень эволюции инженера, когда он так горит своим делом, что становится его евангелистом. Дев-адвокат уже не пишет код в команде, он находится вне команд, работает с сами сообществом, находит проблемы и помогает их решать.
![](https://habrastorage.org/getpro/habr/upload_files/749/963/2a8/7499632a839f35431425e6271ba2433a.jpg)
Влад Тетерин
Head of DevRel
Реализация своих идей — с помощью коллег или самостоятельно. Есть ли в компании механизмы рассмотрения таких предложений, насколько они проработаны и просты. Длинная цепочка согласований и недоверие к идеям демотивируют разработчиков.
В inDrive у разработчика есть несколько простых путей реализовать свои идеи:
поговорить с руководителем нужной команды напрямую и убедить его, что идея полезна;
защитить идею перед Core Team с CEO в составе;
поучаствовать во внутреннем хакатоне.
В особых случаях разработчику могут позволить собрать отдельную команду для реализации его идеи. Но для этого придётся сперва доказать Core Team, что идея стоит усилий.
Влад Тетерин, Head of DevRel:
У нас есть внутренние продукты, которые придумали инженеры компании и захотели сделать. Например, наш внутренний портал Teammate разработали на хакатоне. Систему Documentary Platform тоже придумал один человек, другие поддержали, и теперь ею занимается отдельная команда. Ещё пример — библиотека UDF, которую написали и выложили в опенсорс наши разработчики.
![](https://habrastorage.org/getpro/habr/upload_files/988/289/fe6/988289fe692b3fb095fbbd792502e023.jpg)
Влад Тетерин
Head of DevRel
5-й уровень. Потребность в самоактуализации и признании
Это высший уровень потребностей инженера в компании — когда он полностью осознаёт свой путь и готов транслировать свои знания дальше, становится амбассадором компании в IT-сообществе. На этом уровне ему важно следующее.
Передача знаний. У инженера есть возможности сделать это и самому — через GitHub, Хабр, Medium и т. д. Но если компания поддерживает эту активность, ему будет легче выполнять свою миссию. У компаний много способов помочь: организовывать митапы и конференции, оплачивать участие в сторонних конференциях. Или содержать в штате специалистов, которые возьмут на себя часть работы над материалами, чтобы разработчик не тратил время на технические моменты.
В inDrive есть команда деврелов, технические писатели, дизайнер. Мы помогаем разработчикам пройти весь цикл создания статьи: определиться с темой, написать и отредактировать текст, подобрать или сделать иллюстрации, презентацию оформить.
![](https://habrastorage.org/getpro/habr/upload_files/717/f5d/658/717f5d65871dc54f2378c2439a5b1d5a.jpg)
Влад Тетерин
Head of DevRel
Признание сообщества. Опытный инженер может развивать свой личный бренд — тогда его известность выходит за пределы компании.
У нас есть инженеры, которые хорошо известны в IT-сообществе. Например, Алексей Акулович — в сообществе Go-разработчиков, Алексей Кудрявцев — у iOS-разработчиков, Денис Рыбин — среди безопасников, Станислав Яковлев — у QA-инженеров, Александр Лисаченко — в PHP-коммьюнити.
Ценности разработчика и инженерной культуры компании не всегда совпадают на 100%. Где-то инженер готов подстроиться и пересмотреть свои привычки, где-то поможет компания. Но есть ключевые моменты, с которыми совпадение особенно важно.
В inDrive мы руководствуемся тремя основными принципами, которые называем философией хакерства. Принципы являются базовой линией и помогают нам не сбиться с пути создания большой и классной международной команды inDrive.Tech:
Решать задачи и не отступать от проблем.
Вовлекаться в то, что мы делаем, а не быть простым наблюдателем.
Увлекаться технологиями и знаниями, которые помогают росту компании.
Мы намеренно выбираем людей с подобной философией, чтобы инженеры в наших командах были единомышленниками и максимально эффективно достигали целей.