Привет, Хабр! Меня зовут Сергей, я руководитель разработки в ITFB Group.

Если вы когда-нибудь управляли командой разработки, то наверняка сталкивались с ситуацией: дедлайн горит, проект буксует, а разработчик на стендапе говорит: «Да всё делаю, осталось немного». Ты смотришь в Jira — задача давно в работе, в Git — коммиты есть, а результат не движется. И начинаются «разборы полётов»: попытки понять, где человек реально писал код и коммуницировал с командой, а где просто создавал видимость активности для отчётности.

В этой статье я расскажу, как из таких ситуаций и желания сделать процессы прозрачными родилась наша внутренняя система, которая затем превратилась в продукт KODA. Мы не пытались измерить всех одной линейкой «строк кода в день». Всё началось с потребности понять, почему проекты встают, и научиться видеть проблемы не постфактум, а в моменте.

Предыстория: когда масштабирование выявляет боль

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

Мы начали масштабировать процессы: появились проекты на едином стеке (Java), выработали общие подходы к организации работы, смешивали Agile с Waterfall там, где это требовалось. Это позволило нам миксовать людей между командами — инженерам стало интереснее менять профиль работы, а у компании перестали появляться незаменимые сотрудники. Все знают примерно одно и то же и работают в одном поле.

Но тут же вылезла и проблема. Мы вели два параллельных проекта: один был очень сложным, и как только мы переключались на него, второй начинал тормозить. Я и другой руководитель физически не могли разорваться, возникали конфликты. Кто-то говорит: «Я работаю» — а ты чувствуешь, что человек работает спустя рукава. Начинаются разбирательства, хотя цель была не вывести кого-то на чистую воду, а сдать проект. Для этого нужны объективные факты, которые можно получить только из артефактов, создаваемых сотрудниками: аналитиками, разработчиками, тестировщиками.

Первый прототип: когда стандартных отчётов недостаточно

Мы начали с малого: в конфликтных ситуациях лезли в GitLab и изучали активность. Можно, конечно, построить в голове примерный профиль разработчика и понять, работает он или нет, но это ручной труд, который занимает время и не даёт полной картины.

Мы задумались: а что, если автоматизировать этот процесс и использовать его не только в спорных случаях, а постоянно, чтобы выявлять проблемы как можно быстрее? Например, кто-то перестал пушить изменения два-три дня — тимлид получает уведомление. Аналитик не пишет статьи и не создаёт задачи в Jira — сигнал для руководителя проекта и ресурсного менеджера.

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

Кейс с «дорогостоящим специалистом», который всё перевернул

Настоящий триггер для создания KODA случился в прошлом году. У нас был один очень дорогой специалист. Он думал, что у нас уже есть система мониторинга, и… начал имитировать свою деятельность: создавал фейковые коммиты в GitLab, накидывал себе задачи в Jira. Если бы мы строили стандартные отчёты Jira или просто смотрели активность в GitLab, у нас сложилось бы полное впечатление, что человек пашет. Плюс у него был хорошо подвешен язык, и он мог объяснить руководителю проекта (не техническому специалисту), почему что-то не сделано.

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

Рождение продукта: второе дыхание

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

Мы начали не с попытки измерить всех подряд, а с определения того, какие артефакты создают разные роли. Разработчик пишет код и двигает задачи в Jira, аналитик создаёт задачи, меняет статусы, пишет статьи в Confluence, руководитель проекта планирует спринты. Позже добавились мессенджеры: мы работаем в Telegram, у нас своя культура ведения проектов с разделением на топики. Задача была не в том, чтобы сразу искать аномалии — сначала достаточно подсвечивать отсутствие того, что должно происходить.

Геймификация и дашборд разработчика

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

Сейчас как раз делается дашборд разработчика, где каждый инженер может в любой момент посмотреть свою собственную статистику: частоту и качество PR, время ревью, связь коммитов с задачами, динамику дефектов. И, что важнее, сравнить её не с соседом, а с самим собой в прошлом. Мы вводим элементы геймификации — например, значки за «зрелые» пул-реквесты (мало переделок), за регулярные маленькие коммиты, за быстрое прохождение ревью. Это превращает скучную «метрологию» в челлендж, где разработчик сам заинтересован расти.

Как это работает

Сейчас KODA собирает данные из репозиториев кода (Git), трекеров задач (Jira и российские аналоги), баз знаний (Confluence), систем управления тестированием — Zephyr (встроенный в Jira) и отдельного коннектора к TestIT. Помимо этого, система интегрируется со статическим анализатором кода SonarQube, отслеживает активность через VPN (время нахождения в сети) и включает модуль для сбора данных из мессенджеров.

