В 1999 году NASA потеряла Mars Climate Orbiter: одна команда работала с ньютонами, другая — с фунтами-силами. Ошибка в единицах измерения отправила аппарат слишком близко к Марсу, а для IT-команд это хороший, хотя и дорогой мысленный эксперимент: очевидные вещи в IT редко оказываются одинаково очевидными для всех участников проекта.
Повод разобрал Habr / Карьера в материале о когнитивных ловушках на работе. Его практический вывод звучит почти банально, но банальность здесь обманчива: незафиксированное допущение — это не общее знание, а личная гипотеза. Пока оно живёт только в голове автора, команда может строить совершенно другой продукт, чинить не ту проблему или аккуратно ломать старый костыль, назначение которого давно никто не помнит.
История с Mars Climate Orbiter особенно неприятна тем, что в ней не было фантастической технической загадки. Обе группы инженеров пользовались привычными для себя системами единиц. Не сработала не физика, а коммуникация между частями процесса. В разработке аналог выглядит прозаичнее: бэкенд считает сумму в копейках, фронтенд — в рублях; сервис отдаёт время в UTC, а отчёт ожидает локальную зону; аналитик под «активным пользователем» понимает одно действие за день, продукт — вход в приложение за месяц. В каждом случае код может быть формально корректным. Результат — нет.
Проблема не сводится к небрежности. Её подпитывает так называемое проклятие знания: человек, который уже знает контекст, переоценивает, насколько хорошо его понимают остальные. В эксперименте психолога Элизабет Ньютон 1990 года участники отстукивали ритм знакомой мелодии и ожидали, что слушатели легко её угадают. На практике правильных ответов было лишь 2,5%. У того, кто стучит, в голове играет песня; у того, кто слушает, — набор ударов. Код-ревью работает похожим образом: автор видит в диффе причины выбора библиотеки, ограничения старого API и несколько крайних сценариев, а ревьюер видит несколько изменённых строк.
Вторая ловушка — иллюзия прозрачности. Разработчику кажется, что сомнения заметны по вопросам на встрече, выражению лица или молчанию в чате. Для коллег это обычно выглядит как согласие либо как занятость. Если риск не назван прямо, команда не обязана его угадать. Особенно это заметно на стыке ролей: менеджер говорит «сделать отчёт по продажам», исполнитель готовит PDF, а заказчик ждёт таблицу с фильтрами и возможностью выгрузки. Оба могут добросовестно выполнить свою часть работы и всё равно получить переделку.
Отдельный источник конфликтов — исторический контекст. Новый инженер видит странный участок кода, переписывает его «как правильно», и после релиза выясняется, что этот фрагмент обходил ограничение старого партнёрского API или спасал систему в пиковую нагрузку. Без объяснения прежний автор легко выглядит слабым разработчиком, хотя решение могло быть разумным для конкретного дедлайна. Это близко к фундаментальной ошибке атрибуции: чужие действия удобно объяснять качествами человека, а свои — обстоятельствами. Репозиторий без комментариев и решений по архитектуре только усиливает этот эффект.
Что фиксировать до того, как начнётся переделка
Универсального документа, который отменит все недопонимания, не существует. Но команде полезно явно называть несколько вещей до начала работы: ожидаемый результат, формат данных, границы задачи, критерии готовности и известные ограничения. Формулировка «готово, когда код в ветке» радикально отличается от «готово, когда изменения покрыты тестами, прошли ревью, обновлена документация и функция доступна пользователям». Если definition of done существует только в головах, одна часть команды будет сдавать недотестированные изменения, а другая — бесконечно полировать детали.
Для задач это означает, что в тикете стоит писать не только действие, но и проверяемый эффект: кто получит результат, в каком виде и по каким признакам он считается верным. Для кода — пояснять не очевидный синтаксис, а причину нетривиального решения, внешнее ограничение и последствия его удаления. Для онбординга — давать новичкам возможность спрашивать о базовых вещах без ритуала «сначала погугли три дня». Такая практика не делает специалистов менее самостоятельными; она сокращает стоимость ложной самостоятельности.
В авиации похожая проблема однажды закончилась трагедией рейса Avianca 52: экипаж сообщал диспетчерам о заканчивающемся топливе и просил приоритет, но срочность сообщения была интерпретирована не как аварийная. В катастрофе шаттла Challenger инженеры предупреждали о риске для уплотнительных колец при низкой температуре, однако предупреждение не стало для руководства достаточно убедительным основанием отменить запуск. IT-проект редко ставит на кон жизни людей, но механизм знаком: важный риск формулируют слишком мягко, адресат достраивает смысл по-своему, а затем команда расследует инцидент.
Очевидные вещи в IT не нужно превращать в бюрократию на десятки страниц. Достаточно заменить ожидание телепатии короткими проверками: «мы оба понимаем метрику одинаково?», «что именно будет считаться готовым?», «зачем здесь этот обход?», «какое решение принимаем при конфликте требований?». Чем сложнее система и чем больше в ней команд, подрядчиков и старого кода, тем ценнее такие вопросы. Самый опасный комментарий в рабочем чате — не «это глупый вопрос», а «ну это же и так понятно».