Профессиональное развитие — важнейший мотиватор в работе. Если вы тимлид и согласны с этим тезисом, то наверняка задумывались, как вы можете управлять этим процессом и помогать участникам вашей команды развиваться.

На TeamLead Conf Павел Филонов из Kaspersky поделился своей болью и подходом к её решению: personal development plan, он же индивидуальный план развития.


Далее от первого лица: цель, структура, примеры и фидбек участников команды, над которой проводился эксперимент по составлению ИПР. Это только один вариант реализации, если ваш опыт или интуиция подсказывает, что всё нужно делать по-другому — расскажите в комментариях. Если у вас есть свой ИПР — дополните фидбек, напишите, позволил ли он добиться желаемых целей или не оправдал себя.

О проблемах

Я линейный менеджер средних размеров команды. В моём прямом подчинении 10 человек, которых можно условно разделить на три подкоманды с разной экспертизой: Data Science, Automotive Security Development, HRIS&Analytics. Каждая подкоманда обычно одновременно работает над несколькими проектами. Например, у нас может быть 10 активных проектов, которые все три команды прорабатывают вместе.

В этой ситуации я достаточно часто сталкиваюсь с одними и теми же проблемами, которые наверняка знакомы и вам.

Мотивация через развитие. Ко мне приходит сотрудник и рассказывает о своих проблемах и потребностях. Например, что он хочет развиваться, потому что на конференциях, в подкастах и статьях все твердят, что инженер должен развиваться. Проблема в том, что не всегда понятно, как это делать.

Иногда бывают чуть более конкретные запросы. Например, Маша говорит, что хочет повышения (в должности, в зарплате, в ответственности), и спрашивает, что ей для этого делать. Маша, на мой взгляд, делает абсолютно верную вещь — сообщает руководителю, что хочет повышения, и теперь, по её мнению, это ваша проблема. Мне кажется, она права: вам нужно вместе что-то сделать, например, наметить цели и сроки и договориться, что в случае достижения цели в эти сроки Маша может рассчитывать на повышение. По сути это контролируемый процесс и самостоятельный проект, в котором участвуют двое: руководитель и его подчиненный.

Управление изменениями. Оля любит читать всё подряд, ни одна статья на Хабре не проходит мимо нее. Она большая поклонница конференций и просматривает видео тех докладов, на которые не смогла попасть (прим. ред.: если вы тоже хотя бы изредка возвращаетесь к видео с конференций — смотрите, мы открыли все видео февральской TeamLead Conf). Она изучает много всего и хочет всё новое затащить в проект. Я называю это хаос развития.

С одной стороны, это хорошо — Оля читает, развивается, узнает что-то новое. Но для меня, как для руководителя, желательно, чтобы этот процесс был более контролируемым. Потому что я знаю, допустим, что JavaScript — отличный язык, но в embedded-разработке для микроволновок это не совсем то, что востребовано здесь и сейчас с точки зрения проекта.

С другой стороны, я иногда использую этот инструмент для своих целей. Достаточно часто я могу прогнозировать появление тех или иных проектов и хочу, чтобы когда работа над проектом начнётся, она начиналась не с «давайте посмотрим, что это такое, какой там технологический стек».

Я считаю, что стартовать можно быстрее, если угадать, какой проект может появиться и какой технологический стек ему подойдет. Одного или двух участников команды подготовить заранее: предложить им чему-то поучиться про запас, попробовать, поэкспериментировать. Когда начнется реальная работа, она пойдет быстрее.

Управляя изменениями в технологическом стеке, технологии иногда нужно добавлять, а иногда удалять. К сожалению, мы не можем быть экспертами сразу во всем, чтобы выучить что-то новое, обычно надо забыть что-то старое.

Повышение гибкости команды. Третий важный инструмент не про индивида. Мне, как руководителю, важно, чтобы в проектах и командах было как можно меньше людей-уникумов, которых трудно заменить. Чтобы, если человек заболеет, уйдет в отпуск или уволится совсем, не возникло больших проблем. С моей точки зрения управление индивидуальным развитием это в том числе митигация рисков. Можно пытаться размазывать компетенции, уменьшая вездесущий автобусный фактор.

Расскажу об инструменте, который помогает мне, если не решить все эти проблемы, то хотя бы контролировать или двигаться в сторону их решения.

План

Если мы понимаем проблему, то очевидный инженерный шаг — это декомпозировать ее, составить план решения и придерживаться его, желательно постоянно мониторя путём обратной связи. Вот какой у нас будет план, в том числе этой статьи.