Архитектурно это выглядит так: набор коннекторов к системам-источникам забирает данные и приводит их к обобщённой форме. Данные попадают в несколько слоёв БД (сырые и подготовленные). Дальше мы используем BI-слой — выбрали Яндекс DataLens как российское решение, которое закрывает 95% потребностей. Плюс есть сервисный UI для работы с сущностями: проекты, пользователи, ролевые модели.

Мы не ставили задачу мерить всех по одной линейке и требовать «норму выработки». У нас не стройка, где можно посчитать квадратные метры. 100 строк кода на одном проекте могут быть равноценны 1000 строк на другом. Поэтому в KODA заложена гибкая аналитика: вы сами определяете, что считать нормой, а что — аномалией.

О метриках: от количества к качеству

Мы прошли путь от «количественных» метрик к «качественным». Сейчас в системе есть три больших блока метрик:

• Разработчик: количество и частота PR/коммитов, размер PR, длительность ревью, «зрелость» PR (процент переделок), время деплоя, привязка коммитов к задачам.

• Тестировщик: количество найденных дефектов, процент пропущенных критических дефектов, количество и частота новых тест-кейсов и автотестов, качество тестов.

• Команда и DORA: точность планирования, процент покрытия кода тестами, процент техдолга, длительность цикла разработки, частота релизов, время восстановления после аварий.Следующий шаг — анализ смысла артефактов с использованием больших языковых моделей (LLM). Например, чтобы система могла определить: это действительно объёмный и полезный комментарий?

«Зрелость PR» и другие метрики: кому это нужно?

Раз уж зашла речь о метриках, хочу сразу ответить на вопрос, который наверняка возникнет: «А не высосаны ли эти метрики из пальца?»

Возьмём, к примеру, метрику «зрелость PR». Запрос на слияние редко когда сливают сразу, обычно требуются доработки. Если от изначального кода PR к моменту слияния изменили 0% — есть риск, что ревью было формальным, и код слили «галочки ради». Если изменили 10% — нормально, поправили мелкие недочёты. Если изменили 80% — скорее всего, код был изначально плохим, и его пришлось практически переписывать.Кому нужна эта метрика? Тимлиду — чтобы оценить, насколько тщательно проходит ревью. Для топ-менеджмента или бизнеса она бесполезна. KODA изначально задумывалась как инструмент для разных уровней управления. Кому-то важно видеть просто «жив/мёртв» разработчик, кому-то — time-to-market фичи от постановки задачи до релиза, кому-то — качество кода. Мы не пытаемся сделать «один размер для всех».

Результаты, которые мы получили уже сейчас

По итогам трёх кварталов 2025 года производительность наших команд выросла на 30%, time-to-market сократился до 40%, количество дефектов и переделок снизилось до 30%. Это данные по внутреннему использованию KODA.Важно подчеркнуть: это не только заслуга метрик. Метрики — лишь инструмент. Они дают прозрачность, а дальше в дело вступают тимлиды и руководители проектов, которые могут принимать обоснованные решения, а не гадать на кофейной гуще. Кроме того, мы видим снижение нагрузки на тимлидов: не нужно тратить часы на «разборы полётов» — система автоматически подсвечивает проблемные места.

Текущий статус и планы

Сейчас продукт находится в стадии активной разработки. Если говорить честно, у нас есть моё «топорное» решение, которое работает внутри компании. Оно масштабируемое, его можно использовать, но оно не покрывает весь класс систем анализа продуктивности разработчиков. Новый продукт, который мы сделали с командой, — это уже полноценная платформа инженерной аналитики. Главное отличие KODA от зарубежных аналогов — работа on‑premise. Все данные собираются и обрабатываются внутри контура компании, ничего не передаётся сторонним сервисам. Это критически важно для банков, телекома и других высокорегулируемых отраслей.

История KODA — это история про боль масштабирования и желание управлять разработкой на основе данных, а не ощущений. Мы не придумывали велосипед: подобные системы существуют на Западе (Gartner прогнозирует, что к 2027 году 50% компаний будут использовать платформы инженерной аналитики). В России рынок только начинает формироваться, и нам захотелось стать одними из первых, кто предложит комплексное, дружественное к разработчикам решение.Если вы столкнулись с похожими проблемами, приглашаю к обсуждению в комментариях. Интересно узнать, как вы решаете вопросы прозрачности в своих командах и относитесь к геймификации. И, конечно, если хотите попробовать KODA в деле — пишите, обсудим.