Привет, Хабр!

Меня зовут Кирилл Невзоров, я руководитель отдела анализа и управления проектами. В первой части речь шла про роли, ответственность и точки входа в команды. Но чтобы процесс стал управляемым, одного организационного контура недостаточно. Настоящие изменения начались тогда, когда мы навели порядок в Jira и начали считать числа.

Стандартизация пространств и полей: убираем хаос

До изменений существовало несколько базовых пространств и сущностей:

• Отдельное пространство, в котором создавались только эпики — такая минимальная discovery-часть на стороне заказчика.

• Отдельные пространства для системного анализа, веб-разработки и мобильной разработки. И во всех этих пространствах использовалось два типа задач: баг и таска. Доходило до того, что в каждом типе задач было до 50 кастомных полей, созданных исторически, а эпики содержали сотню задач и могли не закрываться больше года.

Мы изменили подход и разделили работу на два независимых контура: discovery заказчика и доставку. Мы специально разделили эти контуры по разным пространствам Jira, чтобы: 

• проработка требований не смешивалась с инженерной доставкой; 

• команды разработки не работали напрямую с «сырыми» инициативами; 

• метрики delivery не искажались discovery-активностью.

Пространство discovery

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

Уровень эпика — тип задачи, объединяющий технические работы по одной функциональной области. В рамках эпика инженерная команда совместно с заказчиком уточняет технические требования, необходимые для реализации. После внутренней технической проверки эпик передают в разработку

Пространство delivery

Принадлежит трайбу. Например, у e-com своё пространство, у 1С — своё.

Для наглядности отобразим это на схеме. Discovery-часть — на стороне заказчика, delivery — на нашей.

Уровень инициатив

На этом уровне важно понимать контур работ и зоны ответственности:

• Участвующие команды — фиксируем все команды и трайбы, вовлечённые в инициативу.

• Ведущая команда — инициатор и координатор выполнения.

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

Уровень эпиков

Эпик — это уже управляемая единица планирования:

• команда — зона ответственности;

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

• оценки по функциям (бэкенд, фронтенд, iOS, Android и др.).

Функциональная декомпозиция оценки позволяет агрегировать загрузку по ролям и отслеживать узкие места.

Уровень задач

На этом уровне мы фиксируем фактическую работу:

• платформа — какой стек дорабатывается (web, app);

• оценка по функциям — отдельные поля для разработчика и тестировщика;

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

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

На основе этих данных автоматически собираются стандартные поля Jira: Original Estimate, Remaining Estimate, Time Spent.

Что это дало 

Однако стандартизация сущностей и полей — только часть системы. Не менее важно, чтобы жизненный цикл задач в Jira отражал реальный процесс работы команд. Если статусы живут отдельно от процесса, то отчётность перестаёт быть достоверной. Поэтому следующим этапом мы пересобрали рабочий процесс и автоматизацию.

Workflow и автоматизация: прозрачность без компромиссов

Следующий этап после структуры работ — это статусы и их актуальность. Если статусы не отражают реальность, то любая отчётность теряет смысл.

Инициативы: минимум ручного управления

Для инициатив мы сознательно упростили рабочий процесс и убрали ручные переходы. Все статусы автоматизированы, в зависимости от состава и статусов эпиков внутри.
Беклог → Этап discovery → Утверждение задания (здесь несколько путей, в зависимости от затрат) → Этап delivery → Приёмка → Наблюдение (тут живут A/Б-тесты, поддержка) → Готово.

Как результат: исчезает рассинхрон между «реальным» состоянием работ и статусом в системе. Инициативу не нужно обновлять вручную.

Эпики: контроль качества перед разработкой

Для эпика основная задача — качественная приёмка, поиск корнер-кейсов и итоговая оценка:
Беклог → Описание → Грумминг → Техническая декомпозиция и оценка (здесь могут создаваться задачи на исследование, системный и архитектурный анализ и комитет) → Разработка → Приёмка → Готово.

Задачи: максимальная прозрачность и контроль

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

• Первая часть — разработка и тестирование. Команда заканчивает свою работу на статусе «Решено», и по этому статусу мы считаем метрики команды. Статус означает, что команда закончила и больше эту задачу не трогает.

• Вторая часть — от «Решено» через «Готово к релизу» и прочие статусы до «Готово» (где устанавливается резолюция). Это зона ответственности релизной команды, и тут мы считаем их метрики без влияния на команду.