Начнем с известного инструмента — матрицы компетенций (skill matrix). Многие знают и даже составляют такие матрицы. Но этого недостаточно, к ней нужно приложить некоторый процесс — ее нужно заполнять.

В данном случае речь пойдет об индивидуальной матрице компетенций, в которой каждый сотрудник может найти себя и понять, какими компетенциями обладает и какие хотел бы освоить. По сути это процедура оценки (assessment). Причем это двойной параллельный процесс: с одной стороны сотрудник оценивает себя, с другой стороны руководитель может оценить его. Сопоставить оценки и по сути ожидания, куда надо развиваться, может быть очень важной частью.

После этапа оценки идет центральная тема статьи — индивидуальный план развития (Personal Development Plan). В PDP уже должен быть призыв к действию. Документ с планом должен визуализировать сам план и по возможности отвечать на вопрос, что делать, чтобы достигнуть желаемой точки в развитии за установленный срок.

Последняя, но немаловажная деталь — это то, что недостаточно просто составить план и сказать: «Все, поехали!» Любому процессу нужна поддержка, контроль за исполнением и возможность внесения изменений по ходу (execution & control). Трудно угадать всё сразу на год вперед, что-то может изменяться динамически. Поэтому важно иметь инструменты постоянного контроля. Например, я включаю это в структуру one-to-one.

Последний переход на схеме — «execution & control» в «skill matrix» — тоже важен. Это не терминальный процесс. Прокручивать этот цикл нужно с той периодичностью, на которую рассчитан план развития сотрудника. В 2020 у нас началась вторая итерация работы с планами, и некоторые сотрудники уже ожидали этого и спрашивали: «Мы же будем составлять план развития на следующий год?».

ИПР решает не только мои задачи, но и проблемы самих сотрудников.

Пройдемся по всем пунктам плана подробнее.

Матрица компетенций

Трудно представить универсальную матрицу, которая подойдет всем, поэтому рассмотрим принципы на достаточно общих примерах.



Колонки — это области знаний. Кроме разработки программного обеспечения в наших проектах часто нужно машинное обучение и анализ данных, поэтому для них есть отдельные колонки. По строчкам обычно размечаются титулы, уровни, грейды.

И колонки, и их наполнение — индивидуальный вопрос для каждой компании или даже команды. Можно начать с готового примера и доработать под себя.

Когда вы составите матрицу компетенций, то можно переходить к следующему пункту плана. Но обратите внимание, иногда в матрице можно увидеть, что строки соответствуют не титулам, а конкретным участникам команды. Тогда это немного другой инструмент, который позволяет понять, каких навыков не хватает в вашей команде. Это тоже важно знать, но я буду говорить об использовании матрицы компетенции для фокусирования на конкретном индивиде, то есть насколько конкретный сотрудник владеет знаниями в доменных областях важных в наших проектах.

Оценка

Чтобы отметить уровень знаний или владения навыками можно использовать схему светофора, я предлагаю просто три цвета:

• Темно-зеленый — не просто «знаю-знаю», а есть большое количество артефактов, которые подтверждают эти знания.
• Светло-зеленый — что-то читал, слышал, но сам много не работал в этой области.
• Белый — совсем не знаю.

Естественно, возникает вопрос, как понять, как раскрасить клетки. Как разграничить: я знаю, плохо знаю или вообще не знаю? От случая к случаю критерии могут варьироваться, но у меня такие приемы.

Я пользуюсь эмпирическим правилом, которое подсказал один мой коллега: если ты знаешь одну систему, то на самом деле ты не знаешь ни одной; если знаешь две — считай, что знаешь их все.

Что любопытно, это работает с очень многими вещами, например, операционными системами, языками программирования, базами данных и системами визуализации данных. Всё знать всё равно нельзя, но если взять два крайних случая, то начинаешь понимать некоторую генерализацию процесса. Так что можно предложить такой вариант: знаешь, если знаешь хотя бы несколько приемов отсюда.

Второй вариант: знаю, если есть артефакты, которые можно предъявить — код, презентация, выводы. Если есть конкретные артефакты, значит, скорее всего, человек это делал, причем неоднократно.

Итак, просим человека закрасить матрицу как детскую раскраску. Руководитель может сделать это же со своей точки зрения.



Все знают модель T-shaped — когда человек по чуть-чуть знает что-то из разных областей и хорошо разбирается в какой-то одной. В разных статьях можно встретить идею, что это идеал инженера и специалист будущего.

Оказалось, что есть более интересные варианты.


Кроме T-shaped, есть Pi-shaped — когда человек достаточно глубоко разбирается в нескольких областях. Но открытием для меня стал Comb-shaped — человек-расческа, который практически во всем эксперт, и такие люди есть.

