Привет 🫂

В комментариях к посту о Time in Status возникло обсуждение вопроса перемещения задач по доске. Так как речь касается инструментов визуализации, а я давно и плотно работаю с Jira, в которой настройки переходов из статуса в статус называются “workflow”, я буду называть возможности перехода из статуса в статус “рабочим процессом” в рамках этого поста.

В комментариях было затронуто 2 вопроса: 1.  Нормально ли это вообще - возвраты в процессе; 2. Как из аудитов понять есть ли проблемы, связанные с возвратами в рабочем процессе.

В этом посте я разберу лишь один этап процесса - тестирование, и лишь один случай возврата по процессу - в разработку, для задач/пользовательских историй. Все остальные случаи готова детально разобрать на встрече, если будет от вас интерес.

Скажу сразу: ❌ я категорически против возвратов для любой сущности на любом этапе, кроме дефекта. При этом для дефекта допустим только один возврат: из тестирования в “ожидает исправления/разработку”.

1️⃣ Потеря данных или двойная работа. Если во время тестирования обнаруживается дефект, то на дефект должна заводиться “задача на исправление”, в Jira это - bug. Это, скажем так, гигиена процесса тестирования.

Теперь, если соблюдается гигиена, представим, что еще и сама задача/история переводится в статус “ожидает разработку” или “разработка” (что я тоже, к слову, встречала). Разработчик, получается, должен взять в работу в параллели 2 задачи: саму задачу/историю (снова) и багу. И дальше, вместо того, чтобы отслеживать и “проталкивать” по процессу не одну, а две сущности: сначала в “разработку”, а потом в “ожидает тестирование”. Тестировщик, далее, после исправления дефекта, должен, так же, “протолкнуть” 2 сущности вместо одной в “тестирование”.

Если гигиена по заведению дефектов не соблюдается, то вы теряете понимание качества продукта и качества тестирования. Тут я (пока) много писать не буду.

2️⃣ Надежда на память Как руководителю проекта, мне интересно видеть общую картину по прогрессу. При возврате задач по процессу мне необходимо помнить, что часть задач в колонке “в разработке” находится реально в разработке и даже не доходили до тестирования, то есть им “предстоит еще долгий путь”, а другая часть, которая так же, как и первая, находясь в колонке “разработка”, на самом деле уже находятся в тестировании и близки к закрытию, но им мешает дефект. При этом, для того, чтобы понять что на каком этапе на самом деле, мне либо необходимо спрашивать у команды, либо открывать задачу, искать метки/связи, смотреть статусы у связанных задач. Не проще ли держать задачи в их реальном статусе?

3️⃣ Отсутствие прозрачности Если вам кажется, что заинтересованы в статусах ваших задач только руководители проектов и команда (хотя тут чаще команда как раз не заинтересована вообще), то вам кажется. Даже если у руководителей нет статусов по прогрессу проекта с их руководством, владельцем продукта, заказчиком и тп, то это не значит, что они не смотрят время от времени на то, что происходит на командной доске. Я достаточно работаю и с РП, и с их руководством, чтобы четко понимать, что начальство на 1 уровень выше РП тоже смотрит на ваши доски… Да-да 😊 возможно, сейчас я удивила вас, но это так. И им, людям не сильно погруженным в проект, так же важно быстро, с одного взгляда понять что происходит, насколько команда близка к завершению. И как понять им? Так же ходить по ссылкам?.. Не лучший вариант, кажется.

4️⃣ Искажение реальности При возвратах по рабочему процессу одна из основных метрик, отображающая узкие места в процессе, перестает работать. Речь о CFD, которой, к моему великому сожалению, пользуются единицы. Суть в том, что возрастает время в разработке, и не увеличивается время в тестировании. Отсюда можно прийти к выводу, что для уменьшения времени на поставку нужно нанять разработчиков, или проводить более детальную декомпозицию. Хотя вместо этого было бы логичнее ввести дополнительные этапы ревью, тестирование самим разработчиком и тп.

24.09.2025

#возврат_рабочего_процесса