На одном из тренингов участник задал нам вопрос:

— Если в процессе обсуждения выясняется, что заказчики сами не до конца понимают, чего именно они хотят? Означает ли это, что требования вообще не нужны? Или они не должны быть полными, исчерпывающими и ясными — как нас обычно учат?

Стоит ненадолго остановиться и подумать, а как вообще составлять требования, если сами заказчики не понимают, чего хотят? Давайте порассуждаем, как это устроено в гибких организациях.

Требования не должны быть высечены в камне

Во-первых, они не должны быть слишком объёмными. Подход, в котором всё до мелочей расписано и собрано в один большой документ, чтобы потом ему строго следовать — не самый удачный.

Во-вторых, в результате такого подхода появляется огромный, неподъёмный документ, с которым потом приходится разбираться разработчикам и тестировщикам. Они остаются один на один с этими требованиями, без возможности уточнить что-либо у заказчика и получить фидбэк по ходу работы. Их задача — на основе этих правил создать работающий продукт.

Такая модель разработки усложняет весь процесс

Большие требования долго реализуются, тестируются и также долго исправляются. Можно потратить много времени и ресурсов, но получить совсем не то, что действительно нужно пользователю.

Конечно, и в Agile можно ошибиться и сделать что-то не то. Но ошибка в этом случае будет менее критичной, потому что на неё тратится гораздо меньше времени. И остаются ресурсы, чтобы быстро её исправить — и время, и бюджет.

Поэтому, отвечая на этот вопрос, можно сказать следующее:

Да, большинство из нас привыкли, что требования должны быть полными, ясными и исчерпывающими — и это действительно важный фундамент, с точки зрения понимания, как работают каскадные процессы разработки. Но когда мы переходим к продуктовой разработке, где важно быстро выводить решения на рынок, конкурировать и привлекать новых пользователей — этот фундаментальный подход перестаёт быть эффективным.

В таких условиях нужен другой, более гибкий подход к формулировке требований и работе с ними.