Действительно, иногда нам важен человек, который будет очень глубоко знать одну область — специфика проекта такая. А иногда мы хотим супер-универсала (правда, боюсь, что платить ему надо неприлично много).

Индивидуальный план развития

Матрица компетенций — это как система координат в море персонального развития:


Оси связаны доменными областями (разработка ПО и машинное обучение в данном случае). Когда мы делаем оценку, то по сути фиксируем сразу две точки в этой системе координат:

• что человек знает сейчас;
• что мы (сотрудник и руководитель) хотели бы, чтобы было освоено в течение разумного срока.

Очевидно, напрашивается построение плана. В этом визуальном образе индивидуальный план развития — это вектор между точками как способ дойти от текущей ситуации до желаемой. Причем сделать это важно максимально прозрачно, а не: «Ты в течение года поизучай, а через год мы посмотрим». По-моему, такой сложно контролируемый процесс вообще не имеет смысла. А как его контролировать, обсудим чуть позже.

Структура ИПР

Структуру ИПР удобно делить на два больших блока: цели и методы достижения.

Цели — это по сути пункты из матрицы компетенций. Рекомендую не планировать слишком много целей — не более 20. А достаточно абстрактные пункты, например, «изучить средства визуализации данных» или «разобраться с современными алгоритмами обработки естественных языков» лучше дробить на задачи поменьше.

Число целей, конечно, зависит от человека, потому что у людей разная обучаемость. Её даже можно измерить в рамках этого подхода — сколько целей человек освоил за год. В моей команде было, когда сотрудник успел продвинуться по всем пунктам плана, даже время осталось и пришлось добавлять. Мне больше нравится добавлять, чем ситуация, когда не по всем пунктам удалось продвинуться. Что-то добавлять в скоуп — более привычный процесс, чем убирать оттуда.

Методы достижения. Здесь есть три важных составляющих, которые можно грубо расписать по времени, которое потенциально нужно инвестировать.

• Обучение на рабочем месте ~ 70% целей.

Процесс обучения с помощью текущих задач и проектов — самый эффективный. Во-первых, это полезно, потому что заказчики довольны, работа идет. Во-вторых, это задачи из реальной жизни, то есть это реальная боль.

Но почти всегда текущий портфель проектов не позволяет покрыть все навыки, которые хотелось бы освоить. Тогда есть опасность, что вне зависимости от того, нужно это в проекте или нет, как только человек изучит новый инструмент, он попытается его затащить — надо же закрепить знания. На этот случай есть другие два варианта.

• Самообучение ~ 20% целей.

Это своего рода попытка структурировать то, что человек читает, смотрит, на какие доклады ходит, что слушает, чтобы предотвратить хаос. Я это называю «список чтения на лето». Честно говоря, мне он не очень нравился раньше, но если в нем книжки, курсы, лекции, которые интересны, то он начинает восприниматься гораздо лучше.

• Самостоятельные проекты ~ 10% целей.

Pet-projects или исследовательские проекты. Они не всегда имеют заказчика, то есть за эти проекты не платят деньги, они пока не нужны бизнесу. Но если в самообучении просто прочитать книжку, что-то послушать или куда-то сходить, скорее всего, через 1-2 месяца материал полностью вымоется из головы. Самостоятельные проекты нужны, чтобы закрепить новое знание, которое сейчас в боевых проектах не нужно, но может понадобиться в будущем. На самостоятельные проекты выделяется меньше всего времени.

Пойдем вглубь каждого из пунктов методов достижения.

Пример ИПР

Цели ИПР — пункты из матрицы компетенций, которые человек хотел бы освоить, и руководитель хотел бы, чтобы он освоил. Но главное, нужны ожидаемые результаты — грубо говоря, подтверждение, что цель действительно достигнута.
Хорошо, когда достижения подтверждаются артефактами. Например, чтобы обосновать, что сотрудник действительно приобрел навык построения современных CI, он может просто предъявить те конвейеры, которые он запустил, которые уже работают, не сильно сбоят и доставляют value.

Если хочется освоить такой абстрактный навык, как математическая статистика (это большая область и на самом деле изучаются какие-то отдельные её части), то тоже нужно предъявить, например, методы исследования или приёмы, примененные в конкретных задачах.

Процесс развития обычно идет маленькими шажочками. Человек делает свои таски по 1-2 дня и не ощущает, что что-то меняется. Поэтому важно, чтобы можно было раз в квартал собраться, открыть ИПР, выбрать пункт и посмотреть на артефакты прогресса. Это может быть мерилом в том числе для самого сотрудника, которое подсказывает: «Оказывается, я уже это умею, потому что я это делаю! Да, возможно, я еще не все знаю, но уже делал эти вещи».