Такой подход для задач приносит достаточно много проблем с нативной настройкой Jira (базовый процесс подразумевает получение резолюции у задачи, а в нашем процессе ИТ-команда работу закончила, а резолюция появится только после релиза), но позволяет разделить зоны ответственности и сосредоточить усилия команды на выполнении задач.

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

Hold — управление блокерами в Jira

Раньше в Jira не было различия между задачей, над которой ведётся работа, и задачей, которая находится в ожидании. В системе они выглядели одинаково — «в работе». Из-за этого метрики искажались: казалось, что разработка затягивает сроки, хотя команда могла ждать ответ от заказчика или зависеть от другой команды.

Поэтому мы добавили отдельный статус Hold и начали переводить на него заблокированные задачи с обязательным комментарием о причине. Это позволило отделить задержки в разработке от внешних блокеров. Блокеры легли на отдельный дашборды, ежедневный фокус ответственных на них позволил снимать их быстрее. Спустя полгода статистика показала, что Hold вообще перестал значимо влиять на метрики, потому что мы начали снимать блокеры достаточно быстро.

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

Ждём согласования стратегии от @Вася до 15.09

После того как мы стабилизировали работу с блокерами и очистили метрики от искажений, перешли к следующему уровню — планированию.

Стабилизация планирования: от канбана к спринтам

Критерии попадания задачи в спринт

Раньше задачи попадали в спринт довольно свободно, многое решалось «на ходу». В работу иногда брали сырые или недооценённые инициативы, а уточняли уже в процессе.

Мы ввели чёткие правила: задача попадает в спринт, только если она описана (Заполненные поля «Проблема», «Решение», «Ожидаемый результат», Product Requirement Document (PRD), Technical Requirements Document (TRD)), выставлены оценки разработки и тестирования и пройден анализ. Если эти условия не выполнены, то задачу не планируем.

Capacity: перестали планировать «на глаз»

Главная проблема была в том, что мы не знали реальную производительность команд. Спринты планировали примерно так: «возьмём и посмотрим, как пойдёт». В итоге задачи переносились, спринты не сходились, а квартальное планирование строилось на предположениях.

Мы привели Jira в порядок и начали считать фактический объём выполненной работы и долю переноса. Затем рассчитали реальный capacity — сколько задач команда стабильно закрывает за спринт. Параллельно вывели на дашборды сгорание задач, чтобы видеть динамику внутри спринта.

Что касается capacity: если учёт плановых отпусков или коэффициента Work Ratio — это довольно простая задача, то про операционные затраты многие забывают. Например, у наших QA много времени съедают регрессы релизов, а у разработки — проверка кода.

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

Дальше алгоритм такой:

1. Закладываем долю улучшения процессов, инфраструктуры и прочего.

2. Вычитаем отпуски.

3. Добавляем плановые расширения (например, новых сотрудников).

4. Получаем итоговое число доступного времени на разработку.

Со временем добились сходимости примерно в пределах 20% — план почти совпадает с фактом.

Метрики показали, что проблема была не в скорости, а в неопределённости. Как только появились числа, планирование стало спокойнее и предсказуемее.

Bottleneck: этап тестирования

Когда начали смотреть на числа, то стало понятно: разработка отдаёт задач больше, чем тестирование успевает проверить. Раньше казалось, что «разработка тормозит», но метрики показали, что узким местом было QA.

Мы добавили важное правило: у каждой задачи теперь есть не только оценка разработки, но и отдельная оценка тестирования. Это позволило видеть реальную загрузку обеих сторон, а не считать работу команды только по dev-часам. При расчёте capacity стало очевидно, что из условных 80 рабочих часов за двухнедельный спринт тестировщик может планировать примерно 50 часов. Остальное уходит на регрессы, встречи, синки и операционную нагрузку.

Отдельной болью оказались регрессы. Иногда они занимают значительную часть спринта и «съедают» время, которое планировали под новые задачи. Это напрямую ограничивает пропускную способность команды.

Второе важное изменение: у каждой задачи появилось поле QA notes, в котором разработчик обязан указать, какие изменения он внёс и какие модули затронул. Сначала это делали руками, сейчас — с помощью ИИ, анализирующего код.

В итоге поток стал более сбалансированным, а перегруз тестирования — управляемым. Это повлияло на основную метрику C-Time.

