October 31st, 2009

6. Ищите настоящую причину требований

(В оригинале Seek the value in requested capabilities)

Часто заказчики в качестве требований к проекту выдвигают то, что, как им кажется, является жизнеспособным решением их проблемы. В качестве примера, ставшего классическим, можно привести историю, которую рассказал Harry Hillaker, ведущий разработчик самолета F-16 Falcon. Их команде было поручено разработать самолет, летающий со скоростью, в 2-2.5 раз выше скорости звука. Тогда, а возможно, и сейчас, это весьма нетривиальная задача, особенно если при этом требуется построить дешевый и легкий самолет. Вы же, наверное, помните, что аэродинамическое сопротивление увеличивается в четыре раза при увеличении скорости в два, и понимаете, как этот факт влияет на вес самолета.

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

Этот урок стоит использовать и в разработке программного обеспечения. Задавая клиенту вопрос о том, для чего ему нужна желаемая функциональность или требование, проектировщик может увидеть реальную, настоящую проблему, и возможно, найти более лучшее и дешевое решение, чем предлагаемое клиентом. Фокусировка на реальных потребностях к тому же упрощает приоритизацию – наиболее важное для решения реальной задачи становится двигателем для проектирования.

И как же это делать? Один из вариантов следует из манифеста agile разработки: «Сотрудничество важнее контракта». На практике это подразумевает организацию семинаров и митингов, на которых архитекторы концентрируются на проблемах заказчиков, помогая им ответить на вопросы «Для чего? Почему? Зачем?». Имейте в виду, что ответить на эти вопросы заказчику может быть нелегко, потому что часто разговор будет идти о нечетких, не до конца ясных и сформулированных знаниях и мыслях. Обсуждений технических решений и деталей лучше при этом избегать, поскольку они будут переводить дискуссию из домена знаний заказчика в домен знаний разработки.

Автор оригинала: Einar Landre

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!