avl (avl) wrote,
avl
avl

Categories:

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

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

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

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

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

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

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

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

  • Тест на способность доводить до конца пройден!

    Сегодня закончил переводить серию "97 вещей для программиста"! Вот здесь - три последних перевода: 95. Пишите тесты для людей - еще одна статья о…

  • Еще три перевода

    92. Когда программисты и тестеры объединяются - о том, что объединяться для общей цели всегда выгодно. 93. Пишите код так, как будто вы будете…

  • Еще четыре перевода

    88. Юникс-утилиты - это ваши друзья - название говорит само за себя :) 89. Используйте правильные алгоритмы и структуры данных - интересная и…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 3 comments