Дальше в каждом из блоков ИПР уже может пойти конкретика, связанная с текущими или будущими проектами. Хоть мы и планируем двухнедельными спринтами, как руководитель проектов я представляю перспективы и на полгода-год и примерно знаю, какие конкретные задания могут появиться.

Обучение на рабочем месте

Например, я предполагаю, что через три месяца мы получим новый проект, который нужно будет декомпозировать и понять, что вообще требуется сделать. Это отдельный навык — декомпозировать сложную проблему на серию мелких. Другой отдельный навык — оценивать, сколько на это нужно времени и ресурсов. Вполне можно поручить такую задачу сотруднику, если он хочет вырасти и научиться декомпозировать сложные задачи: взять задачу на 3 человеко-месяца и разбить на таски по 1-2 дня (пункт 7 в примере).
Или если человек хочет поднатореть в soft-skills, то можно предложить ему попробовать себя в роли ментора. Таким образом можно поставить задание длинною до года (пункт 10).

Для меня важно обозначить, когда примерно нужно заниматься той или иной задачей, причем достаточно сделать это грубо — в рамках квартала или полугода. Тогда на one-to-one можно возвращаться к этой схеме, но не идти по всем пунктам от начала и до конца, а концентрироваться как раз на задачах прошедшего периода.

Взгляд на текущий временной интервал часто помогает понять, какие задачи сейчас актуальны и что нужно, чтобы выполнить индивидуальный план. Постоянно следить за исполнением плана — задача и сотрудника, и руководителя.

Вы как руководитель можете существенно способствовать продвижению сотрудника по ИПР, если контролируете распределение задач. Тогда, раздавая задачи из бэклога, вы можете ориентироваться на ИПР.


Допустим, мы говорим о классическом спринте. Сначала нужно составить бэклог спринта из большого бэклога, а дальше либо предложить всем взять что кому нравится, либо самому выбирать, кто из команды будет решать ту или иную задачу. Это планирование можно проводить через призму индивидуального плана развития, особенно в проекции текущего квартала или другого короткого периода реализации целей.

Например, с одним сотрудником мы договорились, что в первом квартале он хочет научиться работать с docker-образами. Если возникает задача обновить сертификаты в docker-образе, то у меня есть подсказка для задачи маршрутизации, кого в эту задачу стоит отправить.

Здесь, конечно, есть подводный камень и возможный конфликт интересов. Если сотрудник учится с помощью задачи, то вполне вероятно, он в среднем будет делать ее дольше, чем опытный сотрудник. Это действительно проблема и нужен компромисс.

Если мы хотим, чтобы сотрудники обучались на рабочем месте, то распределение задач не будет оптимальным с точки зрения скорости их решения.

Появляется двухкритериальная задача: закрыть все таски до конца спринта и дать возможность людям научиться чему-то новому. С точки зрения выполнения задач, нет смысла давать задачу неопытному исполнителю. Но я смотрю на это и как ресурсный менеджер, и как руководитель, чья команда должна развиваться, чтобы в длинной перспективе делать работу быстрее.

Я не верю, что можно просто заставить кого-либо делать работу быстрее. Считаю, что это долгий процесс, когда человек начинает разгоняться. В этот этап нужно инвестировать, например, делая правильную маршрутизацию.

Самообразование

В разделе «Саморазвитие» обычно меньше пунктов, чем в блоке «Обучение на рабочем месте», но они тоже максимально конкретны. Правда, за каждым из них уже может крыться целый список литературы.
Например, если человек хочет глубоко освоить Python, то в базовые учебные материалы сходу можно включить 3-4 хорошие книжки. А если цель связана с применением этого языка в конкретной области, например, в веб-разработке или анализе данных, то можно подобрать еще 5-6 хороших материалов. Поэтому невзирая на то, что пунктов немного, они могут быть подкреплены хорошими списками.

В подборки материалов можно включить: онлайн-курсы, ссылки на электронные библиотеки, статьи, доклады на конференциях. Но моя попытка составить такие подборки самостоятельно провалилась, я не во всех областях эксперт. Лучше предложить составлять такие списки и вести их в системе обмена знаниями всем участникам команды и категоризировать их как раз по целям развития.

Добавляйте в тематические подборки материалов оценку Net Promoter Score (индекс рекомендации) — насколько этот ресурс понравился и можно ли рекомендовать его коллегам.

NPS в подборках поможет понять, какие материалы полезнее. Иначе это будет просто список из десятков пунктов только по одному языку программирования.

