Когда перестать искать: цена поиска против цены проверки

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

Причина, по которой это происходит так часто, психологическая и простая: поиск ощущается как продуктивная деятельность и не имеет естественного конца. Всегда есть следующая ссылка. У эксперимента конец есть — он либо получился, либо нет. Поэтому разведка вытесняет проверку, а не наоборот.

Эта глава — про то, как принимать решение «искать или проверять» осознанно.

Три стоимости

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

Правило, покрывающее большинство случаев:

Если стоимость проверки меньше оставшейся стоимости поиска — перестаньте искать.

Дополнительное правило для высоких ставок:

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

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

Восемь признаков, что пора остановиться

Их стоит выучить, потому что изнутри процесса они не заметны.

1. Выдача повторяется. Вы видите те же домены и те же тексты в третий раз.
2. Вы читаете третий пересказ одного источника. Признак того, что первичный источник либо найден, либо не существует.
3. Пятая переформулировка запроса. После третьей проблема почти всегда не в словах, а в том, что вопрос не атомарен (глава 1).
4. Вы ищете подтверждение решения, которое уже приняли. Это не разведка, а её имитация.
5. Открыто больше десяти вкладок. Означает, что вы собираете, а не читаете.
6. Вы не можете за пять секунд сказать, на какой вопрос отвечаете прямо сейчас. Вопрос потерялся два часа назад.
7. Истёк таймбокс. Простое и лучшее правило, если оно у вас есть.
8. Вам не хочется идти проверять. Самый честный признак: разведка стала способом отложить неприятную часть работы. Про этот механизм — глава про прокрастинацию.

Таймбокс

Самое эффективное средство, и оно требует ровно одного действия — назначить лимит до начала, а не в процессе.

Практическая шкала, которая хорошо работает:

Как соблюдать, если само по себе не соблюдается:

• Ставьте таймер. Буквально. Без внешнего сигнала время в разведке не ощущается.
• Ведите лог сессии — три строки: что ищу, что нашёл, что осталось непонятным. Лог сам показывает, когда круги стали холостыми.
• Договоритесь с собой заранее, что произойдёт по истечении. Не «подумаю», а конкретное следующее действие: пойти в исходники, поставить эксперимент, написать вопрос.

Так выглядит структура разведки под серьёзный вопрос, уложенная в полтора часа:

Обратите внимание на пропорции: собственно поиск занимает треть, эксперимент — треть, а подготовка и запись — оставшуюся треть. У большинства людей поиск занимает девяносто процентов, а запись — ноль.

Состояния сессии разведки

Состояние «Отложить» стоит отдельного упоминания. Не на каждый вопрос надо отвечать сегодня. Если незнание не блокирует работу, честный ход — записать вопрос в список открытых и вернуться к нему, когда появится повод. Часть таких вопросов отвечает себе сама: через месяц вы узнаете ответ попутно, а часть перестаёт быть актуальной.

Как сделать проверку дешёвой

Стоимость эксперимента почти всегда переоценивают. Обычно её можно уронить в разы.

# одноразовая песочница с нужной версией — секунды
docker run --rm -it python:3.11 python -c "import ssl; print(ssl.OPENSSL_VERSION)"
docker run --rm -it postgres:15 postgres --version

# минимальный воспроизводящий пример вместо всего проекта
mkdir /tmp/repro && cd /tmp/repro && git init -q

# проверка поведения библиотеки без сборки приложения
go run ./cmd/probe/main.go
python - <<'EOF'
import httpx, time
t=time.time(); httpx.get("http://127.0.0.1:8080/", timeout=1.0)
print("elapsed", time.time()-t)
EOF

# эксперимент на реальной системе, но безопасно
kubectl run probe --rm -it --image=curlimages/curl -- sh

Приёмы удешевления:

• Минимальный пример вместо своего проекта. Десять строк воспроизводят проблему без сборки, конфигурации и данных.
• Контейнер с нужной версией. Проверка «а как было в предыдущей версии» — одна команда, а не установка.
• Тест вместо ручной проверки. Он ещё и останется в проекте как след (глава 13).
• Флаг или переключатель вместо полного переписывания, если проверка требует изменения продукта.
• Копия данных, а не продакшн. Дешевле, чем кажется, и безопаснее, чем эксперименты вживую.

Проектирование различающего эксперимента

Плохой эксперимент подтверждает то, во что вы уже верите. Хороший — различает гипотезы. Разница операционализируется одним вопросом: «какое наблюдение будет разным при разных гипотезах?».

Шаблон, который стоит держать в голове:

Гипотеза A: причина в исчерпании пула соединений.
Гипотеза B: причина в паузах сборщика мусора.

Различающее наблюдение:
  если A — задержки коррелируют с числом активных соединений,
          и при увеличении пула хвост уменьшается;
  если B — задержки коррелируют с длительностью пауз GC,
          и при увеличении пула ничего не меняется.

Минимальная проверка: снять две метрики за один и тот же интервал
и сравнить с распределением задержек. 15 минут.

Три правила, которые делают эксперимент осмысленным:

1. Меняйте один параметр за раз. Иначе результат ничего не различает.
2. Заранее запишите, что вы ожидаете увидеть. Записанное ожидание защищает от подгонки интерпретации под результат — механизм разбирается в главе про научное и инженерное рассуждение.
3. Проверьте, что эксперимент вообще может провалиться. Если при любом исходе вы скажете «ну да, как я и думал», это не эксперимент.

Про измерения и их корректность — Измерения и Проверка гипотез.

Когда искать всё-таки дешевле

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

