Не задавайте вопрос «почему». Как менеджеру общаться с командой правильно

Проработав 20 лет в IT, 12 из которых — в области проектного и операционного менеджмента, я пришел к выводу, что умение задавать вопросы — это один из важнейших навыков менеджера. Я сформулировал для себя правила о том, какие вопросы правильные и как стоит задавать их команде, чтобы достичь поставленных целей. Свою точку зрения я поясню в виде простых кейсов, взятых из реальной жизни и лишь немного видоизмененных. На примерах рассмотрим правильные и неправильные, закрытые и открытые вопросы, а также советы о том, как их задавать в конкретных ситуациях.

Зачем все-таки нужны вопросы

По моему скромному мнению, менеджер задает вопросы, чтобы:

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

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

Почему же «почему» плохой вопрос

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

Например:

  • Почему дедлайн снова сдвигается?
  • Почему проблема до сих пор не решена?
  • Зачем ты убил базу на проде?

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

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

Часто не имеет смысла. Если что-то плохое уже произошло, само по себе выяснение причин сбоя точно ничего не изменит.

Но если поговорить о причинах все-таки хочется, лучше так и спросить: «Какими были причины?». Этот вопрос звучит менее агрессивно и способен вывести вас на диалог.

Стоит ли задавать закрытые вопросы

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

  • Ты можешь сделать эту задачу за 2 часа?
  • Ты можешь выйти в субботу, чтобы сделать задачу быстрее?
  • Этот кривой код — твой?

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

  • Согласна ли команда с содержанием этого спринта? (Хороший вопрос после совместного планирования.)
  • Раз уж мы обсудили все вопросы, давайте начинать работать?
  • Все согласны со сдвигом сроков на две недели? (После того, как обсудили все варианты и ничего другого не остается.)

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

10 признаков правильных вопросов

  1. Открытые, но не начинаются с «почему». Например:
    • Как мы можем решить эту задачу?
    • Какой план мы сможем предоставить клиенту?
    • Каких экспертов мы могли бы привлечь?
  2. Помогают сфокусироваться на проблеме при помощи слов и фраз «ещё», «действительно», «что еще», «как именно». Например:
    • Что еще / какое еще решение можно предложить?
    • Действительно ли это та проблема, которую мы решаем?
    • Как именно ты хочешь это сделать?
  3. Ориентированы на конструктив, результат и решение проблемы. Например:
    • Давай посмотрим, что приведет нас к эффективному и быстрому решению проблемы?
    • Как ты считаешь, что поможет быстрее достичь результата?
  4. Направлены на интерес отвечающего.
    Допустим, менеджер проекта говорит с синьор-разработчиком. Что-то в системе не работает, и эту проблему нужно решить быстро и качественно. Здесь отлично подойдет вопрос: «Что мы как компания можем сделать, чтобы тебе помочь?» Разработчику поддержать такой диалог будет гораздо интереснее, чем пытаться ответить на запрос, который звучит так: «Что у вас там случилось? У нас тут пол фирмы в запаре. Если ты не решишь задачу, мы тебя уволим». Или даже так: «Решение этой проблемы поможет нашей бухгалтерии лучше справляться с работой». Запрос, направленный на интерес собеседника, всегда будет более эффективным, чем тот, связи с которым он не чувствует.
  5. Помогают увидеть новые возможности. Важно, чтобы вопросы были направлены в будущее, а не в прошлое. Например:
    • Какие способы решения этой задачи ты мог бы предложить?
    • Что еще мы могли бы предпринять в этой ситуации?
    • Что можно сделать, чтобы подобных ситуаций не возникало?
  6. Помогают активизировать творческие способности и изобретательность. Например, проджект-менеджер в ответ на запрос получает банальное решение, которое не работает или работает плохо. Дальше можно либо принять этот ответ, либо спросить:
    • Давайте представим, что эта проблема уже решена. Как вы думаете, какими способами мы этого достигли?
    • Чтобы ты посоветовал своему другу, у которого была бы точно такая же проблема?
  7. Поддерживают и мотивируют. Например:
    • Это очень неплохое решение. Возможно, у тебя есть еще что-нибудь интересное?
    • То, что ты предложил, выглядит отлично, что нужно тебе и команде для решения этой проблемы?
  8. Обращаются к эмоциям. Например:
    • Как должна выглядеть архитектура системы, чтобы ты и команда были счастливы?
    • Как переход на новую позицию будет влиять на твои жизненные планы?
  9. Направлены на диалог. Не стоит задавать риторические вопросы или превращать их в длинные монологи. Например:
    • Это сложная проблема, когда лучше всего вернуться к ее обсуждению?
    • Какие риски ты видишь в связи с...?
  10. На них нельзя ответить «да» / «нет» / «может быть». Например:
    • Как я могу помочь? Но не: Могу ли я помочь?

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

