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