Задачу нормально поставьте. Многие разработчики и тестировщи | Shoo and Endless Agony

Задачу нормально поставьте.

Многие разработчики и тестировщики очень не любят работать с плохо проработанными задачами.
Неустанно повторяя древнюю мантру про "нет ТЗ - ..." они выступают на конференциях с рассказами о том,
как классно у них получилось перевоспитать аналитиков и менеджеров, что б им приносили хорошо проработанные задачи.
Или наоборот делятся болью в профессиональных чатиках мол "бардак, прилетают задачи без описания".

Меня эти дискуссии неизменно печалят.
В основном потому, что многие люди действительно считают, что вот так - это хорошо, а по другому - это плохо.
Реальность, конечно, немножко сложнее.

Тут есть несколько моментов, о которых надо помнить.

Первый:
Каждый раз, когда вы хотите, что бы вам принесли идеально проработанную задачу - вы просто перекладываете ответственность.
Вы хотите упростить себе жизнь, не ломая голову над тем, что от вас хотят, избежать всех этих уточняющих вопросов и, заодно, минимизировать риски.
Что бы если к вам придут и спросят "почему это работает вот так?" можно было просто сказать "я сделал как в ТЗ было написано".
В желании упростить себе жизнь нет ничего плохого, но надо понимать, что в данном случае вы делаете это в ущерб команде и продукту.
Потому что ответственность, риски и проблемы вы снимаете с себя, но перекидываете на кого-то другого.

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

Третий:
Способность (и готовность) работать в условиях неявных требований - это конкурентное преимущество.
Даже при хорошо отлаженных процессах требования всегда будут неполными.
Задачи без описания и definition of done "Работает хорошо" будут периодически появляться.
Вопрос только в том, какую цепочку проработки они будут проходить прежде, чем окажутся в продакшене.
Переоткрывая задачу в формате "требования опишите нормально" вы просто докидываете ещё одно звено в эту цепочку и увеличиваете time to market.
Инженеры, способные получить слабо формализованную задачу, взять за неё ответственность и выдать результат ожидаемого уровня качества - на вес золота.
Они стоят гораздо дороже и ценятся компаниями гораздо выше, чем инженеры, просто транслирующие ТЗ в код.

Помните, что разные подходы работают для разных команд.

Я много работал с ребятами, которым можно было поставить задачу в формате "сделай вот такую вот фигню" и быть уверенным, что человек её сделает хорошо.
За счёт технической экспертизы, за счёт погружения в продукт, за счёт взаимопонимания и cultural fit, за счёт наличия софт-скиллов и способности вовремя задать вопросы, если возникают проблемы.
Но, этот подход плохо масштабируется.
Собирать такие команды долго и дорого.

Классический подход "вот вам супер-подробное ТЗ, превратите это в код" - обратная крайность.
Это стандартные проектные рельсы, которые легко масштабировать и можно получать прогнозируемый результат.
Минус в том, что результат - средненький, скорость - тоже.
Создать что-то действительно классное с таким подходом довольно сложно.

И, конечно же, есть целый спектр промежуточных состояний.
Все они по разному подходят для разных команд, разных продуктов и разных этапов жизни компании.
В этом, собственно, и основной поинт, который хотелось бы донести:

Детально проработанные задачи могут нести за собой не меньший набор проблем и ограничений, чем задачи, прилетающие без описания вообще.

Поэтому, каждый раз, когда слышите истории успеха и сладкие речи про идеально проработанные ТЗ и вот это всё - задавайтесь вопросом, а действительно ли это плюс?