Неполное описание задачи в таск‑трекере? – Не надо так 😶
– рассказывает Екатерина, руководитель QA-направления

Часто на проектах задача сначала обсуждается между руководителем разработки и системным аналитиком верхнеуровнево: что именно делать и в каком виде. Автор при переносе такой задачи в таск-трекер может решить, что подробно заполнять поля уже не нужно. Ведь фича уже описана в базе знаний 🙄

Что делать, если такое иногда происходит в команде
1. Напомните команде, чем это может грозить
▪️ Разработчикам и QA-специалистам потребуется больше времени, когда они будут брать фичу в работу. Сначала специалист пойдёт изучать требования в базе знаний, потом уточнять их у коллег, процесс затянется, при доработках снова придётся вспоминать, о чём вообще это всё было.
▪️ Больше вероятности, что задача, вернётся на доработку. Если у задачи отсутствует подробное описание с требованиями, то разработчик может не понять, чего именно от него ждут. Поэтому задача, скорее всего, вернётся на доработку, а того, кто её ставил, попросят уточнить техническое задание.

2. Обсудите единый вариант оформления
При создании задач основные пункты описания:
▪️ Понятное название задачи
▪️ Требования к функциональности и производительности продукта или системы, которые необходимо реализовать
▪️ Ссылки на дизайн-макеты, описание архитектуры, включая структуру, компоненты и взаимодействие между ними
▪️ Требования к тестированию и контролю качества, включая критерии приёмки
Точный перечень будет зависеть от специфики проекта – обсудите его внутри своей команды и придите к единому удобному шаблону оформления.