Кейс 1

Ваш тимлид только что при вас случайно убил базу данных на продакшене. Ваш первый вопрос? «Почему?» или «Какого черта?».

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

  1. Насколько всё серьезно? — Вопрос направлен на анализ ситуации.
  2. Что будем делать? — Вопрос направлен в будущее и никого ни в чем не обвиняет.
  3. Что еще можно сделать? — Этот вопрос, как и два следующих, направлены на поиск решения проблемы.
  4. Кого позовем на помощь?
  5. Какие ресурсы вам необходимы?
  6. Чем еще я могу помочь? — Подчеркивает ваше участие и готовность поддержать коллегу.
  7. В какие сроки мы можем уложиться? — Уточняет детали и определяет дедлайн решения проблемы.

Кейс 2

Вы долго наблюдали на вашим лучшим Senior Java-разработчиком и после успешного завершения проекта предложили ему стать тимлидом проекта. Он отказался! Ваш первый вопрос? Снова «Почему»? На него могу ответить и я.

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

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

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

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

Но причины отказа могут быть и совершенно другими. Например, однажды в моей практике человек отказался от должности тимлида, потому что ему пришлось бы задерживаться в офисе и больше работать. Он был счастлив на своей должности, живя в удобном для себя ритме. Ему нравилось спокойно отдыхать, не отвлекаясь на звонки вечером или в выходной: «Зачем мне больше денег, если я не смогу ездить на рыбалку?».

Какие вопросы подошли бы в этом случае:

  1. Как бы ты хотел развивать свою карьеру? — Всегда очень хороший первый вопрос в разговоре о повышении.
  2. Какая работа делает тебя счастливым? — Вопрос направлен на эмоции.
  3. Как ты думаешь, что помогло тебе так хорошо делать свою работу? — Вопрос подводит человека к собственным сильным сторонам и помогает понять, в какую сторону он хотел бы развиваться дальше.
  4. Какая роль в ближайшем будущем была бы для тебя комфортной? — Вопрос направлен на будущее и помогает задуматься о развитии.
  5. Что должно измениться, чтобы ты захотел стать тимлидом? — Вопрос показывает, что компания ценит сотрудника и готова пойти навстречу.
  6. Чем компания может помочь тебе в развитии твоей карьеры? — Например, человек может чувствовать, что ему недостает конкретных навыков (возможно, он прав, а может, просто себя недооценивает). Задав вместо этого вопрос «Почему ты не хочешь повышения?», вы только заставите человека признать у себя отсутствие нужных скиллов и усилите защитную реакцию. Предложив помощь и поддержку в развитии, вы можете прийти к решению, которое окажется оптимальным для обеих сторон.

Кейс 3

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

Хорошими вопросами в этом случае будут:

  1. Что мы можем сделать, чтобы успеть вовремя / ускорить процесс?
  2. Какие ресурсы нам нужны, чтобы успеть в срок?
  3. Кого мы можем привлечь на помощь команде?

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

Как правильно задавать вопросы

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

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

Правильно: Внимательно выслушать коллег, возможно, что-то подобное предложит команда. Если не предложат — два раза подумать. Возможно, ваше решение не такое уж и гениальное?
Неправильно: «Давайте возьмем за основу вот такое решение...»

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

Правильно: Сфокусироваться на решении проблемы.
Неправильно: «Давайте искать автора коммита, который положил прод».

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

Правильно: «Что мы можем сделать, чтобы исправить ошибку?»
Неправильно: «У нас такие ошибки даже джуны не делают».

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

Классический кейс. Менеджер устраивает коллегам one-to-one и безучастным тоном задает вопросы о планах, профессиональном развитии и тому подобное. Один из коллег обратил на это внимание и спросил: «Зачем ты задаешь эти вопросы?». Менеджер честно признался: «Меня попросили в HR-отделе».

