О нет, опять, только не это!

Начальник отдела только что сказал нам о том, что нас ждет очередная реорганизация. Все, о чем я мог думать во время его речи — «Ну вот, приехали».

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

Почему большинство разработчиков на дух не выносят перемен? На то есть немало причин, которые заставляют срабатывать естественные механизмы защиты человека. Эти причины берегли нас от опасностей столетия, мы выживали благодаря страху и скептицизму. Почему же наша реакция на крупные изменения связана с негативными ощущениями, а не с чувствами положительного принятия и оптимизма?

Потому что большинство из нас уже по горло сыто переменами.

Особенно справедливо это бывает в тех случаях, когда у команды разработчиков появляется какой-нибудь новый менеджер, собирающийся оставить свой след в истории организации. Как много живых менеджеров приходит в новый коллектив и говорит «Вот это да, ваши процессы и технологии настолько совершенны, что мы все оставим так, как есть?»

Я не уверен, что когда-либо вообще услышу эту фразу!

Конечно же, люди давно открыли в себе это сопротивление любым переменам. Недаром популярная книга на эту тему «Кто украл мой сыр?» (“Who Moved My Cheese”) продалась 23 миллионами копий. Но разработчики, как правило, стремятся анализировать всю поступающую информацию, и слишком простые метафоры, приведенные в ней, покажутся им глупостью. Прочти они эту книгу хоть сотню раз и даже посети семинар — это никак не повлияет на них, особенно в том случае, если в своей карьере они уже не один раз сталкивались с неудачными переменами.

И вот вам пять причин, почему у нас проявляется сопротивление переменам и небольшие советы и размышления по поводу того, как мы можно с этим справиться.

Стыд

Наша команда создала руководство по поддержке и обновлении ERP-системы предприятия, которые мы сами находили просто отличным. Когда мы приступили к работам, все и правда шло прекрасно — но лишь до той поры, пока мы не налетели на неудачный переносом данных во время проведения обновления. Нашему IT-директору досталось от финансового отдела, а следующим «получил по заслугам» наш менеджер.

Когда стало ясно, что причина в том, что в руководстве по процессу разработки есть много несогласованных шагов, то наш менеджер нанял консультанта, который должен был переписать этот документ с нуля. Он сообщил нам всем об этом решении по электронной почте, буквально разорвав на части наш нынешний план — и все это случилось где-то посередине процесса работы.

Мы все погрузились в транс. Теперь нам стало очевидно, что мы не просто допустили ошибку, которую можно легко исправить; наша команда на глазах теряла лицо перед остальным предприятием — причем дело происходило по той части, за которую нам обычно хлопали по спине.

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

Вот почему мы тайно сохранили исправленную копию старого руководства. Наш менеджер, кстати, так и не узнал об этом — а у нас никогда больше не возникало проблем.

Всего этого можно было бы избежать, если бы наш менеджер не отреагировал на проблему слишком серьезно. Так что небольшой совет — найдите время для того, чтобы выполнить анализ проблемы «пост мортем», прежде чем принимать решение о масштабных переменах.

Неудачное планирование

На этот раз наша команда команда успевала все в срок; еще одно тестирование — и мы выходим на «золото». Затем глава контроля качества решил переиначить процесс тестирования, включая изменение критерия успешного прохождения (pass/fail criteria). Даже в лучшие времена подобное решение не было бы принято без некоторого ворчания со стороны разработчиков.

Но, Джобс вас дери, почему вы решили это сделать именно сейчас?!

Команда разработчиков взбунтовалась. Мы поклялись, что не будем мыться и бриться до тех пор, пока руководство не изменит своего решения. Конечно же, это было немного по-детски и не принесло никаких результатов. Вдобавок ко всем проблемам, нам вскоре стало слишком душно сидеть всем вместе, так что мы не продержались и нескольких дней.

В конце концов, выпуск приложения был отсрочен на целых три недели. И каждый из нас был (совершенно несправедливо!) признан ответственным за это, как было написано в отчете об эффективности нашей работы.

На самом деле, Стив Джобс возможно поступил бы точно так же, как наше руководство — все потому, что он был перфекционистом. Конечно же, это не приносило ему большой любви среди разработчиков Apple, как и не принесло нашему менеджеру по контролю качества.

Если вы собираетесь что-то изменить в процессе разработки, то сначала проанализируйте риски — чтобы потом не удивляться результатам.

Страх

Страх очень часто становится причиной номер один, по которой люди стараются избегать перемен. Я уже сталкивался с этой темой, когда один из наших разработчиков предложил использовать Scala как новый основной язык разработки. Остальная часть команды (включая нашего менеджера) испугалась таких серьезных перемен.

Команде не хватило уверенности в себе даже на то, чтобы просто попробовать новый язык. Да, настолько тесно они прикипели к тому, что использовали годами — и они не захотели покидать зону комфорта.

Страх можно обойти при помощи новых знаний и повышения уверенности в себе. Если разработчик работал с одной и той же технологией уже много лет, то менеджеру не стоит считать, что его предложения об использовании чего-то другого ждут принято с распростертыми объятьями. Кроме того, из личного опыта могу привести пример, когда я одновременно был и восхищен новым языком, и напуган. В это время в голову приходят разные мысли… А что если я просто не смогу его осилить? Что если я потеряю свою работу?

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

Недоверие

В начале своего рассказа я указывал на то. что наш предыдущий опыт может в итоге привести нас к скептицизму относительно всего нового. Это обстоятельство обязательно следует учитывать.

В моем случае, новый начальник пытался изменить что-то лишь потому, что ему хотелось показать себя. Да, пусть все сделанное до него и нуждалось в улучшении, но сначала ему следовало провести с нами какое-то время, а не приступать к делу без всякой подготовки.

Если вы стали новым руководителем в организации, то прежде чем вы соберетесь что-то менять, озаботьтесь доверием к себе. Узнайте у работников о том, что они думают по поводу изменений, проведите дискуссии за круглым столом — займитесь исследованием того, что вам предстоит изменить! И если вашу голову после этого не покинет мысль о том, что надо что-то менять, то будьте максимально аккуратны в своих объяснениях, зачем вам все это понадобилось, и старайтесь как можно больше опираться на факты.

        Активное сопротивление — Пассивное сопротивление — Принятие — Активная поддержка

Просто «потому что»

А факт состоит в том, что многим разработчикам просто не нравятся перемены. Возможно, им трудно с ними справляться; тогда не важно, насколько хорошо вы будете обучать их тому, как можно легко разбираться с ними или хотя бы предугадывать — они все равно никогда не примут перемен.

В итоге получается что-то вроде борьбы демократов и республиканцев в США: ни те, не другие никогда окончательно не победят хотя бы потому, что каждый твердо уверен, что он — прав, а его соперник — нет. Часто разработчик бывает настолько верен какой-то одной технологии, что даже не будет вслушиваться в любые ваши аргументы в пользу другой.

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

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

Автор: HotWaterMusic

Источник