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

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

🤓 Если в задаче нет ответа на вопрос “зачем мы это делаем?” - будет сложно принимать решения по спорным моментам.

🤓 Если нет критериев приемки - у всех будет разное понимание слова “готово”.

🤓 Если не описаны корнер-кейсы - они все равно всплывут, только уже на тестировании или после релиза.

🤓 Если непонятно, кто принимает результат - задача может зависнуть в статусе “почти готово”.

🤓 Если есть фраза “сделать как обычно” - это почти всегда риск. “Обычно” у разных людей разное.

Мой быстрый чек перед передачей в разработку: - понятна цель задачи? - описан основной сценарий? - есть состояния ошибок и пустые состояния? - есть критерии приемки? - понятны зависимости? - понятно, кто согласует результат?

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

😕 Лайфхак простой: если задачу нельзя объяснить команде за пару минут без длинного созвона и дополнительных “сейчас найду”, она, скорее всего, еще не готова.

Хорошая постановка это не про много текста. Это про то, чтобы команда могла начать работу без угадывания.