Профили инженеров нужны для того, чтобы оценивать коллег в соответствии с их уровнем на performance review и сделать продвижение по карьерной лестнице понятным и прозрачным.
Карьерная лестница — это возможный путь развития инженера в Авито в зависимости от того, какие задачи он решает, и какие основные скиллы при этом использует.
Развиваться можно двумя путями:
- Как инженер (IC, individual contributor), который делает работу преимущественно своими руками, высшая ступень эволюции.
- Как менеджер, который достигает результата через управление людьми или командами.
В настоящий момент у нас в Авито существуют такие уровни:
Все профили описаны по блокам:
- Экспертность
- Инженерная культура
- Ответственность за результат
- Ориентация на бизнес
- Agile Mindset
- Коммуникация
- Развитие себя и обучение других
Карьерное движение не происходит автоматически. Двигаться или нет по карьерной лестнице – это решение и ответственность самого сотрудника. Многое зависит от его проактивности, желания учиться, приобретать новые знания и навыки и (самое главное) брать на себя большую ответственность. Задача менеджера – помочь сотруднику в развитии, например, подключать к новым задачам, давать возможность для участия в кросс-функциональных проектах.
- Ожидания каждого следующего уровня добавляются к ожиданиям предыдущих. Например senior должны уметь делать всё тоже самое что и intern, junior и middle.
- Сотрудник обязательно должен проявить навыки и компетенции своего или следующего профиля на деле. Просто уметь или хотеть делать не достаточно.
- Если менеджер считает, что в команде нет и не будет бизнес необходимости делать что-то, что описано в профиле, например выступать на конференции или обучать новичков, то эти критерии можно не учитывать.
- Решает небольшие задачи из бэклога под руководством наставника.
- Привлекает наставника для оценки потенциальных рисков.
- Изучает с наставником лучшие практики Авито, учится писать качественный код или тестировать используя существующие тестовые модели.
- При планировании работы синхронизирует конечную цель и ожидаемый результат с наставником.
- Выполняет обещанное. Например, выполняет взятую задачу в срок или своевременно оповещает о проблеме, просит о помощи.
- Признает ошибки и берет ответственность за их исправление.
- Выясняет цель и ценность выполнения задачи над которой он работает.
- Вовлеченный участник всех процессов команды.
- Адаптируется к изменениям процессов в команде/компании.
- Адаптируется к изменениям приоритетов/целей.
- Говорит о вещах, которые требуют улучшения и не «замалчивает» проблемы.
- Руководствуется принципом just talk. Понимает, что общение наиболее эффективный и практичный способ обмена информацией.
- Уважает коллег.
- Гибок в общении — слышит коллег, учитывает их мнение.
- Аргументирует свою точку зрения
- Принимает решения учитывая интересы и потребности других людей даже когда они противоречат его собственным.
- Делает выводы для себя на основе обратной связи.
- Совместно с руководителем ставит себе четкие цели на обучение.
- Быстро обучается. Активно задает вопросы, чтобы учиться.
- Берет задачи в работу, которые раньше не делал, чтобы научиться.
- Решает такие же задачи из бэклога как и middle инженеры.
- Оценивает потенциальные риски.
- Привлекает наставника при необходимости.
- Улучшает свой код по замечаниям на code review. Не повторяет одинаковых ошибок.
- Вручную проверяет «зелёные сценарии», обработку ошибок.
- Пишет авто-тесты на свой код, консультируется с наставником насчёт выбора оптимального способа проверки качества и безопасности задач.
- При планировании работы согласует с автором/командой:
- как поймём, что задача успешно выполнена? (acceptance criteria)
- как будет проверена работоспособность?
- как результат будет продемонстрирован?
- когда задача будет выполнена?
- Формирует с командой цель на спринт. Связывает её с целями юнита и компании на текущий квартал.
- Проводит обзор результатов работы фича-команды.
- Вовлеченный участник всех процессов команды.
- Адаптируется к изменениям процессов в команде/компании.
- Адаптируется к изменениям приоритетов/целей.
- Говорит о вещах, которые требуют улучшения и не «замалчивает» проблемы.
- Руководствуется принципом just talk. Понимает, что общение наиболее эффективный и практичный способ обмена информацией.
- Уважает коллег.
- Гибок в общении — слышит коллег, учитывает их мнение.
- Аргументирует свою точку зрения.
- Принимает решения учитывая интересы и потребности других людей даже когда они противоречат его собственным.
- Делает выводы для себя на основе обратной связи.
- Совместно с руководителем ставит себе четкие цели на обучение.
- Быстро обучается. Активно задает вопросы, чтобы учиться.
- Берет задачи в работу, которые раньше не делал, чтобы научиться.
- Самостоятельно решает задачи из бэклога.
- Степень неопределённости невысокая (понятно что нужно сделать, может быть непонятно как). Работает с неопределённостью — проводит ресерчи, собирает информацию.
- Самостоятельно оценивает риски в знакомом функционале. В незнакомом функционале привлекает эксперта для оценки рисков.
- Анализирует возникающие проблемы, старается докопаться до сути и решить корневую проблему. Предлагает и продвигает превентивные решения для предотвращения рецидивов.
- Тестирует нефункциональные требования или привлекает для этого экспертов.
- Проводит Code Review коллег, способствуя тому, чтобы вливаемый код соответствовал лучшим практикам Авито, был тестопригодным, безопасным и поддерживаемым.
- Пишет автотесты на свой код учитывая «пирамиду тестирования» команды. Систематически увеличивает покрытие кодовой базы автотестами.
- Выбирает оптимальный способ проверки качества задач. Использует подходящие виды тестирования.
- Находит баланс между скоростью разработки/тестирования и качеством.
- При реализации или внедрении новых технических решений или подходов валидирует их с ответственными.
- При решении своей задачи, улучшает общие инженерные инструменты компании или даёт конструктивный фидбек их владельцам.
- При разработке придерживается подходов KISS и DRY.
- Устраняет/избегает распространенных уязвимостей безопасности (OWASP) при решении своих задач.
- Проактивно консультируется с коллегами для выбора безопасных подходов к реализации разрабатываемой функциональности.
- При реализации задач добаляет необходимые метрики и мониторит их после релиза.
- Самостоятельно находит ответы на вопросы по техническим метрикам (например: какая нагрузка на мой сервис? какой 99й перцентиль времени ответа?)
- Вместо долгой разработки создает или предлагает владельцу продукта MVP для проверки гипотезы или нового технического решения.
- Берет ответственность за доставку задачи до пользователей. Выходит за рамки просто разработки/тестирования. На всех этапах следит за задачей и помогает её продвижению. Не использует оправдание «На моей машине работает и ОК». Сразу подсвечивает возникающие блокеры и предлагает варианты решения.
- При планировании работы знает на какие команды может повлиять задача и говорит об этом.
- Регулярно интересуется фидбэком пользователей (читает user voice, отчёты поддержки, результаты пользовательских исследований, спрашивает у руководителя или продукт менеджера) и обсуждает с командой полученные инсайты.
- Отслеживает прогресс по целям юнита/команды в течение квартала (вместе с командой).
- Декомпозирует крупные фичи на набор полезных инкрементов, которые можно релизить независимо (например user story).
- Самостоятельно находит ответы на простые вопросы по метрикам (Сколько подач в категории Запчасти совершают в среднем за день пользователи с Андроид?)
- Ставит успех команды выше личных целей. Например:
- Берёт на себя роль scrum-мастера или проводит scrum-встречи в его отсутствие.
- При выборе задачи над которой будет работать выбирает ту которая приближает команду к результату, а не ту которая нравится.
- T-shaping в соседние функции, которые нужны команде/компании.
- Не говорит, что это работа менеджера, а моя только кодить.
- Предлагает свою помощь коллегам, если видит что она нужна.
- Анализирует как улучшить эффективность своей работы. Проводит разборы что было хорошо и что улучшить, выходит в действия.
- Улучшает процессы в фича команде. Например:
- Систематизирует результаты ретроспектив и трекает выполнение договорённостей.
- Проводит регулярные (например каждый спринт) или тематические (например по проекту или конкретной проблеме) ретроспективы. Ретроспектвы приводят к значимому улучшению рабочего процесса.
- Не доводит разногласия до деструктивных конфликтов.
- Если конфликт произошел-решает его, привлекая руководителя если нужно.
- Презентует свои идеи и предложения и результаты на группу или аудиторию (выступления на общих встречах).
- Дает конструктивную и развивающую обратную связь, подкрепленную фактами.
- Планирует свое развитие с учетом планов развития продукта и ближайших целей команды. Например
- Учит новые языки программирования (Go, Kotlin) на которые переходит компания.
- Изучает лучшие практики разработки и проектирования микросервисной архитектуры.
- Следит за последними трендами в своей области технологий.
- По итогам обучения отслеживает динамику развития по тем целям, которые поставил.
- Проявляет терпение к тем, кто обладает меньшими знаниями, умениями и навыками.
- Делится своей экспертизой внутри команды.
- Онбордит новичков
- Степень неопределённости высокая. Непонятно что нужно сделать (нет образа результата). Берёт проблему, проводит исследование, сравнивает альтернативы и предлагает решение. Спектр решений широкий и заранее неопределенный. Примеры проблем:
- Приложение должно работать быстрее конкурентов.
- Что нам нужно сделать для автоматического заполнения параметров объявления на основе технических характеристик?
- Как протестировать сервис прайсинга или item storage?
- При принятии решений анализирует и минимизирует возможные риски и негативные последствия. Например
- При проектировании тестовой модели учитывает как работает Авито в целом.
- При добавлении нового сервиса/метода в цепочку вызовов анализирует как это скажется на общем времени ответа.
- Cовместно с командой реализует проекты в максимально короткие сроки, заботится об уменьшении time to market
- Ведёт технический бэклог и/или дорожную карту (roadmap) команды/юнита/проекта
- Разрабатывает стандарты качества кода, тестирования, безопасности, отказоустойчивости и других NFR (Non-functional requirements), а также занимается внедрением/улучшением соответствующих процессов и инструментов.
- Проактивно ищет неэффективные места в коде/архитектуре/тестовых моделях. Пополняет технический бэклог команды и доносит до владельца бэклога ценность технических изменений.
- При примении новых технологий в рамках своей задачи критически оценивает их пользу и применимость в юните.
- При проектировании больших или высоконагруженных систем проводит защиту на Архитектурном Комитете
- Системно контролирует количество технического долга. Может его оценить. Не допускает ситуации, когда он начнёт тормозить процесс разработки и начнёт мешать вносить изменения.
- В рамках Code Review и в процессе выполнения своих задач выявляет небезопасные подходы и/или уязвимости
- Знает и выбирает изначально безопасные подходы к реализации разрабатываемой им и командой функциональности.
- Берёт ответственность не только за себя, но и за работу других в рамках своей задачи/проекта (отвечает за проект).
- Работает над небольшими проектами размером до 1 квартала.
- Как технический владелец проекта планирует и согласовывает работу над ним других членов команды или внешних экспертов.
- Ставит с командой цель (OKR) на квартал. Связывает её с целями юнита, кластера, компании.
- При проработке задач предлагает альтернативные способы проверки гипотез и технических решений, позволяющие получить данные быстрее/с меньшими затратами.
- Делает базовые выводы по результатам проведенного исследования (например делает базовые выводы по а/б тестам: статистически значимый результат или нет; тест показывает плохие результаты на метриках, его нужно остановить). "Подсвечивает" найденные проблемы или успехи.
- Исследует проблемы пользователей и помогает заказчику найти бизнес решение (например: участвует в дискавери спринтах в роли продукт менеджера).
- Системно улучшает процессы в команде/юните.
- Имеет видение целевой модели команды. Знает какой результат хочет получить.
- Формирует план развития команды. Ведёт бэклог для достижения целевой модели команды.
- При поиске и решении проблем выходит за рамки фича-команды, ищет системные проблемы на уровне юнита.
- Договаривается, используя стратегию "Win-Win" (Сотрудничество).
- Во время обсуждений стимулирует высказывание различных точек зрения и использует их при формировании окончательного решения.
- Наставничество Intern, Junior и Middle. Планирует их развитие с учётом профилей инженеров и целей команды.
- Помогает коллеге закрепить полученные знания на практике и перевести в навык.
- Участвует в TechPR. Выступает на внешних конференциях, пишет статьи в профильные блоги.
- Придумывает, исследует и планирует развитие большого технического проекта.
- Бэкэнд архитектура всего функционала BuyerX (serp, карточка, фильтры, рубрикатор, url builder)
- Архитектура мессенджера.
- Привлечение краудсорсинга к тестированию.
- Фрейморк для написания e2e & компонентных тестов, для снижения ручных проверок мобильных приложений и переводу запуска тестов ближе к разработчику.
- Визионерство. Следит за глобальными технологическими трендами и может сделать прогноз с определённой долей вероятности.
- Внедряет новые подходы и технологии в рамках компании. Оценивает их пользу и применимость.
- Работает над средними проектами размером в 2-4 квартала.
- Как технический владелец проекта планирует и согласовывает работу над ним других команд/юнитов или внешних экспертов.
- Находит технические проблемы, мешающие бизнесу развиваться сейчас или грозящие в ближайшем будущем.
- Планирует и проводит необходимые исследования (например: сплит-тесты, опросы, опыт других компаний) для проверки реальности проблем/пользовательских болей.
- Использует результаты проведённых исследований для аргументации важности предлагаемых решений.
- При работе над задачами учитывает цели юнита и компании на горизонте 1 года и больше.
- Вместе с техническим руководителями формирует техническую стратегию кластера.
- Системно улучшает процессы в кластере/компании.
- Проводит большие ретроспективы состоящие из нескольких юнитов или всего кластера.
- При поиске и решении проблем выходит за рамки команды/юнита, ищет системные проблемы на уровне кластера/организации.
- Договаривается, используя стратегию "Win-Win" (Сотрудничество).
- Во время обсуждений стимулирует высказывание различных точек зрения и использует их при формировании окончательного решения.
- Наставничество Senior.
- Разрабатывает внутренние или внешние курсы и ведёт их как преподаватель.
- Создатель/мэйнтейнер систем/решений, которые влияют на уровне cообщества. Компания получает ощутимые конкурентные преимущества за счёт этого.
- Способен инициировать и реализовывать крупные инициативы уровня компании. Примеры: переход от монолитной архитектуры к микросервисной.
- Анализирует возникающие проблемы, старается докопаться до сути и решить корневую проблему. Предлагает и продвигает превентивные решения для предотвращения рецидивов. Отличается от Lead и Senior масштабом. Principal думает про весь Авито целиком целиком, а не про какую-то отдельную область.
- Внедряет новые подходы и технологии в рамках компании. Оценивает их пользу и применимость.
- Работает над большими проектами размером в 1 год или больше.
- Как технический владелец проекта планирует и согласовывает работу над ним других юнитов/кластеров или внешних экспертов.
- Находит технические проблемы, мешающие бизнесу развиваться сейчас или грозящие в ближайшем будущем.
- Планирует и проводит необходимые исследования (например: сплит-тесты, опросы, опыт других компаний) для проверки реальности проблем/пользовательских болей.
- Использует результаты проведённых исследований для аргументации важности предлагаемых решений.
- При работе над задачами учитывает цели юнита и компании на горизонте 1 года и больше.
- Вместе с техническим руководителями формирует техническую стратегию кластера.
- Системно улучшает процессы в кластере/компании.
- Проводит большие ретроспективы состоящие из нескольких юнитов или всего кластера.
- При поиске и решении проблем выходит за рамки команды/юнита, ищет системные проблемы на уровне кластера/организации.
- Договаривается, используя стратегию "Win-Win" (Сотрудничество).
- Во время обсуждений стимулирует высказывание различных точек зрения и использует их при формировании окончательного решения.
- Евангелист внутренних технических продуктов для разработчиков компании или наших open-source продуктов за пределами компании.