Назад

# Как руководителю спорить и убеждать? Tags: менеджмент, управление, база знаний Статья - сборная солянка мыслей и методов по спорам, убеждению, объяснению и корректировке сотрудников. На работе всегда есть устои, нормы, а иногда правила, регламенты, требования. Важно, чтобы все сотрудники соблюдали их, это залог продуктивной работы компании и принимали их - это залог их личной эффективности. Спорить и убеждать - это трудная задача, на нее тратится много сил и энергии. Кажется что время, потраченное на убеждение человека - потеряно впустую и оно отчасти так и есть, хочется сказать: "тебе же деньги платят, чтобы ты работал по правилам". Но люди разные, все понимают немного по-своему, правила часто сформулированы не идеально, поэтому часто, вводя новые регламенты/правила, лучше выделить специальное время для устного объяснения сотрудникам. Есть мнение, что любые правила нужно периодически освежать в памяти, например раз в год выступая перед сотрудниками, рассказывая про "политику партии". >> Есть мнение, что любые правила нужно периодически освежать в памяти, например раз в год выступая перед сотрудниками ### Я не понял Почему сотрудник может не захотеть соблюдать правила? - Это новые правила Практически всегда у людей есть сопротивление чему-то новому, особенно если это касается работы. Человек может совершенствоваться в своем ремесле, а вы вводите правила, которые не вписываются в его картину деятельности. Или просто нагружаете дополнительной работой. Часто можно услышать мнение: "мне работать нужно, а не заниматься этой фигней!" **Важно быть твердым.** Все новое вводится так, а чтобы закрыть какие-то проблемы или что-то улучшить. Поэтому важно объяснить человеку зачем это нужно, чтобы он это принял и чтобы это правило закрепилось, а не исчезло через месяц. **Запишите обратную связь.** Во время общения можно подчерпнуть много обратной связи, возможно что-то не учтено в новых правилах. Это очень полезный поток информации, нужно поблагодарить человека, если это было конструктивно и по делу. Но правило человеку все равно придется исполнять, даже если оно не идиально. Будьте тверды. - Правила не поняты Делать все идеально - плохо. Поэтому и правила иногда записаны не совсем доходчиво. Придется объяснять, но есть несколько способов облегчить себе жизнь. **Сохраняйте подробные объяснения.** Когда я пишу новую статью в wika, каждый раз получается слишком разжевано. Читать длинные портянки текста ни кто не хочет (особенно когда заставляют), ими трудно пользоваться в работе. Приходится удалять до 80% текста. Остаются короткие, емкие правила, принцип которых легко понять и которые просто исполнять. Но удаляются и полезные вещи: посыл, смысл, предпосылки, истории. Иногда может случиться так, что тебе нужно объяснить правило, а ты сам уже не помнишь зачем оно было придумано. Поэтому рядом с сокращенной версией, под спойлером я оставляю оригинал: на работе смеемся, что если распечатать wika - получится методичка, а если развернуть спойлеры - бизнес-роман. Также стоит упомянуть, что стоит сохранять протоколы совещаний, по ним тоже можно реконструировать предпосылки принятия тех или иных решений. **Обновите правила.** У нас есть правило, по которому мы ведем документацию к продуктам: если клиент прочитал страницу и ничего не понял - значит ее нужно изменить и написать более понятно. Тратим немного больше усилий, зато другие клиенты все поймут и не обратятся к нам с вопросами. Так же и с правилами внутри компании, если вы объяснили правило устно и сотрудник сразу же все понял - стоит выделить время и переформулировать правило. Тут все немного сложнее, так как мы допускаем что документация может быть длинной, но правила должны быть короткими и емкими - возможно, придется поперебирать различные формулировки, чтобы найти нужную. >> Если уж тратить время, то с размахом... **Никогда не объясняй одному человеку.** Если объясняются какие-то общие правила или политика компании, возможно пришло время "толкнуть речь" перед всем отделом, но чаще это бывают какие-то мелкие вещи, которые хочется быстро решить тет-а-тет. Но важно позвать еще кого-нибудь из коллег сотрудника, чтобы знания или понимание вопроса лучше распространялись в коллективе (а если вы считаете, что все коллеги это правило итак понимают - тогда почему они его не объяснили своему коллеге?). Возможно, наличие третьих лиц не даст разгореться бурным спорам, но я не измерял. **Ну и по мелочи.** Если, в ходе разговора вы обсудили что-то, что еще не записано в регламентах - попросите человека записать это в корпоративную базу знаний и скинуть вам ссылку. Этим вы обновите тексты правил и заодно, прочитав обновления, проверите правильно ли вас поняли. Если есть возможность заснять объяснения на камеру, записать на диктофон или вы нарисовали большую диаграмму на маркерной доске и есть фото - очень хорошо, медиа-материалы часто намного понятнее и эффективнее текста. Плюс, они хорошо подойдут для обучения новых сотрудников. - Правила забыты или неизвестны Порой вы сами можете забыть правила, которые составляли на горьком опыте. Или написали их в корпоративной wika и посчитали что на этом ваша миссия выполнена (все сразу радостно начнут эти правила выполнять). Нужно чтобы сотрудники не только узнавали о новых правилах, но и освежали их в памяти время от времени. **Придется объяснять. Снова.** Инструкции не идеальны, правила не идеальны, память тоже. Уже обсуждали выше - упомяну еще раз. **Перепрочтение инструкций.** Не самое веселое занятие, но ежемесячное/ежеквартальное перепрочтение всей корпоративной wika - самый надежный способ поддержания знаний у сотрудников. Мы, например, прописали в должостных чеклистах задачу по перепрочтению статей. **Как не надо делать.** Помимо обычных статей в wika у нас есть модерация заявок в тех.поддержке - краткое текстовое резюме и оценка работы по заявке от модераторов. Новые модерации обязательны к прочтению не только инженером из заявки, но и всем инженерам технической поддержки. У разработчиков есть код-ревью, интересные споры оттуда мы переносим в стати "Как не надо делать" и "Как надо делать", например <http://opencarbon.ru/правила_разработки:start> "виновник" - пишет, все остальные читают. **Виджет "Я прочитал".** У статей в нашей wika можно добавить виджет, на котором можно отметить что ты прочитал статью. Там же можно увидеть список тех, кто еще не прочитал статью - если необходимо чтобы все прочитали. В будущем планируем сделать автоматический контроль прочтения, список непрочитанных статей, рассписание сброса флага "прочитал" для перепрочтения. **Контроль.** Любые правила, особенно новые - нужно контрллировать. Правила без контроля быстро перестают исполняться. Поэтому, чтобы не переучивать отдел с нуля через год-два, нужно организовать регулярный контроль и проверки. Это может быть, выше упомянутая модерация, код.ревью, а также 1 на 1 совещания с руководителем с обсуждением выполнения ежемесячного чеклиста из должостной. **Devops!** Если есть возможность автоматизировать контроль правила, будь то прочтение модерации, соблюдение стиля кодирования, соблюдение временных рамок общения с клиентами в заявках - нужно автоматизировать. Даже если это больно принимают (например, внедрение crab_syntax - анализатора кода для bash), если сразу все не исправить (контроль что не становится хуже) - важно жестко и вовремя реагировать на сигналы о нарушениях, не допускать отключения скриптов контроля. GOTO "Важно быть твердым". **Фидбек.** Общаясь с сотрудниками, полезно узнать не только как у них дела, но и как им правила, не тяжело ли даются регламенты. Здесь не нужно дескредитировать правила, нужно собрать фидбек в целом по регламентам: возможно, что-то уже устарело или есть предложения по улучшениям. А еще можно постараться выявить недовольство или непринятие правил, человек может быть недовольным правилами и не говорить об этом. Важно понять это до появления конфликта или превращения человека в токсичного сотрудника. - Токсичный сотрудник Здесь отсылка к другим статьям на тему "что делать с токсичным сотрудником". ### Правила неписанные Запишите :) ### Лайфхаки **Будь тверд.** Споров быть не должно, нам важно донести до человека смысл какого-либо правила компании и собрать обратную связь, если это нужно и если она будет. Это может выглядеть как спор, но оно им не является. Если есть несколько вариантов правила/решения проблемы, и один из них зафиксирован в правилах компании - обсуждать их может оказаться безсмысленно. Особенно, если они не очень отличаются. Скорее всего, варианты уже обсуждались при создании правила. Поэтому обсуждение вариантов как способ объяснить выбор - да, как спор - нет. **Ограничивай время на объяснения.** Перед погружением в споры, выделите время. По истечении времени нужно перейти от убеждения к прямому приказу - да, у вас не получилось донести свою мысль человека и это не хорошо, но тратить все свое время на споры и убеждения - слишком расточительно. Иногда нужно приказать, без обсуждения. **Профилактика флуда.** Убеждать нужно, но это может привести к ярлыку человека с которым всегда можно интересно что-нибудь пообсуждать. Поэтому после обсуждения стоит сказать, что мы потратили свое время, на муторный, трудный и необязательный процесс, а могли дела делать полезные. Что больше мы к этому вопросу возвращаться не будем. Чтобы не было желания влезать в споры, без необходимости. **Похвали, похвали, не похвали.** Критику человек всегда воспринимает негативно, особенно профессиональную, ОСОБЕННО если он с ней не согласен. Помимо правила, что мы никогда не критикуем человека, а критикуем его деятельность, есть правило как приподносить критику. Другими словами, как корректировать поведение человека на работе. Преподавали это на тренинге по менеджменту: перед критикой обязательно нужно человека сначала похвалить, дважды. Тогда он станет лояльным и сможет принять вашу критику, не воспримет ее в штыки. Например: "Вася, я поражаюсь сколько ты книг по программированию прочитал за последний год, ты можешь решать самые сложные задачи в нашем проекте! Вчера нашел наконец баг, неделю его поймать его не могли. Но парни жалуются что ты сообщения к коммитам пишешь непонятно, смотри вот тут у нас есть статья как это делать правильно, прочитай пожалучста, чтобы парни могли понять что ты поменял. Ок?" **Не спорь просто так.** (правило не подтверждено) Дело даже не в том, что ты тратишь свои ресурсы мозга и время впустую. И даже не в том, что ты составляешь о себе мнение человека с которым можно весело поспорить. Когда ты споришь просто так, на темы по которым сам еще не сформировал четкое мнение или по "хайповым" темам - ты подаешь пример сотрудникам, что с тобой можно спорить и можно в этом споре победить. Когда тема не касается правил и политики компании - тебе не так важно убедить, ты можешь дать заднюю или замять спор - это неправильный паттерн поведения для руководителя и он будет всплывать в спорах, когда это будет касаться важных вещей, где компромисы непозволительны. **Кто твой руководитель?** Есть правила, что нельзя руководить сотрудником, "через голову" его непосредственного начальника. Кто-то придерживается правила, что стоит общаться и убеждать сотрудников непосредственно лично и в крайнем случае упрямства говорить, что будешь обсуждать с руководителем. Я считаю, что некоторые вопросы, особенно менее технические и более личностные - отдавать "на аутсорсинг" непосредственному руководителю. Можно назвать это ябедничеством, но непосредственный руководитель зачастую лучше всего понимает своего сотрудника и лучше всего сможет скорректировать его. Если не относиться к этому с негативом, а относиться как к фидбеку, то все в выйгрыше, как мне кажется. Еще один минус первого варианта мне кажется в том, что сказать сотруднику: "я скажу что ты меня не слушаешься твоему руководителю" - во много раз превысит, по уровню негатива, множество обращений непосредственно к руководителю, мимо сотрудника. Иногда в компаниях у сотрудника может быть больше одного руководителя. Например, у нас у сотрудника есть вертикальный руководитель (всегда один, непосредственный руководитель, например кур.проекта) и может быть один или несколько горизонтальных (например, руководитель тех.поддержки или технолог разработки). Мы пришли к тому, что горизонтальные руководители работают только по "техническим вопросам", а непосредственным менеджментом, основной деятельностью занимается непосредственный руководитель (который так же занимается наймом и может уволить). Поэтому вполне логично, что если дело касается эмоций, убеждений, негатива, фидбека - самый простой вариант это использовать непосредственного руководителя. Такие дела. Поспорим в комментариях?