Лестница профессионального развития: как победить «серый ящик» карьерного роста в IT
Практическая адаптация идей Стива Макконнелла для создания прозрачной системы грейдирования. Опыт внедрения.
Начало (триггер)
Недавно передо мной встала классическая управленческая задача: «расставить» инженеров команды на единую карьерную лестницу.
Аналогичная задача была поставлена и руководителям всех остальных команд.
В подавляющем большинстве команды занимаются каким-то одним направлением деятельности (продуктовые команды аналитиков, разработчиков, тестировщиков, команды внедрения, эксплуатации, тоже специализирующиеся на наборе конкретных продуктов), и внутри каждой из этих команд как-то более-менее можно было ввести общие критерии для грейдирования.
И, конечно же, большинство руководителей пошло по простому пути: ограничиться созданием критериев для грейдирования внутри своей команды. Естественно, многие подсматривали у соседей.
В итоге, если это переложить на язык программного кода, получилась библиотека с функциями, содержащими огромное количество продублированного несколько раз кода, но при этом каждая из них применима только для одной узкой задачи.
Неэффективность такого подхода для компании здесь просто зашкаливает.
Не хочу сказать, что я один такой умный и правильный, но у меня такое отношение к работе реально вызывает физическое отвращение. Ведь понятно, что подход к разработке критериев оценки должен быть общим в рамках компании.
Не знаю, может быть, если бы у меня тоже была команда, занимающаяся одним направление работ, я тоже бы поддался искушению пойти по простому пути, хочется верить, что нет (все-таки очень давно являюсь адептом системного подхода к решению задач, большой поклонник Теории Ограничений Элияху Голдратта, пишу статьи на подобные темы, вот примеры: Управление проектами по Теории Ограничений, Финансовые показатели в Теории Ограничений, Когерентность мышления продуктовой команды).
Контекст
Немного про специфику команды: команда называется DevOps, но это не тот DevOps, про который подумали 90% читателей. Подробно эту тему я описал в статье "DevOps - это не автоматизация", здесь вкратце скажу, что круг задач команды очень обширен - аналитика, разработка, тестирование (и ручное, и автоматизированное), различная внутренняя автоматизация, CI/CD, задачи, связанные с внедрением и эксплуатацией... Для выполнения задач, стоящих перед командой, требуются навыки из разных областей знаний IT.
У каждого инженера команды есть фокусировка на каких-то из направлений работ и квалификация прокачивается, понятное дело, именно в этих направлениях. То есть, напрямую, простым способом, невозможно всех сравнить.
Как при этом их расставить на одну лестницу?
Позаимствовал концепцию
На самом деле, раньше тоже периодически задумывался на эту тему: ведь в целом, отсутствие понятных критериев соответствия инженерным должностям / ступеням плохо сказывается на мотивации людей и приводит к разным нехорошим ситуациям.
Например, человек может считать себя супермегапрофи, достойным повышения в должности/зарплате, но вот с руководителем, принимающим соответствующие решения, отношения не очень сложились, и никакого движения нет. Или видит инженер, что в другой команде его товарища повысили, у него встает вопрос "а чем я хуже?" - а действительно, чем?
К счастью, когда-то давно попалась мне книга Стива Макконнела "Профессиональная разработка программного обеспечения", где речь идет об инженерном подходе к разработке ПО (Software Engineering). В том числе там как раз поднимался этот вопрос и предлагалась очень интересная модель построения такой лестницы в IT-компании.
Поднял свои старые записи (да, обязательно делайте заметки/записи, когда получаете полезные знания и возникают идеи их применения - такие записи часто очень помогают в дальнейшем), сформулировал концепт, показал его коллегам, мнение которых уважаю, получил от них очень положительные отзывы.
В итоге получилась такая
Лестница профессионального развития
Общий принцип
Есть такая дисциплина, как инженерия, и есть ее приложение к разработке программного обеспечения (Software Engineering). Любая уважающая себя компания по разработке программного обеспечения должна применять инженерный подход к процессу.
Инженер (и не только инженер на самом деле), работающий в IT-компании, использует в своей деятельности знания из некоторого набора областей (если не так - это плохой инженер).
Например, человек, работающий на позиции тестировщика, должен обладать в той или иной степени областями знаний, связанными не только с тестированием, но и с разработкой, аналитикой, эксплуатацией. Чем выше профессиональный уровень, тем более должны быть прокачаны софт-скиллы, во многих случаях нужны и некоторые управленческие навыки.
Есть стандарт SWEBOK (свод знаний по программной инженерии), где приведен вариант классификации областей знаний, используемых в программной инженерии, с их детальным описанием, вот пример из одной из версий стандарта:
[SWEBOK]
Для каждой из областей знаний определяются уровни способностей (уровни владения областью знаний).
Пример от Стива Макконнела:
| Уровень | Описание |
|---|---|
| Вводный | Основные работы в данной области сотрудник выполняет под контролем и предпринимает серьезные шаги по развитию своих знаний и мастерства. |
| Продвинутый | Сотрудник эффективно и независимо выполняет работы в данной области, является примером для менее квалифицированных сотрудников, иногда выступает в роли наставника. |
| Ведущий | Сотрудник выполняет образцовые работы в данной области. Регулярно выступает наставником и ведущим в проекте и, возможно, на уровне компании. Рассматривается как крупный ресурс в данной области знаний. |
| Мастерский | Является эталоном работ в данной области и имеет богатый опыт участия во многих проектах. Ведет занятия и семинары, является автором брошюр или книг, которые расширяют объем знаний в данной области. Является лидером на уровне отрасли, признан как эксперт в данной области. |
Из сочетания областей знаний и уровней владения ими и строится лестница профессионального развития, с требованиями к освоению каждой ступени лестницы.
Для того, чтобы перейти с одной ступени лестницы на другую, нужно продвинуться в освоении некоторого количества областей знаний, например:
Требования по освоению областей знаний описываются матрицей: столбцы – области знаний и строки – уровни владения (то, что описано выше). В каждой ячейке матрицы определены элементы, которые должны соответствовать ее требованиям, такие как чтение литературы, семинары, навыки, опыт работы и т.п.
В итоге получается, что у любого инженер есть множество разных путей профессионального развития и карьерного роста, человек выбирает сам, какой из путей ему более близок.
И эта лестница единая для всех инженеров.
Эта лестница может и по идее должна стать частью корпоративной культуры, ее можно использовать и для составления плана профессионального развития инженеров, и для мотивации, и для планирования обучений в рамках всей организации или дирекций/отделов, и для прозрачности (каждой ступени лестницы профессионального развития соответствует в точности один уровень оплаты труда), и для обмена опытом (лестница сама по себе будет стимулировать обмен опытом).
Понятно, что лестницу должен составлять не один и не два человека – это должна делать группа людей, состоящая из специалистов (как руководителей, так и инженеров) в каждой из областей знаний, которые будут в этой лестнице присутствовать. И естественно важно, что людям должно быть интересно это делать, т.е. они должны как минимум понимать и принимать, зачем это нужно.
Реализация
В нашем случае мы использовали этот подход не один-в-один, а немного модифицировали:
1. Определили области знаний
Получилось 11 областей знаний, состоящих из двух групп: первая группа включает 8 "технических", а вторая - две "управленческие" области знаний и софт-скиллы:
Технические области знаний
- Управление требованиями: Идентификация и анализ функций, реализуемых в ПО
- Аналитика и проектирование ПО: Процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или ее компонентов
- Конструирование (создание) ПО: Создание рабочей программной системы посредством комбинации кодирования, верификации (проверки), модульного тестирования (unit testing), интеграционного тестирования и отладки
- Тестирование ПО: Деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.
- Обслуживание: Сопровождение, внедрение, эксплуатация. Вся совокупность деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки программных систем. Эти работы выполняются как перед вводом системы в эксплуатацию, так и после этого.
- Управление конфигурацией и инфраструктурой: Управление и планирование SCM-процессов, идентификация программных конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также управление выпуском (release management) и поставкой (delivery). Автоматизация внутренних процессов, поддержка инфраструктуры, деплой, CDP и т.п.
- Продукты компании: Владение продуктами компании в зоне ответственности специалиста
- Базовые инженерные инструменты и инфраструктура: Владение базовыми инженерными инструментами и знание инфраструктурных продуктов, используемых в компании
Управленческие области знаний и софт-скиллы
- Soft Skills: Личные качества, социальные навыки и коммуникативные способности, которые позволяют специалисту успешно взаимодействовать с клиентами, нормально работать в команде, эффективно общаться, принимать решения в условиях неопределенности и быстро адаптироваться к изменяющимся условиям.
- Управление проектами: Область знаний, которая позволяет реализовать проект любого назначения и сложности в рамках установленных сроков, бюджета и ресурсов.
- Управление командами: Область знаний «Управление командами» подразумевает под собой умение создавать эффективную команду, разрабатывать стратегию её развития, формировать культуру взаимодействия между сотрудниками, а также внедрять новые методы работы. В рамках этой области необходимо уметь анализировать процессы, происходящие в коллективе, определять причины возникновения конфликтов и находить способы их решения. Кроме того, управление командой требует знания основ психологии, социологии и менеджмента. Включает в себя также навыки выстраивания технологических процессов в команде и планирования работ.
2. Описали уровни владения
Для каждой из областей знаний описали четыре уровня владения - конкретные требования для достижения каждого уровня (по каким-то областям знаний эти критерии получилось расписать достаточно подробно, по каким-то - пока очень примерно, это будет постепенно дорабатываться).
3. Провели оценку
Ввели шкалу оценки владения областями знаний в баллах - от 0 до 4.
Каждый инженер оценивается по этим критериям, и набирает определенное количество баллов по каждой из областей знаний. Итого, для каждого инженера получаем сумму баллов по "техническим" областям знаний и по "управленческим".
4. Построили матрицы
Кроме суммы баллов, для каждого инженера строится матрица его владения профессиональными областями знаний, пример:
| Инженер / Область знаний | Инженер 1 | Инженер 2 | Инженер 3 | Инженер 4 | Инженер 5 | Инженер 6 | Инженер 7 |
|---|---|---|---|---|---|---|---|
| Управление требованиями | 1 | 2 | 1 | 2 | 3 | 1 | 1 |
| Аналитика и проектирование ПО | 1 | 2 | 1 | 2 | 2 | 1 | 1 |
| Конструирование (создание) ПО | 2 | 3 | 2 | 3 | 2 | 1 | 2 |
| Тестирование ПО | 3 | 2 | 2 | 3 | 2 | 2 | 0 |
| Обслуживание | 3 | 4 | 1 | 1 | 4 | 4 | 0 |
| Управление конфигурацией и инфраструктурой | 1 | 1 | 1 | 2 | 3 | 1 | 0 |
| Продукты компании | 3 | 4 | 2 | 2 | 2 | 3 | 0 |
| Базовые инструменты и инфраструктура | 2 | 3 | 1 | 2 | 2 | 2 | 1 |
| Сумма баллов по инженерным областям знаний | 16 | 21 | 11 | 17 | 20 | 15 | 5 |
| Soft Skills | 1 | 1 | 1 | 2 | 4 | 2 | 1 |
| Управление проектами | 1 | 1 | 0 | 1 | 4 | 2 | 0 |
| Управление командами | 0 | 2 | 0 | 1 | 3 | 2 | 0 |
| Сумма баллов по управленческим областям знаний | 2 | 4 | 1 | 4 | 11 | 6 | 1 |
5. Построили лестницу из 10 ступеней
| Уровень | Описание | Баллы по областям знаний |
|---|---|---|
| 1 | Инженер-программист на испытательном сроке: Начинающий специалист, который только начинает свою карьеру в IT-компании. Он находится на стадии обучения и адаптации к рабочей среде, процессам и инструментам. | Technical: 4 Management: 0 |
| 2 | Инженер-программист, прошедший испытательный срок и уверенно работающий в команде: Специалист, который успешно прошел испытательный срок и доказал свою способность эффективно работать в команде. Он может выполнять задачи при ограниченном контроле, но все еще нуждается в руководстве и поддержке. | Technical: 8 Management: 1 |
| 3 | Старший инженер-программист: Знания по основным техническим областям знаний, используемым в команде. Может работать полностью самостоятельно. | Technical: 11 Management: 1 |
| 4 | Старший инженер-программист: Специалист с твердыми знаниями в основных технических областях, используемых в команде. Он может эффективно работать над проектами средней сложности, предлагать инновационные решения и делиться своими знаниями с другими членами команды. | Technical: 14 Management: 1 |
| 5 | Ведущий инженер: Специалист, имеющий опыт работы в крупных проектах и принимавший участие в нескольких этапах жизненного цикла программного обеспечения. Он обладает широким пониманием процессов разработки/обслуживания и способен ограниченно управлять ими. | Technical: 16 Management: 2 |
| 6 | Ведущий инженер: Специалист, который участвует во всех аспектах малых и крупных проектов, внося ощутимый вклад в их эффективность. Зарекомендовал себя грамотными техническими решениями и компетентностью в вопросах проектов/продуктов в своей зоне ответственности. | Technical: 17 Management: 2 |
| 7 | Ведущий инженер: Специалист, который вносит инновации в проекты, предлагает новые подходы и технологии, способствуя развитию компании. | Technical: 18 Management: 3 |
| 8 | Ведущий инженер: Специалист, осуществляющий техническое руководство командой, определяющий технические стратегии и стандарты, а также контролирующий качество продуктов и услуг. | Technical: 18 Management: 4 |
| 9 | Главный специалист / Главный инженер-программист / Главный эксперт: Специалист, способный анализировать внешние и внутренние стороны проекта и обеспечивать грамотные решения. Он делает уникальный вклад в работу, обладая обширными знаниями и опытом. | Technical: 20 Management: 6 |
| 10 | Главный специалист / Главный инженер-программист / Главный эксперт: Специалист, являющийся крупным инженерным ресурсом для компании. Он справляется с самыми серьезными проблемами, принимает решения по ключевым задачам и известен многим инженерам внутри компании по конкретным достижениям. Его знания охватывают всю отрасль. | Technical: 22 Management: 8 |
Для каждой ступени определено, какое суммарное количество баллов нужно набрать из "технических" и какое из "управленческих" областей знаний (третий столбец).
То есть, например, чтобы попасть на 7-ю ступень, нужно набрать 18 баллов в "технической" группе и 3 - в "управленческой".
Инженеры, в соответствии с набранными баллами, расставлены по этой лестнице.
Что дает такая модель
Самое главное — понимать, что такая система не является «еще одной HR-метрикой». Это, прежде всего, инструмент развития инженерной культуры.
Ее нельзя купить и внедрить «сверху» за два месяца. Ключ к успеху — в вовлечении самих инженеров и руководителей в ее разработку и постоянную актуализацию.
Это не просто теория. Это работающий инструмент, который решает конкретную бизнес-проблему неопределенности карьерного роста. Он превращает «серый ящик» в прозрачную и понятную для всех дорожную карту.