Все задачи в Done. А фича не работает.
Недавно разбирал Jira по релизной версии одного из наших проектов. БОльшая часть задач - в Done. Открываешь фичи по одной.
В первой серверная часть и основной интерфейс уже закрыты. Часть кода приложения ждёт мержа, проверка всей связки ещё идёт. По ходу появляются новые задачи: проверить настройки и аналитику.
Во второй эпик стоит в New, хотя тестировщики проверяют фичу несколько недель, а многие подзадачи давно закрыты. В тесте всплывают недостающие куски сценария. Реклама пока работает на заглушке.
По задачам картина бодрая. По фичам у каждой свой хвост, который в проценте закрытых карточек не виден.
Это геймдев, но сюжет универсальный. В телекоме и банке я видел то же самое, только вместо игроков были абоненты и клиенты.
И никому не нужно было халтурить, чтобы так вышло. Бэкенд сделал свою часть, интерфейс сделали, тестировщики честно проверяют то, что пришло. Каждый по-своему прав.
🧩 Что именно закончилось
Сам грешен: в телекоме, когда вводили единый флоу в Jira, я спорил больше всех. А сейчас сам собираю общий процесс для нескольких проектов. Спор про Done никуда не делся.
В статье про стандартизацию я писал, что у одних команд Done включает прод, а у других - только передачу в тестирование. Разные маршруты для эпиков и историй это не исправили. Названия были правильные. Done всё равно значил разное.
Тогда меня волновало, что по таким данным ничего не проанализируешь. Сейчас интереснее другое: что именно мы пообещали, когда поставили Done?
Ещё одна фича из того же разбора: интерфейс сделан и принят, а серверная часть ждёт конфигов (настроек и данных от других команд). Готовность фичи целиком ещё не подтверждена: весь сценарий никто не проверял.
Все три утверждения верны одновременно. Проблемы начинаются, когда слово по дороге наверх незаметно меняет масштаб:
- в карточке Done значит «мою часть приняли»;
- в отчёте - «фича готова»;
- в разговоре с бизнесом - «можно ставить в релиз».
Между этими фразами лежит работа: дождаться конфигов, собрать части, проверить их вместе, договориться об исключениях, выпустить. Если у этой работы нет места на доске и хозяина, она никуда не исчезает. Её каждый раз заново раскапывают из чатов и чьей-то памяти.
На встрече про DoD тестировщики описывали ровно это. Концепт показывает целевой объём, а реализация приходит с переносами и компромиссами. Что именно тестировать, выясняется уже во время проверки по тредам и разговорам.
С контентом то же самое: подготовить материалы и встроить их в продукт - разные обязательства. Первое уже выполнено, а второе ждёт остального и легко теряется. При этом самые провальные истории - на стыках.
🏃 Не заставляйте первого бегуна бежать заново
Мне помогает образ эстафеты. Каждый честно пробежал свой этап. Но время команды засекают на финише. Если палочку уронили в зоне передачи, никто не заставляет первого бегуна бежать заново. Смотрят, что случилось в зоне передачи.
Поэтому обратная крайность «ничего не закрываем до релиза» тоже так себе. Если держать карточку интерфейса открытой пока сервер ждёт конфигов, она неделями висит «в работе», хотя делать по ней нечего. На доске видно незакрытый интерфейс, а ждём мы совсем другое.
Принятые вклады закрываем. А у сборки частей и общей проверки появляются своё место и свой хозяин.
В телекоме на направлении с множеством зависимостей мы договорились: за эпик отвечает PO. А delivery-менеджера обсуждали поднять уровнем выше и собирать блоки между командами.
Одна из наших команд уже так живёт. Код влили в общую ветку, но задачу не закрывают, пока есть что доделать. «Влили» ещё не значит «приняли».
✅ Четыре разных «готово»
В модели, которую я сейчас собираю, к каждому «готово» три вопроса: что закончилось, кто это принял и чем это подтверждается.
1. Вклад принят
Кто подтверждает: получатель результата.
Чем: самим результатом и зафиксированной приёмкой: макета, кода, настроек, контента или отчёта о тестировании. Наличие файла ещё не означает, что его приняли.
Ещё не значит: фича работает целиком.
2. Связка проверена
Кто: технический владелец вместе с тестировщиками.
Чем: результатом проверки обязательных частей вместе на общей сборке: версии продукта, где они соединены.
Ещё не значит: выполнены все условия выпуска.
Экран на заглушке вместо обязательного сервиса этот уровень не проходит.
3. Готово к выпуску
Кто: владелец фичи и тестировщики.
Чем: подтверждённым обязательным объёмом, согласованными исключениями и проверенной совместимостью приложения, сервера и настроек.
Ещё не значит: пользователи уже это видят.
Здесь разбирают хвосты: реклама, аналитика, настройки. Что обязательно для выпуска, а что можно отложить, нужно решить, а не угадать по цвету карточек.
4. Поставлено
Кто: тот, кто отвечает за выпуск.
Чем: фактом доступности. Кому, когда и где доступна фича.
Ещё не значит: цель достигнута.
Влитый код, дата в плане и зелёные подзадачи выпуск не заменяют. Ноль подзадач - тоже не доказательство готовности. Пока обязательная проверка связки не пройдена, эпик не закрывается, даже если все вклады в Done. И наоборот: эпик в New, когда фичу уже тестируют - это тоже неправда, просто в другую сторону.
Последнее «ещё не значит» самое неудобное. Можно быстро выпустить первый релиз, вырезав аналитику и часть функциональности. Поставка состоится, но проверить достижение цели будет нечем.
Достигнута ли цель, покажет поведение пользователей после релиза, а не статус в Jira.
🍉 Процент готовности. Сочный арбуз
В статье про стандартизацию была «арбузная метрика»: зелёная снаружи, красная внутри. Процент закрытых задач - её идеальный представитель.
В том же срезе релизной версии нашлись ещё два сюрприза.
У части архивных задач статус был Done, а итог не проставлен. Фильтры «не Done» и «не решено» давали разные числа. Оба честные, просто отвечают на разные вопросы.
А часть работы, без которой релиз не выйдет, в версию вообще не попала. Она жила в эпиках, не привязанных к релизу.
Арифметика ответила на вопрос «какая доля карточек закрыта». От неё ждали ответа на другой: сколько нам до работающей фичи.
Даже нарезка влияет на результат: одну и ту же работу можно разбить на задачи по-разному и получить другой процент при том же состоянии продукта.
С датами похожая история. На вопрос «когда будет готово?» команды называют разные события: конец серверной части, передачу в тестирование, финальную доводку. Самая поздняя дата готовности отдельных частей ещё не даёт дату выпуска. После неё могут оставаться сборка, общая проверка и исправления. Нужна оставшаяся цепочка работ с зависимостями и людьми, которые реально доступны.
Вместо процента мне нравится короткая запись о готовности:
Интерфейс принят. Серверная часть ждёт конфигов от соседних команд, без них весь сценарий не проверить. Следующий ход за теми, кто готовит конфиги. После этого тестировщики проверяют связку на общей сборке. До этой проверки готовность к выпуску не подтверждаем.
Понятно, что происходит, кто ходит следующим и чего ждём. В рабочей версии добавятся номер сборки, ссылка на проверку и имена.
Карточки интерфейса остаются закрытыми: показывать ожидание нужно там, где оно возникло.
Агрегаты при этом не зло. Просто принятые вклады, поставленные фичи и достигнутые цели - разные ряды. И эпик с его подзадачами нельзя складывать как независимые единицы результата.
🛠 Только не надо строить новую Jira
Легко увлечься новыми типами задач, статусами, обязательными полями. И недели две спорить, каким цветом обозначать готовность к готовности.
У меня правило проще: статус нужен, если помогает решить, что брать следующим, кому передать работу или что делать с растущей очередью. Новая карточка - когда появляется отдельное обязательство со своим результатом и получателем. Показать ту же работу на второй доске - не повод заводить копию.
В посте про потери «очень сложно настроенная Jira» стояла у меня в разделе лишней функциональности. Там она и остаётся.
Всё описанное - пока модель и предложение. Jira ещё не перенастраивали, командам предстоит её примерить, эффект не измерен. Статусы на каждое действие никто не будет поддерживать. Начать стоит с одной фичи и нескольких явных договорённостей.
🧪 Как проверить у себя
1. Выбери одну живую фичу. Ту, про которую на вопрос «готово?» отвечают по-разному. Лучше недавно начатую. Почти готовую переделывать не стоит, а в самой горящей проверку утопят в спасении релиза.
2. Собери цепочку на одном экране. Что получит пользователь → какие вклады нужны → где первая совместная проверка → какие условия выпуска. Для каждого «готово» запиши, кто принял и чем это подтверждается. Подтверждения нет - так и пиши.
3. Фиксируй изменения там, где живёт фича. Переносы, компромиссы и исключения - в эпик, а не в тред, который через неделю никто не найдёт. Перед тестированием владелец фичи сверяет реализацию с замыслом и называет исключения. Тестировщикам не приходится восстанавливать решения по памяти.
На встрече про DoD справедливо возразили: часть нюансов вылезает только руками. Снять все вопросы заранее не получится. Нужно, чтобы новые не терялись.
4. Пройди цепочку с теми, кто передаёт работу. Вместо «у тебя готово?» спроси: «Что следующий может сделать с твоим результатом прямо сейчас?» Если ответ начинается с «ещё данные не пришли», «надо получить доступ» или «ждём решения», ты нашёл зону передачи.
5. Проверь маленький кусок целиком раньше, чем готово всё. Один путь пользователя от начала до конца на общей сборке, с настоящими данными и настоящим сервером. Красивый экран на заглушке не проверит подключение рекламы. Он отвечает на другой вопрос.
Ловушка: работу нарезали мелко, а перед первым общим тестом снова собрали в большую партию. Обратная связь всё так же запаздывает. У DORA есть хороший материал про небольшие партии работы как раз об этом.
Ранняя проверка не требует выпускать по фиче каждый день. Старые версии приложения, миграции данных и релизные окна никуда не денутся. Их нужно вписать в условия проверки. Код можно вливать раньше, если у каждого хвоста понятны последствия, владелец и версия. Только не путай влитый код с релизом.
И не превращай приёмку в новый комитет. Для понятного вклада часто хватит обычного ревью или явного «ок» от получателя.
📈 Как понять, что стало лучше
- сколько времени проходит до первой совместной проверки;
- сколько работа ждёт на стыках между командами;
- сколько возникает поздних переделок и почему.
С возвратами осторожно. KPI «ноль возвратов» здесь только помешает. Раздели хотя бы ожидаемое уточнение после ранней проверки, предотвратимый дефект, изменение объёма по продуктовому решению и техническую проблему или внешнюю зависимость.
Ранняя проверка может увеличить число замечаний и при этом сократить дорогие поздние переделки.
Стоп-правило: если растёт только число переданных задач и влитого кода, а очереди на тестирование и повторные проверки увеличиваются без принятых сценариев - не расширяй практику. Упрощай.
И честно: одна фича покажет, что подход выполним. Делать по ней выводы об ускорении рано.
Открой последнюю фичу, которую команда считает готовой. Найди, что получил следующий участник. Потом - что получил пользователь.
Если между этими событиями лежит работа без имени и хозяина, это и есть твоя зона передачи. С неё и начни.
Продолжим в Telegram-канале «Будка трансформатора»: там обсуждаем статью и разбираем ваши случаи 🤝