11:07 — разработчик пишет: «Готово, можно смотреть».
11:10 — менеджер уверен, что задача уже ушла в тестирование.
13:00 — выясняется, что проверка на стороне тестирования не начиналась.

Никто не забыл про задачу и не нарушил процесс. Она просто зависла между «готово» и «взял». Такие паузы редко выглядят критичными, но именно из них складываются задержки релизов, сорванные сроки и ощущение, что все постоянно заняты, а работа движется медленнее, чем должна.

Я работаю QA-инженером в Ozon Tech и часто вижу, как задачи переходят между разработкой, тестированием, менеджерами и другими командами. Статус в тикете может быть обновлён, договорённость в чате зафиксирована, но ни то ни другое не гарантирует, что следующий шаг кто-то действительно принял.

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

Между «готово» и «взял»

Проблема передачи работы известна давно. В software engineering есть отдельный пласт исследований, посвящённых handoff — передаче работы и связанных с ней знаний между людьми или командами. Например, авторы исследования Software Development Waste относят ожидание, потерю знаний и неэффективную коммуникацию к основным видам потерь в разработке. А в работе «Follow the Sun» Workflow in Global Software Development эффективность handoff рассматривается как один из ключевых факторов, от которых зависит сокращение общего цикла разработки.

Дальше я буду говорить не о новой методологии, а о простом способе сделать видимым момент, когда ожидание должно превратиться в действие.

Что такое «мяч»

Наверняка вы слышали или сами говорили что-то такое:

«Я думал, вы уже начали»;
«А я же написал в треде»;
«Я не понял, что это уже на мне»;
«Ну задача же есть в Jira»;
«Я увидел сообщение, но не понял, что от меня ждут старт именно сейчас».

Во всех этих ситуациях между этапами не был явно зафиксирован следующий ход. Для краткости я буду называть явно принятый следующий шаг «мячом». Например, тестировщик может подтвердить, что возьмёт проверку через час, когда закончит текущую задачу. С этого момента «мяч» закрепляется за тестировщиком. Передающему больше не нужно напоминать, потому что передача состоялась в момент принятия, а не в момент старта задачи. Этот момент можно считать активным обязательством, то есть следующий шаг явно принят конкретным человеком.

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

Отсюда следует правило:

Если мяч не принят, значит он ещё не передан.

Где этот подход действительно нужен

Явно фиксировать следующий шаг полезно там, где цена паузы высокая:

• передача идёт между разными командами или ролями (разработка → тестирование → релиз);

• задача срочная (инциденты и т. д.), сложная или многоэтапная, и легко потерять, кто за что отвечает;

• есть жёсткий дедлайн или релизное окно;

• в процессе участвуют люди, которые редко пересекаются вживую;

• в сервисных ролях и местах, где много чатов и неформальной координации.

Почему таск-трекер не гарантирует движение

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

Ещё часть работы никогда не попадает в трекер: синхронные договорённости в чатах, мелкие доработки внутри задачи, внезапные «глянь» и «подхвати». Они есть, их нужно сделать, а статуса у них нет. Я могу взять задачу в работу, но забыть перевести статус — и для всех она всё ещё в очереди. Даже когда статус верен, он не отвечает на вопрос «когда ждать результат?». Статус In Testing не равен обязательству «вернусь с вердиктом до 15:00». И уж тем более статус не покажет, что ты не успеваешь к этому сроку и по какой причине, — для этого нужен не трекер, а живой ответ.

Например, релиз может задержаться не из-за сложного бага, а потому, что между разработкой и тестированием несколько часов никто не подтверждал начало проверки. Формально задача существует, все участники в курсе, но следующий шаг остаётся подвешенным. Такие микропаузы со временем складываются в заметные потери delivery.

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

Почему одной «ответственности» недостаточно

В командах слово «ответственный» слишком широкое. Оно может означать владельца сервиса, автора задачи, дежурного, тестировщика, менеджера, архитектора, того, кто просто помогает координировать работу. Поэтому ответственность за объект и ответственность за следующий шаг — это не одно и то же. Можно отвечать за сервис и не быть тем, у кого сейчас мяч. И наоборот: можно не владеть направлением целиком, но быть человеком, от которого зависит ближайшее движение задачи.

У каждого следующего шага должен быть один владелец. Он может подключать коллег, делегировать часть работы или передать мяч дальше. Главное, чтобы новая передача тоже была явно принята. Когда владельца нет, мяч оказывается в подвешенном состоянии, а если владельцев несколько, возникает коллективная неопределённость.

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

Где теряется следующий шаг

Неясно, кто вообще должен сделать следующий шаг

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

• разработка считает, что это подхватит тестирование;

• тестирование думает, что сначала нужен отдельный запрос от менеджера;

• менеджер уверен, что раз все увидели обсуждение, кто-то уже начал;

• в Jira задача есть, но отдельный следующий шаг никому явно не назначен.

Следующий владелец шага не определён. В такой ситуации помогает прямой вопрос:
Кто берёт следующий шаг? 

Тот, у кого сейчас находится задача, не считает передачу завершённой, пока следующий участник явно её не принял.

Что делать: не оставлять следующий шаг без конкретного владельца. Назвать конкретного человека или попросить принимающую сторону назвать владельца.

Следующий участник понятен, но шаг не принят явно

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

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

Более рабочая версия выглядит так:

