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

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

Чаще всего для решения проблемы в коллективе появляется роль, называемая менеджером. Хотя, правильней было бы назвать выполняющего её человека толкателем. Толкатель посещает регулярные встречи, просматривает задачи и всюду задает один простой вопрос: «какой у нас тут статус?». В итоге любая красивая модель приоритизации отдаёт приоритет тому, у кого больше энергии и кто настойчивее спрашивает. Но заряд менеджера тоже не вечен, поэтому выше в иерархии может появиться тот, кто «толкает» самого менеджера. Работа превращается в абсурд.

Я сделал примитивный скрипт на Python, который использует возможности DeepSeek, притворяется современным менеджером и «толкает» зависшие задачи в Jira. Обобщение истории обсуждения, призывы нужных людей к ответственности и уточнению статуса — тривиальная задача для LLM. Сами формулировки «напоминаний» предельно шаблонны, бестолковы и лишены смысла. Но к этому все привыкли, поэтому тест Тьюринга проходит особенно легко.

Скрипт оставляет «мотивирующие комментарии» в наиболее запущенных тикетах, выбираемых из Jira и ранжируемых в соответствии с заданными критериями. Я протестировал работу «электронного менеджера» в смежном проекте поддержки. Из 10 старых задач после увещевания закрываются примерно 4. Скрипт оставляет комментарии от имени пользователя, токен доступа которого используется для взаимодействия с API Jira. Поэтому человек может продолжать дальнейшее общение в комментариях, либо непосредственно с участниками проекта и никто не заметит перехода «от робота к человеку».

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

Подробности и исходный код проекта: https://github.com/juks/jira-deepseek-manager.

Скриншот, используемый для иллюстрации публикации, показывает результат применения скрипта в реальном проекте. Но в целях конфиденциальности его содержимое было изменено «до неузнаваемости».