Чек-листы вместо скриптов: как навести порядок в операциях малого бизнеса

Пятнадцать самодельных скриптов держали операционку небольшого бизнеса. Каждый понимал ровно один человек — тот, кто его писал. Каждый ломался от обновления API, прихода нового сотрудника или смены процесса. Потом владелец перестал писать код и переписал те же процессы в чек-листы. К моменту, когда библиотека доросла до 87 инструкций, в ней было ноль строк кода, а освободившиеся 15 часов в неделю ушли в продажи и продукт. Выручка выросла втрое.

Как выглядит ловушка самодельной автоматизации

Любой владелец бизнеса, который «немного умеет программировать», проходит один и тот же цикл:

1. Находит автоматизацию и загорается.
2. Строит свой инструмент под конкретную задачу.
3. Неделю всё работает.
4. Что-то меняется — обновление API, новый человек в команде, новый процесс.
5. Инструмент ломается, три дня уходят на починку.
6. Появляется новый инструмент взамен сломанного.
7. Возврат к шагу 4.

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

Разворот: инструкция вместо скрипта

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

1. Убедиться, что инцидент реальный: посмотреть на дашборд мониторинга.
2. Определить серьёзность: P1 — теряем выручку, P2 — деградация, P3 — мелочь.
3. Если P1 — сразу предупредить заинтересованных по шаблону из приложения.
4. Локализовать проблему: откатить, расширить, отключить.
5. Написать пользователям — обновить статус-страницу.
6. Починить причину, а не симптом.
7. Зафиксировать: таймлайн, принятые решения, последствия.
8. Назначить разбор в течение 48 часов.
9. Обновить чек-лист по итогам разбора.

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

Чек-лист против скрипта

Ключевой момент — пятая строка таблицы. AI-агенты уже неплохо идут по пошаговым инструкциям. Автоматизировать операционку кодом не обязательно: пишете чек-лист, агент его исполняет. В этом и смысл «вайб-кодинга», только вывернутый наизнанку — не AI пишет код за вас, а AI выполняет ваши регламенты.

Что в итоге получилось

Стек выглядит предельно скучно: библиотека из 87 чек-листов, бесплатный мониторинг вроде UptimeRobot, который просто сообщает, что что-то упало, AI-агент, читающий алерты и подсказывающий нужный файл, и markdown-документы в Git. Ноль строк кода на операционку, 0 долларов в месяц на инструменты (стартовый набор чек-листов когда-то обошёлся в 14 долларов).

Что изменилось в цифрах: реакция на инцидент сократилась с 45 до 12 минут — идти по пунктам быстрее, чем отлаживать скрипт. Появилось 15 свободных часов в неделю. Команда начала выполнять процессы сама, не дожидаясь, пока основатель починит код.

Когда код всё-таки нужен

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

Как собрать свою библиотеку

• Начните с одного болезненного процесса. Не с идеальной схемы, а с того, что чаще всего горит: инцидент, выставление счёта, онбординг сотрудника.
• Формулируйте шаги проверяемо. «Проверить мониторинг» — плохо. «Открыть дашборд и убедиться, что алерт висит больше пяти минут» — хорошо.
• Ветвления — внутри чек-листа, а не в виде двух отдельных документов: «если P1 — ..., иначе ...».
• Последний пункт всегда один и тот же: обновить чек-лист по итогам выполнения.
• Храните в одном месте. Markdown-файлы в Git дают бесплатную историю правок и откат в один клик.
• Привяжите запуск к событию, а не к памяти. Мониторинг кричит — чек-лист открывается.

Где обычно ошибаются

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

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

Держат инструкции в переписке и в голове. Тогда единственная копия — у одного человека, и болезнь самодельных скриптов возвращается под другим именем.

Никогда не пересматривают. Файл без даты последней правки быстро превращается в музейный экспонат.

Вывод

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