Выжигающие задачи

Почему люди увольняются? Я увольнялся по нескольким факторам: предложение на более вкусное место работы, несработка с командой, отвратительное руководство.
В том случае, когда человек увольняется из-за проблем на работе, а не из-за предложения новой, что-то как правило служит точкой невозврата - достал лист, написал заявление, отнёс начальнику. И, как мне кажется, такой точкой нередко выступают определённого рода задачи.
Как правило, такая задача летит мимо спринта. Аналитики нет, оценки - тоже. Формулировка крайне скудная - реализовать *описание фичи в нескольких словах*.

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

В очередной раз столкнулся на работе с прекрасной постановкой - реализовать возможность *функционал фичи*. Аналитики нет, в спринт задачу вкинули уже после его запуска. Совокупность факторов - и я не разбираясь перевёл статус задачи в "In progress". И через пару дней пообещал себе, что без предварительной оценки, какие бы факторы вокруг не происходили, задачи больше браться в работу не будут.

Основные критерии:
1. Описание задачи затрагивает несколько логических разделов в коде. Например, моя задача, если бы я получше вчитался в описание, затрагивала ядро генерации PDF-файлов и подразумевала большой объем кода в совершенно другом месте для реализации бизнес-логики.
Как это можно было решить? Вчитаться на планировании, поставить задачу на аналитику, выявить проблему и разбить задачу на 2 подзадачи, поочерёдно втягивая их в спринт.

2. Нет чёткой оценки времени. "Да делай, ещё есть время" - самый паршивый для разработчика ответ. В голове сразу мысли: "Сколько? Когда могут спросить? До конца спринта? Или уведём в следующий?". Ответы такого формата делают только одно - заставляют торопиться, из-за чего возникают ошибки, в PR пушатся всё новые комментарии и цикл "правки - PR - комментарии" раскручивается.

3. Нет приёмочный критериев (для тех, кто в танке - приёмочные критерии - одноимённый раздел, который можно активировать у карточки задачи в jira). Это, наверное, самая важная часть, резюмирующая большинство из вышесказанного. Если тебе набросали макет, дали краткую формулировку, но в разделе с приёмочными критериями пусто - уже стоит задуматься, а брать ли задачу или стоит сначала обсудить. Когда менеджмент/команда/лид описывает то, что он хочет видеть на выходе - это уже половина решения. На одном из предыдущих мест работы в процессе формулировки приёмочных мы с командой могли обсуждать задачу несколько встреч подряд, находя всё новые и новые моменты, разбивая задачу на новые подзадачи и описывания новые блокирующие связи. Потеря времени? Как бы ни так. После такого планирования весь пулл подзадач выполняется за пару дней, что бизнесу идёт только на пользу.

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

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