Составлял на работе “индивидуальный план развития сотрудника” и понял что именно мне не нравится в этой штуке.
1. Нет никакой связи между задачами на работе и этим самым развитием. Можно качать навык по БД но если задач на это нет - то и навык быстро уйдет и не закрепится.
2. На развитие нужно время и ресурсы - или программист тратит свое личное время, или тратит рабочее. Ни компания ни человек - особо тратить свое время и ресурсы не хотят.
3. Мотивация - выполнение какого либо пункта из плана развития сотрудника никак на него не влияет. И тут вопрос даже не про повышение оклада или грейда - а про промежуточные шаги, прогресс по развитию.
4. Выставление целей по методикам типа STAR на начальном этапе чаще всего туманно. Непонятно можно ли будет получить практический результат, можно ли его будет оценить?
5. ИПР это штука обязательная, но почему-то за пару лет все синьорами не стали. И не станут. И не факт, что хотят. И не факт, что нужно.
6. Есть бизнес задачи, цели спринта, итерации, квартала, до отпуска надо дожить, давайте после майских. Развитие не в фокусе. И это относится и к разработчику и к руководителю.
Как заставить эту штуку работать? И быть полезной и сотруднику и тимлиду? Что я делаю или пробую делать.
1. Нужен список болей, проблем, точек роста конкретно у вас на рабочем месте. Запросы долгие, процесс хромает, документации мало - с таким списком сотруднику будет легче выбрать навык который он может прокачать на практической проблеме.
2. Не делайте эту штуку обязательной: кто-то просто не захочет делиться своими планами, у кого то они просто не совпадают с вашими. Шапочно знаю одного девопса который активно осваивает пивоварение в свободное время и уже строит себе цех под Кропоткиным(никакого кубернетеса).
3. Если у человека все таки есть план развития - и он сам его составил, помогайте, спрашивайте про прогресс, отмечайте его.
Всякие штуки типа evolution review могут быть полезными только если обе стороны видят в них пользу иначе это свалится в бюрократию и демагогию.
1. Нет никакой связи между задачами на работе и этим самым развитием. Можно качать навык по БД но если задач на это нет - то и навык быстро уйдет и не закрепится.
2. На развитие нужно время и ресурсы - или программист тратит свое личное время, или тратит рабочее. Ни компания ни человек - особо тратить свое время и ресурсы не хотят.
3. Мотивация - выполнение какого либо пункта из плана развития сотрудника никак на него не влияет. И тут вопрос даже не про повышение оклада или грейда - а про промежуточные шаги, прогресс по развитию.
4. Выставление целей по методикам типа STAR на начальном этапе чаще всего туманно. Непонятно можно ли будет получить практический результат, можно ли его будет оценить?
5. ИПР это штука обязательная, но почему-то за пару лет все синьорами не стали. И не станут. И не факт, что хотят. И не факт, что нужно.
6. Есть бизнес задачи, цели спринта, итерации, квартала, до отпуска надо дожить, давайте после майских. Развитие не в фокусе. И это относится и к разработчику и к руководителю.
Как заставить эту штуку работать? И быть полезной и сотруднику и тимлиду? Что я делаю или пробую делать.
1. Нужен список болей, проблем, точек роста конкретно у вас на рабочем месте. Запросы долгие, процесс хромает, документации мало - с таким списком сотруднику будет легче выбрать навык который он может прокачать на практической проблеме.
2. Не делайте эту штуку обязательной: кто-то просто не захочет делиться своими планами, у кого то они просто не совпадают с вашими. Шапочно знаю одного девопса который активно осваивает пивоварение в свободное время и уже строит себе цех под Кропоткиным(никакого кубернетеса).
3. Если у человека все таки есть план развития - и он сам его составил, помогайте, спрашивайте про прогресс, отмечайте его.
Всякие штуки типа evolution review могут быть полезными только если обе стороны видят в них пользу иначе это свалится в бюрократию и демагогию.