Чем чаще нужно уточнять задачу, тем хуже она поставлена

Для меня, как лида в продуктовой бэкенд-команде, это видно особенно ярко, потому что бэкенд редко работает с одной сущностью — он работает с их пересечением: данные, бизнес-правила, интеграции, edge-кейсы, которые никто не проговорил вслух.

Если разработчик за день пишет тимлиду или продакту три разных вопроса по одной задаче — это не значит, что разработчик невнимательный. Это значит, что задача сформулирована на уровне идеи, а не на уровне решения.

Типичные вопросы, которые вскрывают плохую постановку: 🟠«А что делать, если пользователь уже существует?» 🟠«А это должно работать синхронно или через очередь?» 🟠«А кто у нас источник правды — это поле берём из CRM или из биллинга?»

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

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

Что делать тимлиду, если он видит, что по задачам команды идёт поток уточнений: 🟢вводить короткий чек-лист готовности задачи: есть источники данных, есть поведение при ошибках, есть договорённость про синхронность/асинхронность 🟢требовать явно прописывать edge-кейсы в тикете, а не оставлять «разберёмся по ходу» — по ходу разбираются все по-разному 🟢проводить груминг перед стартом спринта, где вопросы задаются один раз всей командой, а не по одному в личке весь спринт

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

Сколько уточнений в среднем требует одна задача в вашем беклоге — и на каком этапе они обычно всплывают?