Что такое ad-hoc-задачи и как с ними работать

Представьте: вы в потоке, пилите сложную фичу, у вас в голове выстроена архитектура на три слоя вперёд. И тут в личку влетает сообщение от менеджера: «Срочно! Выгрузи список пользователей, которые вчера купили красные носки, маркетинг ждёт». Вы вздыхаете, подключаетесь к БД, пишете SELECT, кидаете CSV. Через час прилетает: «Ой, а добавь ещё тех, кто купил синие». Это и есть ad-hoc-задачи (от лат. «по случаю»).

В мире больших данных такими задачами занимаются аналитики, но в реальности небольших команд эта роль часто падает на разработчиков. И если этот поток не контролировать, спринт будет сорван, а вы превратитесь в оператора SQL-запросов.

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

Что такое ad-hoc-задачи и почему их нужно автоматизировать

В идеальном мире IT мы живём по Agile, где есть бэклог, спринты, планирование и чёткие релизы. Но в реальном мире всегда есть поток внезапных задач, которые не спрашивают разрешения у вашего спринта. Это и есть ad hoc.

Термин пришёл из латыни (ad hoc — «для этого случая», «специально для»). В контексте разработки и аналитики это одноразовая, нестандартная задача, которая возникла «здесь и сейчас» и требует немедленного решения.

Чем она отличается от багов или фич:

Именно поэтому ad-hoc-задачи почти всегда решаются вручную и «в обход» процессов. Они не проходят через нормальный цикл планирования, не документируются и редко переиспользуются.

Проблемы, которые создают ad-hoc-запросы

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

Самая главная проблема — это переключение контекста. Чтобы написать «простой запрос», вам нужно вынырнуть из кода, который вы писали, погрузиться в базу, сделать дело и попытаться вернуться обратно. Исследования показывают, что на возврат в состояние потока уходит до 23 минут. Пять «минутных» вопросов в день могут убить весь рабочий день.

Вторая проблема — Bus Factor (фактор автобуса). Обычно в команде есть один человек, который знает базу лучше всех, и все ad-hoc-запросы летят в него. Но если он заболеет или уйдёт в отпуск, бизнес-процессы встанут, потому что никто больше не умеет «доставать данные».

Кроме того, когда вы пишете сложные запросы в спешке прямо в консоли боевой базы, всегда есть риск случайно положить сервер или (о ужас) забыть WHERE в DELETE.

Признаки того, что ad-hoc-задачу пора автоматизировать

Не каждый запрос нужно превращать в код. Автоматизация — это инвестиция времени. Если вы потратите 10 часов на написание скрипта для отчёта, который нужен раз в год, вы ушли в минус. Но есть чёткие сигналы, которые говорят: пора писать код, иначе рутина вас съест.

1. Повторяемость и частота (правило трёх раз)

Золотое правило: 0 раз — не нужно, 1 раз — случайность, 2 раза — совпадение, 3 раза — паттерн. Если к вам третий раз приходят с просьбой «выгрузи продажи за прошлую неделю», значит, придут и в четвёртый. В этот момент выгоднее потратить час на написание скрипта, который будет делать это по кнопке или по расписанию. Ловушка «да мне тут 5 минут руками сделать» приводит к тому, что через год вы тратите на эти «5 минут» половину недели.

2. Время на выполнение и переключение контекста

Иногда сам запрос выполняется секунду, но подготовка к нему занимает полчаса. Вспомнить структуру легаси-базы, найти нужные таблицы, проверить, не изменились ли ключи... Если каждый раз вам приходится заново погружаться в контекст задачи («А как мы считаем LTV? По этой формуле или по той?»), это сигнал. Автоматизация здесь работает как законсервированное знание: вы один раз зашили логику в код и забыли.

3. Критичность данных для бизнеса

Есть запросы, где цена ошибки слишком высока. Например, «выгрузи список должников для блокировки». Если вы делаете это руками через SQL-консоль, всегда есть риск опечататься и заблокировать не тех. Или забыть условие WHERE active = 1. Чем выше цена ошибки, тем быстрее нужно убрать человека из процесса. Скрипт не устаёт, не отвлекается и всегда выполняет алгоритм одинаково.

Аудит и классификация ad-hoc-задач

Прежде чем бросаться писать скрипты и админки, нужно понять: а с чем мы вообще воюем? Часто разработчики живут в ощущении «я пашу весь день», а в коммитах — пустота. Это верный признак того, что вас съели ad-hoc-задачи.

Сбор и анализ текущих запросов

