Должен ли анализ быть технологически независимым? [закрыто]

У меня вчера был спор с одним из моих коллег. Он (бизнес-аналитик, ранее программист) считает, что ему следует знать о технологии, используемой для реализации системы, чтобы он мог принимать лучшие проектные решения. По моему мнению (я программист), анализ никоим образом не должен быть связан с технологией, и я считаю, что хороший аналитик может сделать отличный дизайн, не беспокоясь о деталях реализации.

Прав ли я так думать? Есть ли причины, по которым бизнес-аналитику нужно знать технологию, используемую для внедрения системы?

EDIT: Я считаю , что я использовал неправильный термин, говоря business analyst. Может быть, я имел в виду архитектора или системного аналитика. Я не привык к этим условиям. Я имел в виду что-то вроде архитектора или системного аналитика, если хотите.

Спасибо всем за ваши потрясающие ответы! Я еще не очень опытен, и я рад, что вы открыли мне глаза на это.

Конечно, есть случаи, когда бизнес-аналитику имеет смысл понять технологию хотя бы достаточно хорошо, чтобы понять, где имеет смысл задавать вопросы бизнес-пользователю о важности конкретной функции. Например, если бизнес привык к поведению толстого клиентского приложения, в то время как новое приложение будет основано на веб-технологиях, вполне вероятно, что будет много «требований», которые были бы тривиальными в толстом клиенте, но относительно трудными с веб-приложением. Если бизнес-аналитик понимает, будет ли запрос от бизнеса тривиальным для команды разработчиков или он потребует 20 часов разработки AJAX,

Для любого конкретного проекта, вероятно, существует большое количество наборов требований, которые на самом деле удовлетворяют бизнес, делая различные компромиссы. Чем больше у бизнес-аналитика понимания компромиссов, тем выше вероятность того, что он собирается предоставить набор требований, который максимизирует выгоду для бизнеса при минимизации затрат.

Проработав обе стороны этого вопроса, я должен согласиться с аналитиком. Я видел несколько поразительно плохих конструкций, возникающих из-за непонимания возможностей технологии. В некоторых случаях это было результатом принятия рекламного шумихи за правду. В общем, проблема заключалась в создании спецификаций, которые не соответствуют техническим возможностям.

Аналитик должен указать, что необходимо сделать, когда и кем. Они должны знать, почему это делается. Приоритет развития должен в большей степени зависеть от причины, чем от других факторов. Команда дизайна и разработки должна справиться с How. Чтобы разработать экономически эффективные системы, аналитики должны указать, что необходимо сделать в терминах, которые не выходят за рамки доступной технологии.

Расширение границ может увеличить затраты несколькими способами, но в некоторых случаях может иметь значительную отдачу. Некоторые из факторов стоимости:

• Экспериментирование может потребоваться для разработки рабочего решения;
• Возможно, потребуется привлечь новых сотрудников или консультантов со специальными знаниями;
• Обучение новым технологиям может потребоваться;
• Разработка, как правило, медленнее и частота ошибок выше; и
• Дополнительные усилия могут задержать более простые решения, которые имеют более непосредственную ценность.

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

Однако бизнес-аналитикам не нужно заботиться о том, какие технологии используются, их задача - собирать бизнес-правила и делать их понятными для технической команды. Системные аналитики / архитекторы / дизайнеры или любые другие имена, которые им могут дать, должны знать используемые технологии и проектировать их, потому что они должны быть теми, кто занимается фактическим проектированием, а не бизнес-аналитиками.

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

Есть ли какие-либо рабочие параметры, которые направляют вас в определенном направлении? У вас есть широкий спектр ресурсов, способных внедрить решение в любой технологический стек? Существуют ли проблемы взаимодействия, требующие доступа к другим системам?

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

Не имея ограничений и будучи очень высокоуровневым дизайном, я могу согласиться с вашим мнением о том, что дизайн должен быть действительно независимым. Однако за более чем 20-летний опыт работы я редко сталкивался с ситуацией, когда не было никаких ограничений, ограничивающих мой выбор, и которые приводили мой дизайн к определенным технологиям или семействам технологий.

Пользовательский интерфейс идеально было бы , когда пользователь думает , что мысль, и то , что они хотели сделать это просто сделать. Все, кроме этого, ограничено технологическими ограничениями, которыми мы располагаем, поэтому, конечно, БА должен понимать, в каком контексте они могут проектировать систему.

Различные технологии могут иметь очень разные структуры затрат и эффективности для решения данной проблемы. Эти затраты могут включать в себя такие вещи, как расходы на аренду персонала в локальной сети, затраты на электроэнергию и охлаждение для конкретных систем, существующий код и возможности повторного использования существующего оборудования и т. Д. И т. Д. И т. Д. Итак, да, возможно, можно игнорировать эти недостатки и детали конкретных технологий если кто-то работает над проектом, в котором стоимость и эффективность не так важны, как другие соображения (например, в области безопасности полетов, управления ядерными установками, медицинских имплантатов и т. д.). Но для большинства бизнес-ситуаций руководство может заботиться о структуре затрат потенциальных решений в сравнении с преимуществами внедрения системы.

Бизнес-аналитик должен знать, какое приложение мы разрабатываем, например * веб-приложение / консольное приложение / мобильное приложение / приложение для составления отчетов и т. Д. *, Чтобы он мог лучше придумать хороший набор функций для приложения или оттолкнуть пользователя на невозможных ожиданиях, таких как вложенное перетаскивание 3-го уровня (например).

Ему / ей не нужно знать, какие технологии, такие как Java / C # / Python / SQL и т. Д.

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

Хотя это правда, что большая часть разработки программного обеспечения, по сути, одинакова, независимо от используемой технологии, всегда есть области, где дизайн будет зависеть от выбора технологии. Выбор платформы может влиять на выбор языка и API, в то время как наличие сделанного выбора также зависит от наличия опыта, поддержки и даже стоимости. Таким образом, с одной точки зрения, часть вашей позиции оправдана тем, что фактический анализ должен проводиться без влияния какой-либо конкретной технологии, однако использование анализа для определения дизайна всегда потребует более широких технологических знаний, так что аналитик может давать рекомендации что позволит применять конструкции, предназначенные для удовлетворения потребностей заказчика.

Каждая технология имеет пределы и ограничения, поэтому аналитику имеет смысл рассмотреть эти ограничения. С другой стороны, аналитик, который хорошо знает .net, но не видел Java с конца девяностых, скорее всего разработает решение .net - с использованием терминологии .net и шаблонов проектирования - даже если Java (или RoR и т. Д.) будет лучше соответствовать проблеме. Относительно сложно реализовать такой дизайн позже в другой технологии.

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