Привет, Хабр! На связи DevRel-команда inDrive. Мы прошли путь от стартапа из Якутии до компании с продуктом, которым пользуются в 47 странах мира. В процессе мы поняли важность 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-планирования.
В наших командах бывают дискавери- и деливери-спринты, в обоих процессах участвует вся команда, включая разработчиков. Ещё у нас существует пре-деливери-процесс для подготовки задач к разработке. Используем и свои инструменты. Например, систем-ревью с участием стейкхолдеров — они смотрят на результат спринта и дают обратную связь. Или техинсайт, где платформенные команды делятся результатами, достижениями и фокусами со спринтов и итераций за месяц».
Дарья Балбенова
Agile Coach, процессы и практики
Мы проводим дискавери-синки на всю компанию. Они открытые, кто угодно может прийти, хотя обычно участвуют продакты, дизайнеры-аналитики, иногда приходят и представители бизнеса. Внутри направлений проходят свои дискавери-синки, они менее официальные, участники на них свободно комментируют, обсуждают идеи, цели и другие детали.
Григорий Гаршин
Head of Product
Регламенты. Упорядочивают процессы, задают границы действий разработчиков. Иногда разработчикам регламенты мешают — тем, кто предпочитает свободу творчества без рамок. Для других регламенты — ориентиры, вносящие порядок в разработку. Подход к регламентам зависит и от стадии развития компании: в стартапе их может не быть вовсе, в большой компании они нужны, чтобы не возник хаос. Мы поддерживаем дух стартапа в компании и стараемся давать больше свободы инженерам, но регламенты есть — при наших размерах они необходимы.
Кстати, восприятие регламентов — вещь относительная. Мы сталкивались с тем, что в inDrive одни новички жаловались на суровые регламенты нашей компании, другие же считали, что регламенты у нас не проработаны и процессы не выстроены.
Коммьюнити в компании, практики код-ревью. Они помогают разработчику находить и исправлять ошибки, перенимать опыт других коллег, делают его код лучше.
Например, iOS-сообщество inDrive проводит еженедельные встречи и постепенно уходит от broadcast-формата, когда один вещает, а остальные слушают. Человек может записаться в агенду встречи и сказать: «У меня болит», и после общего обсуждения это приведёт к тому, что что-то изменится.
Понятная и актуальная документация к коду. Она позволяет разработчику в любой момент вникнуть в код, написанный до него, и сделать свой код понятным для других инженеров в компании. Бывает, что вопросы документации в компании не продуманы, её составляют как придётся, не систематизируют, оставляют на потом. Инженеру, пришедшему в такую компанию, будет нелегко.
Мы тоже столкнулись с этой проблемой. inDrive быстро рос, поначалу мы пренебрегали гигиеной документации, теперь приходится заниматься техдолгом.
Мы пересмотрели подход к технической документации — используем подход Docs-as-Code, написали свой удобный сервис Documentary Platform для отображения данных и документации. Сама документация ведётся командами в репозиториях GitHub рядом с кодом с использованием легковесного языка разметки Markdown и актуализируется синхронно с реализацией новой функциональности. Documentary Platform отображает все необходимые данные из репозитория: документацию из Markdown-файлов, API, зависимости между сервисами, PlantUML- и Mermaid-диаграммы, GraphSQL, proto-файлы. Каждый может разместить пост на любую техническую тему в блоге платформы.
Анна Гончарова
Technical Writer
4-й уровень. Потребность в самосовершенствовании
Инженер заинтересован в своей эволюции как специалиста, и для роста ему нужно прокачивать скиллы. Для той или иной должности ему могут потребоваться разные компетенции. И не всегда инженер точно знает, куда расти, какие скиллы качать.
Компания с развитой инженерной культурой поддерживает разработчика в прокачке скиллов и создании комфортных условий для этого. Разработчику могут помочь определиться с компетенциями для определённого карьерного трека, подобрать и оплатить сторонние курсы, подписки на конференции. В некоторых компаниях есть и свои готовые курсы, практики приглашения тренеров.
К помощи в обучении мы пришли давно и собрали много своих курсов и обучающих материалов на платформе Academy Ocean, если нет нужного — оплачиваем внешнее обучение. Ещё мы разработали систему грейдов, чтобы инженер мог видеть, какие скиллы нужны для продвижения по его карьерному треку.
Не реже раза в год департамент информационной безопасности (ИБ) вместе с партнерами проводит для команд разработки соревнования CTF, где участвуют команды из сильных IT-компаний. Обычно такие соревнования проводят среди ИБ-специалистов, но мы считаем, что разработчикам полезно взглянуть на свои системы под другим углом и прочувствовать реальность киберугроз.
Денис Рыбин
Application Security Lead
Обмен опытом внутри компании. Источником полезных знаний могут быть и коллеги. Разработчики придумывают новые решения задач, которые пригодятся и другим командам. Компания может стимулировать этот процесс — организовывать встречи, распространять статьи инженеров через внутренние каналы. Мы проводим подобные мероприятия регулярно: раз в неделю разработчики обмениваются опытом создания полезных фич, раз в квартал своими достижениями делятся хеды разработки, а ещё организовываем ежеквартальные хакатоны.
Пока в компании десятки инженеров, для решения системных проблем хватает лидов. Но в больших компаниях с сотнями инженеров нужны новые роли — деврелов и дев-адвокатов. Дев-адвокат — это высокая ступень эволюции инженера, когда он так горит своим делом, что становится его евангелистом. Дев-адвокат уже не пишет код в команде, он находится вне команд, работает с сами сообществом, находит проблемы и помогает их решать.
Влад Тетерин
Head of DevRel
Реализация своих идей — с помощью коллег или самостоятельно. Есть ли в компании механизмы рассмотрения таких предложений, насколько они проработаны и просты. Длинная цепочка согласований и недоверие к идеям демотивируют разработчиков.
В inDrive у разработчика есть несколько простых путей реализовать свои идеи:
поговорить с руководителем нужной команды напрямую и убедить его, что идея полезна;
защитить идею перед Core Team с CEO в составе;
поучаствовать во внутреннем хакатоне.
В особых случаях разработчику могут позволить собрать отдельную команду для реализации его идеи. Но для этого придётся сперва доказать Core Team, что идея стоит усилий.
Влад Тетерин, Head of DevRel:
У нас есть внутренние продукты, которые придумали инженеры компании и захотели сделать. Например, наш внутренний портал Teammate разработали на хакатоне. Систему Documentary Platform тоже придумал один человек, другие поддержали, и теперь ею занимается отдельная команда. Ещё пример — библиотека UDF, которую написали и выложили в опенсорс наши разработчики.
Влад Тетерин
Head of DevRel
5-й уровень. Потребность в самоактуализации и признании
Это высший уровень потребностей инженера в компании — когда он полностью осознаёт свой путь и готов транслировать свои знания дальше, становится амбассадором компании в IT-сообществе. На этом уровне ему важно следующее.
Передача знаний. У инженера есть возможности сделать это и самому — через GitHub, Хабр, Medium и т. д. Но если компания поддерживает эту активность, ему будет легче выполнять свою миссию. У компаний много способов помочь: организовывать митапы и конференции, оплачивать участие в сторонних конференциях. Или содержать в штате специалистов, которые возьмут на себя часть работы над материалами, чтобы разработчик не тратил время на технические моменты.
В inDrive есть команда деврелов, технические писатели, дизайнер. Мы помогаем разработчикам пройти весь цикл создания статьи: определиться с темой, написать и отредактировать текст, подобрать или сделать иллюстрации, презентацию оформить.
Влад Тетерин
Head of DevRel
Признание сообщества. Опытный инженер может развивать свой личный бренд — тогда его известность выходит за пределы компании.
У нас есть инженеры, которые хорошо известны в IT-сообществе. Например, Алексей Акулович — в сообществе Go-разработчиков, Алексей Кудрявцев — у iOS-разработчиков, Денис Рыбин — среди безопасников, Станислав Яковлев — у QA-инженеров, Александр Лисаченко — в PHP-коммьюнити.
Ценности разработчика и инженерной культуры компании не всегда совпадают на 100%. Где-то инженер готов подстроиться и пересмотреть свои привычки, где-то поможет компания. Но есть ключевые моменты, с которыми совпадение особенно важно.
В inDrive мы руководствуемся тремя основными принципами, которые называем философией хакерства. Принципы являются базовой линией и помогают нам не сбиться с пути создания большой и классной международной команды inDrive.Tech:
Решать задачи и не отступать от проблем.
Вовлекаться в то, что мы делаем, а не быть простым наблюдателем.
Увлекаться технологиями и знаниями, которые помогают росту компании.
Мы намеренно выбираем людей с подобной философией, чтобы инженеры в наших командах были единомышленниками и максимально эффективно достигали целей.
Привет, Хабр! На связи DevRel-команда inDrive. Мы прошли путь от стартапа из Якутии до компании с продуктом, которым пользуются в 47 странах мира. В процессе мы поняли важность 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-планирования.
В наших командах бывают дискавери- и деливери-спринты, в обоих процессах участвует вся команда, включая разработчиков. Ещё у нас существует пре-деливери-процесс для подготовки задач к разработке. Используем и свои инструменты. Например, систем-ревью с участием стейкхолдеров — они смотрят на результат спринта и дают обратную связь. Или техинсайт, где платформенные команды делятся результатами, достижениями и фокусами со спринтов и итераций за месяц».
Дарья Балбенова
Agile Coach, процессы и практики
Мы проводим дискавери-синки на всю компанию. Они открытые, кто угодно может прийти, хотя обычно участвуют продакты, дизайнеры-аналитики, иногда приходят и представители бизнеса. Внутри направлений проходят свои дискавери-синки, они менее официальные, участники на них свободно комментируют, обсуждают идеи, цели и другие детали.
Григорий Гаршин
Head of Product
Регламенты. Упорядочивают процессы, задают границы действий разработчиков. Иногда разработчикам регламенты мешают — тем, кто предпочитает свободу творчества без рамок. Для других регламенты — ориентиры, вносящие порядок в разработку. Подход к регламентам зависит и от стадии развития компании: в стартапе их может не быть вовсе, в большой компании они нужны, чтобы не возник хаос. Мы поддерживаем дух стартапа в компании и стараемся давать больше свободы инженерам, но регламенты есть — при наших размерах они необходимы.
Кстати, восприятие регламентов — вещь относительная. Мы сталкивались с тем, что в inDrive одни новички жаловались на суровые регламенты нашей компании, другие же считали, что регламенты у нас не проработаны и процессы не выстроены.
Коммьюнити в компании, практики код-ревью. Они помогают разработчику находить и исправлять ошибки, перенимать опыт других коллег, делают его код лучше.
Например, iOS-сообщество inDrive проводит еженедельные встречи и постепенно уходит от broadcast-формата, когда один вещает, а остальные слушают. Человек может записаться в агенду встречи и сказать: «У меня болит», и после общего обсуждения это приведёт к тому, что что-то изменится.
Понятная и актуальная документация к коду. Она позволяет разработчику в любой момент вникнуть в код, написанный до него, и сделать свой код понятным для других инженеров в компании. Бывает, что вопросы документации в компании не продуманы, её составляют как придётся, не систематизируют, оставляют на потом. Инженеру, пришедшему в такую компанию, будет нелегко.
Мы тоже столкнулись с этой проблемой. inDrive быстро рос, поначалу мы пренебрегали гигиеной документации, теперь приходится заниматься техдолгом.
Мы пересмотрели подход к технической документации — используем подход Docs-as-Code, написали свой удобный сервис Documentary Platform для отображения данных и документации. Сама документация ведётся командами в репозиториях GitHub рядом с кодом с использованием легковесного языка разметки Markdown и актуализируется синхронно с реализацией новой функциональности. Documentary Platform отображает все необходимые данные из репозитория: документацию из Markdown-файлов, API, зависимости между сервисами, PlantUML- и Mermaid-диаграммы, GraphSQL, proto-файлы. Каждый может разместить пост на любую техническую тему в блоге платформы.
Анна Гончарова
Technical Writer
4-й уровень. Потребность в самосовершенствовании
Инженер заинтересован в своей эволюции как специалиста, и для роста ему нужно прокачивать скиллы. Для той или иной должности ему могут потребоваться разные компетенции. И не всегда инженер точно знает, куда расти, какие скиллы качать.
Компания с развитой инженерной культурой поддерживает разработчика в прокачке скиллов и создании комфортных условий для этого. Разработчику могут помочь определиться с компетенциями для определённого карьерного трека, подобрать и оплатить сторонние курсы, подписки на конференции. В некоторых компаниях есть и свои готовые курсы, практики приглашения тренеров.
К помощи в обучении мы пришли давно и собрали много своих курсов и обучающих материалов на платформе Academy Ocean, если нет нужного — оплачиваем внешнее обучение. Ещё мы разработали систему грейдов, чтобы инженер мог видеть, какие скиллы нужны для продвижения по его карьерному треку.
Не реже раза в год департамент информационной безопасности (ИБ) вместе с партнерами проводит для команд разработки соревнования CTF, где участвуют команды из сильных IT-компаний. Обычно такие соревнования проводят среди ИБ-специалистов, но мы считаем, что разработчикам полезно взглянуть на свои системы под другим углом и прочувствовать реальность киберугроз.
Денис Рыбин
Application Security Lead
Обмен опытом внутри компании. Источником полезных знаний могут быть и коллеги. Разработчики придумывают новые решения задач, которые пригодятся и другим командам. Компания может стимулировать этот процесс — организовывать встречи, распространять статьи инженеров через внутренние каналы. Мы проводим подобные мероприятия регулярно: раз в неделю разработчики обмениваются опытом создания полезных фич, раз в квартал своими достижениями делятся хеды разработки, а ещё организовываем ежеквартальные хакатоны.
Пока в компании десятки инженеров, для решения системных проблем хватает лидов. Но в больших компаниях с сотнями инженеров нужны новые роли — деврелов и дев-адвокатов. Дев-адвокат — это высокая ступень эволюции инженера, когда он так горит своим делом, что становится его евангелистом. Дев-адвокат уже не пишет код в команде, он находится вне команд, работает с сами сообществом, находит проблемы и помогает их решать.
Влад Тетерин
Head of DevRel
Реализация своих идей — с помощью коллег или самостоятельно. Есть ли в компании механизмы рассмотрения таких предложений, насколько они проработаны и просты. Длинная цепочка согласований и недоверие к идеям демотивируют разработчиков.
В inDrive у разработчика есть несколько простых путей реализовать свои идеи:
поговорить с руководителем нужной команды напрямую и убедить его, что идея полезна;
защитить идею перед Core Team с CEO в составе;
поучаствовать во внутреннем хакатоне.
В особых случаях разработчику могут позволить собрать отдельную команду для реализации его идеи. Но для этого придётся сперва доказать Core Team, что идея стоит усилий.
Влад Тетерин, Head of DevRel:
У нас есть внутренние продукты, которые придумали инженеры компании и захотели сделать. Например, наш внутренний портал Teammate разработали на хакатоне. Систему Documentary Platform тоже придумал один человек, другие поддержали, и теперь ею занимается отдельная команда. Ещё пример — библиотека UDF, которую написали и выложили в опенсорс наши разработчики.
Влад Тетерин
Head of DevRel
5-й уровень. Потребность в самоактуализации и признании
Это высший уровень потребностей инженера в компании — когда он полностью осознаёт свой путь и готов транслировать свои знания дальше, становится амбассадором компании в IT-сообществе. На этом уровне ему важно следующее.
Передача знаний. У инженера есть возможности сделать это и самому — через GitHub, Хабр, Medium и т. д. Но если компания поддерживает эту активность, ему будет легче выполнять свою миссию. У компаний много способов помочь: организовывать митапы и конференции, оплачивать участие в сторонних конференциях. Или содержать в штате специалистов, которые возьмут на себя часть работы над материалами, чтобы разработчик не тратил время на технические моменты.
В inDrive есть команда деврелов, технические писатели, дизайнер. Мы помогаем разработчикам пройти весь цикл создания статьи: определиться с темой, написать и отредактировать текст, подобрать или сделать иллюстрации, презентацию оформить.
Влад Тетерин
Head of DevRel
Признание сообщества. Опытный инженер может развивать свой личный бренд — тогда его известность выходит за пределы компании.
У нас есть инженеры, которые хорошо известны в IT-сообществе. Например, Алексей Акулович — в сообществе Go-разработчиков, Алексей Кудрявцев — у iOS-разработчиков, Денис Рыбин — среди безопасников, Станислав Яковлев — у QA-инженеров, Александр Лисаченко — в PHP-коммьюнити.
Ценности разработчика и инженерной культуры компании не всегда совпадают на 100%. Где-то инженер готов подстроиться и пересмотреть свои привычки, где-то поможет компания. Но есть ключевые моменты, с которыми совпадение особенно важно.
В inDrive мы руководствуемся тремя основными принципами, которые называем философией хакерства. Принципы являются базовой линией и помогают нам не сбиться с пути создания большой и классной международной команды inDrive.Tech:
Решать задачи и не отступать от проблем.
Вовлекаться в то, что мы делаем, а не быть простым наблюдателем.
Увлекаться технологиями и знаниями, которые помогают росту компании.
Мы намеренно выбираем людей с подобной философией, чтобы инженеры в наших командах были единомышленниками и максимально эффективно достигали целей.
Комментарии (13)
vovatelbukhov
24.04.2023 14:03+1Базовую потребность эйчаров отвечать кандидатам на их вопросы, а не игнорить забыли :( но я напомнил, не благодарите!
Notte
24.04.2023 14:03«Кем ты видишь себя через пять лет?»
У меня такие вопросы стресса не вызывают после истории, когда меня собеседовал IT-директор и спросил именно этот вопрос. Мой ответ был прост: "Через пять лет я вижу себя IT-директором". Был конфуз, но не с моей стороны.
dyadyaSerezha
А где же такая базовая потребность, как хорошая зарплата?
g_volgin
Хорошая зарплата, безусловно, базовая потребность, но в этой статье мы сконцентрировались на нематериальных вещах)
dyadyaSerezha
Хахаха, я попытался отправить вам свое резюме через сайт Indride.tech, чтобы узнать о зарплате. В короткой форме аппликанта не смог ввести свой сингапурский телефон - пишет красным, что невалидный. Не смог прицепить резюме в docx-формате (почему?? Пишет, что только pdf). Ладно, цепляю в pdf - опять пишет, что не тот размер/тип, хотя все то. В результате послал просто своё имя, имейл и российский виртуальный телефон, благо он есть у меня.
Не нашёл нигде на сайте раздела "contact us", что очень странно. Ладно, пошёл на сайт indrive.com, нашёл форму "contact us", описал проблему, никаких файлов не прицеплял, нажимаю на Submit и.....
Failed to load / An error occurred, please try again / Try again
И так 4 раза подряд. Ребята, ну просто нет слов.... ????
Ubudragon
зато столько заумных не русских слов в статье...
s7eepz
Выглядит как реклама, обычно с действительностью не имеющая ничего общего)
Corsonamor
У вас хотя бы не было кринжового опыта как у меня. Когда они спамили свою вакансию в телеграмме, я отправила им резюме, мне ответили что-то в духе: "сорри, уже не нанимаем" и на следующий день в том канале снова их вакансия.
Казалось бы, если я - недостаточно хороший специалист, то так и ответьте.
Зато теперь видно, что они начинают заботиться о сотрудниках только когда их уже наняли.
g_volgin
Спасибо за обнаруженные баги — сайт недавно вышел в прод, поэтому нам важна любая обратная связь. В форме добавили поддержку .doc- и .docx-файлов, а также увеличили размер файлов до 25 МБ. Также вы можете отправить резюме напрямую нашему рекрутеру на почту plotnikova.olesya@indriver.com
dyadyaSerezha
Я посылал файл размером 250К и он не прошёл. Фича?
А сингапурские телефон пофиксили?
В прод? Кто-нибудь из тестировщиков или разработчиков хоть раз пытался подать заявку на работу через этот сайт??
Кстати, все вакансии похожи, как близнецы, кроме единственного короткого параграфа. Сайт явно делали "для галочки". До прода его пилить и пилить.
Mike-M
Ничего удивительного.
Посмотрите список их вакансий: на примерно полсотни позиций всего один QA Engineer. И тот в разделе "Другое".
Да и что можно ожидать от компании, которая считает, что модель Waterfall "хорошо подходит для стартапов".
frek17
Никого не защищаю, но считаю, что о заработных платах практически не пишут явно, это своего рода табу в наше время. Но думаю, что если есть релокационные пакеты, то с зп проблем не должно быть
g_volgin
Всё верно. Писать «конкурентная заработана плата» — зашквар, писать конкретные суммы — NDA. Релокационный пакет, конечно же, есть, также как и помощь с арендой жилья, ДМС и другие социальные плюшки)