От собеседования до амбассадора: пирамида потребностей разработчика24.04.2023 17:16

Привет, Хабр! На связи DevRel-команда inDrive. Мы прошли путь от стартапа из Якутии до компании с продуктом, которым пользуются в 48 странах мира. В процессе мы поняли важность culture fit — насколько хорошо вписывается разработчик в инженерную культуру компании. Мы представили её в виде пирамиды по аналогии с пирамидой Маслоу. 

Уровни пирамиды разделены в соответствии с потребностями инженера на работе и проиллюстрированы примерами из нашего опыта. В основе пирамиды — комфортное рабочее окружение, на вершине — самоактуализация на конференциях.

 1-й уровень. Комфорт и безопасность

«Хочу ли я тут работать?»

Как и у Маслоу, в основании пирамиды самые базовые потребности — комфорт и безопасность. Инженер оценивает компанию и решает, подходит ли она ему.

Контакт на собеседовании. Здесь происходит первый контакт инженера с культурой компании. О ней можно судить уже по характеру собеседования: по теплоте в общении с соискателем, пониманию его уровня, адекватности вопросов. Если на этом этапе инженера что-то оттолкнёт, дальнейшей его истории в компании не случится. 

Мы поработали над подходом к собеседованиям, чтобы инженеры не испытывали стресс. Например, у нас нет практики закидывать соискателей нелепыми вопросами — например, «Кем ты видишь себя через пять лет?» и ему подобными. Уделяем внимание характеру общения, стараемся, чтобы беседа была на равных. Как между живыми людьми, а не между сотрудником и корпорацией.

Условия труда. От компании зависит, получится ли работать в привычных условиях или придётся подстраиваться, мириться с неудобствами. И сможет ли она помочь инженеру влиться в новую команду.

Простая ситуация: инженер удалёнку не хочет, а офис компании — в другом городе или стране. Уже на этом этапе разработчик видит, что они с компанией не совпадают: нужно или отказаться от вакансии, или переезжать. Релокация — это тяжело и тревожно. Но в компании могут быть инструменты, которые снимут с инженера часть проблем, — например, релокационные пакеты, помощь с переездом, страховкой.

У нас есть и офисы — на Кипре и в Казахстане, — и удалёнка. Тем, кто релоцируется, помогаем с финансами на первое время, документами, перевозкой вещей. Также у нас есть программа «Офис без границ» для временно выезжающих в другие города и страны: инженеры, которые трудятся в компании больше года, могут до шести месяцев работать удалённо из любой точки мира. Ещё неочевидный момент инженерной культуры в таких условиях — время встреч. Проводим их в те периоды, когда удобно инженерам из всех офисов разработки.

Адаптация. Инженер уже стал сотрудником компании, но ему ещё нужно освоиться. Исчерпывающая документация, гайды, практики наставничества и другие инструменты онбординга сокращают этот процесс. Например, в inDrive фронтенд-разработчикам помогает освоиться монорепозиторий. А у бэкенд-разработчиков в некоторых командах используют парное программирование.

В inDrive онбординг обычно длится три дня, затем следует период адаптации — 1–2 месяца, в зависимости от команды и роли новичка. У нас есть много welcome-встреч, чтобы инженеру было легче знакомиться с нашей разработкой и культурой. Сотрудники команд People & Culture и IT Infrastructure & Security проводят встречи, посвящённые компании в целом: её целям, структуре, ценностям, основным внутренним процессам и так далее. 

Отдельно проходят технические встречи: сотрудники платформы из соответствующего сообщества погружают в контекст проекта, а команда Process & Practice — в процессы разработки. Раз в квартал проходит встреча новичков с CTO, SVP of Engineering и всеми хедами разработки в формате All-Hands, а иногда и с CEO компании. Эти встречи собирают всех новичков, пришедших в компанию с момента предыдущих встреч.

Освоиться помогают и наставники. Поначалу новичку помогает адаптироваться бадди — человек из команды, куда онбордится инженер. После у разработчика появляется другой наставник — ментор, обычно это кто-то из руководителей направления. К ментору можно обратиться, чтобы прокачать свою экспертизу, менеджерские скиллы, публичные выступления и другие навыки.

Отношения с коллективом. Инженеру комфортно в здоровых рабочих отношениях с окружающими. Многое зависит от людей, но культура может задавать стандарты, которые направят инженера в правильное русло. Кодексы, манифесты, правила — задокументированные или негласные, но принятые в компании.

