Профили инженеров нужны для того, чтобы оценивать коллег на performance review. Это делает продвижение по карьерной лестнице понятным и прозрачным.
Мы ввели карьерную линейку инженеров с 2024 года, чтобы они лучше отражали действительность, а людям было проще расти.
Стало 7 уровней: E1-E7. Структура команды инженеров горизонтальная, нет прямого подчинения однго уровня инженеров другому, но учитываются роли инженеров (тимлид, эксперт, архитектор). Миссия команды добиваться решение задач бизнеса максимально эффективным путём.
Карьерная лестница — это возможный путь развития инженера в Тетра транс. Он зависит от того, какие задачи решает специалист и какие основные навыки использует в работе.
Для выбора вектора развития и отслеживания прогресса инженер вместе с тимлидом могут составить Windrose навыков на текущем и следующем уровне.
Развиваться можно двумя путями:
-
Как инженер (IC, individual contributor), который делает работу преимущественно руками.
-
Как менеджер, который достигает результата через управление людьми или командами.
Сейчас в Тетра транс существуют такие уровни:
Все профили описаны по блокам:
- Экспертность;
- Инженерная культура;
- Ответственность за результат;
- Ориентация на бизнес;
- Agile Mindset;
- Коммуникация;
- Развитие себя и обучение других.
Двигаться ли по карьерной лестнице — это решение самого сотрудника. Многое зависит от его проактивности и желания учиться. Задача менеджера — помочь специалисту в развитии, например, подключать к новым задачам, давать возможность участвовать в кросс-функциональных проектах.
- Ожидания каждого следующего уровня добавляются к ожиданиям предыдущих. Например, E4-инженеры должны уметь делать всё то же самое, что E1, E2 и E3.
- Сотрудник должен проявить навыки и компетенции на деле. Просто уметь или хотеть делать задачи недостаточно.
- Если менеджер считает, что специалисту в команде не нужен какой-то навык, то его можно не учитывать.
- Уважает коллег. Слышит и учитывает их мнение.
- Аргументирует свою точку зрения.
- Принимает конструктивную обратную связь от коллег, адекватно реагирует на неё.
- Не доводит разногласия до деструктивных конфликтов. Старается разрешить конфликт спокойно, если он произошёл.
- Учитывает интересы и потребности других людей, даже когда они противоречат его собственным.
- Презентует идеи и предложения команде, участвует в обзоре результатов работы.
- Даёт конструктивную обратную связь, подкрепляет её фактами.
- Выбирает подходящие инструменты для коммуникации в разных ситуациях. Например, собирает встречу или создаёт чат в Teams вместо нескольких P2P-обсуждений.
- Договаривается о взаимовыгодном решении, когда стороны видят решение по-разному.
- Модерирует дискуссии, не допускает неэффективных обсуждений.
- В случае не возможности прийти к согласию между двумя сторонами в команде разработки, то выносит обсуждение в чат разработчиков на общее обсуждение
- Фокусируется на развитии инженерных скиллов.
- Слышит и принимает обратную связь от наставника. Корректирует действия в соответствии с ней.
- Получает от наставника чёткие цели на обучение (роадмап). Вместе с ним отслеживает ключевые точки пути — чек-пойнты.
- Берёт в работу задачи, которые раньше не делал, чтобы научиться.
- Перенимает лучшие практики от наставника и коллег.
- Совместно с наставником составил план развития и двигается по чек-пойнтам.
- Самостоятельно находит мотивацию. Двигается по плану развития без напоминаний со стороны менеджера/наставника.
- Изучает лучшие практики разработки и проектирования микросервисной архитектуры.
- Отслеживает динамику развития по тем целям, которые поставил.
- Развивает инженерные навыки и soft skills.
- Терпелив к тем, кто обладает меньшими знаниями и навыками. Поддерживает их.
- Проводит технические интервью, прокачивает навыки интервьюера.
- Занимается онбордингом новичков.
- Делится опытом внутри команды.
- Выступает на внутренних митапах. Делится ценными знаниями с коллегами.
- Прокачивает новых интервьюеров.
- Планирует развитие инженеров младшего уровня с учётом их профилей и целей команды.
- Участвует в Tech PR, выступает на внешних конференциях, пишет статьи в профильные блоги.
- Участвует в создании обучающих курсов и материалов.
- Следит за трендами и самостоятельно изучает новые технологии, которые будут полезны команде. Делится знаниями с командой.
- Выступает на международных конференциях.
- Системно работает над развитием технического уровня всех членов команды в своём функциональном направлении.
- Создаёт сообщества, где все заинтересованные лица могут обмениваться знаниями и вырабатывать решения, или активно участвует в них.
- Решает небольшие задачи из бэклога на 1–2 дня.
- Выполняет полностью декомпозированные задачи с детализацией до кода, который нужно поправить.
- Работает под присмотром наставника.
- Не оценивает потенциальные риски сам, а привлекает для этого наставника. Говорит, если не успевает выполнить задачу. Работает только с не очень важной функциональностью.
- Изучает с наставником лучшие практики, учится писать качественный код или тестировать с помощью существующих моделей.
- Вручную проверяет «зелёные сценарии» работы своей программы и обработку ошибок.
- Синхронизирует план работы и конечную цель. Срок выполнения и ожидаемый результат обсуждает с наставником или командой.
- Выполняет обещанное. Например, делает задачу в срок или своевременно оповещает о проблеме, просит о помощи. Убеждается, что задача соответствует критериям готовности команды, а при завершении — критериям приёмки команды.
- Признаёт ошибки и берёт ответственность за их исправление.
- Вовлекается во все процессы команды.
- Адаптируется к изменениям процессов и приоритетов/целей в команде/компании.
- Решает задачи на 1–2 дня c подробным объяснением, что и как делать.
- Декомпозирует задачи и пишет код в основном самостоятельно. Если нужно, привлекает наставника.
- Работает с важной функциональностью под присмотром наставника.
- Предупреждает, если не успевает в срок.
- При разработке применяет лучшие практики и стандарты разработки.
- Не изобретает велосипед.
- Контролирует, как решение работает в проде, например смотрит мониторинги. Если возникают аномалии, спрашивает мнение наставника.
- Обращается к наставнику, чтобы выбрать оптимальный способ проверки качества и безопасности задач.
- Выясняет цель и ценность задачи, над которой работает.
- Своевременно говорит о том, что требует улучшения, и не замалчивает проблемы.
- Самостоятельно решает задачи на спринт из бэклога в своём домене. Code Review для него проводит эксперт уровня E4 и выше.
- Декомпозирует задачи в виде: «Нужно передавать тарифы из А в Б», а не «Нам нужен сервис, чтобы передавать данные». Иногда просит помочь старших коллег в декомпозиции больших задач.
- Самостоятельно оценивает риски и работает с важной функциональностью.
- Проверяет свой код и его влияние на работоспособность остальных систем.
- Выбирает оптимальный способ проверки качества задач. Использует подходящие виды тестирования.
- Использует принятые в компании инструменты и технологии.
- Валидирует новые технические решения или подходы с ответственными за проект специалистами.
- Консультируется с коллегами для выбора безопасных подходов к реализации функциональности.
- Избегает распространённых уязвимостей безопасности (OWASP) при решении задач.
- Добавляет метрики при реализации задач. Мониторит их после релиза.
- Анализирует проблемы и исправляет их видимые симптомы
- Проверяет «зелёные» (функциональность работает так, как ожидалось) и «красные» (не работает так, как ожидалось) сценарии.
- Просит помощи у опытных коллег, когда нужно сделать дизайн-ревью решения.
- Проактивно говорит о проблемах во время спринта. Вместе с командой ищет выход из ситуации.
- Делает всё, чтобы команда достигла цели спринта. Помогает коллегам, если может, и просит помощи, когда она нужна.
- Понимает, как задачи бэклога влияют на бизнес-метрики юнита.
- Интересуется обратной связью от пользователей и обсуждает её с командой. Разбирается с проблемами в своей зоне ответственности. Например, ищет причину, если в общий канал зарепортили баг.
- Описывает для пользовательских историй/задач критерии приёмки и корнер-кейсы.
- Ставит успех команды выше личных целей.
- Предлагает помощь коллегам, если она нужна.
- Ищет способы повысить эффективность своей работы. Составляет план действий.
- Декомпозирует задачи. Умеет оценивать технические риски. Предлагает меры по их смягчению или устранению.
- Работает с неопределённостью, например открытыми задачами в своей области ответственности. Понимает, что нужно сделать, но может не понимать, как.
- Делает проекты на несколько спринтов.
- Анализирует проблемы, которые возникают в продакшене. Может их разрешить. Старается докопаться до сути и решить корневую проблему. Предлагает и продвигает способы предотвращения рецидивов.
- Умеет проектировать независимые компоненты так, чтобы они были простыми, тестируемыми и поддерживаемыми.
- Понимает, как задачи могут повлиять на другие команды/сервисы. Уведомляет коллег об изменениях, которые планирует внести.
- Ведёт технический бэклог и/или роадмап команды/юнита/проекта.
- Разрабатывает стандарты качества кода, тестирования, безопасности, отказоустойчивости.
- Даёт содержательные комментарии на Code Review.
- Находит баланс между скоростью и качеством разработки/тестирования.
- Самостоятельно находит ответы на вопросы по техническим метрикам.
- Вместо долгой разработки создаёт или предлагает владельцу продукта прототип. На прототипе проверяет гипотезы или новое техническое решение.
- Документирует технические решения и поддерживает документацию команды в актуальном состоянии.
- Отвечает за проект. Находит мотивацию чинить, договариваться, мониторить и отвечать за всех, как и за свои задачи.
- Убеждается, что цели команды прокачивают продукт и позитивно влияют на пользователей. Помогает формировать бэклог, исходя из ценностей компании.
- Помогает владельцу продукта декомпозировать крупные фичи на набор полезных инкрементов, которые можно релизить независимо.
- Помогает коллегам из поддержки или из других юнитов. Умеет приоритизировать запросы и давать обратную связь. Объясняет причину, если не может помочь коллегам сразу.
- Пользуется продуктом компании, предлагает UX или продуктовые улучшения на основе своего опыта
- Самостоятельно находит ответы на простые вопросы по продуктовым метрикам.
- Предлагает улучшения и берёт на себя ответственность, если видит проблему в процессах или при реализации задач.
- Декомпозирует проблемы или бизнес-сценарии в решениях, которые состоят из нескольких компонентов.
- Локализует/предотвращает проблемы и ошибки в функциональности своей команды. Даже если они связаны с изменениями, которые внесли другие команды.
- Находит и решает проблемы с внешними зависимостями проекта.
- Улучшает общие инженерные инструменты компании.
- Тестирует сложные корнер-кейсы.
- Проектирует тестопригодные системы и исправляет те, которые сложно тестировать.
- Ищет неэффективные места в коде/архитектуре/тестовых моделях. Пополняет технический бэклог команды.
- Устанавливает и тестирует нефункциональные требования или привлекает для этого экспертов.
- Знает и использует безопасные подходы к реализации функциональности.
- Регулярно выступает в роли фича-лида. Отвечает за полную реализацию фичи: декомпозицию, контроль сроков и качества, доставку до пользователей.
- Работает прозрачно, разрешает техническую неопределённость для коллег и стейкхолдеров.
- Интересуется обратной связью от пользователей и обсуждает с командой инсайты.
- Предлагает альтернативные способы проверки гипотез и технических решений, которые позволят получить данные быстрее или с меньшими затратами.
- Выполняет работу смежных ролей (T-shaping), которые нужны команде.
- Берёт на себя дополнительные роли в команде, например, скрам-мастера, секьюрити-чемпиона.
- Предлагает и реализует улучшения для инженерных процессов в команде.
- Берёт задачи с высокой степенью неопределённости, в которых нет образа результата и непонятно, что нужно сделать. Исследует, анализирует, сравнивает альтернативы и предлагает решение.
- Видит большую картинку в целом (бэк, фронт, мобильные приложения, базы), когда прорабатывает решение.
- Ведёт кросс-юнитные, квартальные и более длительные и масштабные проекты.
- Применяет широкий круг библиотек, платформ и систем на экспертном уровне.
- Оценивает долгосрочные технические риски и предлагает способы их предотвращения.
- Знает, в каких случаях стандартные инструменты и технологии будут неэффективными. Анализирует и находит альтернативные решения.
- Системно контролирует величину технического долга. Не допускает, чтобы техдолг затормозил процесс разработки. Доносит до владельца бэклога ценность технических изменений.
- Системно выявляет небезопасные подходы и/или уязвимости в рамках Code Review и в своих задачах.
- Даёт коллегам качественную обратную связь по сложным темам. Задаёт правильные вопросы. Использует аргументы, которые подтверждают выбранное решение и вскрывают ошибочные предположения.
- Выступает как фича-лид проектов, которые длятся больше квартала.
- Отвечает за техническую реализацию проекта и работу других членов команды. Отвечает за доставку фичи до конечных пользователей.
- Организует нужных людей под конкретный стрим, проводит груминги (подумать над формулировкой (это процесс обновления журнала невыполненных работ по продукту на основе отзывов или меняющихся требований)) и погружает в контекст.
- Убеждается на продуктовых метриках, что бизнес-задача решена.
- Следит за продуктовыми метриками своей команды. Организует их мониторинг, реагирует в случае непредвиденных колебаний. Добавляет новые метрики, если чего-то не хватает.
- Проектирует техническю архитектуру, которой пользуются другие инженеры.
- Создаёт и внедряет новые подходы и технологии в рамках компании. Оценивает их пользу и применимость.
- Синхронизирует новую технологию со всеми стейкхолдерами и платформенными командами. Следит за всем жизненным циклом, адаптацией и внедрением технологии, анализирует обратную связь по ней.
- Ведёт актуальную и понятную техническую документацию по продукту для инженеров.
- Владеет техническим бэклогом и роадмапом продукта.
- Устанавливает метрики успеха продукта и регулярно следит за ними.
- Следит за метриками удовлетворённости пользователей.
- Обеспечивает прозрачность планов и приоритетов для стейкхолдеров и пользователей продукта.
- Хорошо знает потребности пользователей продукта и бизнес-контекст команды.
- Может обосновать, как продукт влияет на бизнес и продуктовые метрики компании.
- Помогает дискавери- и деливери-командам вырабатывать технологические решения, которые доставляют максимальную ценность до пользователей.