> Изменения по задаче готовы. Нужна проверка на тестовом стенде N. Кто берёт? Результат нужен сегодня до 13:00 максимум.

Ответ:

> Беру. Начну до 11:00, вернусь с результатом до 12:30.

Здесь ключевое отличие в том, что у передачи появился явный момент принятия.

Что делать: дождаться явного «беру» с ориентиром по сроку.

Шаг вроде передан, но неясно, что считать результатом

Ещё один частый тип потери, это когда следующий участник даже может согласиться взять работу, но сам шаг описан слишком расплывчато. Например, в чат пишут:

> Можешь посмотреть тесты? Кажется, там что-то странное.

Ответ:

> Да, посмотрю.

Формально всё звучит нормально. Но на деле непонятно:

• что именно нужно сделать;

• где граница работы;

• какой результат ожидается;

• когда будет понятно, что шаг завершён.

«Посмотреть» можно пять минут, а можно полдня. «Что-то странное» не описывает нужный результат. Например, для одного участника «посмотреть тесты» может означать перезапустить упавший билд, а для другого провести глубокий анализ причин flaky-тестов. Разница в ожиданиях превращает ту же фразу в два разных следующих шага.

Более рабочий вариант:

> Можешь сегодня посмотреть падение этих тестов, найти причину и вернуться с выводом до 16:00?

Тогда следующий шаг становится измеримым: есть действие, есть ожидаемый результат, есть сроки.

Что делать: в запросе, кроме сроков, зафиксировать действие и ожидаемый результат.

Шаг понятен, но он невыполним в текущих условиях

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

> Возьми, пожалуйста, проверку на стенде N и дай ответ по выпуску до 14:00.

Ответ может быть таким:

> Не могу взять: нашему отделу запрещён доступ к этому стенду.

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

В этом случае в цепочке появляется новый промежуточный этап «разблокировать работу». У этого этапа должен быть новый владелец: лид, менеджер, ИБ (тот, кто может решить проблему). Передающий или принимающий после принятия шага в зависимости от ситуации и договорённостей должен определить этого человека и передать мяч ему с явным подтверждением. Если мяч у того, кто должен разблокировать, движение продолжается, просто по другому маршруту с новым промежуточным этапом. Если мяч ни у кого, то задача стоит.

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

Что делать: отказ должен сразу породить новый шаг, нужно снять блокер или найти другого исполнителя.

Ожидание осталось, а владельца уже нет

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

Формально проблема где-то «в процессе», но реально мяч лежит на земле. Такая работа просто зависает в воздухе без конфликта и явного отказа.

Что делать: при появлении новых данных заново назвать владельца следующего шага и получить подтверждение.

Фактически решили ничего не делать, но явно это не проговорили

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

В результате одна часть команды считает вопрос закрытым, а другая продолжает ждать движения.

Решение ничего не делать тоже должно быть зафиксировано. Иначе ожидание остаётся жить без следующего шага.

Что делать: явно закрыть ожидание: «решили не делать до X или не делать вообще по причине Y».

Приоритеты изменились после принятия шага

Владелец мяча есть, срок назван, но появляется инцидент или более приоритетная задача. Человек переключается и понимает, что выполнить первоначальное обязательство уже не успевает.

Например, договорились вернуться с результатом до 16:00, но в течение дня прилетел инцидент. Как только становится понятно, что срок сдвигается, лучше вернуться к договорённости заранее: «Я вынужден переключиться на инцидент, освобожусь примерно через два часа. Если эта задача критична, давайте передадим её другому».

Смена приоритета сама по себе не отменяет принятого шага. Нужно обозначить новый срок, передать мяч другому участнику или явно договориться, что задача подождёт.

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

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

Так как передать мяч и убедиться, что его приняли?

Большинство подобных зависаний сложно заметить, потому что внешне процесс выглядит живым: задача есть, обсуждение идёт, статусы меняются. Но иногда работе не хватает всего одной вещи — человека, который действительно принял следующий шаг.

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

В чатах и трекерах иногда помогают простые маркеры в заголовках вроде [ИНФО], [ВОПРОС], [ЗАДАЧА] и [РЕШЕНИЕ] и т. п. Они не требуют отдельного процесса, зато сразу показывают, ждут ли от сообщения действия. Особенно хорошо разница заметна на формулировках. «Глянь, пожалуйста», «ну это надо проверить», «я отметил в Jira» или «дальше QA подхватят» оставляют слишком много пространства для разного понимания.

Гораздо понятнее звучит:

>[ЗАДАЧА] Возьми, пожалуйста, проверку логов и вернись с причиной до 16:00.

И ответ:

>Беру. Вернусь с выводом до конца дня.

Если взять задачу сейчас невозможно, это тоже лучше обозначить сразу:

>Не могу взять из-за отсутствия доступа. Смогу после 11:00 или предлагаю передать Владу.

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

> [ВОПРОС], [Имя], нужен [конкретный шаг]. Результат — [что должно получиться]. Нужен до [срок]. Сможешь взять?

Ответ:

>Беру. Начну [когда], вернусь с результатом [когда].

Или:

>Не могу взять из-за [причина]. Могу после [время] / предлагаю передать [кому].

Передача состоялась в тот момент, когда обе стороны одинаково понимают, кто делает следующий шаг, какого результата ждут и когда к нему вернутся. А если вы начнёте чаще задавать вопрос «у кого сейчас мяч?», значит, статья была написана не зря. Теперь мяч на вашей стороне.