Инструменты мудрого менеджера. Принятие решений

Меня зовут Дмитрий Климчук, я методический директор компании «Инфостарт». В ИТ я с 1998-го года, прошел путь от эникейщика до исполнительного директора. Проектов у меня было очень много. С 2019-го года я ушел в сферу обучения и считаю, что немного разбираюсь в теме взаимоотношений между людьми.

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

Кейс

Предлагаю перейти к делу и сразу рассмотреть первый кейс. Но прежде синхронизируем глоссарий: в ходе доклада я буду говорить «тимид», «руководитель», «менеджер», подразумевая одного и того же человека, который непосредственно работает с командой, у кого есть люди в подчинении. Я не буду затрагивать топ-уровень, который решает стратегические вопросы. Мой доклад – про управление командой и взаимоотношения с людьми.

Итак, ситуация:

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

А если эти люди матерятся, используют ненормативную лексику?

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

А если они громко матерятся и переходят на личности?

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

Чуть-чуть изменим:

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

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

Этот кейс показывает, как из-за маленьких штрихов в рассматриваемой ситуации меняется наше решение.

Нелинейные шахматы

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

• доска не плоская, у неё есть несколько измерений;

• играют в эту партию больше двух человек;

• фигуры на доске имеют свободу воли – могут принимать какие-то самостоятельные решения;

• правила могут меняться;

• и как в любой игре, в управлении людьми есть свои тонкости.

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

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

Элементы этой системы для тимлида – все то, что окружает его на работе:

1. Процессы, проекты или задачи.

2. Команда (состав, состояние).

3. Сотрудник (состояние, поведение).

4. Начальник (ресурсы, решение).

5. Заказчик (проекты, деньги).

Через эти элементы тимлид (или руководитель подразделения) ведёт свою шахматную партию.

Ключевой элемент в системе – это сотрудник. Причем сотрудник – это в первую очередь личность человека и его роль.

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

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

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

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

Для каждой из групп элементов в системе у менеджера есть свой богатый набор инструментов влияния:

• мы знаем, как управлять проектами;

• как мотивировать человека;

• как строить команду.

Но когда в системе происходит сбой, мы озадачиваемся: «Как так? У меня же такой инструментарий!» А дело не в инструментах. Дело в том, что умный менеджер умеет разруливать сложные ситуации на работе, а мудрый в эти ситуации не попадает.

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

Универсальный алгоритм

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

1. Нужно определиться, надо ли вообще вмешиваться в ситуацию.

2. Собрать первичную информацию, чтобы понимать, на какой поляне мы находимся.

3. Уточнить информацию – посмотреть ее предысторию, очистить от эмоций, работать только с фактами.

4. И только потом – выбирать решение и контролировать его исполнение.

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

Так устроен наш мозг – когда он видит знакомую ситуацию, он говорит: «Я знаю, как это решать». И выдает решение. На эту тему рекомендую почитать книгу Дэвида Канемана «Думай медленно, решай быстро».

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

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

0. Надо или не надо вмешиваться?

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

Посмотрим на этот же кейс еще раз.

Как мы принимали решение о том, надо ли вмешиваться? Очень просто: мы заглядывали в будущее, конструировали его. И чем страшнее будущее, тем решительнее хотелось туда вмешаться.

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

Работа с рисками – это таблица с вероятностями. Но на ходу, идя по коридору, никто такую таблицу составлять не будет. Чтобы сделать это быстро, нужно задать себе два вопроса:

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

2. Если не вмешиваться, что будет?

Посмотрим несколько ситуаций, где необходимость вмешательства определяется контекстом:

Ситуация №1. Вам внезапно звонит админ и говорит:

• «Сервер лег, восстановлю через 20 минут». На работу влияет? Влияет. Надо ли вмешиваться? Я бы не стал – в любом случае через 20 минут сервер восстановят, и я вернусь к работе. В худшем случае, надо будет просто через 20 минут проконтролировать, что все корректно восстановилось.

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

Ситуация №2. Заказчик звонит напрямую вашему тестировщику.

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

• А вот если заказчик звонит ведущему разработчику, то последствия могут быть хуже – задачи встали; непонятно, какие изменения будут в проекте, в который погружен этот ведущий разработчик; а в худшем варианте еще и сманят разработчика к себе. Зачем мне это? Однозначно стоит вмешаться.

Ситуация №3. Ведущий разработчик постоянно опаздывает.

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

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

