Возникли вопросы ?
Мы перезвоним в течение часа и вы сможете подробнее озвучить вашу задачу
Управление cookies
Настройки Cookies
Cookies, необходимые для корректной работы сайта, всегда включены.
Остальные cookies можно настроить.
Остальные cookies можно настроить.
Деловое общение, понимание, доверие, нетворкинг, C-level, команда.
«Я думал, ты понял» - самая дорогая фраза в IT-проекте
Три техники, которые помогут убедиться, что команда поняла задачу правильно, без ощущения экзамена и без раздражения.
Коммуникации C-level
Почему "я думал, ты понял" убивает сроки и мотивацию в IT-команде
Фраза «я думал, ты понял» стоит IT-командам недель переработки, сорванных релизов и сломанных отношений внутри команды. Проверять понимание собеседника без раздражения умеют единицы - большинство менеджеров и тимлидов либо не делают этого совсем, либо делают так, что человек чувствует себя идиотом. Есть 3 конкретных техники, которые работают в любом формате - на стендапе, в Slack и на встрече с заказчиком: «парафраз», «контрольный вопрос» и «резюме от собеседника». Они применимы в любой IT-команде, где задачи передаются устно или в переписке, и разница в статусах создаёт барьер для уточнений.
Почему недопонимание в IT обходится дороже, чем кажется
По данным исследования Project Management Institute (PMI) за 2023 год, некачественная коммуникация является основной причиной провала 31% IT-проектов. Средняя стоимость переработки из-за неверно понятых требований в проектах с командой от 20 человек составляет от 15 до 40% бюджета спринта.
Я провожу тренинги по коммуникации в IT-компаниях уже более 10 лет и вижу одну и ту же картину: задача была поставлена вслух, все кивнули, никто ничего не переспросил.
Через 2 недели выясняется, что backend-разработчик понял под «гибкой авторизацией» одно, а продакт - совсем другое.
Приехали.
Я провожу тренинги по коммуникации в IT-компаниях уже более 10 лет и вижу одну и ту же картину: задача была поставлена вслух, все кивнули, никто ничего не переспросил.
Через 2 недели выясняется, что backend-разработчик понял под «гибкой авторизацией» одно, а продакт - совсем другое.
Приехали.
Почему люди не переспрашивают
Причин три, и они не про невнимательность.
Первая - страх выглядеть некомпетентно. В культуре большинства крупных IT-компаний переспросить означает признать, что ты не понял. Это воспринимается как слабость, особенно когда рядом тимлид или CTO.
Вторая - иллюзия понимания. Человек слышит знакомые слова - «интеграция», «микросервис», «флоу» - и мозг автоматически достраивает картину из прошлого опыта. Картина оказывается неверной, но субъективно всё выглядит ясным.
Третья - темп. В режиме постоянных митингов, когда следующий звонок через 15 минут, никто не хочет задерживать разговор уточнениями. Бежим? Бежииим!
Первая - страх выглядеть некомпетентно. В культуре большинства крупных IT-компаний переспросить означает признать, что ты не понял. Это воспринимается как слабость, особенно когда рядом тимлид или CTO.
Вторая - иллюзия понимания. Человек слышит знакомые слова - «интеграция», «микросервис», «флоу» - и мозг автоматически достраивает картину из прошлого опыта. Картина оказывается неверной, но субъективно всё выглядит ясным.
Третья - темп. В режиме постоянных митингов, когда следующий звонок через 15 минут, никто не хочет задерживать разговор уточнениями. Бежим? Бежииим!
Два кейса, которые я наблюдал лично
Кейс 1: «Простая доработка» на 3 спринта
Продакт крупного финтех-стартапа (команда 60 человек, Москва) на планировании сказал разработчику: «Нужно доработать модуль уведомлений - сделать его гибче». Разработчик кивнул. Уточнений не последовало ни с одной стороны.
Через 3 недели продакт увидел результат и сказал: «Это не то, что я имел в виду». Разработчик построил конфигуратор уведомлений с 12 параметрами. Продакт хотел просто добавить 2 новых триггера.
Стоимость ошибки - 3 недели работы одного разработчика. Причина - слово «гибче» у каждого участника разговора значило своё.
Кейс 2: Онбординг нового тимлида
В команде разработки одного e-commerce-проекта новый тимлид после первой встречи с СТО сказал: «Всё понятно, я понял задачи на квартал». Я попросил его пересказать своими словами 3 главных приоритета. Он назвал правильно только один из трёх.
Остальные два он либо перепутал с задачами прошлого квартала, либо добавил от себя то, чего CTO не говорил. При этом субъективно тимлид был уверен, что понял всё.
Это классический случай «иллюзии понимания» - человек слышит знакомые слова и не замечает, что мысленно достроил смысл из своего прошлого опыта.
Продакт крупного финтех-стартапа (команда 60 человек, Москва) на планировании сказал разработчику: «Нужно доработать модуль уведомлений - сделать его гибче». Разработчик кивнул. Уточнений не последовало ни с одной стороны.
Через 3 недели продакт увидел результат и сказал: «Это не то, что я имел в виду». Разработчик построил конфигуратор уведомлений с 12 параметрами. Продакт хотел просто добавить 2 новых триггера.
Стоимость ошибки - 3 недели работы одного разработчика. Причина - слово «гибче» у каждого участника разговора значило своё.
Кейс 2: Онбординг нового тимлида
В команде разработки одного e-commerce-проекта новый тимлид после первой встречи с СТО сказал: «Всё понятно, я понял задачи на квартал». Я попросил его пересказать своими словами 3 главных приоритета. Он назвал правильно только один из трёх.
Остальные два он либо перепутал с задачами прошлого квартала, либо добавил от себя то, чего CTO не говорил. При этом субъективно тимлид был уверен, что понял всё.
Это классический случай «иллюзии понимания» - человек слышит знакомые слова и не замечает, что мысленно достроил смысл из своего прошлого опыта.
3 техники проверки понимания, которые не раздражают собеседника
Раздражение возникает тогда, когда проверка понимания звучит как экзамен или недоверие. Ни одна из трёх техник ниже не направлена «на собеседника» - все они сформулированы так, что говорящий берёт ответственность на себя.
Техника 1: Парафраз от первого лица
Вместо «ты понял?» - «дай я проверю, правильно ли я объяснил». Это простой и мощный переворот: ты не проверяешь собеседника, ты проверяешь себя как коммуникатора.
Формула: «Чтобы убедиться, что я донёс главное - скажи своими словами, как ты понял задачу?»
Формула: «Чтобы убедиться, что я донёс главное - скажи своими словами, как ты понял задачу?»
Техника 2: Контрольный вопрос на решение
После постановки задачи задаётся один вопрос: «Что ты сделаешь первым делом?» или «С чего начнёшь?».
Ответ мгновенно показывает, понял ли человек задачу или просто кивнул.
Я использую эту технику на тренингах с менеджерами крупных компаний.
Примерно в 40% случаев первый названный шаг не соответствует тому, чего ожидал постановщик.
Ответ мгновенно показывает, понял ли человек задачу или просто кивнул.
Я использую эту технику на тренингах с менеджерами крупных компаний.
Примерно в 40% случаев первый названный шаг не соответствует тому, чего ожидал постановщик.
Техника 3: Резюме от собеседника в конце встречи
В конце любого совещания, где принимались решения, просить одного из участников озвучить: кто что делает? в какой срок, какой результат ожидается?
Замечу: это НЕ протокол встречи, а живая проверка понимания прямо сейчас, когда ещё можно исправить расхождения.
Замечу: это НЕ протокол встречи, а живая проверка понимания прямо сейчас, когда ещё можно исправить расхождения.
Как выглядит проверка понимания в разных форматах
Что мешает менеджерам применять эти техники
Три барьера, которые я наблюдаю на тренингах у руководителей IT-команд.
Барьер первый - «не хочу тратить время». Проверка понимания занимает 2-3 минуты. Переработка из-за неверно понятой задачи занимает от 3 дней до 3 недель.
Барьер второй - «они взрослые, сами переспросят». Не переспросят. Особенно если это джун перед тимлидом или тимлид перед CTO. Иерархия убивает уточняющие вопросы быстрее любого другого фактора.
Барьер третий - привычка к «синхронизации». Фраза «мы в синке» стала корпоративным мемом, за которым прячется ровно то, что описано в этой статье: видимость понимания вместо реального.
Барьер первый - «не хочу тратить время». Проверка понимания занимает 2-3 минуты. Переработка из-за неверно понятой задачи занимает от 3 дней до 3 недель.
Барьер второй - «они взрослые, сами переспросят». Не переспросят. Особенно если это джун перед тимлидом или тимлид перед CTO. Иерархия убивает уточняющие вопросы быстрее любого другого фактора.
Барьер третий - привычка к «синхронизации». Фраза «мы в синке» стала корпоративным мемом, за которым прячется ровно то, что описано в этой статье: видимость понимания вместо реального.
FAQ
Как проверить понимание, не обидев опытного разработчика?
Используй технику парафраза от первого лица: «Хочу убедиться, что правильно объяснил - расскажи своими словами, как ты понял задачу?» Формулировка переносит ответственность на тебя как постановщика, а не ставит разработчика в позицию ученика.
Что делать, если человек в ответ на проверку снова пересказывает задачу неверно?
Не исправляй сразу - сначала уточни, откуда у него такое понимание. Скажи: «Интересно, расскажи подробнее - почему ты решил, что нужно именно так?». После этого корректируй.
Нужно ли проверять понимание в каждом разговоре?
Нет. Проверка нужна там, где задача многошаговая, результат неоднозначен, или у участников разный уровень контекста. Для простых операционных задач («обнови зависимости», «напиши в канал») достаточно фиксации в трекере.
Как применять техники в асинхронной переписке - в Slack или Jira?
В Slack: завершай описание задачи вопросом «Правильно понимаю, что ты возьмёшь это в работу сегодня?» и жди явного подтверждения, не только реакции-эмоджи. В Jira: добавляй в описание задачи раздел «Ожидаемый результат» с конкретным критерием готовности.
Почему на ретроспективах команды не говорят о проблемах с пониманием?
Потому что ретроспектива обычно фокусируется на процессах, а не на коммуникации. Люди обсуждают «не успели», «были блокеры», но не называют прямо «мы не поняли задачу». Добавь в формат ретро один вопрос: «Был ли момент, когда ты думал, что понял, но оказалось иначе?» - это открывает нужный разговор.
Используй технику парафраза от первого лица: «Хочу убедиться, что правильно объяснил - расскажи своими словами, как ты понял задачу?» Формулировка переносит ответственность на тебя как постановщика, а не ставит разработчика в позицию ученика.
Что делать, если человек в ответ на проверку снова пересказывает задачу неверно?
Не исправляй сразу - сначала уточни, откуда у него такое понимание. Скажи: «Интересно, расскажи подробнее - почему ты решил, что нужно именно так?». После этого корректируй.
Нужно ли проверять понимание в каждом разговоре?
Нет. Проверка нужна там, где задача многошаговая, результат неоднозначен, или у участников разный уровень контекста. Для простых операционных задач («обнови зависимости», «напиши в канал») достаточно фиксации в трекере.
Как применять техники в асинхронной переписке - в Slack или Jira?
В Slack: завершай описание задачи вопросом «Правильно понимаю, что ты возьмёшь это в работу сегодня?» и жди явного подтверждения, не только реакции-эмоджи. В Jira: добавляй в описание задачи раздел «Ожидаемый результат» с конкретным критерием готовности.
Почему на ретроспективах команды не говорят о проблемах с пониманием?
Потому что ретроспектива обычно фокусируется на процессах, а не на коммуникации. Люди обсуждают «не успели», «были блокеры», но не называют прямо «мы не поняли задачу». Добавь в формат ретро один вопрос: «Был ли момент, когда ты думал, что понял, но оказалось иначе?» - это открывает нужный разговор.
Учимся понимать друг друга. Внимательно :-0
Проверка понимания - это не недоверие к команде, это профессиональная гигиена коммуникации. 2-3 минуты на уточнение в начале задачи защищают от 2-3 недель переработки в конце. Начни с одной техники - парафраза от первого лица - и применяй её на ближайших 5 встречах.
вместо 'распыли краску на камеру' иногда проще сказать '...да не на меня, а перед камерой!'
но после - что тут скажешь уже? :)
но после - что тут скажешь уже? :)
Леонид Бугаев
эксперт в области бизнес-коммуникаций, корпоративный тренер, спикер и модератор конференций. Он автор книг «Мобильный маркетинг» и «Мобильный нетворкинг».
Подписывайтесь на Леонида в Telegram, Facebook и Instagram и YouTube и не пропускайте новые публикации. Посмотрите также на бизнес-тренинги по нетворкингу и продажам B2B.
Подписывайтесь на Леонида в Telegram, Facebook и Instagram и YouTube и не пропускайте новые публикации. Посмотрите также на бизнес-тренинги по нетворкингу и продажам B2B.
Об авторе, клиенты
Услуги для бизнеса
Ивенты