Югославия, 1959 год, турнир за право сыграть титульный матч с Ботвинником. В паузе претенденты и шахматисты из их штабов успели ещё турнир по блицу провести. Вот тут и встретились за доской Таль (чёрные) и его секундант Авербах (белые).
Дальше рассказывает Михаил Таль.
Точную позицию сейчас не восстановить, но механизм "зевка" таков:

Ход Чёрных. Авербах предложил ничью, но я решил поиграть. Вижу, надо защититься от угрозы
2. С:h7+ и 3. Ф:d5. И защитился: 1. ... h6??? Как вы догадываетесь, Авербах ответил 2. С h7+
и больше ничьей не предлагал.

Начало. Снова всё правильно

В прошлый раз его подвела слепота к людям. В этот раз — методология.

Задача звучала знакомо: перевести офлайн-ритейлер в онлайн, спроектировать интернет-магазин. Постановка была короткой и на вид безупречной — «изучить всё как есть, спроектировать как должно быть».

Аналитик изучил всё. Оргструктуру, ценообразование, сборку, перемещение между складами, доставку, возвраты, приёмку товара, сверку с бухгалтерией. Десятки процессов, сотни шагов, аккуратные схемы AS IS. Работа на загляденье.

Разве не молодец?

Первый звонок. TO BE рождается похожим

Началось проектирование TO BE. И оно стало обрастать знакомыми чертами.

Приём заказов проектировался по образу приёма заявок в офлайне. Информирование покупателя — как обзвон менеджером. Оплата — как касса на входе. Каждый новый процесс аналитик невольно лепил из уже описанного старого.

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

Смена угла зрения. AS IS — не для того, чтобы его описать

Аналитик остановился и задал вопрос, который стоило задать до, а не после: зачем вообще нужен AS IS?

Не чтобы задокументировать текущую систему во всей красе. AS IS нужен, чтобы понять, на каком фундаменте мы строим TO BE и что именно из старого TO BE наследует.

Интернет-магазин наследует у офлайна не всё. Ценообразование, сборку, перемещение, доставку — да, это фундамент. Но интерфейс покупателя, приём заказов, приём оплат, информирование о статусе — это новое, уникальное, и лепить его из старого нельзя.

Значит, «изучить всё» — не добродетель. Это крайность. Аналитик копал офлайн-кассу с той же глубиной, что и сборку, — и офлайн-касса протекла в дизайн онлайн-оплаты.

Ошибка. Почему «изучить всё» — это не глубина

Тут прячется ловушка, которую видно не сразу.

Кажется, что проблема в объёме — изучил слишком много, потратил время. Но настоящий вред тоньше: **чем детальнее описан старый процесс, тем труднее от него отказаться.** Подробный AS IS легитимизирует текущий порядок. Аналитик, вложивший неделю в схему офлайн-приёма заказов, бессознательно защищает её в TO BE. Он построил не фундамент. Он построил якорь.

И «изучить всё» проваливает не глубину. Оно проваливает **зонирование**. Оно заставляет копать то, что вообще не станет частью нового решения, так же тщательно, как то, что станет его спецификацией.

Карта. Четыре связи с AS IS, а не одна

Аналитик понял: наследование — не единственная нить между старым и новым. Их четыре, и глубина изучения зависит от того, какая именно связывает фрагмент с TO BE.

Наследуем. Процесс переходит в TO BE почти как есть — ценообразование, сборка, доставка. Его нужно описать полно: это готовая спецификация.

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

Не трогаем, но стыкуемся. Бухгалтерия, склад-система — их не переписываем, но TO BE обязан сохранить контракт с ними. Нужен только интерфейс.

Не трогаем и не стыкуемся. Всё остальное. Одна строка: «существует».

Противоречие. AS IS надо изучить полностью — и нельзя

Вот напряжение, которое аналитик наконец увидел ясно.

AS IS надо изучить полностью — иначе теряются скрытые ограничения и стыки. Странный шаг в старом процессе часто кодирует регуляторное или договорное требование; выбросишь его как «легаси» — переоткроешь в проде.

AS IS нельзя изучать полностью — это дорого, а главное, детальный AS IS легитимизирует старое. Чем подробнее описал — тем сильнее якорь.

Это и есть механизм, из-за которого TO BE становится копией AS IS. Не вопреки качественному AS IS. Из-за него.

Разрешение. Два прохода вместо одного

Противоречие снимается разделением во времени. Не один тщательный проход по всему — а два разных.

Проход 1 — широкий и мелкий. Карта всех процессов на один уровень, без деталей. Единственная цель — найти границы и стыки, разложить процессы по четырём зонам. Здесь же рождается гипотеза TO BE: что наследуем, что заменяем.

Проход 2 — узкий и глубокий. Только по зонам «наследуем» и «заменяем». Первый проход дал вход для гипотезы TO BE — гипотеза TO BE задала глубину второго прохода.

Круг размыкается: раньше, чтобы понять, что изучать глубоко, нужно было уже знать AS IS. Теперь первый проход отвечает на этот вопрос дёшево, а второй тратит силы только там, где они станут спецификацией.

Что изменилось

Аналитик не стал изучать меньше из лени. Он стал изучать прицельно.

Офлайн-касса получила одну строку и контракт на границе. Сборка и доставка — полное описание. Приём заказов проектировался с чистого листа, потому что аналитик больше не держал перед глазами подробную схему старого приёма заявок, от которой не мог оторваться.

TO BE перестал быть копией AS IS. Не потому что команда стала смелее. Потому что аналитик перестал приносить якорь под видом фундамента.

Детальность AS IS — не добродетель, а риск. Аналитик, изучивший всё, построил не фундамент, а якорь. Задача — не описать текущую систему целиком. Задача — понять, что из неё переживёт переход, и изучить глубоко только это.