Как на самом деле писать IDP для разработчиков

Знаете, в чём главная беда индивидуальных планов развития? Их часто составляют ради галочки. Тимлид гуглит шаблон, закидывает туда пару пунктов для развития, а сотрудник благополучно забывает об этом до следующего ревью.

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

Если заставить фронтера учить Rust просто потому, что это модно, он выгорит или уйдёт. Если разрешить ему полгода ковырять то, что бесполезно для продукта, то бизнес не поймёт, за что платит. Ищите точку соприкосновения. Разработчик хочет прокачать архитектуру, а в бэклоге висит рефакторинг старого легаси модуля? Отлично, закрепите задачу за ним, дайте время на проектирование и станьте его ревьюером. Выиграют все.

IDP - это не список абстрактных лозунгов в духе улучшить софт-скиллы. Любая цель должна быть осязаемой и ограниченной по времени (например, на 3 месяца). Если мы качаем софт-скиллы для командного взаимодействия, то критерием успеха должно быть не прочесть книгу, а конкретное действие. Например, самостоятельно декомпозировать крупную фичу и защитить ее архитектуру перед командой. Теория без практики выветривается за пару недель.

Не пытайтесь впихнуть в план десять технологий. Выберите одну, максимум две цели на полгода и заложите под них ресурс. Если 1005 времени уходит на тушение пожаров, никакой IDP не взлетит. Договоритесь на берегу, сколько чесов в неделю человек легально тратит на развитие. И обязательно раз в месяц проверяйте прогресс и вовремя корректируйте курс, если проект штормит.