Первый шаг — вытащить задачи из тени. Главная проблема ad hoc в том, они часто прилетают в личку в Телеграме или Слаке: «Глянь по-братски». В итоге задача сделана, время потрачено, а следов нет.

Самое главное правило: «Нет тикета — нет работы». Заставляйте заводить задачи в трекер, даже если это «на 5 минут».

Раз в месяц открывайте закрытые задачи с тегом support / hotfix / ad-hoc и смотрите, на что реально ушло время команды. Вы удивитесь, но, скорее всего, 30% времени съела одна и та же повторяющаяся ерунда.

Категоризация по типам и частоте

Когда вы увидите список, разбейте его на кучки. Обычно у бэкендера это три категории:

1. «Дай данные»: выгрузки, отчёты, «почему у юзера Х такой статус». Это кандидаты на дашборды.
   
   Если таких запросов много — проблема не в менеджерах, а в том, что у бизнеса нет прозрачности. Люди не видят цифры и начинают дёргать разработчика как живой API. Повторяемые «дай статистику» почти всегда означают, что пора строить self-service: BI, мастер-отчеты, регулярные выгрузки.
2. «Почини контент»: поправь опечатку, замени баннер, поменяй имейл в футере. Это кандидаты на CMS или конфиги.
   
   Если для смены текста на лендинге нужен деплой, значит, система спроектирована под разработчиков, а не под бизнес. Каждый такой тикет — индикатор, что вы держите в коде то, что должно лежать в базе или в админке. Чем чаще прилетают такие задачи, тем очевиднее, что пора выносить контент из репозитория.
3. «Объясни, как работает»: вопросы от новичков или менеджеров. Это лечится документацией или посыланием в неё.
   
   Если вам третий раз за месяц задают один и тот же вопрос про расчёт LTV или про статусы заказов — это не глупость коллег, а пробел в знаниях команды. Значит, нужно короткое описание логики, схема или хотя бы закреплённый пост в чате. Иначе вы становитесь живым FAQ-ботом.

Как только задача попадает в какую-либо категорию и вы видите, что она повторяется, она перестаёт быть ad hoc в чистом виде. Она превращается в системную проблему. А системные проблемы не гасят вручную — их автоматизируют.

Оценка ROI автоматизации

ROI (Return on Investment) звучит страшно, но для программиста это простая формула из комикса xkcd: «Сколько времени я потрачу на скрипт vs Сколько времени я сэкономлю за 5 лет».

Если задача занимает 1 минуту и прилетает раз в год — автоматизировать её невыгодно. Вы потратите 2 часа на скрипт, который никогда не окупится. А вот если задача занимает 10 минут, но прилетает каждый день — автоматизация окупится за неделю.

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

Приоритизация задач для автоматизации

За что браться в первую очередь? Здесь есть три главные категории:

Если сомневаетесь, с чего начать, задайте вопрос: что будет больнее через полгода — продолжать делать это руками или потратить день на инструмент? Автоматизация — это, по сути, снижение постоянного трения в системе, поэтому убирайте то, что чаще всего скрипит.

Инструменты для автоматизации ad-hoc-задач

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

Скрипты на Python для регулярных запросов

«Швейцарский нож» бэкендера: если задачу нельзя решить одним SQL-запросом, например нужно сходить в базу, потом в API платёжки, склеить данные и отправить отчёт на почту, Python (и инструменты из его экосистемы) незаменимы.

Pandas — для работы с таблицами, агрегациями и CSV. Даже если вы не дата-инженер, 10–15 строк кода позволяют сгруппировать данные, отфильтровать лишнее, посчитать метрики и выгрузить CSV или Excel.

Jupyter Notebooks — отличный вариант для полуаналитических задач. Удобно, когда нужно не просто отправить цифру, а показать ход мысли: код → таблица → график. Менеджеру можно дать ссылку на ноутбук или экспортированный HTML, и он увидит прозрачный процесс. Плюс это хороший способ сохранить эксперименты, а не терять их в истории терминала.

Cron (или любой планировщик) — чтобы убрать себя из процесса. Если отчёт нужен каждый понедельник в 9:00, не надо ждать напоминания в чате. Оберните скрипт в Docker или хотя бы виртуальное окружение, настройте переменные окружения и поставьте задачу в cron.

SQL-процедуры и триггеры

Иногда логику вообще не надо выносить из базы данных и использовать SQL-процедуры, то есть предварительно скомпилированный набор SQL-команд, которые хранятся на сервере базы данных

