Последние 5 лет так получалось, сначала как доп нагрузка, потом уже по обязанностям, я отвечал за формирование и поддержание необходимой компетенции групп разработки и проектирования. За это время я даже с 0 поднял и поддерживал -) тех компетенцию нового отдела.
Этот пост начинался как ответ на простой вопрос "Как построить и наладить процесс обучения команды тестировщиков из 6 человек?", но потом сформировался в отдельную статью.
Здесь я попытаюсь прозрачно изложить те методы которые я использовал в работе и которые прошли проверку практикой.
1. Матрица компетентности
В первую очередь необходимо определится со структурой требуемой компетенции. Как говорится - нет потребностей, нет компетенции.
Для этого я использую простой список. Выделяю 2-а уровня: первый это домен знаний, второй конкретные технологии или методологии. Потом добавляю к списку колонки с фамилиями и - опа, у нас матрица компетентности.
При создании списка, который сам по себе важная задача, я использую следующие правила:
Конечно создание списка требует само по себе хороших знаний и практического опыта в данной области. Мне моих знаний хватало -). Но если вы чистый ПМ, то рекомендую не сочинять, а найти толкового ведущего и поручить ему. И заодно проверить его компетенцию по организации.
2. Специализация
После того как у вас появилась матрица компетенции, необходимо выделить Направления специализации. Необходимость данного шага является обязательной если у вас в группе можно ее выделить. То есть комплект требуемой компетенции достаточно широк и лежит в разных доменах знаний.
Например (для разработки и внедрения систем ITSM) специализация выглядела так:
Этот пост начинался как ответ на простой вопрос "Как построить и наладить процесс обучения команды тестировщиков из 6 человек?", но потом сформировался в отдельную статью.
Здесь я попытаюсь прозрачно изложить те методы которые я использовал в работе и которые прошли проверку практикой.
1. Матрица компетентности
В первую очередь необходимо определится со структурой требуемой компетенции. Как говорится - нет потребностей, нет компетенции.
Для этого я использую простой список. Выделяю 2-а уровня: первый это домен знаний, второй конкретные технологии или методологии. Потом добавляю к списку колонки с фамилиями и - опа, у нас матрица компетентности.
При создании списка, который сам по себе важная задача, я использую следующие правила:
- В список вносится только требуемая для проектов компетенция.
- При создании списка забываем о существующей компетенции людей и руководствуемся только требованиями "производства". То что человек знает PLSQL нас не волнует, если мы это не используем и не оплачиваем
- Не вносим компетенции "на перспективу" и "на интерес".
Конечно создание списка требует само по себе хороших знаний и практического опыта в данной области. Мне моих знаний хватало -). Но если вы чистый ПМ, то рекомендую не сочинять, а найти толкового ведущего и поручить ему. И заодно проверить его компетенцию по организации.
2. Специализация
После того как у вас появилась матрица компетенции, необходимо выделить Направления специализации. Необходимость данного шага является обязательной если у вас в группе можно ее выделить. То есть комплект требуемой компетенции достаточно широк и лежит в разных доменах знаний.
Например (для разработки и внедрения систем ITSM) специализация выглядела так:
- системщик (установка ОС, БД, прикладного ПО, импорт данных, прикладное скриптование)
- программист (знание продуктов и языков по платформе А или Б)
- консультант (бизнеспроцессы и обучение)
И вот тут важно - нельзя думать, что люди могут знать все. Люди знают только то, с чем непрерывно работают. Если думать, что если спец когда-то знал Яву, но последние 2-а года писал на точкаНЕТ, то Яву он все еще знает. Да знает, НО НЕ ПОМНИТ. Именно поэтому я считаю, что впрок учить невыгодно.
3. Сотрудники
Итак после пп. 1 и 2 у вас уже есть то прокрустово ложе куда надо уложить Уникальных и неповторимых личностей.
Всех личностей я при приеме на работу делю на 3-и категории:
1. "Готовый" - обладает необходимой компетенцией, готов сразу приступить к работе . Встречается редко, учить не надо. Надо выделить пару недель на ввод в курс дела и знакомство, потом еще месяц контролировать и разбирать результат.
2. "Неполноценный" - обладает необходимой базой, знает часть в своей специализации. Чаще всего такого и берем. Обучение как у Студента, но частями можно ставить на работу.
3. "Студент" - чего-то знает, есть техническая база. Надо учить
4. План обучения
Нет плана - нет обучения. Проверено.
На каждого сотрудника пишется план обучения. План включает:
- список необходимых компетенций
- состав материалов которые необходимо изучить
- достигаемые проверяемые результаты (контрольные примеры или презентация, решенные проектные задачи, что-то новое до чего все руки не доходили)
- календарные сроки
- проверяющий и ведущий
При обучении я выработал следующие принципы:
- На обучение надо выделять время (лучше всего одним куском, 3-и дня минимум. Студенты у меня учились 1 месяц минимум)
- Не надо прерывать обучение (ну если только форс мажор, но тогда надо понимать, что обучение тогда надо начинать почти заново)
- Обучение надо непрерывно контролировать. Если это общая теория- то презентация теории, если новая технология - рабочий результат. Нет результата - неспособен. Поэтому пункт 1 и 2 важны. Иначе вам обязтельно скажут - "что вы нас прерывали"
- План обучения и материалы делаете вы и передаете обучаемому в "письменном" виде
Обучаемому выделяются ресурсы:
- время (на обучение)
- деньги (на оплату курсов и зарплату)
- технические средства (тестовые машины и тп)
- методические средства (инструкции, проекты, кодовая база на чтение и тп)
- время других сотрудников, тех которые помогают или ведут обучение.
Комментариев нет:
Отправить комментарий