Требования
К сожалению, требования к системам часто появляются не в результате обсуждений между разработчиком и бизнесом, а как нечто переданное разработке без ожидания обратной связи.
Как это часто бывает: бизнес смотрит на ПО, думает, как его можно так доработать, чтобы решить свою проблему и выдает эти фантазии за требования. В итоге бизнес не приходит в разработку с проблемой, он уже приходит со своим решением, которое по его мнению должно решить проблему.
Задача же бизнес аналитика или разработчика - игнорировать первоначальные требования бизнеса и попытаться понять - какая у него на самом деле проблема, почему он хочет то что хочет. Для этого у бизнес аналитика должен быть авторитет, чтобы спорить с бизнесом. И даже после этого еще не будет требований. После этого с проблемой должен поработать архитектор.
Quote
На протяжении почти всего первого десятилетия моей карьеры в IT, которое я провел за созданием ПО для розничной торговли, я вообще обходился без слова «требования» – ну или очень редко его слышал. Этот термин попросту не годился для обозначения того, что я делал. […]
По мере того как компания росла, на работу поступало все больше людей, привыкших к традиционному процессу разработки. Однажды ко мне пришла начальница другой команды и сказала:
- Джефф, нужно, чтобы вы внесли вот эти изменения в продукт, над которым сейчас работаете.
- Нет проблем, ответил я, только расскажите мне, для кого мы делаем эти изменения и какие задачи люди будут решать с их помощью.
Что я услышал в ответ?
- Это нужно для соответствия требованиям.
- Я вас понял, кивнул я. Мне только нужно знать подробнее, для кого мы внедряем эти штуки, как эти люди будут их использовать, а также какой этап их рабочего процесса изменится.
Она посмотрела на меня так, словно я был самым тупым человеком на свете, и повторила с нажимом:
- Это. Для. Соответствия. Требованиям.
И в этот момент я осознал, что слово “требования” на самом деле означает “заткнись”. Вот что означают требования для большинства людей. Они перестают говорить о людях и проблемах, которые надо решить. Правда же состоит в том, что, даже если вы сделаете лишь часть того, что требуется, пользователи вполне могут остаться довольными.
-- Джефф Паттон. «Пользовательские истории. Искусство гибкой разработки ПО»