Если менеджеры постоянно просят «выгрузку со сложной фильтрацией», не пишите SELECT каждый раз. Создайте VIEW — то есть, виртуальную таблицу, основанную на результате SQL-запроса. Для внешнего наблюдателя это будет выглядеть как простая таблица, из которой можно сделать SELECT *, а под капотом база сама выполнит все джойны.

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

Чтобы каждый раз не отправлять из приложения длинный набор запросов, вы вызываете одну команду — CALL archive_users(older_than := '2022-01-01') — и вся логика выполняется рядом с данными. Это снижает сетевые накладные расходы, упрощает переиспользование и позволяет централизовать критичную бизнес-логику.

Плюс в том, что логика лежит рядом с данными и выполняется очень быстро. Минус — это сложнее версионировать, тестировать и ревьюить. Код находится внутри базы, а не в привычном git-репозитории.

BI-системы с режимом self-service

Это высшая точка развития ленивого разработчика. Если вопросы касаются красивых графиков («А покажи динамику роста LTV»), не нужно мучить библиотеку Matplotlib. Поднимите бесплатную BI-систему типа Metabase или Grafana, подключите её к базе данных, желательно к реплике, чтобы не нагружать прод, и дайте менеджерам доступ.

Главная ценность здесь не в самих графиках, а в визуальном конструкторе запросов. Менеджер может выбрать период, фильтр по региону или продукту, а под капотом будет выполняться ваш заранее оптимизированный SQL.

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

Low-code-платформы

Иногда нужно сделать не просто отчёт, а кнопку действия: «Забанить пользователя», «Вернуть платёж», «Сбросить кеш». Писать для этого полноценный фронтенд с кнопками и формами — долго и дорого. Тут на помощь приходят low-code-инструменты для внутренних админок типа Retool, Appsmith или n8n. Это конструкторы интерфейсов, которые позволяют собрать внутренний инструмент из готовых блоков: таблица, форма, кнопка, селектор дат.

Вы подключаете источник данных (Postgres, REST API, GraphQL), пишете один SQL-запрос или вызываете существующий эндпоинт, привязываете его к кнопке — и через 15–30 минут у вас есть рабочая админка.

Практические примеры автоматизации

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

Автоматизация выгрузок из базы данных

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

Правильное решение — написать простой python-скрипт, который:

Скрипт лучше запускать не с вашего ноутбука, а в изолированной среде: упаковать в Docker-образ, пробросить переменные окружения через .env или секреты и настроить ограничение ресурсов. И уже после этого поставить задачу в cron или использовать scheduled pipeline в GitLab / GitHub Actions.

Теперь каждый понедельник в 9:00 менеджеры будут получать свои данные автоматически, даже если вы спите или в отпуске.

Создание мастер-отчётов на основе частых запросов

Бывает, что запросы похожи, но немного различаются: одному менеджеру нужны продажи по Москве, другому — по Питеру, третьему — только по красным носкам. Если писать отдельный скрипт под каждого, можно сойти с ума.

Вместо этого можно создать «Мастер-отчёт» — одну большую SQL-вьюху или таблицу, в которой есть вообще все данные: и города, и цвета, и даты.

То есть не просто SELECT * FROM everything, а заранее продуманная структура, где есть нормализованные названия колонок, вычисленные поля, например LTV, маржа, сегмент клиента и единая логика фильтрации (без расхождений «в одном отчёте с НДС, в другом — без»).

Дальше можно настроить автоматическую выгрузку этого файла в Google Sheets или в BI-систему раз в день. Менеджеры сами смогут использовать фильтры, сводные таблицы и формулы, чтобы получить свой узкий срез. Суть в том, что вы создаёте один источник истины. Бизнес работает с ним, а не дёргает вас каждый раз за новую вариацию одного и того же запроса.

Настройка автоматических уведомлений об аномалиях

Ad-hoc-задачи часто возникают, когда что-то сломалось: «Почему у нас ноль продаж за последний час?». Обычно об этом пишет встревоженный бизнес, когда проблема уже висит полдня.

Самое разумное — сработать на опережение. Напишите простейший демон или scheduled job, который раз в 5–10 минут:

На старте достаточно простого правила: допустим, если количество заказов за последние 10 минут меньше 30% среднего за последние 7 дней — отправить алерт. Это превращает «влёт» менеджера в плановую работу по инциденту, о котором вы узнали первыми.

Пошаговый процесс автоматизации ad-hoc-задачи

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

Анализ требований и формализация запроса

Прежде чем писать код, включите режим «душного аналитика». Бизнес часто просит решение («Сделай мне кнопку»), но не озвучивает проблему. Спросите: «Зачем вам эти данные?», «Как часто они нужны?», «В каком формате?».

