Исполнитель должен понимать контекст задачи #

Не что нужно сделать, а зачем. Иногда возникает ситуация, когда даже лид не знает, что надо - ну и получается, “пойди туда - не знамо куда, принеси то - не знамо что”. А вот зачем обычно кто-то обязательно знает. Если нет - то стоит подумать, нужна ли эта задача вообще? Когда исполнитель понимает зачем, он обычно выдает результаты лучше, чем когда не знает, и может предложить неожиданное решение (в хорошем смысле).

Надо хорошо понимать исполнителя #

Если вы в одном контексте, и исполнитель хорошо знает тему, то и описание ему можно дать достаточно короткое. “Петрович, дай ту фиговину, чтобы я ее прихреначил на эту приблуду”. Петрович в контексте, он и так знает, что надо без 1000 слов. А если вместо Петровича придет стереотипная Софочка, то ей придется долго рассказывать про фиговины, хреначение и приблуды. А если подавать фиговины больше некому - что ж, лучше потратить время на то, чтобы Софочку ввести в контекст, писать первое время подробно все и разжевывать, а потом постепенно уменьшать уровень подробностей. В идеале Софочка превратиться в Петровну и без проблем сможет подавать даже хреновины для прифигачивания, а не только фиговины для прихреначивания. Чем опытнее исполнитель, тем больше свободы ему стоит давать (и меньше лишних подробностей).

Еще один аспект про понимание исполнителя #

Сейчас уже некоторые люди книжку не могут прочитать, а чтиво на 5 минут - уже лонгрид. Можно сделать суперподробное описание, но какой-нибудь зумер с клиповым мышлением скажет TLDR и прочитает только заголовок. Тут либо человека образумить (хороший вариант), либо находить к нему подход - кинуть голосовое в чатик, пантомиму с рисованием у доски сделать и т.п. А если серьезно, то есть вариант обсуждения - дайте краткое описание задачи, спросите человека, как будет делать, обсудите, и пусть сам потом запишет это в описание тикета (разумеется, потом надо проверить). Ему уже и по башке можно будет с чистой совестью дать, если сам себе задачу описал и сам же неправильно сделал.

Адекватно декомпозируйте задачи #

Зависит от многих вещей, но в среднем по больнице задача дольше дня уже должна быть декомпозирована. Не обязательно отдельным тикетом, в формате TODO-шек в тикете и/или чеклистов тоже сойдет, зависит от вашего workflow. И декомпозировать может не только руководитель, но и исполнитель. Ежедневные agile-митинги примерно про это - что сделал, какие проблемы и т.п. (но они не панацея, и не всегда нужны). Это нужно, чтобы держать руку на пульсе и перенаправить исполнителя в нужное русло. Иначе получится, что человек неделю варился в собственном соку и на выходе совсем не то. Если будет привита практика регулярного отписывания по тикетам - то там и варианты решения можно обсудить на ранних стадиях.

Исполнитель должен знать неявные условия задачи #

Окружение, проект и его цели, стек технологий, сложившиеся практики, стиль кода и т.п.. Чтобы это все было как данность и незамусоривало сам тикет. Отпадут проблемы когда весь стек на java, а чувак написал сервис на rust просто потому что (“ну а че, в тикете написано же не было”). Как вы определяете, что “сделано не то”?

Определите, по каким критериям будет приниматься задача. Знает ли их исполнитель? А он как раз должен. Определите, что критично - напишите в тикет это. Подумайте о definition of ready (DOR) и definition of done (DOD) (а если не знаете, что это такое - стоит почитать, например, тут).

И помните, что garbage in => garbage out.