Кстати, сам по себе вопрос «Кем вы себя видите через 5 лет?» — отличный! Он переносит вас в будущее, заставляет подумать, в какую сторону вы хотите расти, пересмотреть планы и так далее. Проблема в том, что за последнее время его испортили, выхолостив суть. Ведь чаще всего задают его на собеседованиях люди, которые знакомы с кандидатом 5 минут и практически ничего о нем знают.

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

В итоге

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


Иллюстрации Ульяны Патоки.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному13
LinkedIn

Схожі статті




34 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Ка по мне норм статья, если все буквально не воспринимать... работал как то с «эффективными менеджерами» и дал им кличку — почемучки )) , но как по моему наблюдению менеджер, который часто задаёт этот вопрос, просто не знает работы которой управляет... а если менеджер пришел из спецов, то он и так знает ответ )

Спасибо, что поддержали)

Представил рыцарей, говорящих «ни» из «Монти Пайтон и Священный Грааль», только вместо слова «ни» вопрос «почему?»

Японцы со своими целыми пятью Почему закурили и пошли думать.

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

В технике 5w why идет на предпоследнем месте со смыслом «какие были причины»

Какие способы решения этой задачи ты мог бы предложить?

В розмові про проблему взагалі не можливо побудувати корректне питання зі словом «ти» в реченні. Або «ми» або без займенників взагалі, безособово.

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

А від цього повіяло питаннями «Де ви бачите себе в нашій команії через 5 років?» та «Чому люки круглі?»

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

...

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

осталось ли ещё чего не убитого и ПОЧЕМУ!? lil

Забавная статья. В каждом разделе: первая половина советов/кейсов — хорошая, вторая — нерабочая.

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

Не все статьи одинаково полезны ©

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

...якщо ти Program Manager.

В усіх інших випадках, ймовірно отримаєш пояснення, яке не зможеш зрозуміти (спеціально, тому що грають проти тебе, або просто так вийде). Що робитимеш далі? Варіант «поясніть мені, щоб я зрозумів» і виписати ще авторитету з корпоративного сховища замість втраченого?

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

В контексте «здоровой» команды

Згоден, краще бути здоровим та багатим.

например почему какой-то тимлид имеет доступ к базе на проде)

Он сейчас СIO, потому что лажают все, а вот учатся на ошибкаx — немногие)

Chief Input/Output? Я в этих тайтлах с буквой C теряюсь.

Chief Internet Officer главный ответственный за наличие интернета в офисе

Этот кривой код — твой?

Это смешно xD

Хорошая статья, спасибо. Практика «5 why?» может помочь найти корень проблемы, главное уметь правильно использовать этот инструмент.

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

Но вопросы «как сделать так, чтобы подобного не повторилось» был бы более эффективен)

Думаю, автор имел ввиду то, что «Почему?» — ориентировано на прошлое, что никак не изменишь, вместо него можно использовать «Как?» — с прицелом на решение подобных проблем в будущем.

«Почему он вообще лазил руками на проде?»

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

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

я тоже стал так отвечать )) ну конечно с коррекцией на дрессированность софт скиллов а то со всякими неадекватами приходится работать )) и фраза претворяется в вариант «а почему нет?» и «если можешь сделать лучше разберись и сделай технически и организационно я поддержу ну как поддержу при полной технической и орг. самостоятельности а я если что прикрою»

... и вы не поверите пока никто таки не взял и не сделал лучше и даже просто не сделал ))

хотя таки да советчиков «а давайте так сделаем» и спросителей «а почему так сделано?» на любом сколь-либо сложном проекте миллион и маленькая тележка но «отвечать и делать» при этом почему-то должны другие и вообще все остальные

(почему именно такая-то система принята на проекте, бо я новый в компании и пока не в курсе)

простой же ж подход вот возьми посиди разберись «таки почему?» а попутно как человек новый и пока не в курсе и приобретёшь (здесь «ты» обобщение) чисто технически бесценный опыт а) знания системы как результата б) разбирания в работе системе как процесса но ніт!

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

ЗЫ: кстати «неадекватный пинок» класса «не нравится сделай лучше» таки работает по крайней мере в части случаев я проверял ))

но если внутренняя документация написана криво, то

то разберись и поправ и возьми с полки пирожок )) будешь новым автором с почестЯми!

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

Підписатись на коментарі