В inDrive отношения и общение регулирует этический кодекс. Под запретом харрасмент, буллинг, токсичность. Общаемся на равных: все друг с другом на «ты». Если между сотрудниками возникают конфликты, не оставляем их тлеть — привлекаем дивизион People & Culture, а если не помогло, то и комитет по этике.

Неформальная жизнь — тоже часть культуры компании. Клубы по интересам, спортивные команды — это есть у многих. Наша особенность — акцент на активные виды спорта. Можем послать людей на соревнования за счёт компании (например, на марафон) или помочь группе коллег собраться для поездки в горы или на море посёрфить. 

2-й уровень. Потребность принадлежности

«Где моё место тут?»

Инженер становится частью команды. На этом уровне ему важно следующее.

Понимание роли в команде и компании, ответственности. По мере роста компании становится сложнее поддерживать темп разработки. Поэтому модели управления разработкой могут меняться, усложняться. Инженер должен понимать иерархию, перед кем и за что он отвечает.

У inDrive был опыт существования в разных структурах, по мере роста мы их меняли, когда структуры переставали подходить. Начинали с waterfall — в западных компаниях её также называют технологической моделью: были отделы, задачи путешествовали по ним до продакшена, ответственность за разработку лежала на тимлидах. Эта модель хорошо подходит для стартапов и небольших компаний, и поначалу нас тоже устраивала.

Затем компания выросла, разработка замедлилась, и мы совершили переход к матричной модели с кросс-функциональными командами. Каждая такая команда способна сама разработать и запустить продукт, проверить гипотезу. О причинах и деталях перехода можно почитать в нашей статье.

Со временем скорость разработки снова начала падать, и в 2022 году мы перешли к продуктовой модели управления. В этой модели тоже есть кросс-функциональные команды, но они существуют не по отдельности, а объединены в более крупные образования — кластеры, по 3–8 команд в каждом. Команды кластера занимаются определёнными направлениями бизнеса, в каждом есть свои Engineering Director и Head of Product. Они вдвоём принимают ключевые решения и отвечают за технологии и развитие продукта. У разработчиков внутри кросс-функциональных команд больше свободы, но больше и ответственности. 

Понимание, чего от него и его команды ждёт компания. Задача, которую инженер делает в команде, лишь кусочек картины. Инженер может не знать её контекста: зачем она нужна, как связана с задачами других команд, как её будут оценивать. Эти вопросы снимают прозрачность планирования и оценки работы в компании — когда инженер видит всю картину и чёткие ориентиры.

В случае inDrive для этого служит OKR: мы проводим встречи со всеми командами раз в квартал. Планирование проходит в несколько этапов. Вначале руководители команд и техлиды представляют контексты, которые команды должны учесть. Затем команды проводят мозговые штурмы и генерируют гипотезы, которые помогут достичь нужных OKR. Причём в процессе могут участвовать как команды этих продуктов, так и другие сотрудники компании, у которых есть идеи.

Гипотезы приоритезируют, оценивают их жизнеспособность и добавляют в продуктовые планы. После команды делятся своими планами с руководством, другими командами и сотрудниками, получают от них обратную связь. Так встречи OKR позволяют всем видеть полную картину планов команд и компании на ближайший квартал.

Мы также разработали дерево метрик, оно показывает командам связи бизнес-метрик и их продуктов. Так команды видят своё влияние на цели компании.

Обратная связь о своей работе. Когда разработчик получает обратную связь, он чувствует важность своего труда, внимание со стороны коллег и руководства.

В inDrive развита культура открытой обратной связи: каждый в любой момент может дать конструктивную обратную связь кому угодно. А для массового сбора обратной связи сразу по всем инженерам и менеджерам в компании есть процесс ежеквартального перфоманс-ревью.

Иногда обратная связь бывает спонтанная.

Иногда — в форме опроса.

3-й уровень. Потребность в гармонии и порядке

«Как я тут буду работать?»

Инженеру важно, чтобы процессы помогали ему кодить, а не мешали. Здесь становятся важными следующие параметры.

Методология. Она определяет, как команды ставят и решают задачи, в какие процессы будет вовлечён инженер. При этом компания не только выбирает и внедряет методологию, но и адаптирует её под свои процессы.

