Когда ковид ещё не стукнул, и мы все работали из офиса, жизнь была проста и безмятежна. Все были на виду, сидели рядом, всегда могли быстро переговорить, узнать прогресс или что-то напомнить друг другу. Командные активности были офлайн, легко было собраться у доски или пойти вместе в переговорку, никого не забыв. На командном телевизоре крутилась статистика спринта, метрики продукта, результаты OKR-ов.

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

  • Постоянно собирать прогресс по разным доскам.

  • Напоминать о стендапах, задачах и PR-ах.

  • Собирать всех в Зуме на разные встречи.

Процессы и работа в целом начали терять прозрачность. Стало понятно, что надо с этим что-то делать.

Больше ботов богу ботов

С приходом удалёнки, Slack стал чуть ли не единственным местом помимо Зума, где мы постоянно общались. Нам пришла идея написать бота, который будет регулярно собирать различную статистику и выкладывать её в общий чат команды.

Сказано — сделано. За выходные был состряпан простенький бот, который был гордо назван Sheldon в честь персонажа «Теории большого взрыва» и награждён соответствующей аватаркой.

Daily status

На тот момент Шелдон умел лишь ежедневно присылать уведомление в чат с сообщением, содержащим список того:

  • какие задачи подвисли;

  • какие PR-ы сейчас открыты и под какие задачи;

  • какие critical-баги присутствуют в бэклоге — у нас есть регламент исправления подобных задач.

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

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

Шелдон берёт информацию из Jira, Stash и нашего внутреннего портала Avito People.

Weekly report

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

Прогресс по OKR. К сожалению, Slack не умеет отображать много графики. Надо было найти хоть какой-то вариант, который бы помог отобразить прогресс по OKR. Идея пришла отсюда: отображать прогресс-бар в виде 10 символов ⬜ и ????, где первый означает сам прогресс-бар, а второй — его выполнение. 

Таким образом, если у нас эпик на OKR, в котором 100 задач, и 20 из них выполнено, рисуем последовательность ???? ???? ⬜ ⬜ ⬜ ⬜ ⬜ ⬜ ⬜ ⬜ (20/100). Подправленные под наш юзкейс исходники можно найти тут.

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

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

С этим было сложнее: это уже графика, а единственный более-менее рабочий вариант прикрепить картинку к сообщению бота — ссылка на файл, доступный по http. Нормального варианта складывать картинку на персистентный сторадж на тот момент у нас не было, и пришлось выкручиваться.

По итогу был сделан http-хендлер, который генерирует график в png по массиву точек, полученных в get-запросе. Саму ссылку генерируем прямо в момент отправки сообщения после сбора этих самых точек из статистики. Таким образом мы избавляемся от стораджа и можем генерировать разные виды графиков в рантайме. Единственное ограничение — количеством точек, которые мы можем передать, ведь get лимитирован 2048 символами. Исходники можно найти здесь.

По итогу получилось сообщение, которое приходило каждый понедельник:

Больше автоматики

Просто показывать статус и отправлять напоминалки о зависших задачах — это хорошо, но что если добавить сразу кнопку на то, чтобы их закрыть? Сказано — сделано. Шелдон научился сам закрывать PR, в которых прошли тесты и есть апрув, а также таски, в которых все PR смерджены.

Постепенно Шелдон стал выходить наружу. Его добавили в общий чат поддержки продуктов команды, чтобы систематизировать запросы. Бот научился менять дежурных и звать всех заинтересованных на наши демо.

А ещё Шелдон:

  1. Автоматизирует процесс дежурств. Он назначает дежурного, напоминает, что нужно ответить на вопрос в канале и напоминает, когда ты дежуришь.

  2. Напоминает закрыть дела перед отпуском.

  3. Напоминает команде о демо, чтобы не забыть подготовиться.

Итоги

Постепенно о боте узнали в других командах, и из pet-project он стал массовым. Пришлось его рефакторить. Код был разделен на модули, модули на блоки, был добавлен простой механизм сетапа. В итоге, после массированной рекламы в общих каналах, его подключили себе ещё 10 команд. И Шелдон стал полноценным членом семьи.

А какие боты используются у вас?

Комментарии (5)


  1. 13werwolf13
    26.04.2022 12:06

    лайк за отсылку к TBBT
    дизлайк за slack)))))))


  1. kirill-scherba
    26.04.2022 23:34

    Спасибо! Очень интересно!


  1. GrimAnEye
    28.04.2022 16:32

    А каким образом бот был разделен на модули? Буквально на плагины, микросервисы или условно раскиданы по папкам?

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


    1. temamagic
      28.04.2022 23:32

      А зачем вам го плагины? Про разделение на модули, скорее всего подразумевается разделение кода на точку входа, гейтвеи (работа с бд, источниками и тп) и бизнес логику

      Вам надо копать в сторону DDD, Clean Architecture

      А плагины как по мне решают немного другую задачу


  1. temamagic
    29.04.2022 00:21

    Спасибо за статью! Занимаюсь разработкой ботов уже 6 лет, и хорошо что они в тг, т.к судя по вашей статье прикрепить фотографию к сообщению это попаболь)

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

    Вообще было много ботов, и если собрать их в одно, то эти боты решали следующие задачи:

    • У нас часто скидывали задачи в чат, и с мобильника было не очень удобно просматривать их в браузере, по этому он показывал краткое превью задачи (и по кнопке разворачивал полный таск с комментариями) если кто-то кидал ссылку, и позволял делать "быстрые" опции с ней

    • У нас был мониторинг обычный, но увы не было мониторинга версий, по этому он стал следить за выходом релизов каких-то групп сервисов связанных вместе и показывал понизилась версия или повысилась и писал об этом в чат. Было удобно потому что не все процессы были идеально в этом плане отлажены, и порой случалось так что зависимая часть сервиса выкатывалась а ты не в курсе :(

    • можно было "подписаться" на уведомления о выходе релиза у сервиса:) Этим пользовались те, у кого не было доступа в систему релизов, но им хотелось узнавать о выходе, как правило, это были менеджеры или тестеры

    • Через бот можно было с мобильника послать запрос на внутрисетевой ресурс и получить ответ :) Узкий кейс, но пару раз пригождалось

    • Как и у вас,бот напоминал о подвисших тасках тегируя нужных людей, и в целом можно было попросить о чем-то напомнить

    • Помимо релиза версий еще и следил за SSL и доменами, у нас уже был простенький внутренний мониторинг этого, но постоянно нужно было напоминать об этом куда-то еще, и бот в тг показался отличным вариантом

    • Еще один супер узкий кейс - это мониторинг апи тестами. Все по той же причине плохих процессов пришлось докручивать и это, помогало понять что какой-то релиз сломал апи, если кто-то невнимательный плохо проверил или пропустил это в релиз, а сами тесты описывались как json схема с правилами)