Есть много хороших статей о возможных карьерных путях, которые вы можете выбрать в сфере ИТ. Я не видел много статей, которые можно было бы использовать в качестве реального руководства для продвижения по карьерной лестнице. Практически в любой более или менее зрелой ИТ-компании обычная карьерная траектория для инженера-программиста линейна. Дальнейшая карьерная траектория будет зависеть от ваших наклонностей, того, что вам нравится делать, и того, готовы ли вы к изменению своего способа работы.
Существует множество хороших статей о возможных карьерных путях, которые можно реализовать в сфере ИТ, однако я не видел многих из них, которые можно было бы использовать в качестве реального руководства для продвижения по карьерной лестнице.
В настоящее время я работаю в компании, которая предъявляет очень четкие требования к продвижению инженеров и что может быть использовано в качестве достаточного доказательства выполнения этих требований. Сочетание этих двух факторов натолкнуло меня на мысль, что дополнительная информация по этой теме может помочь другим инженерам, работающим в компаниях, где ее нет, выстроить стратегию, которая позволит им перейти на следующий уровень.
Практически в любой более или менее зрелой ИТ-компании обычная карьера инженера-программиста линейна и выглядит примерно одинаково:
Должность младшего инженера-программиста необязательна и может быть представлена или не представлена в общей структуре ИТ-отдела по очень простой причине: в течение первых 12 месяцев она приносит отрицательный доход, поскольку требует большого контроля, поэтому не у всех компаний есть ресурсы и время, чтобы допускать такие должности в свою структуру.
Дальнейший карьерный путь будет зависеть от ваших наклонностей, того, что вам нравится делать, и того, готовы ли вы к изменению подхода к работе.
Нет ничего плохого в том, чтобы оставаться старшим инженером-программистом, если вы хотите посвящать большую часть своего времени кодированию. Однако, если вы чувствуете необходимость уполномочить других и руководить, то это подходящий момент, чтобы взвесить все ожидания от каждой роли, свои сильные стороны, то, что вами движет, и выбрать наиболее подходящий для себя путь.
Несмотря на визуальную простоту треков выше, неясно, как приблизиться к правильному концу. Следующие идеи будут применимы к компаниям, которые:
иерархическая структура, в которой у каждого работодателя есть линейный руководитель
искренний интерес к развитию сотрудников
Почему вышеперечисленное важно? Ответ довольно прост: с первого дня у вас есть союзник - ваш непосредственный руководитель .
Эффективность каждого линейного менеджера основана на результатах каждого подчиненного ему человека: чем быстрее вы растете, тем больше ваш результат, тем выше эффективность линейного менеджера. Учитывая все это, рано или поздно, после того как вы присоединитесь к своей компании, ваш линейный менеджер подойдет к вам с вопросом: «Где вы видите себя через определенное время?» Если этого не происходит и у вас есть регулярные личные встречи, смело добавляйте это в качестве темы для обсуждения в повестку дня.
Озвучивание своих намерений и постановка цели — это только первый шаг на вашем пути. Следующий шаг — собрать список требований для более высокой роли и составить список достижений, которые могут служить доказательством вашей квалификации, которые вы можете использовать в качестве руководства, которому следует следовать, чтобы добраться из точки А в точку Б. В компаниях с прозрачными процессами продвижения это должно быть уже сделано.
Если это не так, вы и ваш менеджер можете составить его. Помните, что этот процесс выгоден для обеих сторон: вы получаете соглашение, что после определенных достижений вас похвалят и повысят в должности, а ваш линейный менеджер может получить более высокую производительность от команды, так что это беспроигрышный вариант.
У разных компаний могут быть разные требования к определенным должностям, и я не буду утверждать, что нижеперечисленные являются универсальными и подойдут всем. Основная цель — дать вам представление о том, как это может выглядеть, если вам нужно то, что можно дополнительно подстроить под ваши потребности.
Руководящие принципы для доказательств можно использовать как дорожную карту, которая приведет вас к желаемому пункту назначения. Следующие шаги для общего пути могут быть
Проверьте дорожную карту команды на предмет подходящих проектов или запросов на изменение, которые могут соответствовать цели доказательства.
Озвучьте свои намерения непосредственному руководителю, чтобы он мог помочь с распределением проекта по подходящим параметрам и предоставить информацию о его приоритетности, ценности для бизнеса и о том, когда его можно будет взять на разработку.
Определите любые потенциальные области для улучшения кода, наблюдаемости, расширяемости и перспектив безопасности и вынесите их на рассмотрение в качестве заявок на владение.
Ознакомьтесь с текущим процессом подбора персонала в вашей компании и попросите о сопровождении во время сессий по подбору персонала. Попросите поменяться ролями, где кто-то более старший будет сопровождать вас, и попросите дать обратную связь.
Вот краткий список ролей, которые будут охвачены требованиями/руководствами по доказательным перспективам:
Общий трек
Требования к младшему инженеру-программисту
Требования к инженеру-программисту
Требования к старшему инженеру-программисту
Инженерное направление
Требования к ведущему инженеру
Требования к старшему инженерному руководителю
Трек управления
Менеджер по инжинирингу
Технический директор
Требования к младшему инженеру-программисту
Область
Требования
Руководящие принципы для доказательств
Доставка
Выполняет задачи · Нужны четкие требования (бизнес и система) · Разрабатывает/реализует технические решения ограниченного масштаба · Требуется ограниченное руководство
1. Список выполненных задач o Задачи должны быть достаточно сложными, чтобы их можно было упомянуть o Сроки соблюдены o Никаких серьезных проблем с качеством. o Задачи были выполнены без посторонней помощи 2. Ввод от линейного руководителя, подтверждающий, что все требования выполнены.
Качество
Применяет лучшие практики · Изучает и постоянно применяет передовой опыт · Умение работать с различными инструментами разработки · Расследует и устраняет сложные проблемы/ошибки
Отзывы от непосредственного руководителя и коллег, подтверждающие, что все требования выполнены.
Требования к инженеру-программисту
Область
Требования
Руководящие принципы для доказательств
Доставка
Предоставляет запросы на изменение (функции) · Принимает бизнес-требования в качестве входных данных · Разбивает работу на задачи с достаточной степенью детализации решения (что необходимо сделать и когда это будет сделано) и реализации (как это должно быть сделано) · Предоставляет точные оценки на уровне задачи/пользовательской истории · Объединяется с другими инженерами для более быстрой поставки
Список отправленных запросов на изменение, соответствующих следующим требованиям: 1. Запрос на изменение был полностью доставлен, и срок был соблюден. 2. Часть по обнаружению была выполнена сотрудником (билеты, сметы). 3. Запрос на изменение достаточно сложен с технической точки зрения (более 2 человеко-недель для его реализации одним инженером). 4. Запрос на изменение оказывает значимое влияние на бизнес. 5. Запрос на изменение подписан предприятием и запущен в производство. 6. Сотрудник продемонстрировал достаточный уровень самостоятельности и качества (на основании отзывов технического руководителя и менеджера по инжинирингу).
Проектирование системы
Дизайн-услуги · Разрабатывает и реализует более мелкие сервисы, принимая во внимание все нефункциональные аспекты (расширяемость, безопасность, наблюдаемость и т. д.) · Пишет высококачественный код с полным применением инженерных практик и методологий · Участвует в обзорах кода для внедрения передовых практик · Устраняет основные причины ошибок и возникающих проблем.
Не менее двух услуг, разработанных в соответствии со следующими требованиями: 1. Это может быть новая услуга или полная переработка существующей услуги. 2. Это может быть автономная служба, библиотека или компонент, используемый другими службами. 3. Услуга не должна быть тривиальной с точки зрения дизайна. 4. Инженер должен был следовать формальному процессу проектирования: · Получить бизнес-требования и системные требования · Определите ограниченный контекст · Определить нефункциональные требования · Разбить контекст на услуги · Получите отзыв о решении · Реализовать это 5. Сервис внедрен и запущен в эксплуатацию.
Старший инженер-программист
Область
Требования
Руководящие принципы для доказательств
Доставка
Обеспечивает фазы проекта (эпики) · Принимает требования и высокоуровневый дизайн системы в качестве входных данных · Создает проект системы для услуги или компонента, принимает решение о технологиях и инженерных методах, которые будут использоваться · Разбивает работу на задачи или пользовательские истории с достаточным уровнем детализации решения (что необходимо сделать и когда это будет сделано) и реализации (как это должно быть сделано) · Предоставляет точные оценки на уровне задач/пользовательской истории · Руководит небольшой командой по выполнению поставленной задачи · Разблокирует свою команду, решает проблемы и устраняет препятствия
Список выполненных этапов/эпопей проекта, соответствующих следующим требованиям: 1. Эпическая/проектная фаза полностью выполнена, сроки соблюдены. 2. Часть по обнаружению была выполнена сотрудником (билеты, сметы). 3. Фаза эпика/проекта достаточно сложна с технической точки зрения (требует не менее 2 инженеров на >= 2 недели). 4. Эпическая/проектная фаза оказывает существенное влияние на бизнес. 5. Функциональность одобрена бизнесом и запущена в эксплуатацию. 6. Сотрудник продемонстрировал достаточный уровень самостоятельности и качества (на основании отзывов технического руководителя и менеджера по инжинирингу). 7. Инженер принимал участие во внедрении в качестве технического руководителя.
Проектирование системы
Проектирует подсистемы · То же самое, что и у инженера-программиста, но фокусируется на более сложных сервисах или подсистемах. · Знание проектирования и внедрения облачных и распределенных систем
Не менее 3 услуг, разработанных в соответствии со следующими требованиями: 1. Это может быть новая услуга или полная переработка существующей услуги. 2. Это может быть автономная служба, библиотека или компонент, используемый другими службами. 3. Услуга не должна быть тривиальной с точки зрения дизайна. 4. Инженер должен был следовать формальному процессу проектирования: а. Получить бизнес-требования и системные требования б) Определить ограниченный контекст в) Определить нефункциональные требования г. Разбить контекст на службы е. Получите отзыв о решении е. Реализовать это 5. Сервис внедрен и запущен в эксплуатацию.
Движущие изменения
Предлагает изменения · Ставит под сомнение статус-кво и сделанные предположения · Найти способы улучшить платформу, процессы, рабочую среду и техническую команду в целом.
Было предложено не менее трех существенных изменений, которые могут быть любыми из следующих: 1. Функциональность: предложенный запрос на изменение, который был расставлен по приоритетам и реализован (запрос на изменение должен быть достаточно существенным, чтобы его можно было рассматривать как изменение, а не как косметическое изменение). 2. Люди: интервью с инженером, который был принят на работу и прошел испытательный срок (младший инженер-программист или выше, рассматривается как изменение в команде). 3. Право собственности: предложен проект права собственности (включен в дорожную карту права собственности, одобрен техническим директором).
Требования к ведущему инженеру
Область
Требования
Руководящие принципы для доказательств
Доставка
Технический руководитель проектов (проектные предложения) · Принимает бизнес-требования в качестве входных данных · Найти наиболее эффективное решение для бизнес-проблемы (исследовать альтернативы, проверить решения с использованием подходов «без кода» или «с малым кодированием») · Создает системный проект для новой услуги или подсистемы, принимает решение о технологиях и инженерных методах, которые будут использоваться · Разбивает работу на этапы с достаточной степенью детализации решения (что необходимо сделать и когда это будет сделано) и реализации (как это должно быть сделано) · Предоставляет точные оценки на уровне проекта, придерживается сроков · Выступает в качестве технического руководителя всего проекта · Разблокирует свою команду, решает проблемы и устраняет препятствия · Управляет технологическими, реализационными и операционными рисками
Список реализованных проектов, соответствующих следующим требованиям: 1. Решение проблемы было предложено сотрудником и считается эффективным. То есть было оценено несколько альтернатив, и на основе проверки low-code/no-code была выбрана лучшая альтернатива. 2. Часть по обнаружению была выполнена сотрудником (билеты, сметы). 3. Решение было разработано сотрудником. 4. Проект должен быть «особенным» проектом, инициированным посредством проектного предложения. 5. Инженер участвовал во внедрении в качестве технического руководителя (более подробную информацию см. в столбце «Требования»).
Движущие изменения
Проводит технические изменения (команда) · Предлагает и реализует инициативы по улучшению качества системы и сокращению технического долга · Предлагает и внедряет изменения для улучшения опыта и производительности разработчиков · Пропагандирует и обеспечивает соблюдение чистого кода и чистой архитектуры
Список внесенных основных изменений (обычно не менее четырех), соответствующих следующим требованиям: 1. Изменение обеспечивает существенное улучшение качества системы (например, улучшение платформы), опыта разработчиков или производительности разработчиков. Изменение влияет на весь отряд. 2. Инженер не обязательно должен быть тем, кто предложил изменение. Инженер должен быть основной движущей силой изменения (например, разрабатывать, выступать в качестве технического руководителя, участвовать в реализации). Изменение может быть реализовано инженером или в рамках командных усилий. 3. Изменение должно быть полностью реализовано и использоваться отрядом/платформой (изменение должно быть «липким» и обеспечивать достаточную ценность, чтобы его сохранить). 4. Изменение должно быть достаточно значительным, чтобы о нем упомянуть.
Люди
Наставник · Наставляет и поддерживает менее опытных инженеров · Эффективно проводит технические интервью · Действует как «магнит» для хороших инженеров во время найма (становится решающим фактором, когда мы конкурируем за хорошие таланты с другой компанией)
Возможные доказательства: 1. Проведено собеседование с инженерами, которые были приняты на работу и прошли испытательный срок. 2. Отзывы от высококвалифицированных инженеров. 3. Организуются/проводятся обучающие сессии для всей технической команды (например, Tech Sync, Engineering Dojo). 4. При руководстве рабочей группой в качестве доказательства может быть использован список изменений, предложенных/внедренных в сферу деятельности рабочей группы.
Старший инженер-руководитель
Область
Требования
Руководящие принципы для доказательств
Доставка
Технический руководитель сложных проектов (проектные предложения) То же, что и ведущий инженер, но фокусируется на проблемах, которые являются сложными с технической, организационной или деловой точки зрения. · Проект требует координации между несколькими отрядами. · В проекте участвует сторонний поставщик технологий или заинтересованная сторона (например, партнерство) · новая сборка продукта, пока продукт находится в режиме обнаружения · высокоприоритетный/срочный проект с фиксированными сроками и множеством неизвестных
Список реализованных проектов, соответствующих следующим требованиям: 1. Проект считается сложным (см. примеры слева). 2. Проект был полностью выполнен (все результаты + DoD), и сроки были соблюдены. 3. Решение проблемы было предложено сотрудником, и оно считается эффективным (т.е. было оценено несколько альтернатив, и на основе проверки с низким кодом/без кода была выбрана лучшая альтернатива). 4. Часть исследования была завершена сотрудником (системные требования, тикеты, оценки). 5. Решение было разработано сотрудником. Проект имеет высокую сложность с точки зрения проектирования системы. 6. Инженер принимал участие в реализации в качестве технического руководителя.
Движущие изменения
Стимулирует технические изменения (технологии) · То же, что и E5, но на техническом уровне · Владелец системы по крайней мере для одного нефункционального аспекта (например, безопасность, наблюдаемость и т. д.).
Список внесенных основных изменений (обычно не менее 4), соответствующих следующим требованиям: 1. Изменение обеспечивает существенное улучшение качества системы (например, улучшения платформы), опыта разработчиков или производительности разработчиков. Изменение затрагивает несколько отрядов (например, внедрение технологий). 2. Инженер не обязательно должен быть тем, кто предложил изменение. Инженер должен быть основной движущей силой изменения (например, разрабатывать, выступать в качестве технического руководителя, участвовать в реализации). Само изменение может быть реализовано инженером или в результате командных усилий. 3. Изменение должно быть полностью реализовано и использовано несколькими отрядами (изменения должны быть «липкими» и обеспечивать достаточную ценность, чтобы их сохранить). 4. Изменение должно быть достаточно значительным, чтобы его можно было упомянуть. Оно должно отслеживаться на странице «предстоящие проекты» как проект владения (в данном контексте владение означает изменения платформы, инструментов, процессов и т. д., а не только изменения, связанные с платформой). 5. По крайней мере 2 изменения должны быть связаны с нефункциональным аспектом, принадлежащим данному лицу.
Люди
Признанный эксперт · Признанный эксперт в определенной области знаний на уровне компании, выступает в качестве технического контактного лица в области технологий в своей области знаний · Отслеживает тенденции/технологии в области своей компетенции и сообщает об обновлениях и результатах · Активно и регулярно делится опытом с другими инженерами (семинары, технические беседы, обучение) · Способствует сотрудничеству для поиска решений сложных проблем (рабочие группы и т. д.) · Эффективно проводит технические интервью · Наставляет и поддерживает менее опытных инженеров, направляет их карьеру с точки зрения профессионального развития · Действует как «магнит» для хороших инженеров во время найма (становится решающим фактором, когда мы конкурируем за хорошие таланты с другой компанией)
Возможные доказательства: 1. Проведено собеседование с инженерами, которые были приняты на работу и прошли испытательный срок. 2. Отзывы от высококвалифицированных инженеров. 3. Организуются/проводятся обучающие сессии для всей технической команды (например, Tech Sync, Engineering Dojo). 4. При руководстве рабочей группой в качестве доказательства можно использовать список изменений, предложенных/внедренных в сфере деятельности рабочей группы.
Менеджер по инжинирингу
Область
Требования
Руководящие принципы для доказательств
Доставка
Предоставляет дорожную карту отряда · Руководит отрядом из 3-6 инженеров · Выступает в качестве менеджера проектов для нескольких параллельных инициатив · Способность предоставлять результаты, имея в качестве входных данных только бизнес-требования (способность создавать и утверждать системные требования) · Фокусируется на влиянии на бизнес, обусловленном ценностью бизнеса · Сообщает заинтересованным сторонам об обязательствах, статусе и рисках · Обеспечивает, чтобы все члены отряда имели всю необходимую им информацию · Общается с третьими лицами в рамках инициатив/владения · Находит правильный баланс между предоставлением функций и качеством системы · Все требования к старшему инженеру-программисту
Новые проекты, реализуемые отрядом, соответствуют следующим требованиям: 1. Проект инициирован посредством проектного предложения. 2. Проект достиг своих показателей воздействия, и общественные обязательства были выполнены. 3. Проекты, о которых сообщалось в предыдущем цикле продвижения, не могут быть включены в список.
Производительность
Проводит управленческие изменения (команда) · Измеряет и постоянно улучшает эффективность работы команды · Определяет и внедряет лучшие практики в команде, уделяя особое внимание производительности · Поддерживает высокое качество доставки · Обеспечивает прозрачность прогресса, рисков и результатов
1. Значения показателей производительности (эффективности) отряда. 2. Внесены существенные изменения (не менее 4), соответствующие следующим требованиям: а. Это решает проблему, связанную с собственным отрядом или племенем, проблема должна быть включена в ТОП-5 проблем и согласована с линейным менеджером. б) Изменение должно быть полностью реализовано и использовано командой (изменение должно быть «липким» и обеспечивать достаточную ценность, чтобы его сохранить). в) Изменение должно обеспечить существенное улучшение производительности, вовлеченности или качества доставки. d. Менеджер не обязательно должен быть тем, кто предложил изменение. EM должен быть основной движущей силой изменения. Изменение может быть реализовано инженером или в рамках командных усилий.
Люди
Линейный менеджер (>=3 прямых подчиненных) · Управляет 3-6 прямыми подчиненными · Тренирует и поддерживает инженеров · Поддерживает и направляет карьерный рост · Примиряет разногласия и помогает управлять и разрешать конфликты · Поощряет позитивную командную культуру и сотрудничество
1. Значения показателей взаимодействия отряда. 2. Список инженеров, принятых на работу и прошедших испытательный срок (можно пропустить, если мы не нанимаем, EM должен быть менеджером по найму).
Технический директор
Область
Требования
Руководящие принципы для доказательств
Доставка
Предоставляет дорожную карту для нескольких отрядов · Обеспечивает доставку в 2-3 отряда · Выполняет обязанности технического менеджера в одном из отрядов · Имеет партнерские отношения с третьими лицами · Все требования от технического руководителя
Новые проекты, реализуемые отрядами, соответствующими следующим требованиям: 1. Проект инициирован через проектное предложение (не деятельность BAU). 2. Проект достиг своих показателей воздействия, и общественные обязательства были выполнены. 3. Результаты проекта были представлены в виде сессии технических новостей. 4. Проекты, о которых сообщалось в предыдущем цикле продвижения, не могут быть включены в список. 5. По крайней мере 2 проекта должны быть признаны ключевыми на уровне компании (например, новый продукт и т.п., может быть подтверждено техническим директором).
Движущая сила перемен
Проводит управленческие изменения (несколько составов/технологий) · Все требования от инженеров, но в отношении нескольких отрядов · Владелец системы как минимум для одного процесса (например, поддержка и т.д.)
1. Значения показателей производительности (результативности) отрядов по нескольким отрядам. 2. Внесены существенные изменения (не менее 6), соответствующие следующим требованиям: а. Решает проблему, связанную с отрядами или племенем, проблему необходимо включить в ТОП-5 проблем и согласовать с линейным руководителем. б) Изменение должно быть полностью реализовано и использовано отрядами (изменение должно быть «липким» и обеспечивать достаточную ценность, чтобы его сохранить). в) Изменение должно обеспечить существенное улучшение производительности, вовлеченности или качества доставки. d. Менеджер не обязательно должен быть тем, кто предложил изменение. Директор по инжинирингу должен быть основной движущей силой изменения. Изменение может быть реализовано инженером или в рамках командных усилий. е. По крайней мере 2 изменения должны быть связаны с процессом, которым владеет директор.
Люди
Линейный руководитель (>=10 подчиненных, включая косвенные подчиненные) · Все требования к инженерному менеджеру · Тренирует и поддерживает инженеров · Поддерживает и направляет карьерный рост · Управляет оттоком клиентов, сокращает «досадный отток»
1. Значения показателей вовлеченности отрядов в разных отрядах. 2. Список инженеров, принятых на работу и прошедших испытательный срок (можно пропустить, если мы не нанимаем). 3. Список инженеров, получивших повышение (можно пропустить, если нет деловой необходимости в повышении).
