Consulting Work Блог Контакт
← Назад к блогу

Сигнал к автоматизации - второй раз, а не пятый

Сигнал к автоматизации - второй раз, а не пятый

Я выпустил схему с ошибкой и два дня её не замечал. Выглядела она безупречно. Блоки стояли на своих местах, подписи были верными, а линии между ними вели не к тем блокам. На одной лишней ручной правке соединитель тихо сполз на позицию в сторону, и никто не заметил, потому что на беглый взгляд замечать было нечего. Эта мелкая ошибка дала мне правило, которое я теперь применяю далеко за пределами схем: момент перестать делать что-то руками - это второй раз, а не пятый.

Если коротко

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

Что я переделывал снова и снова

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

Что на самом деле сломалось

На одной из таких правок я добавил новый ряд ближе к низу. Всё под ним съехало, я подтянул соединители следом, прикинул на глаз и счёл дело сделанным. Выглядело правильно. Правильным не было. Одна линия теперь вела к соседу того блока, к которому должна была.

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

Решение на один вечер

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

Дело не столько в скорости, хотя так и быстрее. Дело в том, что новая версия не может совершить мою ошибку. Линия рисуется из «A связан с B», поэтому идёт из A в B. Чтобы добавить блок, я теперь пишу одну строку текста о том, где его место, и перезапускаю.

Опасна не та задача, что трудна. Опасна та, что достаточно проста, чтобы выглядеть правильной, будучи неверной.

Расчёт, который никто не делает

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

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

Почему второй раз, а не третий

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

Где это применимо, если ты не пишешь код

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

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

Что бы я сделал иначе

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

Что ты раз за разом пересобираешь руками и что прямо сейчас может тихо быть неверным, и что потребовалось бы, чтобы вместо этого описать его один раз?

Нужно что-то похожее для вашего бизнеса? Посмотрите, как я могу помочь →