Ситуация №4: бухгалтерия ввела новую форму отчетности за командировки.

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

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

1. Сбор информации

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

Кейс: заходит сотрудник, назовем его Петя. Говорит: «Вася – идиот. Так работать невозможно, я больше не буду с ним разговаривать».

На работу влияет? Влияет. А что будет, если не вмешиваться? Непонятно. Но вмешиваться надо, так как единственный факт, с которым здесь можно работать – то, что Петя не будет больше с Васей разговаривать. У этого факта перспективы вариативные и очень неприятные.

Но сначала надо выяснить, что происходит.

1. Включаем доктора, собираем анамнез. Задаем вопрос: «А что произошло? Ты чего вообще пришел? Что случилось?»

2. В чем это выражается?

3. Почему это плохо?

4. А как хотелось бы?

Проиграем этот кейс. Спрашиваем:

– Что происходит?

– Вася прислал обработку, а она кривая.

Хорошо. Уже есть какой-то предмет – кривая обработка. Но что это значит? Непонятно. Спрашиваем:

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

– И он начинает говорить: Обработка запускается только из командной строки.

С моей точки зрения это не так уж плохо – она же запускается, значит работает. Спрашиваем:

– А почему это плохо?

– Потому что там пять параметров, которые непонятно откуда взять и на что они влияют! Даже справки нет!

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

– А как хотелось бы? Это позволит вам получить для себя дополнительные варианты решения.

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

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

Также дополнительно имеет смысл прояснить:

• Какие еще есть факты или вводные по ситуации. Если вы работаете с командой давно, то уже понимаете сложившуюся в ней обстановку и можете проследить, какие еще факты могли повлиять на ситуацию.

• На каком уровне у вас отношения с шефом? Если над вами есть вышестоящий руководитель, полезно понимать, можете ли вы его привлечь для внешнего авторитета, если решение пойдет как-то не так. Особенно это может быть важно для начинающих – для тех, кто недавно назначен.

• На каком этапе «по Такману» находится ваша команда? Командообразование «по Такману» – это синусоида зависимости производительности от времени на разных этапах развития команды: форминг, шторминг, норминг и перформинг:

  • Если ваша команда на этапе шторминга, конфликты между сотрудниками – это нормально. Это не значит, что на них не надо реагировать, но это нормально – люди просто выясняют, у кого скилы толще.

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

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

2. Всегда ли так было? Что послужило триггером?

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

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

Несколько примеров:

Ситуация №1. Вас назначили новым руководителем в команде, а один из «старичков» устроил саботаж. Скорее всего, он метил на ваше место, а когда вас назначили, огорчился и теперь пытается доказать, что ваш руководитель был сильно неправ, выбирая вас. Это надо проверять, но если это действительно так, у вас появляется совершенно четкий триггер – причина, почему этот человек саботирует. С этим надо работать.

Ситуация №2. Начинающий программист перестал высказываться на ретроспективе. Раньше он участвовал в обсуждениях, а сейчас резко перестал. Ретро для джуна – это один из мощнейших бустеров в его развитии. Если он вдруг замолчал, это плохой признак. Вполне возможно, что кто-то из коллег нелицеприятно о нем высказался. Джун затаился, боится слово сказать, чтобы не повторилась эта ситуация – никому не приятно выслушивать претензии по поводу качества твоей работы. С этим надо работать.

Ситуация №3. Ваш директор начал требовать еженедельные подробные отчеты. Это моя личная боль. У нас был достаточно сложный проект, и мы в самый последний момент немного сорвали сроки – потом все сдали, обошлось без штрафов, но переживали все. После этого шеф по каждому проекту начал требовать отчеты и задавать через них вопросы: «Что вы делаете? Что происходит на проекте? Как он распланирован? Какое его состояние?» Так он, с одной стороны, снимал свою тревожность по поводу следующего проекта, а с другой стороны, проверял, насколько я вообще квалифицированный руководитель. И мы потом с этим отдельно работали – я объяснил команде, где мы допустили ошибки, мы провели ретро, осознали, что за нами следят, и дальше постарались, чтобы все было хорошо.

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

И только потом выбираем способ решения.

Как может влиять тимлид

Как принимать решения по тем ситуациям, которые происходят вокруг нас?

Например, если вы формализовали проблему и понимаете, что она относится к процессам, проектам:

1. Берете курсы по управлению проектами.

2. Находите идеальное правильное решение.

