Пять минут на ручной пинг, десять — на поиск релизного чек‑листа, еще день — на MR, о котором все забыли. По отдельности это мелочи. Вместе — заметная часть time‑to‑market.
Привет! Меня зовут Шухрат Ерматов, сейчас работаю в Ви.Tech — ИТ‑дочке ВсеИнструменты.
Расскажу про микроавтоматизации: небольшие скрипты и уведомления, которые снимают рутину вокруг разработки. Без отдельной платформы, проекта на квартал и попытки сразу сделать идеально. Внутри — десять сценариев, которые крутятся у нас, их экономика и критерий, по которому мы решаем, что автоматизировать, а что оставить руками.
Разработка при этом может идти быстро. Time‑to‑market растягивается в паузах: между аналитикой и разработкой, разработкой и тестированием, в ожидании ревью и согласований.
Сначала это были скрипты «для себя»
Во многих командах микроавтоматизации появляются сами собой. Кто‑то устает вручную собирать данные, искать ссылки или пинговать коллег и пишет небольшой скрипт под конкретную боль. Он может лежать локально, запускаться из консоли или передаваться из рук в руки. Это еще не сервис и не продукт — просто быстрый способ не делать одно и то же руками.
Такие решения создают не только разработчики. Тестировщики, аналитики и тимлиды тоже автоматизируют куски собственного процесса, потому что лучше всех видят повторяющуюся рутину.
Такие штуки есть во многих командах, просто о них не принято говорить.
Дальше разберем повторяемые сценарии: где теряется время, что имеет смысл автоматизировать и как не превратить маленький скрипт в большую платформу.
Время утекает в паузах между этапами
Список потерь у всех примерно одинаковый:
-
ждем согласования;
-
ждем, когда посмотрят MR, — а про него просто забыли;
-
пингуем и напоминаем, особенно если ты руководитель;
-
в поддержке теряется фокус: заявку закинули, начали обсуждать, потом потеряли тред.
Каждая потеря мелкая. Но их много, и дело даже не в минутах.
Приходится отвлекаться, менять контекст, переключаться. Тратим время и внимание.
При этом почти все эти мелочи можно автоматизировать, потому что данные для них уже лежат в Jira, Confluence и GitLab. Надо только оставить их источником правды и перестать держать в голове, кого сегодня пнуть.
Критерий выбора простой: повторяется часто, задевает сразу несколько человек и делается по‑простому.
«Пока мучайся с конфлюенсом, положи в бэклог»
Рутина была всегда. Почему тогда мы не автоматизировали ее десять лет назад?
Потому что арифметика не сходилась. Приходишь к руководителю: слушай, у нас рутина, каждый релиз руками заводим чек‑листы. Руководитель считает: польза — экономия пяти минут в день, затраты — полдня работы разработчика.
Нет, дружок, пока мучайся с этим конфлюенсом. Когда‑нибудь сделаем, положи в бэклог.
И это был честный ответ. Ресурс разработки дорогой, тратить его на такую мелочь нецелесообразно. Поэтому люди делали что‑то по‑быстрому, пользовались молча, и появлялись те самые скрипты, о которых не принято говорить.
Полдня работы превратились в 20 минут
Две вещи.
Первая — ИИ. Полдня на релизные чек‑листы превращаются в 10–20 минут. Написали простой промт, на выходе скрипт строки на 23, из которых 15 — выборка данных, а 5 — отправка уведомления. Вычитать такое легко, ничего чувствительного там нет.
Вторая — dev‑контур и Backstage. У многих компаний сейчас есть готовое решение, которое разворачивает сервис по кнопке. Раньше под это надо было планировать ресурс devops, а заявку могли и не согласовать.
Теперь добавляешь свой сервис и сразу получаешь развертку. Не нужно выбирать фреймворк под окружение, придумывать, где это развернуть, заводить деплойменты, реплика‑сеты и поды. Прокликал в нескольких местах, написал промт — и оно уже крутится на тестовом стенде.
После этого разговор с руководителем выглядит иначе:
Слушай, мы каждый день тратим по пять минут. Ты не против, если я потрачу десять и это автоматизирую?
Ответ тоже очевиден, только теперь другой.
Один сервис на четыре команды
Мы собрали небольшой сервис, который тянет данные из Jira, Confluence, GitLab, внутреннего портала и Sentry, а уведомления и кнопки кидает в корпоративный мессенджер. Сейчас им пользуются 40 человек из четырех команд.
Платформой это называть не хочется. Платформу проектируют, согласовывают, потом поддерживают. Здесь другой цикл: появилась проблема — написали скрипт, пошли работать дальше.
Сложная документация тоже не понадобилась. Интерфейс собирается из готовых шаблонов, с нуля ничего не выдумываем.
Десять автоматизаций, которые у нас крутятся
Ревью аналитики. Аналитик написал ТЗ и отдал в разработку, чтобы посмотрели и накидали комментов. Раньше приходилось напоминать каждому руками. Теперь бот сам читает, кто указан в ТЗ в Confluence, и пингует их в чате: ребята, посмотрите.
Релизные чек‑листы. Говоришь, что хочешь укатить такой‑то сервис по такой‑то задаче, а сервис сам вытягивает, кто тестировщик, что за задача и какой у нее чек‑лист. Галочки закрываешь прямо в мессенджере, параллельно приходит инструкция: вот ссылка, посмотри, где сейчас мастер, и катни его последним, дерни тестировщика, проверь, что все работает.
Так выглядит релизный чек‑лист в корпоративном мессенджере. Имена и внутренние идентификаторы скрыты.
Отдельная польза — новички. Порядок деплоя у всех примерно схожий, но в каждом сервисе есть свои особенности, и обычно они живут в чек‑листах в Confluence, которые надо сначала найти. Здесь они лежат в настройках и приходят сами в нужный момент.
Авто‑трекинг времени. Время трекается по реальным статусам задач, а не руками.
Вручную всем было лень, писали всякую фигню. А тут оно смотрит по фактическим статусам, и качество выше.
Признаюсь: эту штуку мы долго прятали. Сделали давно, но не раскрывали, потому что опасались, что придет проектный офис, скажет «так нельзя, трекайте сами» и заберет ее. Мучиться руками не хотелось.
Напоминания тимлидам. Уведомления про задачи, которые требуют внимания. Задач много, и не надо по каждой пинговать вручную.
Еще шесть маленьких скриптов
Кроме этих четырех, есть еще набор совсем небольших автоматизаций. Каждая решает одну конкретную повторяющуюся проблему:
-
longReview. Напоминает о задачах, которые слишком долго находятся на ревью, чтобы они не терялись и не тормозили разработку.
-
vacations. Заранее напоминает команде об отпусках. Полезно для планирования — особенно когда о своем отпуске может забыть даже сам отпускник.
-
supportPing. Следит за задачами поддержки и напоминает о них, если долго нет активности, чтобы обращения не зависали без ответа.
-
poker. Автоматически создает игры для оценки задач и раскладывает их по нужным чатам, избавляя команду от ручного заведения покера.
-
message. Автоматизирует регулярные сообщения: например, собирает темы к встрече, формирует повестку или запускает синхронизацию по задачам.
-
issuesToDeploy. Собирает в одном сообщении все готовые к выкладке задачи, группирует их по сервисам и отмечает участников.
Ни одна из этих штук не начиналась с постановки задачи и обсуждения, как сделать правильно. По ревью аналитики пришел руководитель направления и сказал, что хочет вот такое. Пять минут — скрипт готов. Скажи только, какой канал, кого пинговать и где смотреть в ТЗ.
400 минут в день только на трекинге
Считать надо по всей рутине сразу: экономия суммируется.
-
Задачи тимлидов: не пингуем по каждой.
-
Ревью аналитики: не напоминаем руками.
-
Ревью MR: не забыли — значит не потеряли дни time‑to‑market.
-
Релизы: не упустили важный шаг.
-
Трекинг: 5–10 минут × 40 человек ≈ 400 минут экономии в день.
Уже явно не пять минут. И это только то, что мы успели закрыть.
Почему не пошли в платформенную команду
Логичный вопрос, который я задал себе сам: зачем писать это самим? Есть платформенная команда, есть Backstage, есть направление, которое делает автоматизацию для всего IT. Почему не прийти к ним?
-
Backstage — это больше про сервисы. Если автоматизация про то, что происходит вокруг сервиса, туда идти нормально: там открыты к идеям.
-
Платформенная команда делает универсальное решение на весь IT. Как только появляется задача вроде «уведомлять тимлидов о задачах, которые надо разобрать», решение надо согласовать со всей компанией. Согласование затягивается по понятным причинам.
-
И вот здесь автоматизация теряет смысл. Пока идет обсуждение и выбор идеального решения, руководитель скажет: давай пока не будем, иди работай по старинке в Confluence.
Выигрыш микроавтоматизации — именно в отсутствии бюрократии. Написали скрипт, пошли работать.
Отсюда честный критерий: если на согласование уходит больше времени, чем на реализацию, вы делаете уже не микроавтоматизацию. Такое проще либо отдать платформе, либо продолжать делать руками.
Как применить это у себя
-
Посмотрите, что вы чаще всего повторяете: что ищете, что собираете, куда пишете.
-
Сформулируйте задачу: что именно должно происходить само.
-
Напишите простой MVP и поднимите сервис через dev‑контур.
-
Проверьте на одном‑двух людях. Работает — масштабируйте на команду, потом на отдел.
Про стек: берите то, на чем вам удобнее. Если вам все равно, сейчас чаще выбирают Node.js — для типовых задач получается меньше строк кода. Меньше строгости, больше гибкости.
Правила, которые у нас остались
-
Ускорение разработки — только часть time‑to‑market. Уберите то, что вокруг: ручные пинги, ожидание людей, потерянные треды.
-
Автоматизируйте то, что повторяется часто и задевает сразу нескольких людей.
-
Экономику считайте по всей рутине сразу. Пять минут в день на сорока людях — это уже часы.
-
Данные уже лежат в Jira, Confluence и GitLab. Оставьте их источником правды и не держите ничего в голове.
-
Держите решение маленьким. Как только оно требует согласований и идеального проектирования, оно перестает окупаться.
И самое короткое, если у вас пока такого нет:
Была проблема — быстро написали скрипт, пошли работать дальше.
А освободившееся время и внимание уже можно потратить на сами задачи и ускориться еще раз.
Автор: shukhratlead