Самостоятельные проекты

Раздел самостоятельных проектов еще короче. Обычно в нём те цели, которых нет в текущих проектах и проектах на этот год. Например, у нас сейчас нет необходимости заниматься Named entity recognition (это подзадача из области обработки естественных языков), но можно придумать pet-project и реализовать его в рамках ИПР.
В свое время мне пришло озарение, что если инженер мотивированный, скорее всего, у него такие pet-project уже есть. Может быть, он даже занимается ими на работе, просто вы об этом не знаете. Это хороший повод, чтобы они наконец вышли наружу. Поэтому мне очень нравится, когда эти пункты предлагают сами сотрудники. Тогда можно узнать, допустим, что ваш специалист по обработке естественных языков изучает Kotlin, чтобы писать мобильные игры. Если этот процесс и так уже идет, почему бы не взять его на вооружение, если это когда-нибудь потребуется.

С другой стороны, самостоятельные проекты спасают наш прод от внедрения технологий ради интереса. Потому что можно сделать очень короткую задачку, в течение года потратить одну-две недели и за это время проверить технологию в деле.

Самостоятельные проекты обычно не имеют внешнего заказчика, им может выступить руководитель и предложить такие варианты задач:

• Сделать внутренний инструмент для команды.
• Проверить продуктовые идеи — иногда хорошие идеи приходят из команд разработки, а не от продакт-менеджеров.
• Подготовить доклад — для этого точно придется получше разобраться в теме.

Но важно не пытаться навалить всё и сразу. Если запланировать на первый квартал и обучение на рабочем месте, и самообразование, и самостоятельные проекты, многое точно не будет сделано. Нужно стараться максимально их размазывать. К счастью, дедлайны в индивидуальных планах развития появляются очень редко.

Обратная связь

Моя команда оставила обратную связь по этому инструменту. В нём есть и плюсы, и минусы.

Плюсы ИПР:

• Удобная и эффективная практика, которая позволяет определить цели, необходимые для индивидуального роста и методы их выполнения.
• Постоянный мониторинг дает возможность оценить полученные навыки или, наоборот, обратить внимание на отстающие моменты.
• Самообразование очень продуктивно встраивается в рабочий процесс.
• Позволяет оценить, куда стоит двигаться, каким областям уделить внимание в первую очередь, и они будут при этом полезны в работе.
• Позволяет не пытаться оптимизировать все метрики сразу.
• С подобранными материалами легче перейти, собственно, к изучению, потому что есть список конкретных книг и курсов.
• Частично отвечает на вопрос «Чем я вообще занимаюсь».
• Создает ощущение, что ты не стоишь на месте, и даже можно посмотреть, что нового узнал за год.

Минусы ИПР:

• Может возникнуть ситуация отсутствия задач под определенные цели. Конечно, даже при наличии самостоятельных проектов иногда нет текущих задач для закрепления.
• Пункты из раздела Soft skills непонятно, как оценивать.
• Как-то так вышло, что последние месяца два почти не встречались, что позволило забыть про план. То есть хотелось бы сделать акцент на регулярности встреч.

Выводы

Итак, вот основные рекомендации по работе с ИПР:

• Составляйте план — наличие плана лучше его отсутствия, и команда согласна с этим.
• Распределяйте задачи с учетом ИПР.
• Составляйте списки материалов с привлечением команды и используйте их как инструмент саморазвития.
• Используйте самостоятельные проекты как экспериментальную площадку для закрепления навыков, когда а в текущих проектах таких задач нет.

Полезные ссылки

• Programmer Competency Matrix.
• How to create a Skills Matrix for Success.
• Harvard Manage Mentor — Developing Employees.
• A framework for evaluating data scientist competency.
• Data Science Competency Matrix.
• T-shaped, Pi-shaped and Comb-shaped skills.

25 мая начинается двухнедельный фестиваль «Российские инетрнет-технологии» — всё, чтобы подстегнуть профессиональное развитие. Вот несколько мастер-классов, которые пригодятся тимлидам и тем, кто собирается ими стать:

• Двухстороннее собеседование: как собеседовать компанию? / Анна Афонина, Виталий Левченко, Александр Швецов.
• Инструменты декомпозирования, планирования и приёмки задач / Алексей Ягур (YouDo).
• Практики развития личной эффективности руководителя / Ирина Шилова (СКАУТ-Академия).

А подбор программы на осенний Saint TeamLead Conf идет своим чередом. Если хотите выступить — пишите. Чем раньше, тем лучше, потому что мы не ждём дедлайна, чтобы начать принимать доклады в программу конференции.