Индивидуальный план развития часто умирает не из-за плохих шаблонов, а из-за управленческой лени: встречи идут, документы заполняются, а нужные команде навыки так и не появляются. В материале для Habr / Менеджмент автор с опытом Head of L&D предлагает довольно неприятный, но полезный диагноз: если цикл развития не встроен в работу тимлида, ИПР быстро превращается в еще один HR-ритуал, который ест время и демотивирует людей.
Как пишет Habr / Менеджмент, главная проблема не в отсутствии курсов, матриц компетенций или корпоративных платформ. Сбой начинается раньше: руководители нередко воспринимают развитие сотрудников как чужую зону ответственности, отданную HR или L&D. В итоге цели в планах слабо связаны с задачами бизнеса, формулируются слишком абстрактно, а само развитие сводится к чтению статей, обучению и редким разговорам один на один. Автор перечисляет типичный набор симптомов: нет связи с реальными потребностями компании, нет ресурсов на достижение целей, нет среды для обмена опытом и нет системы оценки прогресса. Результат предсказуемый: команда тратит силы, но экспертиза не растет.
Самая сильная часть материала — жесткий перенос ответственности обратно к руководителю. Тимлид здесь не администратор формы и не человек, который раз в полгода спрашивает, что сотрудник успел прочитать. Он должен оценивать текущий и целевой уровень навыков, помогать с выбором приоритетов, подбирать рабочие задачи под новые компетенции, регулярно обсуждать прогресс и давать обратную связь. Плюс — создавать безопасную среду, где можно обсуждать ошибки и обмениваться практикой без страха выглядеть слабым. Для многих IT-команд это неприятная мысль: хочется верить, что развитие можно автоматизировать через LMS, каталог курсов и пару обязательных встреч. Но автор прямо говорит, что даже хорошая методология и современные HR-инструменты не спасают, если руководитель не использует цикл развития как часть управления результатом команды.
Отдельно разбирается вопрос, с которого, по-хорошему, и надо начинать любой индивидуальный план развития: зачем он вообще нужен конкретной команде в конкретный цикл. Автор предлагает смотреть на развитие не как на универсальную добродетель, а как на ответ на разрыв между текущей и будущей экспертизой. Для этого он использует матрицу «Приоритеты развития», в которую сводятся три блока: текущие и будущие роли в команде, потребности бизнеса и реальные сильные стороны, дефициты и карьерные ожидания сотрудников. Подход особенно полезен там, где в компании нет зрелой архитектуры ролей и компетенций, а это для многих российских IT-команд вполне обычная ситуация. Иначе говоря, сначала определяем, каких навыков команде не хватает для достижения целей бизнеса, и только потом открываем шаблон ИПР. Если сделать наоборот, получится знакомая корпоративная экзотика вроде цели «развить лидерство» у человека, которому в ближайшие полгода нужно просто научиться нормально вести сложные переговоры с заказчиком или брать на себя техническое решение в проекте.
Есть и вполне прикладная рекомендация, которая может понравиться менеджерам, уставшим от перегруженных планов: на цикл длиной шесть месяцев автор советует ставить не больше двух целей, а если команда новая или сам процесс еще сырой, начинать вообще с одной. Логика простая. Чем больше целей в ИПР, тем сильнее расплывается фокус и тем выше шанс, что не будет выполнено ничего. Одна цель обычно относится к профессиональной экспертизе: либо углубление в текущей области, либо освоение новой специализации. Вторая — к универсальным навыкам, которые влияют на взаимодействие и личную эффективность. Но и здесь автор предупреждает от любимой ошибки менеджеров: не записывать в план красивые абстракции вроде «тайм-менеджмента» или «коммуникабельности», если за ними не стоит конкретная рабочая ситуация. Сначала задача или контекст, потом навык. Не наоборот.
Еще один важный тезис: ядро развития находится не в теории, а в работе. Автор опирается на знакомую модель 70-20-10, но использует ее без сектантства и лишней магии процентов. Смысл в том, что навык формируется через рабочие задачи, принятие решений, запуск инициатив, разбор проблем и практику в реальных условиях. Если сотруднику нужно прокачать переговоры, ему мало пройти курс и прочитать пару статей. Нужны несколько встреч, где он действительно будет добиваться взаимовыгодного соглашения, ошибаться, получать обратную связь и пробовать снова. Для IT-команд это особенно актуально: в разработке очень легко подменить развитие потреблением контента. Люди смотрят лекции, закрывают внутренние треки, получают бейджи, а потом не меняют поведение в проекте. Автор фактически напоминает банальную, но часто игнорируемую вещь: навык без рабочего применения — это не навык, а заготовка.
При этом сам по себе опыт тоже не гарантирует роста, если команда не умеет превращать его в осмысленное обучение. Поэтому в ИПР, помимо рабочих задач, автор предлагает закладывать систему поддержки: немного теории, сопровождение более опытных коллег, регулярную обратную связь, обсуждение сложных кейсов, обучение в парах, наставничество и командные встречи. Здесь интересен акцент на safe space, который в русскоязычном IT давно перестал быть исключительно модным словом из HR-презентаций. Без среды, где можно признавать ошибки и обсуждать неудачные решения без показательной порки, развитие быстро становится декоративным. Особенно в командах, где скорость поставки продукта ценится выше рефлексии, а любая ошибка трактуется как личный провал, а не как материал для роста. Для бизнеса вывод тоже вполне практичный: если компания хочет не просто удерживать людей, а наращивать нужную экспертизу внутри, ей придется инвестировать не только в обучение, но и в управленческую дисциплину руководителей.
На фоне разговоров о кадровом голоде, дефиците сильных мидлов и дорогом найме эта логика звучит даже слишком приземленно, чтобы попасть в модные презентации. Но именно поэтому она и работает. Индивидуальный план развития в IT-команде все меньше похож на документ для HR-архива и все больше — на способ ответить на неприятный вопрос: какие навыки понадобятся бизнесу в ближайшие полгода и кто в команде реально сможет их дотащить до рабочего уровня, а не просто отметить в профиле.