Как спектральный анализ улучшает оценку задач и снижает стресс в команде разработки
Привет! Меня зовут Илья, я руководитель команды индивидуальных интеграций CDEK. В рамках этой статьи хочу поговорить о спектральном анализе — инструменте для аналитики и прогнозирования задач команд разработки. По итогу мы с вами разберемся, когда стоит его применять, почему он делает оценку задач прозрачнее и как с его помощью улучшить не только доставку фич, но и атмосферу в команде.
Статья, как и сам инструмент, подойдёт тимлидам, product‑ и project‑менеджерам, которые уже имеют опыт управления командами, набили шишки в запуске фич и ищут понятный и наглядный инструмент планирования, но не обладают большим техническим опытом.
Важно учесть
Перед началом спектрального анализа убедитесь, что используемый командой менеджер задач позволяет делать выгрузки за необходимый вам период с заданными параметрами, иначе сбор информации отнимет все силы.
Спектральный анализ отлично совместим с Kanban, позволяет найти узкие горлышки и настроить поток с учётом особенностей команды.
Инструмент подойдет как для внутренних команд, так и при работе со сторонними компаниями.
Что же такое «спектральный анализ»
Если мы обратимся к Википедии, то узнаем классическое научное определение:
Спектральный анализ — совокупность методов качественного и количественного определения состава объекта, основанная на изучении спектров взаимодействия материи с излучением, включая спектры электромагнитного излучения, акустических волн, распределения по массам и энергиям элементарных частиц и др.
С разработкой и тем более оценкой задач команды это определение никак не связано, так что предлагаю вам свой вариант.
Спектральный анализ — инструмент визуального представления и прогнозирования результата работы с обязательным сравнением относительно референсного значения системы, учитывающий особенности реализуемых задач и поведенческие факторы команды.
Далее давайте рассмотрим применение спектрального анализа на примере моей команды в разрезе первых шести месяцев 2023 года.
Этапы спектрального анализа
Этап 1: определяем целевой показатель
Сам по себе анализ задач полезен, но без конкретной метрики для оценки успешности он будет малоинформативен.
В каждой компании и команде целевая метрика может быть своей. Это обусловлено как особенностями команды, так и целями компании на текущем этапе её развития. Я буду рассказывать про анализ задач на основании показателя Cycle Time.
У нас в CDEK целевой показатель Cycle Time зафиксирован и равен 14 дням (референсное значение системы). Фактически реализация задачи должна укладываться в двухнедельный спринт. Именно по значению Cycle Time я оценивал задачи команды в процессе аналитики.
Этап 2: сбор информации по задачам
Для аналитики нужно убедиться, что в вашем менеджере задач можно выгрузить необходимые задачи. Мы работаем в Jira и для выгрузки используем удобный плагин из официального стора. Он позволяет гибко настроить список задач для выгрузки с использованием фильтров:
Используемые фильтры для поиска задач в Jira
Для себя я взял период выгрузки в шесть месяцев, потому что пришёл в команду в январе 2023 года, и ранее подобная аналитика не проводилась. Мне нужен был максимально доступный период, за который команда могла поработать с совершенно разными задачами.
Если вы в команде давно и хорошо знаете своих сотрудников, но не используете регулярно спектральный анализ, тогда период выгрузки задач можно сократить до трёх месяцев.
Проводить аналитику менее чем за три месяца не рекомендую, потому что выборка задач будет значительно меньше, что не позволит вам сформировать полный спектр по итогу работы.
Кроме периода выгрузки нам важно получить информацию:
название задачи;
тип задачи: аналитика, фича, эпик (финальный список зависит от особенностей вашей команды, у нас в рейтинг попадают только задачи с типом «баг», «фича» и «улучшение», их и беру для себя);
общий CT задачи;
статусы задачи и время, которое она в них провела (разработка, ревью, тест и др.);
общее время, потраченное командой на задачу (опционально, если вы журналируете; это позволит сравнить реальную длительность работ по задаче с её CT).
Пример получившейся выборки задач
Этап 3: оформление документа для работы
Для удобства выгруженный файл добавляем в онлайн таблицу. Настраиваем фильтры по колонкам, сортируем по нашему ключевому показателю Cycle Time от большего к меньшему. Для наглядности рекомендую покрасить задачи в цвета, исходя из величины CT. Для себя выделил следующие сегменты:
1–3 дня: быстрые задачи;
4–5 дней: задачи в рамках одной рабочей недели;
6–10 дней: начали неделю назад, но релиз после выходных;
11–15 дней: задачи полного спринта;
16–20: не успели, но были близки;
сегменты 21–25, 26–30, 31–40, 41–50 и 50+ использовал для большей детализации.
Такая детализация периодов вначале себя полностью оправдала, но дальше использовать её не планирую. Для нашей команды все сегменты после 20 дней CT можно смело брать с периодом в 10 дней, на точности это не отразится.
В итоге получаем структурированный файл для дальнейшей аналитики.
Список задач обрел вид спектра
Этап 4: аналитика
Я принял для себя, что не буду рассматривать задачи, которые укладываются в 14 дней CT. Это сократило исследование, к тому же в первую очередь важно было понять, что пошло не так в реализации задач, не уложившихся в целевой показатель.
Первым делом рассматриваю жизненный цикл задачи по статусам на доске команды. Ищу «выбросы», когда очевидно, что задача провела в статусе слишком много времени.
Например: задача по переходу на новый API провела в статусе «Ждёт теста» две недели.
Фиксирую это отклонение в комментарии рядом с информацией о задаче, которую мы выгрузили ранее. Если «выбросов» несколько, то фиксирую каждый в формате «статус + время пребывания задачи в нём».
Далее открываю задачу в Jira и восстанавливаю по ней контекст, если требуется. Изучаю комментарии команды, логику переходов из статуса в статус (были ли движения по доске назад), сверяю релизы команды с периодом работы над задачей (нужно понимать, насколько мы были загружены в тот момент). Здесь важно максимально подробно понять, какие проблемы возникли при реализации задачи. Найденные причины фиксируем в комментарий.
Такую работу необходимо проделать по всем задачам. Сначала изучение каждой будет занимать значительное количество времени, но чем дальше двигаешься по списку, тем больше проявляются взаимосвязи и повторяются причины. Спектр начинает обретать описание.
Этап 5: описание сегментов
После того, как у меня были готовы описания всех исследованных задач, перешёл к детализации информации о сегментах. Зафиксировал, сколько задач попало в каждый выделенный сегмент. В описание сегмента добавил типы и специфику задач, попавших в него: метрики мониторинга; фичи с добавлением уведомлений на почту, переработкой статусной модели заказа, разработкой нового API; залежавшийся техдолг и т. д.
Этап 6: визуализация результатов
Мне захотелось иметь наглядные итоги проделанной работы в разрезе общего количества задач. Для этого я создал простые диаграммы. Посчитал долю задач от общего количества за шесть месяцев, которые попали или не попали в целевой показатель CT 14 дней.
Отдельно посчитал, насколько могла быть больше доля успешных задач, если бы соблюдали принятый в компании процесс.
Здесь хочу подробнее рассказать про внутренние договорённости между командами разработки CDEK. Выше я упоминал о том, что в рейтинге команд разработки мы учитываем лишь три типа задач (баг, фича и улучшение). Но кроме ограничений по типу есть условия, что если задача вышла из бэклога, побыла в работе на доске, а затем вернулась в бэклог — её CT не прекращается и из рейтинга задача не пропадает. Увы, в начале года у нас нашлось целых 20 таких задач, что существенно испортило наши показатели.
Оформил сегменты с количеством попавших в них задач в виде столбчатой диаграммы.
Визуализация результатов помогла мне лучше понять, где команда находится сейчас, и презентовать итоги коллегам.
Этап 7: прогнозируем задачи команды
После завершения работы по анализу и визуализации итогов внедрил применение полученных спектров в планирование задач. Для этого добавил отдельный столбец «Группа спектра» в наш месячный план команды.
Это позволяет мне видеть планируемую скорость потока и заранее менять приоритеты команде, если становится очевидно, что задачи могут начать накапливаться на каком‑то из этапов разработки.
Какую пользу можно получить при регулярном применении спектрального анализа
Во‑первых, это добавляет прозрачности работе команды. Ежедневная рутина забирает у меня большую часть внимания, и в памяти фиксируются только крупные успехи или неудачи. Переключаясь на аналитику, можно увидеть всю картину целиком и вовремя скорректировать путь команды.
Во‑вторых, мне больше не нужно просить команду оценивать каждую задачу. Да‑да, наличие чётко описанных спектров позволяет при появлении новой задачи обратиться к ним. Это экономит время, ускоряет планирование задачи и попадание её в план спринта. Особенно подойдёт командам, в которых есть проблемы с оценкой или её постоянным саботажем отдельными участниками.
В‑третьих, улучшает процесс оценки задач, если вы им всё же занимаетесь. Вы, как руководитель, можете более аргументированно задавать вопросы, почему та или иная задача требует заявленного времени. Также вы сможете избежать фраз «мне так кажется», «может быть» и пр. Вместо них будете ссылаться на конкретные примеры ранее реализованных задач. Например, вам необходимо разработать новый API. По итогам спектрального анализа вы видите, что подобные задачи занимают у команды 10 дней CT. При оценке новой задачи у вас получается 15 дней на разработку, тестирование и отладку. Резонно обсудить с командой, чем новая задача отличается от ранее реализованных, какие риски добавились и были учтены командой, но вы о них не знаете.
И в‑четвертых, это позволяет аргументированно запрашивать ресурсы для команды. Добавить в неё нового человека сложно в компании любого уровня. Достаточно часто встречаются случаи, когда найм полностью остановлен и максимум, на что можно рассчитывать — ротация сотрудника между командами.
Когда у вас на руках есть актуальная аналитика возможностей команды, где четко видны проблемные зоны, ваши аргументы будут звучать убедительнее и шанс получить заветный ресурс будет выше.
Заключение
Описанный процесс исследования для меня является частью творческой работы руководителя команды разработки. Это не скучный поиск причин неудач команды, а скорее, нащупывание точек роста и улучшения.
В нашем случае, по результатам проведенной аналитики, стало понятно, что основным «узким горлышком» команды является ресурс тестирования. Задачи часто подвисают в ожидании или в процессе тестов. Для улучшения ситуации решили выделить больше ресурсов на покрытие модулей автотестами, что сократит длительность регресса задач.
Рассмотренный в статье инструмент является лишь частью большого количества полезных практик по мониторингу ситуации в команде. Для меня ключевыми его преимуществами являются универсальность (подходит всем командам и совместим с любой методологией управления проектами) и наглядность.
Если вы уже применяли спектральный анализ или у вас альтернативные инструменты в управлении командой и вы можете поделиться опытом, пишите комментарии! Буду рад продуктивному диалогу.