Например, в inDrive мы используем подходы гибкой разработки, тестируем методы и инструменты, лучшие варианты собираем в собственный фреймворк. У команд, в зависимости от их контекста, есть выбор: работать по спринтам или с потоком задач. Выравнивание между командами проходит на внутренних событиях кластера, встречах-синхронизациях вокруг общих программ и во время OKR-планирования.

В наших командах бывают дискавери- и деливери-спринты, в обоих процессах участвует вся команда, включая разработчиков. Ещё у нас существует пре-деливери-процесс для подготовки задач к разработке. Используем и свои инструменты. Например, систем-ревью с участием стейкхолдеров — они смотрят на результат спринта и дают обратную связь. Или техинсайт, где платформенные команды делятся результатами, достижениями и фокусами со спринтов и итераций за месяц».

Мы проводим дискавери-синки на всю компанию. Они открытые, кто угодно может прийти, хотя обычно участвуют продакты, дизайнеры-аналитики, иногда приходят и представители бизнеса. Внутри направлений проходят свои дискавери-синки, они менее официальные, участники на них свободно комментируют, обсуждают идеи, цели и другие детали.

Регламенты. Упорядочивают процессы, задают границы действий разработчиков. Иногда разработчикам регламенты мешают — тем, кто предпочитает свободу творчества без рамок. Для других регламенты — ориентиры, вносящие порядок в разработку. Подход к регламентам зависит и от стадии развития компании: в стартапе их может не быть вовсе, в большой компании они нужны, чтобы не возник хаос. Мы поддерживаем дух стартапа в компании и стараемся давать больше свободы инженерам, но регламенты есть — при наших размерах они необходимы.

Кстати, восприятие регламентов — вещь относительная. Мы сталкивались с тем, что в inDrive одни новички жаловались на суровые регламенты нашей компании, другие же считали, что регламенты у нас не проработаны и процессы не выстроены.

Коммьюнити в компании, практики код-ревью. Они помогают разработчику находить и исправлять ошибки, перенимать опыт других коллег, делают его код лучше.

Например, iOS-сообщество inDrive проводит еженедельные встречи и постепенно уходит от broadcast-формата, когда один вещает, а остальные слушают. Человек может записаться в агенду встречи и сказать: «У меня болит», и после общего обсуждения это приведёт к тому, что что-то изменится.

Понятная и актуальная документация к коду. Она позволяет разработчику в любой момент вникнуть в код, написанный до него, и сделать свой код понятным для других инженеров в компании. Бывает, что вопросы документации в компании не продуманы, её составляют как придётся, не систематизируют, оставляют на потом. Инженеру, пришедшему в такую компанию, будет нелегко.

Мы тоже столкнулись с этой проблемой. inDrive быстро рос, поначалу мы пренебрегали гигиеной документации, теперь приходится заниматься техдолгом.

Мы пересмотрели подход к технической документации — используем подход Docs-as-Code, написали свой удобный сервис Documentary Platform для отображения данных и документации. Сама документация ведётся командами в репозиториях GitHub рядом с кодом с использованием легковесного языка разметки Markdown и актуализируется синхронно с реализацией новой функциональности. Documentary Platform отображает все необходимые данные из репозитория: документацию из Markdown-файлов, API, зависимости между сервисами, PlantUML- и Mermaid-диаграммы, GraphSQL, proto-файлы. Каждый может разместить пост на любую техническую тему в блоге платформы.

4-й уровень. Потребность в самосовершенствовании

«Как я могу расти?»

Инженер заинтересован в своей эволюции как специалиста, и для роста ему нужно прокачивать скиллы. Для той или иной должности ему могут потребоваться разные компетенции. И не всегда инженер точно знает, куда расти, какие скиллы качать.

Компания с развитой инженерной культурой поддерживает разработчика в прокачке скиллов и создании комфортных условий для этого. Разработчику могут помочь определиться с компетенциями для определённого карьерного трека, подобрать и оплатить сторонние курсы, подписки на конференции. В некоторых компаниях есть и свои готовые курсы, практики приглашения тренеров.

К помощи в обучении мы пришли давно и собрали много своих курсов и обучающих материалов на платформе Academy Ocean, если нет нужного — оплачиваем внешнее обучение. Ещё мы разработали систему грейдов, чтобы инженер мог видеть, какие скиллы нужны для продвижения по его карьерному треку.  

