Определение набора возможностей
Есть вещи, которые мы делаем ради самого процесса - например, бегаем трусцой по утрам или разучиваем гаммы на фортепиано. Есть дела, которые мы выполняем, чтобы получить результат, - например, печем пирог с сыром или чиним автомобиль. Определение набора возможностей системы относится к обеим категориям сразу: это ценный процесс, который дает ценный результат.
Процесс ценен тем, что заставляет вас выявлять потенциальные противоречия и «шероховатости» конечного продукта на том этапе, когда сам результат существует лишь в вашей голове. Мы можем определить, за что следует взяться прямо сейчас, а что придется отложить на потом.
Результат представляет ценность, так как дает вашей команде точку отсчета для всей последующей работы над проектом и общий язык, на котором вы сможете обсуждать эту работу. Определение требований убирает из процесса разработки неоднозначность.
Однажды я работал над веб-приложением, которое, казалось, навеки застряло в состоянии бета-версии: почти (но не совсем) готово к передаче пользователям. Многое в нашей работе было неправильным: технология была ненадежной, мы ничего не знали о наших пользователях, а я был единственным человеком в компании, имевшим хоть какой-то опыт разработки для Всемирной паутины.
Однако ни один из этих фактов не объяснял, почему мы не можем закончить работу над продуктом. Главным камнем преткновения было наше нежелание документировать требования. В конце концов, какой смысл занудно протоколировать все и вся, если мы и так работаем в одной комнате? Да и нашему менеджеру необходимо было направить всю свою энергию на отслеживание новых технологических веяний...
Результатом был продукт, представлявший собой постоянно меняющуюся мешанину функциональных возможностей разной степени завершенности. Любая прочитанная кем-то из нас статья, любая мысль, пришедшая кому-нибудь в голову во время возни с продуктом, вдохновляла нас на обсуждение новой функциональности. Работа кипела, но без графика, без каких-либо контрольных точек - и этому не было ни конца ни края. Если никто не знал четкого набора возможностей продукта, как можно было понять, что проект закончен?
Существуют две основных причины для документирования требований к продукту.
