Когда команда растёт, а процессы усложняются, тратить время на ручную сборку аналитики — непозволительная роскошь. Особенно если речь о разработке, где Lead Time, плотность багов и скорость релизов — ключевые метрики OKR.
CPO Эсборд Владимир Гладун рассказывает, как его команда построила автоматическую систему трекинга задач с помощью скрипта и API Weeek
и получила прозрачную аналитику по задачам.
😎 Как управлять проектами без постоянных уточнений
Делимся опытом команды Weeek →Работа по OKR и нехватка аналитики
Мы в работе используем фреймворк OKR как центральную систему управления качеством и скоростью работы.
В OKR фиксируются конкретные показатели: доля закрытых приоритетных багов, воронка обнаружения багов (тестировщики или пользователи), плотность багов
на фичу, crash-free rate, скорость выполнения задач от технического дизайна
до релиза, показатели автотестов и время жизни багов.
Поэтому автоматическая выгрузка аналитики из Weeek стала ключевой: OKR требуют частого мониторинга — не раз в месяц, а ежедневно. Без автоматизации ни одна из этих метрик не могла бы поддерживаться актуальной и управлять работой команды.
С учётом нашей работы по OKR, аналитику и выгрузку нам нужно было смотреть чаще, чем раз в месяц. Так что мы решили написать скрипт и сделать собственную аналитику.
Тот самый скрипт
Придумали мы схему из трёх компонентов:
Написали Python-скрипт. Он раз в день по Cron (через Yandex Cloud Functions) ходит в API Weeek, забирает все задачи из конкретной доски, сравнивает их с предыдущим днём, фиксирует изменения статусов и передаёт всё это в Google-таблицы
Google-таблица — наша база исторических данных. Каждая строка является задачей, столбец — колонкой Канбан-доски из Weeek, например, «Новые баги», «В реализации», «Готово к релизу», «Зарелизено» и т. д. Если задача в какой-то день перешла в новую колонку, в ячейке появляется дата перехода.
Внутренние дашборды по багам и задачам также в таблицах. На основе таблицы выводим метрики и графики: «Время жизни багов по приоритетам», «Плотность багов на фичу», «Распределение багов по типам», «Lead Time от Technical Design до релиза», «Доля закрытых багов с критичностью Red/Orange в OKR-периоде»
И вот теперь мы ежедневно видим эти цифры, принимаем на их базе решениеи вылавливаем проблемы.
Всю эту систему сделали не разработчики, а аналитик-джун с помощью AI. Где-то за два дня эту задачу удалось реализовать. И, кстати, вот тот самый скрипт! В формате txt.
❗Дисклеймер. Публикация скрипта носит ознакомительный характер. Его содержание не соответствует вашей команде и процессам, так как написан для команды и процессов Эсборд. Не пытайтесь применить скрипт у себя, не сработает. Но поучить на нём ИИ можно
Не про скрипт, но очень интересно
После успеха со сбором данных команда пошла дальше — теперь ЯндексGPT помогает приоритизировать баги.
Как работает:
➡️ Скрипт берёт новые баги из Weeek (по кастомному полю Task Type)
➡️ Передаёт название + описание в нейросеть
➡️ Нейросеть возвращает приоритет и объяснение, почему он такой
➡️ В Weeek проставляется отметка «обработано ИИ», а тестировщик получает отчёт в Telegram
Комбинация Weeek и небольшого слоя автоматизации превращается в мини-аналитическую систему. В итоге мы экономим время, получаем данные для зрелой продуктовой культуры, укрепляем дисциплину и эффективнее достигаем целей
по OKR.
