А сами исполнители умеют описывать задачи?

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

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

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

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

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

Александра Шаламова
#agile_который_работает #agile #управлениекомандой #разработка #ит #бизнеспроцессы