3. Ищете человека, с которым это решение можно внедрить в жизнь.

4. Внедряете решение в жизнь.

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

Если проблема в команде, то:

1. Убеждаемся, что проблема не в нас самих и не в наших решениях.

2. Ищем «заводилу», который поднял волну, и переводим эту проблему на уровень сотрудника – решаем уже с ним.

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

4. Если проблема из-за вас самих – идете к психологу, коучу, начальнику, составляете индивидуальный план развития, приходите к команде, наводите прозрачность: «Ребята, я все понял, я был не прав, у меня есть план развития, через месяц я буду другим человеком». Команда прослезилась, а у вас есть фора в месяц, чтобы исправить эту ситуацию.

5. Если команда в совсем запущенном состоянии, ничего не получается сделать, надо быть готовым к ее расформированию либо к какому-то серьезному и достаточно глубинному преобразованию.

Если проблема в конкретном сотруднике – точно так же:

1. Первым делом убеждаемся, что проблема не в нас самих и не в наших решениях.

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

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

4. И садимся разговаривать:

   1. Если договорились – назначаем контроль.

   2. Если не договорились, чисто по Батыреву: учить, лечить, мочить. Жестко, но зато справедливо.

Если проблема с начальником или заказчиком – здесь принципы и подходы очень простые и похожие:

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

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

3. Если договорились – назначаем контроль.

4. Если не договорились – ищем новые факты, привлекаем новых авторитетов либо обновляем резюме.

Итого, универсальный алгоритм – это четыре с половиной пункта, которые необходимо соблюдать, чтобы уменьшить вероятность проблем в будущем:

0. Решаем, нужно ли вмешиваться.

1. Собираем первичную информацию.

2. Уточняем – очищаем информацию от эмоций, выводим чистые факты.

   1. Обязательно формализуем проблему, записываем

3. После этого выбираем решение и контролируем, что оно сработало.

Как составить план решения

Поскольку решение так или иначе завязано на разговоре с человеком, к этому разговору необходимо заранее подготовиться. Возникает вопрос – как составить план разговора и вообще план решения этой ситуации?

Во вложении к докладу – шпаргалка подготовки к разговору, ее мы подробнее разберем на следующем слайде.

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

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

• Описываем проблему.

  • Влияет ли она на работу?

  • Если не решать, что будет не так – там может быть много вариантов.

  • Выписываем все, что вас волнует и что происходит с вами: эмоции, реакции, отношения к этой ситуации.

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

• Анализируем ситуацию.

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

  • Разбираемся, всегда ли он себя так вел.

  • Что и как происходило, когда все началось.

• И, прежде чем переходить к человеку и как-то его оценивать, обязательно перебирайте четыре причины, почему он ведет себя не так, с вашей точки зрения – вы ожидаете от него одного, а он делает как-то по-другому. В этих причинах важна последовательность, а их всего четыре: нечеткая цель или понимает по-своему; не умеет; не может; и не хочет. Возьмем того Васю с обработкой. Наш мозг играет с нами в игры – у нас первая реакция на то, почему Вася сделал такую обработку: «Да он не хочет нормально работать! Раздолбай он, идиот!» Но это неправильно.

  • Для начала надо уточнить – понимал ли он вообще, что надо сделать расширение и нарисовать для него красивый интерфейс? Ему кто-нибудь об этом вообще сказал? Если нет – какие претензии? Здесь не катит подход: «Это же все знают».Фактически вы касаетесь сущности человека, хотите изменить его поведение. Человек должен поверить, что это ему нужно. А «это же все знают» – это манипуляция. Манипуляции люди не любят. Если задача была поставлена некорректно или неполно, и он сделал по-своему, претензий к Васе быть не может.

  • Вторая причина – не умеет. Вопрос: а Вася вообще раньше делал такие обработки? Может он не умеет с расширениями работать? Может интерфейсы не умеет настраивать? Он раньше подтверждал свою квалификацию? Он такое уже делал хотя бы раз?

  • Если умеет и уже делал, третья причина – не может. А мог ли Вася вообще в принципе это сделать? Был ли у него ресурс? Временной, технологический, финансовый наконец. Знаете, как в армии: «Прокопай канаву 20 метров до того столба. Держи совочек – через час приду, проверю». Траншею прокопать можно, но если ее копать совочком, она получится совсем неглубокой, а нам обычно требуется что-то поглубже. Нельзя требовать от человека результата, если у него нет возможности это сделать. Если вы утром поставили задачу на три дня, а вечером спрашиваете результат – не надо ожидать, что результат будет таким, каким он ожидается через три дня. Если вы поставили задачу, а у сотрудника параллельно еще идет поток задач, определите ему приоритеты: «Вася, вот эта задача – приоритет номер один. Будет еще кто-то звонить, отправляй всех ко мне, ты должен делать эту задачу». Тогда вы будете это гарантировать. Если Вася не может, вы не можете с него требовать.

  • А если он может, остается последняя причина – не хочет. Такое тоже бывает..

