Привет, Хабр!

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

Каждый Delivery Manager хотя бы раз переживал этот момент: вы показываете заказчику готовый продукт, а он смотрит на вас с искренним недоумением. «Мы же обсуждали совсем другое». Разработчики пожимают плечами — они сделали ровно то, что было написано в задаче. Аналитик ссылается на протокол встречи. Тестировщик докладывает, что все сценарии проходят успешно. И вроде бы все правы, но результат — мимо цели.

Добро пожаловать в мир информационных потерь, где на каждом переходе между ролями растворяется до трети смысла исходного требования. И если в небольшой команде из пяти человек это ещё можно пережить, то в цепочке «заказчик → аналитик → разработчик → тестировщик», растянутой по разным часовым поясам, искажения достигают критического порога.

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

Почему мы слышим не то, что нам говорят

Иллюзия понятности — главный враг Delivery Manager. Мы склонны переоценивать точность передачи информации, потому что наш мозг достраивает недостающие фрагменты на основе собственного опыта. Заказчик, говоря «сделайте удобный интерфейс», видит перед глазами конкретную последовательность действий, которая кажется ему очевидной. Аналитик, услышав это, транслирует в требование то, что он считает удобным. Разработчик интерпретирует это через призму фреймворка, который он использует. Тестировщик проверяет то, что было написано, а не то, что ожидалось.

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

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

Про три пересказа

Рассмотрим практический пример. В одной финтех‑компании заказчик пришёл с задачей: «Нам нужно, чтобы клиенты могли видеть историю своих переводов за последние три года на одной странице». Аналитик записал требование, разработчик реализовал пагинацию с подгрузкой по скроллу, тестировщик проверил, что данные подгружаются. Всё работало идеально, но на демо‑встрече заказчик побледнел.

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

Заказчик не сказал про Excel, потому что считал это само собой разумеющимся. Аналитик не спросил, потому что «на одной странице» для него всегда означало веб‑интерфейс без выгрузки. Разработчик не догадался, потому что он занимался фронтендом и не знал о регламентах налоговой отчётности.

Проект уехал на два спринта в доработку. Репутация команды была подпорчена.

Что же в такой ситуации изменил новый Delivery Manager? Он ввёл правило «трёх пересказов» для критичных по сложности задач. На встрече с заказчиком аналитик фиксирует требования не стенограммой, а формулировкой результата на языке пользователя. Перед тем как уйти в детализацию, аналитик обязан пересказать заказчику услышанное в формате:

«Давайте проверим, что мы договорились вот о чём: после внедрения вы сможете открыть экран с историей всех переводов, отфильтровать их по дате и контрагенту, а затем скачать отфильтрованный список в Excel».

Когда заказчик слышит эту конкретику, он либо кивает, либо поправляет. В нашем случае он бы сразу сказал: «Да, и ещё важно, чтобы в Excel были итоговые суммы по каждому контрагенту за выбранный период». Это уточнение на старте занимает минуту. Переделка на финише занимает две недели.

Второй пересказ — на уровне acceptance criteria, уже в бэклоге, где аналитик подробно расписывает сценарии. Третий пересказ — на демо‑макете в Figma, который заказчик получает до начала разработки. На этом этапе он видит, где будет кнопка выгрузки, и понимает, что его потребность учтена.

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

Обратный пересказ

Рассмотрим немного другой пример понимания непонимания.

Разработчик получает задачу: «Реализовать загрузку файлов в личном кабинете пользователя». Аналитик написал требование на три страницы: типы файлов, размеры, маски ввода. Всё выглядело исчерпывающе. Разработчик оценивает задачу в один день и берётся за работу. Он использует стандартный компонент загрузки из корпоративного фреймворка, который по умолчанию ограничивает размер файла 10 мегабайтами и требует, чтобы файл загружался за один сеанс без разбивки на чанки.

Разработчик при написании кода не проверяет эти ограничения, потому что они «стандартные», а аналитик не указывает их в требовании, потому что для него загрузка файла — это атомарная операция без технических нюансов. Через два дня разработчик сообщает, что задача готова. Тестировщик проверяет загрузку файлов на 5, 8 и 10 мегабайт. Всё работает. Задача закрыта.

Через неделю продакт‑менеджер приносит обратную связь от первых пользователей: «Мы не можем загрузить годовой отчёт в PDF, он весит 25 мегабайт. Приложение выдаёт ошибку, ничего не объясняя». Выясняется, что реальные пользователи загружают большие файлы регулярно, но в задаче этот кейс не был описан, потому что аналитик не знал про ограничения фреймворка, а разработчик не спросил.

Что сделал Delivery Manager в похожей ситуации в другой компании. Он ввёл практику «техники обратного пересказа» перед стартом разработки. Когда разработчик получил задачу на загрузку файлов, DM подошёл к его столу и сказал: «Расскажи мне устно, как ты понял задачу, будто я пользователь, которому нужно загрузить отчёт».

Разработчик ответил: «Я понял, что пользователь нажимает кнопку, выбирает файл, система показывает прогресс загрузки, а если файл больше 10 мегабайт — выдаём сообщение, что нужно выбрать файл поменьше или разбить на части».

DM услышал слово «10 мегабайт» и переспросил: «А ты уверен, что наши пользователи не загружают файлы больше? Помнишь историю с отчётами в прошлом квартале?»

Разработчик задумался и полез в документацию к API, который должен был принимать файлы на бэкенде. Оказалось, что там нет ограничения по размеру, но есть ограничение по времени сессии — 30 секунд. Если файл не загрузился за 30 секунд, сессия падает. Большой файл при низкой скорости интернета мог не успеть загрузиться.

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

Делаем выводы

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

Именно поэтому Delivery Manager обязан быть не просто организатором встреч и хранителем бэклога. Он должен быть живым фильтром искажений на каждом переходе. Его работа на старте задачи — задать разработчику вопрос «перескажи устно» — выглядит как микро‑действие, но в масштабах проекта это макро‑эффект. Потому что каждый пятиминутный пересказ вскрывает 80% недоговорённостей ещё до того, как они превратились в технический долг.

Три пересказа на этапе анализа с заказчиком. Один пересказ на стыке аналитика и разработчика. Чек‑лист зоны влияния на стыке разработчика и тестировщика. Тесты до кода как способ синхронизации понимания, а не как догма.

В компаниях, где это работает, фраза «я думал, речь идёт о другом» на демо‑встрече звучит всё реже. И Delivery Manager понимает, что он починил сломанный телефон не магией, а системным вниманием к каждому переходу смысла. Это не про скорость передачи информации, а про её точность. И это единственное, что в итоге спасает проект от фиаско, когда все участники искренне уверены, что они говорили об одном и том же.

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

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

• 5 августа в 20:00. «Оценка проекта: от интуитивных догадок к системному подходу». Записаться

• 19 августа в 20:00. «Метрики Delivery Manager: что измерять, а что — пустая трата времени». Записаться

Больше бесплатных уроков августа смотрите в дайджесте.