«Нам это не нравится!»: как работать с сопротивлением в IT‑командах

Эту фразу я несколько раз слышал на собеседованиях на руководящие позиции в IT. Недавно услышал её снова и решил наконец написать эту статью.

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

Сразу оговорюсь: я не претендую на истину в последней инстанции. Мне интересно разобраться, что вообще означает «уметь работать с сопротивлением» и как этому научиться.

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

Что вообще считать сопротивлением?

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

Но за внешне одинаковыми реакциями могут стоять совершенно разные причины.

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

И здесь, на мой взгляд, начинается самое интересное.

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

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

Не каждое возражение нужно преодолевать

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

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

Или другой пример: сотрудник говорит, что новый процесс займёт больше времени. Это может быть попыткой избежать изменений, а может быть вполне обоснованным опасением.

Недавно я сам оказался по другую сторону такого разговора.

Руководство сообщило мне, что я как менеджер процессов должен присутствовать на всех мероприятиях команд разработки (таких 10). Решение было принято сверху, но его обоснование мне не объяснили. Единственный аргумент, который я услышал, звучал так: «Компании нужна прибыль».

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

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

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

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

Разбирай сопротивление на части

Один из основных приемов который я считаю действительно действенным это переводить оценочные суждения в факты. Например в некоторых аргументах можно задать такие вопросы:

«Это долго» - сколько именно времени занимает процесс?

«Это неудобно» - что конкретно вызывает неудобство?

«Это не работает» - на каком этапе возникает проблема?

Так оценочное суждение превращается в предмет для обсуждения. И уже можно проверить, действительно ли проблема существует, насколько она существенна и что с ней делать. Следующая история как раз об этом.

Мне предстояло внедрить новые правила создания задач.

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

С разработчиками договориться оказалось несложно: они сами были заинтересованы в изменениях.

А вот для менеджеров продукта новые правила означали дополнительные действия при создании задач. Привычный процесс усложнялся, поэтому неудивительно, что они отнеслись к изменениям скептически.

После того как я рассказал о новых правилах, услышал короткое:

«Нам это не нравится».

Первое, что я сделал, - спросил, что конкретно не нравится.

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

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

Разница составила примерно 20–25 секунд.

После этого я спросил, сколько задач менеджеры создают в течение месяца. Оказалось что проблема “долго создавать задачу” не такая уж существенная.

Для меня здесь важен сам подход: я не стал доказывать, что менеджеры неправы, а предложил проверить их предположение.

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

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

Умей выслушать другую сторону и найти компромисс

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

В этот раз спорить было не о чем. Дополнительные действия действительно появились, и я понимал, почему они вызывают недовольство.

Я объяснил, что часть заполнения полей планируется автоматизировать в ближайшее время.

Но мне было важно не только объяснить, почему изменения необходимы, а ещё и показать пользу для самих менеджеров продукта.

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

Я не мог обещать, что новый процесс вообще не создаст неудобств. Но мог объяснить, зачем мы его меняем, признать реальные недостатки и рассказать, что планируем с ними делать.

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

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

Иногда для этого достаточно объяснения. Иногда приходится искать компромисс. А иногда нужно пересмотреть часть самого решения.

И это подводит нас к ещё одной ситуации.

А что, если человек согласился, но ничего не изменилось?

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

Первая реакция может быть такой: «Мы же обо всём договорились. Почему ничего не меняется?»

Но я бы не спешил делать выводы. Сначала стоит разобраться, что произошло. На мой взгляд, здесь есть три основных варианта:

• Человек не совсем понял договорённость. Вы обсуждали одно и то же, но каждый понял результат по-своему. Или договорились о принципе, но не обсудили, как применять его на практике.

• Человек не может выполнить договорённость. Например, не хватает инструментов, информации или времени. Возможно, в процессе обнаружились нюансы, которые вы не учли.

• Человек не хочет выполнять договорённость. Он понял, что от него требуется, у него есть всё необходимое, но он по-прежнему считает новый подход неправильным или просто не готов менять привычки.

В зависимости от ситуации и действовать нужно по-разному.

Поэтому вместо «Почему ты опять делаешь по-старому?» я бы спросил: «Мы договорились работать по-новому, но я вижу, что пока ничего не изменилось. Что мешает перейти на новый процесс?»

Такой вопрос не снимает с человека ответственности, но позволяет разобраться в причинах, прежде чем предъявлять претензии.

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

Я объяснил модель одному из продакт-менеджеров, мы обсудили подход, и он согласился его использовать. Через неделю я увидел, что задачи по-прежнему остаются без оценок.

Можно было решить, что человек просто не хочет следовать договорённостям, и потребовать соблюдения новых правил. Но я решил сначала разобраться, в чём дело.

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

В итоге мы пересмотрели модель с учётом обратной связи.

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

При этом важно не превращать разбор возражений в бесконечное обсуждение.

Если человек понимает договорённость, у него есть всё необходимое для её выполнения, а новые аргументы или обстоятельства не появились, стоит вернуться к тому, о чём договорились.

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

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

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

Вместо заключения

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

Скорее, это обычная часть работы с людьми и изменениями.

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

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

Где-то нужно скорректировать само решение, где-то помочь людям адаптироваться, а где-то настоять на выполнении принятого решения.

И, пожалуй, именно поэтому мне сложно оценивать опыт работы с сопротивлением по одному ответу на собеседовании. Можно знать десяток техник и всё равно не разобраться в конкретной ситуации. А можно не называть происходящее сопротивлением, но последовательно пройти весь путь от возражения до договорённости.

Интересно, как вы сами понимаете этот навык? Что для вас означает «уметь работать с сопротивлением» и по каким признакам вы оцениваете, что руководитель действительно умеет это делать?