Меня жутко веселит этот мем, но в то же время он достаточно печальный.

Будучи разработчиком, я часто сталкивался с тем, что поставленные мне задачи были оформлены "абы как". Но что это значит? Давайте разбираться.

Важное уточнение. Есть много умных книжек по этой теме. Они появляются каждый месяц (если не каждый день), и все их прочесть невозможно. Но в то же время есть мой собственный опыт, наработанный годами выполнения и постановки задач - технических и не только. Именно на опыт я опирался при написании этого поста. Верю, что мой опыт будет полезен и вам. Критерии плохой задачи. 🔹 Недостаток контекста Это один из важнейших критериев плохой задачи. Если исполнитель не понимает, зачем он что-то делает, а в случае, когда нужно что-то переделать, не понимает, как оно работает "сейчас", - он не может посмотреть на задачу критически.

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

50/50, что задача будет выполнена не в полном объёме. 🔹 Отсутствие декомпозиции Насколько удобно выполнять задачу, срок которой - 1 год? Или почти 1900 рабочих часов? Сложно представить такую задачу, но именно в преувеличении видны проблемы.

У задачи на 1900 часов: - Невозможно описать однозначные критерии готовности - Невозможно дать полезные рекомендации по выполнению - Невозможно в полной мере описать требования - Оценка такой задачи, мягко говоря, будет хромать. Итог: чем больше задача, тем сложнее её ставить и исполнять.

В идеале одна задача - 1 день. Не больше. 🔹 Отсутствие критериев готовности Также один из важнейших параметров задачи. Он отвечает на вопрос: "Как однозначно понять, что задача сделана?" А также добавляет дисциплины и позволяет исполнителю провести самопроверку.

Если в задаче указан блок "Критерии готовности" и в одном из пунктов написано: «Написаны автотесты, покрывающие: ...» или «Результат анализа содержит: ...», - исполнитель не сможет это пропустить (забыть), а постановщик получит бОльшую гарантию полной реализации задачи. 🔹 Неоднозначность Критерий, хорошо описанный в меме этого поста. Любая фраза, написанная в задаче, должна быть однозначной. Двусмысленность фраз категорически не допускается. Исполнитель задачи, читая её, не должен бежать к постановщику с вопросом: "А что значит фраза „...“?"

Если к вам пришли с таким вопросом - подумайте над тем, как вы формулируете предложения в своих задачах. Парочка менее важных критериев - коротко. 🔹 Отсутствие ссылок/глоссария. Если в задачах используются уникальные термины или они имеют отношение к ТЗ, статьям или сообщениям, хорошим правилом считается оставлять ссылки и давать определения терминов. Это часть контекста, но часто забывается.

🔹 Отсутствие реалистичных сроков. Слово «реалистичных» очень важно в этой формулировке. Частые ошибки исполнителей в оценке сроков - маркер, говорящий о том, что задачи ставятся неясно или неверно.

Подведём итог. Если нам нужно контролируемое выполнение задачи - все вышеперечисленные критерии должны там присутствовать. Это упрощение жизни исполнителю и себе. Не говоря уже об истории выполнения задач, когда переходя на полностью оформленную задачу - не нужно догадываться что было сделано и для чего.

Получилось достаточно мало о каждом критерии по отдельности... Но иначе пост был бы сильно больше. Если действительно интересно - распишу каждый критерий отдельными постами с примерами.

Ну и если у вас есть ещё критерии задач, которых вам часто не хватает - пишите в комментариях, обязательно обсудим. Хорошей недели и только качественных задач :)