• Задаемся вопросом «Почему сотрудник не хочет?» и заполняем следующий пункт – его цели и хотелки.

  • Чего он вообще хочет по жизни, как человек? От этой жизни, от этой работы, от этой должности, от этого проекта? Выписываете эти хотелки. Здесь сильно помогают встречи «Один на один», опросы 360, мнение других людей – все это может быть полезно.

  • Если вы не боитесь аббревиатуры НЛП, нейролингвистическое программирование, то можете рассмотреть такой тезис, как позитивное намерение. Многие в это не верят, считают профанацией, но на самом деле оно существует.

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

Проверка на устойчивость. Заглядываем в будущее

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

Устойчивость – это вероятность того, что решение будет реализовано в том виде и в те сроки, которые вы заложили. Если вы ляпнули: «Да просто как-нибудь сделай!», это «как-нибудь» скорее всего приведет не к тому результату, как вы ожидаете.

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

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

• На этапе обсуждения непосредственно с человеком можно задать два вопроса:

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

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

• Если договоренность все-таки провалилась, попробуйте скорректировать решение.

  • Если что-то недоработали, узнайте причину, как так произошло – где вы споткнулись, когда договаривались,

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

Резюме

При принятии решений следуйте чек-листу:

• Вмешиваться или нет?

• Сбор первичной информации.

• Уточнение информации: очистка от эмоций, переводим все в факты.

  • Формализация проблемы.

• Выбор решения.

• Проверка на устойчивость.

• Контроль.

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

И еще ремарка. Есть еще один параметр, который может влиять на ваше решение.

Когда вы анализируете ситуацию, вы балансируете между тремя вещами:

• интересами бизнеса;

• интересами команды;

• и собственным авторитетом.

Интересы бизнеса и команды рассматриваются всегда и везде, а собственный авторитет – эфемерная штука, но это единственный актив у тимлида, который невозможно отнять. Он тяжело наращивается, но легко теряется.

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

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

Вопросы и ответы

Чем круче мы становимся как руководитель, тем больше растет наше эго. Чем больше растет наше эго, тем больше страдают интересы бизнеса и интересы команды. Как с этим работать?

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

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

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

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

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

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

Как правило, такие ситуации разрешаются.

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

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

Да, такое, согласен, возможно. А если сотрудник не управляющий, а рядовой, такая ситуация тоже возможна?

Если сотрудник не управляющий и он обидел всю команду? Зашел в офис с ноги, сказал: «Вы все козлы!», плюнул и вышел? Я бы его назад не пустил.

А если он просто пишет плохой код? Возможна ли ситуация, что он перед всеми извиняется за свой плохой код?

Если все от этого мучаются и страдают – может быть.

А если никто об этом не знал, и вы решили так сделать в назидании, такое возможно?

Возможно все, но нужно знать все вводные – без конкретного кейса сложно что-то обсуждать.

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

• Во-первых, подчеркну – это мое личное мнение.

• Во-вторых, кейс о том, что он раньше высказывался, а потом перестал.

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

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

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

А что делать, если руководитель проекта отказывается проводить ретро, и тимлиды отказываются от ретро, мотивируя тем, что это очень больно, что с ними делать?

А вы при этом в какой роли?

Я – разработчик. Мне хочется провести ретро, у меня есть предложения, а им больно.

Исходите из их целей – это тот же самый принцип, просто вы работаете вверх. Скажите руководителю: «Я очень хочу, чтобы код стал лучше. Я вижу, что есть такие-то проблемы, но я вижу только кусочек, который отведен мне. Я понимаю, что проблемы не только у меня, было бы полезно, чтобы мы вместе посовещались – как это стыкуется и что можно с этим сделать».

Вы не приходите: «Дай! Пустите меня!», нет. «Было бы полезно, было бы хорошо».

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

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.