![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
И еще, оттуда же:
97 Things Every Software Architect Should Know:
Часто заказчики в качестве требований к проекту выдвигают то, что, как им кажется, является жизнеспособным решением их проблемы. В качестве примера, ставшего классическим, можно привести историю, которую рассказал Harry Hillaker, ведущий разработчик самолета F-16 Falcon. Их команде было поручено разработать самолет, летающий со скоростью, в 2-2.5 раз выше скорости звука. Тогда, а возможно, и сейчас, это весьма нетривиальная задача, особенно если при этом требуется построить дешевый и легкий самолет. Вы же, наверное, помните, что аэродинамическое сопротивление увеличивается в четыре раза при увеличении скорости в два, и понимаете, как этот факт влияет на вес самолета.
Когда же команда разработчиков спросила военных, зачем им нужна скорость в два с половиной раза выше скорости звука, они ответили, что это нужно для возможности выйти из боя. Когда реальная потребность была озвучена, стало возможным выделить главную задачу и найти работающее решение. Решением стал самолет с высоким отношением силы тяги к весу, что позволяло ему резко ускоряться и маневрировать при необходимости, а не лететь длительное время с максимально возможной скоростью.
Этот урок стоит использовать и в разработке программного обеспечения. Задавая клиенту вопрос о том, для чего ему нужна желаемая функциональность или требование, проектировщик может увидеть реальную, настоящую проблему, и возможно, найти более лучшее и дешевое решение, чем предлагаемое клиентом. Фокусировка на реальных потребностях к тому же упрощает приоритизацию – наиболее важное для решения реальной задачи становится двигателем для проектирования.
Сколько раз в нашей практике такое было - не счесть. Просят одно, когда спросишь, оказывается что хотели другое, а в итоге часто оказывается что нужно вообще третье.
Часто заказчики в качестве требований к проекту выдвигают то, что, как им кажется, является жизнеспособным решением их проблемы. В качестве примера, ставшего классическим, можно привести историю, которую рассказал Harry Hillaker, ведущий разработчик самолета F-16 Falcon. Их команде было поручено разработать самолет, летающий со скоростью, в 2-2.5 раз выше скорости звука. Тогда, а возможно, и сейчас, это весьма нетривиальная задача, особенно если при этом требуется построить дешевый и легкий самолет. Вы же, наверное, помните, что аэродинамическое сопротивление увеличивается в четыре раза при увеличении скорости в два, и понимаете, как этот факт влияет на вес самолета.
Когда же команда разработчиков спросила военных, зачем им нужна скорость в два с половиной раза выше скорости звука, они ответили, что это нужно для возможности выйти из боя. Когда реальная потребность была озвучена, стало возможным выделить главную задачу и найти работающее решение. Решением стал самолет с высоким отношением силы тяги к весу, что позволяло ему резко ускоряться и маневрировать при необходимости, а не лететь длительное время с максимально возможной скоростью.
Этот урок стоит использовать и в разработке программного обеспечения. Задавая клиенту вопрос о том, для чего ему нужна желаемая функциональность или требование, проектировщик может увидеть реальную, настоящую проблему, и возможно, найти более лучшее и дешевое решение, чем предлагаемое клиентом. Фокусировка на реальных потребностях к тому же упрощает приоритизацию – наиболее важное для решения реальной задачи становится двигателем для проектирования.
Сколько раз в нашей практике такое было - не счесть. Просят одно, когда спросишь, оказывается что хотели другое, а в итоге часто оказывается что нужно вообще третье.
no subject
no subject
Мало ли, как ещё обосновать, что это мы
не злобные, а хотим, как лучше...