Не реже раза в год департамент информационной безопасности (ИБ) вместе с партнерами проводит для команд разработки соревнования CTF, где участвуют команды из сильных IT-компаний. Обычно такие соревнования проводят среди ИБ-специалистов, но мы считаем, что разработчикам полезно взглянуть на свои системы под другим углом и прочувствовать реальность киберугроз.

Обмен опытом внутри компании. Источником полезных знаний могут быть и коллеги. Разработчики придумывают новые решения задач, которые пригодятся и другим командам. Компания может стимулировать этот процесс — организовывать встречи, распространять статьи инженеров через внутренние каналы. Мы проводим подобные мероприятия регулярно: раз в неделю разработчики обмениваются опытом создания полезных фич, раз в квартал своими достижениями делятся хеды разработки, а ещё организовываем ежеквартальные хакатоны.

Пока в компании десятки инженеров, для решения системных проблем хватает лидов. Но в больших компаниях с сотнями инженеров нужны новые роли — деврелов и дев-адвокатов. Дев-адвокат — это высокая ступень эволюции инженера, когда он так горит своим делом, что становится его евангелистом. Дев-адвокат уже не пишет код в команде, он находится вне команд, работает с сами сообществом, находит проблемы и помогает их решать.

Реализация своих идей — с помощью коллег или самостоятельно. Есть ли в компании механизмы рассмотрения таких предложений, насколько они проработаны и просты. Длинная цепочка согласований и недоверие к идеям демотивируют разработчиков.

В inDrive у разработчика есть несколько простых путей реализовать свои идеи:

• поговорить с руководителем нужной команды напрямую и убедить его, что идея полезна;

• защитить идею перед Core Team с CEO в составе;

• поучаствовать во внутреннем хакатоне.

В особых случаях разработчику могут позволить собрать отдельную команду для реализации его идеи. Но для этого придётся сперва доказать Core Team, что идея стоит усилий.

Влад Тетерин, Head of DevRel:

У нас есть внутренние продукты, которые придумали инженеры компании и захотели сделать. Например, наш внутренний портал Teammate разработали на хакатоне. Систему Documentary Platform тоже придумал один человек, другие поддержали, и теперь ею занимается отдельная команда. Ещё пример — библиотека UDF, которую написали и выложили в опенсорс наши разработчики.

5-й уровень. Потребность в самоактуализации и признании

«Как я могу помогать другим, когда вырос сам?»

Это высший уровень потребностей инженера в компании — когда он полностью осознаёт свой путь и готов транслировать свои знания дальше, становится амбассадором компании в IT-сообществе. На этом уровне ему важно следующее.

Передача знаний. У инженера есть возможности сделать это и самому — через GitHub, Хабр, Medium и т. д. Но если компания поддерживает эту активность, ему будет легче выполнять свою миссию. У компаний много способов помочь: организовывать митапы и конференции, оплачивать участие в сторонних конференциях. Или содержать в штате специалистов, которые возьмут на себя часть работы над материалами, чтобы разработчик не тратил время на технические моменты.

В inDrive есть команда деврелов, технические писатели, дизайнер. Мы помогаем разработчикам пройти весь цикл создания статьи: определиться с темой, написать и отредактировать текст, подобрать или сделать иллюстрации, презентацию оформить.

Признание сообщества. Опытный инженер может развивать свой личный бренд — тогда его известность выходит за пределы компании.

У нас есть инженеры, которые хорошо известны в IT-сообществе. Например, Алексей Акулович — в сообществе Go-разработчиков, Алексей Кудрявцев — у iOS-разработчиков, Денис Рыбин — среди безопасников, Станислав Яковлев — у QA-инженеров, Александр Лисаченко — в PHP-коммьюнити.

Ценности разработчика и инженерной культуры компании не всегда совпадают на 100%. Где-то инженер готов подстроиться и пересмотреть свои привычки, где-то поможет компания. Но есть ключевые моменты, с которыми совпадение особенно важно.

В inDrive мы руководствуемся тремя основными принципами, которые называем философией хакерства. Принципы являются базовой линией и помогают нам не сбиться с пути создания большой и классной международной команды inDrive.Tech:

• Решать задачи и не отступать от проблем. 

• Вовлекаться в то, что мы делаем, а не быть простым наблюдателем. 

• Увлекаться технологиями и знаниями, которые помогают росту компании. 

Мы намеренно выбираем людей с подобной философией, чтобы инженеры в наших командах были единомышленниками и максимально эффективно достигали целей.

© Habrahabr.ru