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