Часто выясняется, что им не нужна ежедневная выгрузка миллионов строк в CSV, а достаточно одной цифры в мессенджере раз в неделю. Ваша задача на этом этапе — упростить ТЗ до предела. Не автоматизируйте бардак — сначала упорядочьте его.

Выбор инструмента и архитектуры решения

Выбирайте инструмент, который требует минимум поддержки:

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

Разработка и тестирование автоматизации

Универсальное правило: пишите код так, чтобы он не положил продакшен.

Ad-hoc-скрипты часто пишутся на коленке, и это опасно. Обязательно используйте лимиты в запросах, работайте с репликой (read-only), а не с основной БД и проверяйте входные данные.

Идеальный сценарий: сделать MVP за пару часов, показать заказчику, получить ок и только потом ставить это на расписание.

Документирование и передача пользователям

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

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

Создание self-service-культуры

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

Разработка интерфейсов для бизнес-пользователей

Если вы дадите менеджеру доступ к чистому SQL, он рано или поздно напишет SELECT * без указания лимита и повесит базу. Интерфейс должен быть ограничителем.

В BI-системах (Metabase, Grafana) или админках (Retool) используйте параметризированные запросы. Например, вместо поля «Напиши запрос», сделайте выпадающий список: «Выберите город», «Выберите даты». И под капотом это подставится в ваш оптимизированный SQL.

Пользователь чувствует власть, но на деле он просто меняет переменные в вашем безопасном коде.

Обучение команды работе с инструментами

Лучшее обучение — это интуитивный UI, потому что документацию почти никто не читает.

Добавьте подсказки в интерфейсе, используйте плейсхолдеры и тултипы (?) прямо возле кнопок: «Нажми сюда, чтобы скачать CSV». Например, если поле требует ввода ID, напишите рядом пример: e. g. 12345.

Один раз запишите скринкаст на 30 секунд («Куда тыкать в Metabase») и закрепите его в общем чате. Это работает лучше, чем PDF-инструкция на 20 страниц.

Установление правил использования системы

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

Первое — доступы. Учётка, под которой работает BI-система или скрипт менеджера, должна иметь минимально необходимые права. В идеале — только SELECT к определённым схемам или view. Никаких критичных операций типа DROP, UPDATE, DELETE. Бизнесу нужен доступ к данным, а не власть над ними.

Второе — технические ограничения. Даже безопасный SELECT может положить базу, если он делает полный скан таблицы на десятки миллионов строк. Поэтому имеет смысл на уровне базы задать statement_timeout или аналогичный лимит. Если запрос выполняется дольше, скажем, 30 секунд — он автоматически прерывается.

Третье — изоляция. Подключайте BI и внутренние инструменты к read-only-реплике. Даже если кто-то напишет тяжёлый запрос, основной продакшен не умрёт.

Мониторинг качества данных и запросов

Когда вы дали людям удочку, надо следить, чтобы они не выловили динамит. Настройте логирование медленных запросов (slow query log). Если вы видите, что менеджеры каждое утро запускают какой-то адский отчёт, который грузит систему на 100%, — это сигнал. Либо этот запрос нужно оптимизировать, либо перенести его на ночное время, либо вообще материализовать эти данные заранее.

Не пускайте self-service на самотёк, иначе однажды утром вы проснётесь с лежащей БД.

Система управления ad-hoc-запросами

На собеседованиях все рассказывают про Agile, Kanban и красивые процессы. В реальности же ad-hoc-задачи — это Дикий Запад: они прилетают в личку, в коридоре, в общий чат без тега, в почту, и у всех статус «вчера».

Система управления здесь нужна не для красоты отчётов, а чтобы канализировать этот поток. Если вы не построите дамбу, вас смоет.

Централизованный трекер задач

Главный враг разработчика — «личка». Задача, прилетевшая в личные сообщения мессенджера, не существует. Она потеряется через 10 минут, у неё нет истории, и её не видит команда.

Железное правило: «Нет тикета — нет задачи». Заведите отдельную доску или колонку «Входящие / Inbox» в таск-трекере. Любая просьба «глянуть одним глазком» должна сначала упасть туда. Это единственный способ увидеть реальный объём бедствия и не сойти с ума от мультитаскинга. А если менеджер ленится завести задачу — значит, она не такая уж и срочная.

Шаблоны для стандартизации запросов

Обычно ad-hoc-запрос выглядит так: «Выгрузи данные по продажам». И после этого начинается словесный пинг-понг: «За какой период?», «По всем городам?», «С НДС или без?». Вы тратите час только на то, чтобы понять, что нужно.

