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

11

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

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

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

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

марко-fiset
источник
8
Вы спрашивали его о том, когда это будет иметь значение?
Карл Билефельдт
Он не привел мне пример, но мы используем широкий спектр технологий, начиная от старых систем AS / 400, некоторых Delphi и затем .Net для чего-то нового. Но я все еще думаю, что если вы разрабатываете что-то, что должно быть реализовано в RPG, вы создадите то же самое в C #, используя разделение задач и надлежащий уровень для бизнес-логики и т. Д.
marco-fiset,
Ему нужно знать столько же, сколько и пользователю. AS / 400 против веб-приложения - это деталь, которая ему понадобится.
кодер
2
Разница будет в части «тогда вы должны представить что-то пользователю». Бизнес-аналитик должен знать, какой тип пользовательского интерфейса используется и какие варианты доступны. Существуют инструменты, которые могут использовать бизнес-аналитики, которые, по сути, позволяют им определить, что функционально должно произойти, когда пользователь выполняет x (например, нажмите кнопку). Если на платформе нет кнопки (зеленый экран), это полезная информация.
кодер
1
@marcof: идеальный пользовательский интерфейс - это то, где пользователь думает, а то, что он хотел сделать, просто сделано. Все, кроме этого, ограничено технологическими ограничениями, которые мы имеем в нашем распоряжении, поэтому, конечно, БА должен понимать, в каком контексте они могут проектировать систему.
gahooa

Ответы:

18

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

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

Джастин Кейв
источник
4
+1 за «максимизирует выгоду для бизнеса при минимизации затрат». Это невозможно сделать без понимания технологии БА. Работа бакалавра в том, чтобы понять больше технологий, чем программист, на более высоком уровне.
Mattnz
Кроме того, следует изменить не требования, а ограничения, влияющие на выполнение этих требований. То, что бизнес не может получить то, что он хочет, не означает, что он должен перестать хотеть этого, хотя это заставляет их рационализировать то, что они могут иметь сейчас . Например, плохая работа сейчас не мешает мне хотеть лучшую, ее просто невозможно достичь с текущими ограничениями. Важно то, что это открывает возможность того, что если ограничение будет снято, требование теперь может быть выполнено. Если вы измените требование на сейчас, вы потеряете его навсегда
BiGXERO
8

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

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

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

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

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

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

Ryathal
источник
6

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

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

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

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

Ларри Гектор
источник
3

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

gahooa
источник
2

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

hotpaw2
источник
1

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

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

java_mouse
источник
1

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

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

S.Robins
источник
0

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

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

user281377
источник
Разве шаблоны дизайна не зависят от языка?
marco-fiset
2
Они обычно не привязаны к конкретному языку, но некоторые технологические стеки могут сделать их проще в реализации, чем другие. Дизайн, созданный с учетом ASP.net MVC, может быть громоздким для реализации на простом PHP или Oracle Application Express.
user281377