Серия «Аналитика в разработке»

Когда руководитель отдела продаж приходит на встречу с директором, он открывает CRM и за несколько минут отвечает практически на любой вопрос.

• Сколько лидов пришло?

• Какая конверсия?

• Почему просели продажи?

• Какие менеджеры перегружены?

• Какие сделки находятся в зоне риска?

Маркетинг живет примерно так же.

Есть стоимость привлечения клиента, ROI, LTV, эффективность рекламных каналов и десятки других метрик.

Финансовый отдел тоже давно привык принимать решения на основе данных.

Доходы, расходы, прогнозы, отклонения от бюджета — всё доступно практически в режиме реального времени.

А теперь представьте аналогичный разговор с руководителем разработки.

— Почему сорвали прошлый спринт?

Именно этот вопрос несколько раз ставил меня в тупик.

Когда данных много, а ответов нет

За последние годы мне довелось руководить несколькими командами разработки.

У нас были вполне современные процессы:

• двухнедельные спринты;

• Story Points;

• Code Review;

• CI/CD;

• Яндекс Трекер;

• GitLab;

• регулярные ретроспективы.

На первый взгляд казалось, что информации более чем достаточно.

В любой момент можно было открыть трекер и увидеть:

• Velocity;

• Burndown;

• Cumulative Flow;

• количество выполненных задач;

• загрузку сотрудников.

Но каждый раз, когда возникал вопрос:

Почему мы не успели?

ответ приходилось искать вручную.

Самая дорогая фраза в разработке

Обычно обсуждение выглядело одинаково.

👨‍💻 Разработчики: «Было слишком много срочных задач.»

👨‍💼 Тимлид: «Мы ошиблись в оценке.»

📋 Продакт: «Требования постоянно менялись.»

🏢 Руководство: «Команда работает недостаточно быстро.»

Каждая версия выглядела убедительно.

Но была одна проблема.

Это были мнения.

Не данные.

Почему существующих отчетов недостаточно

Современные таск-трекеры отлично отвечают на вопрос:

Что произошло?

Но почти не помогают ответить на другой:

Почему это произошло?

Представьте ситуацию.

Спринт завершился с выполнением всего 70% запланированного объема.

Трекер покажет красивые графики.

Но не расскажет, что:

• в середине спринта появилось двадцать новых задач;

• несколько задач несколько раз меняли исполнителя;

• критические задачи неделями ждали ревью;

• один разработчик стал узким местом сразу для нескольких проектов;

• значительная часть времени ушла на незапланированную поддержку.

Именно эти события могли стать настоящей причиной срыва сроков.

Но увидеть их в стандартных отчетах практически невозможно.

Что изменилось для меня

В какой-то момент стало понятно:

проблема не в отсутствии данных.

Наоборот.

Их слишком много.

Не хватает инструмента, который сможет превратить тысячи событий из GitLab и трекера в понятные управленческие выводы.

Не показать еще один график.

А ответить на простой вопрос руководителя:

Почему это произошло?

Вместо вывода

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

Не просто хранить задачи и строить графики.

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

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

Если тема окажется интересной читателям, в следующей статье расскажу, какие метрики действительно помогают понять здоровье команды и почему классический Velocity далеко не всегда отражает реальную картину.