11:07 — разработчик пишет, что работа готова. 13:00 — команда выясняет, что тестирование даже не началось. Такая передача задачи выглядит мелкой бытовой накладкой, но именно из этих пауз собираются задержки релизов, нервные дейли и ощущение, что все заняты, а продукт едет на ручнике.
О типичном разрыве между «готово» и «взял» рассказал QA-инженер Ozon Tech, сообщает Habr / Карьера. В центре текста не новая методология и не очередная попытка переименовать ответственность красивым словом, а очень практичная проблема: статус в трекере обновили, сообщение в чат отправили, но следующий человек так и не подтвердил, что действие теперь на нём.
Автор предлагает смотреть на работу как на «мяч»: у каждого следующего шага должен быть один текущий владелец. Не команда в целом, не «QA посмотрит», не «менеджеры разберутся», а конкретный человек, который явно принял следующий ход и назвал хотя бы ориентир по времени. Пока такого принятия нет, передача не состоялась. Это важное различие: написать «можно смотреть» — ещё не то же самое, что передать задачу в работу.
В статье приводится знакомый почти любой продуктовой команде сценарий. Разработка считает, что после сообщения в чате тестирование уже в курсе. Менеджер уверен, что задача ушла дальше по процессу. Тестировщик видел уведомление, но не понял, что от него ждут старта прямо сейчас. Jira, YouTrack или другой трекер при этом может быть формально в порядке: задача существует, статус стоит, участники не пропали. Но ближайшее действие никем не принято, и процесс зависает в промежутке.
Проблема особенно заметна там, где работа проходит через несколько ролей: разработка, тестирование, релиз-инженеры, менеджеры, поддержка, соседние команды. Чем больше чатов и асинхронных договорённостей, тем выше шанс, что передача задачи превратится в информационный шум. Фраза «я написал в треде» не гарантирует, что адресат понял ожидание, приоритет, дедлайн и критерий готовности. Для бизнеса это не философия Agile, а вполне денежная история: релизное окно можно потерять не из-за сложного бага, а из-за пары часов молчаливого ожидания.
Отдельный важный тезис — трекер сам по себе не двигает работу. Статус «In Testing» говорит, где задача находится в процессе, но не отвечает на вопросы «кто сейчас делает следующий шаг?» и «когда ждать результат?». Ещё хуже с мелкими просьбами: «глянь тесты», «проверь сценарий», «подхвати перед релизом». Они часто живут только в чатах и никогда не становятся полноценными тикетами. В итоге команда вроде бы следует процессу, но теряет управление ближайшим действием.
Редакционно полезная часть материала — не термин «мяч», а набор простых формулировок. Вместо расплывчатого «готово, можно смотреть» лучше писать: что именно готово, где проверять, какой результат нужен и к какому времени. А принимающая сторона должна отвечать не просто «ок», а «беру, начну до такого-то времени, вернусь с результатом тогда-то». Это звучит почти занудно, зато снимает главный риск: люди перестают угадывать, на ком сейчас следующий шаг.
Для разработчиков это означает меньше внезапных пингов в конце дня. Для QA — меньше ситуаций, когда задача «сама приехала» без контекста и срока. Для менеджеров — более честную картину delivery: задержка видна не тогда, когда дедлайн уже горит, а в момент, когда следующий шаг не принят. Для HR и тимлидов здесь тоже есть сигнал: зрелость команды часто проявляется не в количестве церемоний, а в том, насколько аккуратно люди передают друг другу незавершённую работу.
Передача задачи в IT всё чаще становится не техническим, а коммуникационным узким местом. Чем больше распределённых команд, гибридного графика и параллельных инициатив, тем меньше помогает надежда на «все и так поняли». Следующий уровень процессной гигиены, похоже, будет не в новых статусах трекера, а в привычке фиксировать простую вещь: кто держит следующий ход и когда он вернётся с ответом.