• Необратимые решения. Формат хранения данных, схема миграции, публичный контракт API. Ошибка стоит годы, эксперимент её не выявит.
• Безопасность и криптография. Здесь «у меня работает» ничего не значит: система, которую вы сломать не смогли, не является безопасной.
• Юридическое и лицензионное. Эксперимент не отвечает на вопрос, можно ли так делать.
• Распределённые протоколы и согласованность. Редкие сценарии отказов не воспроизводятся на вашем ноутбуке; здесь нужна спецификация и, при высоких ставках, формальные модели.
• Работа с чужими деньгами и данными. Эксперимент, который может испортить продакшн, дороже любой разведки.
• Всё, что уже стандартизировано. Изобретать заново формат даты — потеря времени, стандарт существует.

Общий признак: эксперимент отвечает на вопрос «что происходит у меня сейчас», но не отвечает на вопрос «что произойдёт в редком случае» и «что разрешено». Для этих двух вопросов источник обязателен.

Достаточно хороший ответ

Полезная рамка — понятие satisficing, введённое Гербертом Саймоном: в условиях ограниченного времени рационально выбирать первый вариант, удовлетворяющий требованиям, а не искать оптимальный. Для разведки это означает, что цель — не «лучший ответ», а «ответ, достаточный для этого решения».

Практическая формулировка критерия достаточности до начала поиска:

• Что я должен узнать, чтобы принять решение? Один-два пункта, не десять.
• Какая точность нужна? «Порядок величины» и «точное значение» — разная работа.
• Что я сделаю, если узнаю ответ? Если ответ ничего не меняет в действиях, вопрос можно не задавать вовсе.

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

Три случая остановки

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

Случай второй: «какой уровень изоляции транзакций нам нужен». Проверка возможна, но она не покрывает редкие сценарии: аномалии проявляются при конкретных совпадениях по времени, которые вы не воспроизведёте на ноутбуке. Правильное действие: читать документацию своей СУБД и спецификацию, а эксперимент использовать как подтверждение понимания, а не как источник (Транзакции и изоляция).

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

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

Ловушки

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

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

«Ещё пять минут». Разведка не имеет естественного конца, и оценка «почти нашёл» систематически оптимистична. Помогает только внешний ограничитель.

Перфекционизм разведки. Стремление понять тему целиком перед тем, как что-то сделать. В большинстве инженерных задач полное понимание не требуется и недостижимо; требуется достаточное.

Разведка вместо решения. Самая коварная: пока вы читаете, вы не ошибаетесь. Ощущение безопасности, за которое платят сроками.

Остановка в команде

У коллективной разведки есть свои патологии, и они дороже личных.

• Параллельный поиск одного и того же. Три человека независимо ищут ответ на один вопрос и не знают об этом. Лечится одной строкой в общем канале: «беру на себя вопрос X, вернусь через полчаса».
• Разведка вместо решения на встрече. Обсуждение, в котором участники по очереди зачитывают найденное в интернете, — самый дорогой формат поиска из существующих. Правильный ход: разойтись, назначить одному человеку таймбокс и вернуться с результатом.
• Никто не решается остановиться. Когда вопрос коллективный, ответственность за прекращение размыта. Помогает явное назначение: кто принимает решение и когда.
• Потеря результата чужой разведки. Коллега вчера выяснил ровно то, что вы ищете сегодня, и это осталось у него в голове. Единственное лекарство — след (глава 13).

Протокол выхода

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

1. Запишите, что установлено — с ссылками и версиями.
2. Запишите, что осталось неизвестным — именно формулировками вопросов. Это самая ценная часть: список открытых вопросов направляет следующую сессию.
3. Запишите тупики. «Искал там-то, не нашёл» экономит вам же час через месяц.
4. Назовите следующее действие. Эксперимент, вопрос человеку, отложить до появления повода.

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

Типичные ошибки

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

Мини-практика

В течение недели ведите очень простой учёт: каждый раз, когда вы уходите в разведку дольше чем на десять минут, записывайте три поля — вопрос, потраченное время, чем закончилось (нашёл, проверил экспериментом, бросил).

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

Мини-итог

• Поиск не имеет естественного конца и вытесняет проверку; это надо компенсировать явным решением.
• Сравниваются три величины: оставшаяся стоимость поиска, стоимость проверки, стоимость ошибки.
• Единственная законная цель продолжения разведки — сокращение числа гипотез.
• Восемь признаков тупика: повторяющаяся выдача, третий пересказ, пятая переформулировка, поиск подтверждения, десяток вкладок, потерянный вопрос, истёкший таймбокс, нежелание идти проверять.
• Таймбокс назначается до начала и заканчивается конкретным следующим действием, а не размышлением.
• Стоимость эксперимента обычно переоценивают: контейнер, минимальный пример и тест уменьшают её в разы.
• Хороший эксперимент различает гипотезы, меняет один параметр и может провалиться.
• Искать дешевле, чем проверять, когда решение необратимо, касается безопасности, права, редких сценариев отказа или уже стандартизировано.
• Достаточный ответ лучше оптимального; если ответ ничего не меняет в действиях, вопрос можно не задавать.

Источники

• Simon H. A. (1956). Rational Choice and the Structure of the Environment. Psychological Review, 63(2) — введение понятия satisficing.
• Simon H. A. (1971). Designing Organizations for an Information-Rich World — известная формулировка о том, что изобилие информации порождает дефицит внимания.
• Kahneman D., Tversky A. (1979). Intuitive Prediction: Biases and Corrective Procedures — про систематическую недооценку сроков.
• Arkes H. R., Blumer C. (1985). The Psychology of Sunk Cost. Organizational Behavior and Human Decision Processes, 35(1).
• Klein G. (1998). Sources of Power: How People Make Decisions — про принятие решений в условиях дефицита времени и информации.

Что дальше

Есть один жанр разведки, где всё это применяется в предельном режиме и под давлением. Поиск во время отладки: отдельный жанр.