Опыта работы с задачами недостаточно, чтобы уметь их описывать

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

Одно дело знать, чего тебе не хватает, а другое самому описать так, чтобы всего хватало исполнителю. Я столкнулась с этой проблемой больше всего, когда занялась разработкой собственных проектов и перелезла в шкуру бизнес-заказчика. На первом же серьезном заказе дизайна для проекта я облажалась в написании ТЗ везде, где только можно. Спорю, что многим иногда приходят задачи от коллег-технарей из соседнего отдела, в которых вообще ничего не понятно. Так почему же даже опытные исполнители не всегда хорошо описывают задачи?

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

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

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

Александра Шаламова