Инцидент-менеджмент: от пожаров к статистике

Параллельно с настройкой Jira мы навели порядок в работе с инцидентами. Раньше их решали по факту: собрались, починили, разошлись. Статистики почти не было, выводы делали точечно, системной картины не хватало.

Мы выделили отдельный проект под инциденты, ввели классификацию по приоритетам (P0, P1, P2), начали фиксировать длительность простоя и считать потенциальные потери для заказчика. По каждому серьёзному случаю пишем постмортем с разбором причин и шагами по предотвращению повторений.

Типизация: код проекта, администрирование, внешнее воздействие, инфраструктура, внешняя интеграция.

Классификация: P0 — полная недоступность, P1 — недоступность критичной функциональности (от продуктовых метрик), P2 — недоступность некритичной функциональности (нет влияния на продуктовые метрики), P3 — проблемы, не влияющие на пользователя.

Появилось распределение ответственности: есть ведущий инцидента, есть команда, которая разбирает техническую причину, и есть зафиксированные действия по улучшению.

В итоге стало понятно, где чаще всего происходят сбои, что лежит в основе проблемы — код, инфраструктура или внешний вендор, — и какие направления требуют усиления.

Инциденты перестали быть разовыми «пожарами» и стали частью управляемой статистики.

Метрики разработки: три уровня глубины

Все доработки позволили нам подступиться к важному этапу жизни ИТ-команд — метрикам. Всего у нас около 60 ключевых метрик по всем направлениям. Какие-то из них операционные — команда смотрит их на дейликах, другие — по итогам спринта, есть метрики, которые чаще раза в квартал смотреть нет смысла.

Мы разделили их на три уровня.

1. Личная эффективность — метрики линейных сотрудников (dev, QA). Делятся на ролевые и операционные.

Операционные:

• Work ratio — сколько обещал потратить времени на задачи и сколько фактически потратил.

• Утилизация времени — сколько ушло на созвоны и операционную работу, а сколько — на целевую разработку.

• Как часто изменялся остаток времени у задач.

Ролевые:

• Для dev: возвраты в разработку, количество дефектов, среднее количество изменённых строк в PR, количество отказов и комментариев к PR, участие в проверке.

• Для QA: сколько багов найдено в dev/preprod/prod, затраты времени на регрессы, соотношение решённых багов к «ложным» с учётом приоритета.

2. Командная эффективность — метрики команды (TPM, TL):

• Cycle Time эпиков в команде;

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

• выполнение плана поставки (плановое время — фактическое);

• доля сходимости спринта.

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

3. Метрики трайба — глобальные показатели в рамках направления:

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

• Cycle Time по командам;

• сгорание квартальных планов;

• стоимость регрессов;

• длительность проверки и затраты на него;

• выполнение планов релизной команды.

Как собирать, отображать и настраивать метрики стоит написать отдельную статью, тема очень объёмная. Отдельный блок — какие метрики у нас не получилось собрать и какие принесли только вред команде. Из того, что вылезло сразу:

1. Некорректный учёт затраченного времени практически у всех команд.

2. WorkRatio некоторых разработчиков явно выбивался, разобрали с ними проблему «оптимистичного планирования» — что в итоге повлияло на сходимость спринтов.

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

10 ключевых выводов

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

2. Эпик должен принадлежать одной команде. Иначе метрики размываются, а ответственность — нет.

3. Hold ≠ парковка. Заблокированные задачи нужно честно маркировать с комментарием причины, иначе метрики Cycle Time теряют смысл.

4. Задача в спринте — только когда готова к разработке. Чёткие критерии входа дисциплинируют команду. 

5. Планируйте не «на глаз», а от реального capacity. Сходимость плана и факта в пределах 10% достижима, если знать фактическую производительность.

6. Тестирование — часто узкое место. Планируйте спринт от реальной пропускной способности QA, а не от разработки.

7. QA notes обязательны. Разработчик указывает, что менял и какие модули затронул, это сокращает тестирование.

8. Инциденты — не пожары, а статистика. Классификация, постмортемы и выделенный проект превращают хаос в управляемый процесс.

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

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

Результаты изменений

После всех изменений работа стала гораздо прозрачнее. Начали видеть реальные сроки и понимать, на чём строится планирование. Команды получили явные зоны ответственности, а задачи перестали «зависать» без внимания.

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

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