FAQ
Как проверить понимание, не обидев опытного разработчика?
Используй технику парафраза от первого лица: «Хочу убедиться, что правильно объяснил - расскажи своими словами, как ты понял задачу?» Формулировка переносит ответственность на тебя как постановщика, а не ставит разработчика в позицию ученика.
Что делать, если человек в ответ на проверку снова пересказывает задачу неверно?
Не исправляй сразу - сначала уточни, откуда у него такое понимание. Скажи: «Интересно, расскажи подробнее - почему ты решил, что нужно именно так?». После этого корректируй.
Нужно ли проверять понимание в каждом разговоре?
Нет. Проверка нужна там, где задача многошаговая, результат неоднозначен, или у участников разный уровень контекста. Для простых операционных задач («обнови зависимости», «напиши в канал») достаточно фиксации в трекере.
Как применять техники в асинхронной переписке - в Slack или Jira?
В Slack: завершай описание задачи вопросом «Правильно понимаю, что ты возьмёшь это в работу сегодня?» и жди явного подтверждения, не только реакции-эмоджи. В Jira: добавляй в описание задачи раздел «Ожидаемый результат» с конкретным критерием готовности.
Почему на ретроспективах команды не говорят о проблемах с пониманием?
Потому что ретроспектива обычно фокусируется на процессах, а не на коммуникации. Люди обсуждают «не успели», «были блокеры», но не называют прямо «мы не поняли задачу». Добавь в формат ретро один вопрос: «Был ли момент, когда ты думал, что понял, но оказалось иначе?» - это открывает нужный разговор.