Чтобы этого избежать, сделайте шаблоны (Issue Templates). Настройте трекер так, чтобы при создании задачи типа «Запрос данных» менеджер обязан был заполнить поля:

Пока поля не заполнены — кнопка «Создать» неактивна. Это экономит вам часы выяснений.

SLA и приоритизация

Для бизнеса любая ad-hoc-задача — это «АСАП» (As Soon As Possible). Но если всё срочно, значит, ничего не срочно. Поэтому договоритесь на берегу об уровнях обслуживания (SLA, Service Level Agreement):

Если менеджер ставит «Пожар» на обычную выгрузку, возвращайте задачу обратно с понижением приоритета.

База знаний решений для переиспользования

Звучит как скучная вики, которую никто не читает. Но фишка в том, что писать там не статьи, а сделать склад сниппетов:

Главное, чтобы решения были версионируемыми, доступными команде и снабжёнными коротким описанием: что делает, какие параметры принимает, к какой базе подключается. Достаточно README на 5–10 строк: «Этот скрипт выгружает активных пользователей за период X. Требует переменные окружения DB_HOST и DB_USER».

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

Мониторинг и развитие автоматизации

В IT нет ничего вечного: базы данных мигрируют, API меняются, токены протухают. Если вы написали скрипт и забыли о нём, однажды он сломается и менеджер снова придёт к вам с вопросом «А почему кнопка не работает?».

Относитесь к внутренним инструментам как к микропродукту: у него есть жизненный цикл.

Отслеживание использования автоматизированных решений

Вы потратили 3 дня на дашборд в Grafana, а его открывали один раз в день релиза? Это сигнал.

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

Сбор обратной связи от пользователей

Чтобы получить фидбэк от пользователей, не надо проводить опросы: пользователи либо врут, либо молчат. Самый честный фидбэк — это ошибки и поведение системы.

Ваш скрипт автоматизации должен писать логи (в Sentry или хотя бы в текстовый файл). В логах должно быть понятно:

В идеале — добавьте метрики: количество успешных запусков, время выполнения, процент ошибок. Даже простая отправка статуса в чат вроде «Отчёт за неделю сформирован: 12 543 строки» уже даёт уверенность, что всё работает.

Важно не только фиксировать падения, но и замечать деградацию: если скрипт обычно выполняется 20 секунд, а сегодня за 4 минуты, это тоже сигнал. Значит, либо данные выросли, либо запрос стал неоптимальным.

Когда менеджер пишет: «Ничего не работает, я не могу выгрузить отчёт!», это плохо. А вот если вам пишет бот: «Ошибка подключения к БД в скрипте отчётов», вы чините всё за пять минут и менеджер даже не заметит, что что-то не так.

Выявление новых паттернов для автоматизации

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

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

Оптимизация существующих решений

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

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

FAQ: распространённые ошибки при автоматизации

Собрали главные грабли, на которые наступают разработчики, пытаясь автоматизировать спонтанные задачи. Проверьте себя.

Преждевременная автоматизация редких запросов

Вопрос: «Менеджер попросил сложную выгрузку за прошлый год. Я потратил два дня, написал универсальный скрипт, а он больше не пригодился. Я молодец?»

Ответ: нет, вы ушли в минус.

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

Создание сложных решений для простых задач

Вопрос: «Нужен бот для сброса кеша. Я решил поднять для него отдельный микросервис на Kubernetes, базу данных и очередь сообщений Kafka. Норм?»

Ответ: нет, это оверинжиниринг.

Для внутренней задачи, которой пользуются пять человек, критерий качества — не «идеальная архитектура», а «скорость разработки». Если задачу можно решить простым c URL-запросом или скриптом на 20 строк, запускаемым по крону, — делайте так. Не плодите сущности, которые потом придётся поддерживать.

Отсутствие документации и обучения

Вопрос: «Я сделал крутую админку, скинул ссылку в чат, но мне всё равно пишут в личку с просьбой нажать кнопку за них. У них там всё хорошо?»

Ответ: нет, у них просто нет инструкции.

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

Игнорирование обслуживания автоматизированных систем

Вопрос: «Я написал скрипт полгода назад, он работал, а сегодня упал и менеджеры в панике. Почему так?»

Ответ: потому что софт деградирует.

Базы данных мигрируют, API меняются, токены протухают. Нельзя написать код и забыть о нём навсегда. Закладывайте в свои планы время на техподдержку своих же инструментов. Или делайте их настолько простыми, чтобы там нечему было ломаться: чем меньше кода — тем меньше багов.