Стратегия и тактика обучения сотрудников в проекте внедрения методологии и технологии работ
Второй закон Кларка
Единственный способ установить границы возможного
— это выйти из них в невозможное.
1. Проблема…
Среднестатистический разработчик на сегодня не является сколь-угодно подготовленным специалистом, который сможет наладить и запустить процесс управления конфигурациями.Подводя итоги прочитанным курсам приходится задаться вопросом: почему на курсы приезжают именно и только Специалисты (инструментальщики), а не Менеджеры проектов, лидеры групп разработчиков? Анализ вопросов, которые поднимаются в процессе обучения студентами и анкет заполняемых в процессе контроля передаваемых знаний, позволяют нам сделать выводы, что в большинстве случаев у менеджеров проектов, с которыми работают студенты, нет даже базовой подготовки в вопросах управления конфигурациями и изменениями.
Складывается занятная ситуация: с одной стороны, есть специалист, на которого будет возложено внедрение процесса в организацию и который прошел обучение , а с другой стороны есть руководство, которое даже на концептуальном уровне не понимает целей и задач процесса. Мало того это руководство не может пойти на курсы, так как большинство курсов отнимают 2-3 дня рабочего времени. Попробуйте примерить ситуацию на себя, ведь если вы являетесь менеджером проекта и работаете в среднестатистической разработческой компании, то вероятнее всего вы есть носитель знаний по процессу разработки. И, скорее всего, вы есть тот человек, на котором сходятся все пути — вы носитель знаний, вы определяете, как и куда будет развиваться проект, и любое ваше необдуманное решение может в итоге дорого обойтись.
Давайте признаем ситуацию неправильной и сравним ее с обучением дорожного строителя новой технике. Которая позволит в 10 раз быстрее осуществлять прокладку асфальта. Обученные специалист будет работать эффективнее, вот только если инженер не знает куда нужно вести дорогу, то эффект от подобного ускорения нулевой!
Возможно, мы слишком драматизировали ситуацию, но в большинстве случаев, понятийно непокрыты базовые вещи: работа с требованиями, управление версиями и релизами, планирование процесса, планирование внедрения, определение аналитических отчетов. Их просто нет.
Анализируя ответы, мы сделали следующее допущение: среднестатистический менеджер проекта на сегодня не является сколь-угодно подготовленным специалистом, который сможет наладить и запустить процесс управления конфигурациями в полном объеме. Имеет ли смысл в такой ситуации вкладывать силы и время в обучение работе с конкретными инструментальными решения? Ответ напрашивается сам собой — нельзя — это просто пустая трата времени, сил и денег.
Позволим себе несколько революционный лозунг или скорее даже воззвание: давайте всё-таки отдавать себе отчёт в том, что <белые пятна> в собственных знаниях менеджера не закроются путём обучения специалиста навыкам работы с Инструментом.
Получается замкнутый круг. Специалист не влияет на общую ситуацию (за редким исключением), а люди, чей опыт и знания помогут провести успешное внедрение слишком заняты, чтобы этим заняться. Причем самое обидное в том, что постановка процесса позволит снизить нагрузку на менеджеров за счет формализации, повышения прозрачности… и т.д., все, о чем говорилось выше.
Из ситуации есть только один выход — посещать общие курсы самим (пусть это будут непродолжительные и не детальные курсы), а на специализированные отсылать специалистов.
2. И все же…
Обучение является ключом к успеху. В зависимости от квалификации и опыта, сотрудникам может также потребоваться дополнительное обучение в конкретных областях. Например, для разработчиков может потребоваться обучение языку UML , а для пользователей — обучение использованию прецедентов и управлению требованиями. Если прикладные области углубленного обучения и пилотного проекта совпадают, то проектная группа может подготовить мини-проект, аналогичный пилотному, не опасаясь возможной неудачи и не тратя напрасно время.
Важным побочным результатом обучения является создание сплоченного коллектива, который формируется лишь в том случае, если члены группы обучаются совместно.
Обучение, связанное с конкретным инструментом, проводится перед планируемым использованием этого инструмента. В проектной среде такое обучение обычно проводится в форме семинара, на котором изучаются функции инструмента, имеющие отношение к проекту, а основное внимание уделяется артефактам проекта.
Когда проектная группа начинает внедрять новую технологию или методику, ей требуется инструктаж.
Напомним, что недельное обучение заменяет собой 6-7 месяцев самостоятельных поисков методом проб и ошибок.
3. Классификация тренингов — залог успеха
Перед тем, как мы займемся стратегией успешного обучения, давайте определимся с типами курсов, которые необходимы для успешного внедрения любой методологии.
Ниже приведена классификация курсов по типам:
1. Предварительное обучение (когда компания выбирает методологию и инструменты).
2. Обучение в проекте (перед пилотным проектом).
3. Обучение всех сотрудников (после пилотного проекта).
Рассмотрим подробнее каждый из типов:
3.1 Предварительное обучение (когда компания выбирает методологию и инструменты для внедрения)
Данный тип курсов наиболее распространен — специалисты записываются в сборные группы в учебных центрах.
Кого учим? Менеджер проекта, лидеры разработчиков, разработчики Положительные стороны: За короткое время и без потерь слушатели получают много информации и могут сделать вывод о
применимости методологии и инструментов для целей их проекта. Отрицательные стороны:
На таких курсах рассматриваются очень общие, усредненные примеры (искусственные).
Если полученные знания не будут подкреплены практикой в первые 2 месяца после обучения,
то ценность такой учебы также низка.
Выводы:
Если организация не знает, какую методологию и технологию работ нужно внедрить,
если в организации есть новые специалисты которых нужно обучить, то данный тип курсов обеспечивает успех.
3.2 Обучение в проекте (перед пилотным проектом)
Перед внедрением всегда выделяется пилотная группа, которая проходит курсы. Причем курсы делятся не только по инструментальным средствам, но и по уровням руководства.
То есть необходимо проходить некую общую часть всем участникам, а потом разработчикам, менеджерам и остальным участникам рассказать их часть.
Но тут следует иметь ввиду, что пилотная команда должна знать максимум о внедряемой методологии и инструментах.
Гораздо больше, чем те участники, которые потом будут по ней работать.
Кого учим? Менеджер проекта, лидеры разработчиков, разработчики. По большому счету учим всех тех, кто является
участником пилотного проекта. Положительные стороны: Пилотное внедрение на подходе. Люди получают информацию, которая тут же применяется в проекте. Отрицательные стороны:
Нет. Главное, чтобы в пилоте работал тот, кто прошел обучение
Выводы:
Наш опыт показывает, что в большинстве случаев заказчики хотят обучить на этом этапе максимальное
число сотрудников. Этого делать ни в коем случае нельзя, и дело не в том, что «жалко» обучать, а дела
в том, что обучение для остальных пойдет только во вред. Вся компания не будет заниматься внедрением и эти
специалисты «заржавеют» уже к середине пилотного проекта.
3.3 Обучение всех сотрудников (после пилотного проекта, либо по ходу внедренных частей процесса)
Еще раз отметим, что пилотная группа проходит максимальное обучение по всем инструментам и технологиям. Всем остальным сотрудникам не нужно владеть технологией и инструментом в его полном объеме.
Глупо объяснять техническому писателю функции по администрированию конкретного инструмента. Глупо разработчику рассказывать о тонкостях использования инструмента. На этапе проведения пилотного проекта организация получает адаптированный процесс, в котором расписаны все роли и виды деятельности. Соответственно и цель данного типа курсов: обучить специалистов в соответствии с их ролевым предназначением. То есть, учим не всему, что есть, а выполнению конкретных функций в адаптированном процессе (ставим на конвейер).
Этот тип обучения может занять много времени, так как нужно обучить всех сотрудников. В этом случае составляется программа курса и начинается «волновое» обучение в соответствии с выполняемой ролью.
Очень эффективен подход, при котором собираются группы по 10-12 человек из разных отделов и в форме деловой игры обучаются на живых примерах (здесь уже не нужна общая теория), на практике.
Кого учим? ВСЕХ
Положительные стороны: Люди получают только необходимый комплект знаний по свое работе. Нет загромождения и отторжения новой технологии. Отрицательные стороны:
нет. Единственное, что может иметь негативный результат — в компании может не быть людей у которых есть опыт обучения.
В этом случае придется приглашать специалистов со стороны.
Выводы:
мы хотели поставить процесс и сделать так, чтобы каждый участник выполнял отведенную ему роль.
Данный тип обучения позволит сделать это в полной мере.
4. Стратегия обучения и общий план подготовки специалистов. Как правильно и недорого обучить специалистов
Подведем некоторый итог написанному выше. Выделим темы, которые необходимо рассмотреть при обучении (безотносительно средств автоматизации) и составим примерный сценарий в виде плана. Определим состав тем для курсов в зависимости от типа курса. За отправную точку возьмем внедрение дисциплины управления конфигурациями.
Тип курса Роль
Тематический план
Объем в часах
Предварительное обучение
Руководитель
Лидер разработчиков
Лидер тестировщиков
Аналитик
Архитектор
Основы методологии.
Цели и задачи УК
8-16 часов Лидер группы разработчиков
Администратор
Интегратор
Планирование и осуществление дисциплины
(включая средства автоматизации) 30-40 часов
(с использованием
общих примеров)
Обучение в проекте
(перед пилотным проектом) Руководитель
Лидер разработчиков
Лидер тестировщиков
Аналитик
Архитектор
Основы дисциплины и средств автоматизации.
Цели и задачи дисциплины 8-16 часов Лидер группы разработчиков
Администратор
Интегратор
Планирование и осуществление дисциплины
(включая средства автоматизации) 30-40 часов
(применительно к
проблемам компании. То есть
на практических примерах)
Остальные участники пилотного
проекта Основы работы со средством автоматизации 5-6 часов Обучение всех сотрудников
(после пилотного проекта) Все
Введение в адаптированную методологию
(читается не общетеоретический курс, а о том,
что уже внедрении и как это использовать на практике)
3-4 часа Руководители Основы дисциплины для руководителей
+ инструментальное средство 6-7 часов Все, кроме руководителей
Основы дисциплины для руководителей
+ инструментальное средство 6-7 часов
Данные, используемые в таблице получены на основе личного опыта и не претендуют на объективность или непогрешимость. Остается только добавить, что данные получены на основе нескольких десятков внедрений.
5. Заключение. Общая последовательность действий при подготовки обучения
В заключении приведем общий план для организации, которая стремится внедрить новую технологию, дисциплину, средство и так далее. Отметим, что приведенный план рассчитан на тех, кто не имеет внедренной дисциплины или инструмента, и перед руководством стоит цель ВЫБОРА и последующего ВНЕДРЕНИЯ. Обучение в данном плане лишь один из винтиков большой машины под именем выбор и внедрение технологии:
1. Посылаем на обучение 1-2 человек, чтобы подобрать подходящую методологию. Очень трудно выбрать технологию по книжкам и статьям. ОБЯЗАТЕЛЬНО необходимо отослать лидеров проекта на НЕСКОЛЬКО курсов по тематике планируемого внедрения.
2. Принимаем решение о внедрении. Специалисты в обязательном порядке составляют отчет и пытаются дать прогноз о том приживется новая технология или инструмент в организации или нет. Почему важно обучить нескольких специалистов: руководству будет проще принять решение, основываясь на мнении нескольких специалистов (желательно обучать специалистов из разных отделов, так как взгляд на один и тот же объект у людей в принципе разный, а у специалистов из разных отделов он более ярко выражен)
3. Открываем пилотный проект. Внедрять технологию в организации без пробы на чем-то мелком — неразумно. Выбираем некритичный проект и обкатываем технологию.
Далее по накатанной схеме:
4. Обучаем пилотную группу (всему, что есть в методологии и инструментах)
5. В рамках пилота получаем свой адаптированный процесс
6. Обучаем всех сотрудников адаптированному процессу (каждого своей части работ и задач)
Автор: Новичков Александр
www.cmcons.com
