Чи повинен аналіз бути технологічно-агностичним? [зачинено]

Я вчора посперечався з одним із колег. Він (бізнес-аналітик, раніше програміст) вважає, що він повинен знати про технології, що застосовуються для впровадження системи, щоб він міг приймати кращі дизайнерські рішення. На мою думку (я програміст), аналіз не повинен жодним чином поєднуватися з технологією, і я вважаю, що хороший аналітик може зробити чудовий дизайн, не переймаючись деталями реалізації.

Чи прав я так думаю? Чи є причини, чому бізнес-аналітику потрібно знати технологію, що використовується для впровадження системи?

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

Дякую всім за чудові відповіді! Я ще не дуже досвідчений і радий, що ти відкрив мені очі на це.

Безумовно, є випадки, коли бізнес-аналітик має сенс зрозуміти технологію хоча б досить добре, щоб зрозуміти, де має сенс запитувати бізнес-користувача про те, наскільки важливою буде певна особливість. Наприклад, якщо бізнес звик до поведінки жирного клієнтського додатка, коли новий додаток буде веб-базі, то, ймовірно, буде багато "вимог", які були б тривіальними у товстого клієнта, але відносно важкі із веб-додатком. Якщо бізнес-аналітик розуміє, чи буде запит від бізнесу тривіальним для команди розробника, чи буде він залучати 20 годин розвитку AJAX,

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

Опрацювавши обидві сторони цього питання, я повинен погодитися з аналітиком. Я бачив деякі вражаюче погані конструкції, що виникають через нерозуміння можливостей технології. У деяких випадках це було результатом сприйняття маркетингової реклами як істини. Загалом, проблема полягає у створенні специфікацій, які не відповідають технічним можливостям.

Аналітик повинен уточнювати, що потрібно робити, коли і ким. Вони повинні знати, чому це робиться. Пріоритет розвитку повинен бути більш залежним від Чому, ніж від інших факторів. Команда з розробки та розробки повинна розібратися з How Для того, щоб розробити економічно ефективні системи, аналітикам потрібно уточнити, що потрібно робити в термінах, які не підштовхують межі наявної технології.

Просування меж може збільшити витрати різними способами, але в деяких випадках може мати значну віддачу. Деякі фактори витрат:

• Для розробки робочого рішення може знадобитися експериментація;
• Можливо, потрібно буде придбати нових співробітників або консультантів зі спеціалізованими знаннями;
• Навчання новій технології може знадобитися;
• Розвиток має бути повільнішим, а рівень помилок - вищим; і
• Додаткові зусилля можуть затримати більш прості рішення, які мають більш безпосереднє значення.

Якщо технологія, яка буде використовуватися, відома, її слід враховувати аналітикам при створенні дизайну. Різні технології роблять все по-різному, і дизайн, який не враховує цих відмінностей, матиме проблеми.

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

Я вважаю, що між двома лініями думки є певний момент, який, мабуть, реалістичніший. Хоча дизайн високого рівня може бути найкращим, коли технологія підтримується агностиком, слід враховувати відомі обмеження та вимоги реального світу, які повинні бути включені в дизайн. На якому рівні цей дизайн? Чи є у вас достатні вимоги? Наскільки гнучким є середовище? Чи вкладено управління в конкретний технічний напрям?

Чи немає оперативних параметрів, які спрямовують вас у певному напрямку? Чи є у вас широкий набір ресурсів, здатних реалізувати рішення в будь-якому стеку технологій? Чи існують проблеми взаємодії, які потребують доступу до інших систем?

Відповіді на ці запитання потрібні, перш ніж ви зможете остаточно сказати, чи повинна технологія бути частиною рівняння, чи дизайн повинен керувати вибором технології.

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

Інтерфейс ідеально було б , коли користувач думає , що думка, і то , що вони хотіли зробити це просто зробити. Все, що не відрізняється від цього, обмежує технологічні обмеження, які ми маємо у своєму розпорядженні, тому, звичайно, BA повинен зрозуміти, в якому контексті вони можуть проектувати систему.

Різні технології можуть мати дуже різні структури витрат і ефективності для вирішення заданої проблеми. Ці витрати можуть включати такі речі, як витрати на найм у місцевій зоні, витрати на енергію та охолодження для конкретних систем, наявний код та можливості використання обладнання тощо тощо. Так, так, можливо, можна ігнорувати ці протипоказання та деталі конкретних технологій якщо хтось працює над проектом, де вартість та ефективність не є десь настільки важливими, як інші міркування (наприклад, в галузі авіаційної безпеки, управління ядерними станціями, медичних імплантатів тощо). Але для більшості бізнес-ситуацій керівництво може піклуватися про структуру витрат потенційних рішень порівняно з перевагами впровадження системи.

Бізнес-аналітик повинен знати, який саме додаток ми розробляємо, як-от * Веб-додаток / Консольний додаток / Мобільний додаток / Доповідь та ін. *, Щоб вона змогла краще придумати гарний набір функцій для програми або натиснути назад на користувача на неможливі очікування, такі як вкладене перетягування 3-го рівня (наприклад).

Йому / їй не потрібно знати, які саме технології, такі як Java / C # / Python / SQL і т.д.

Сам процес аналізу повинен бути повністю техногенним. Коли ви досліджуєте клієнта та його потреби, вам потрібно це робити з цілком відкритим розумом. Інша сторона монети полягає в тому, що аналітику часто пропонують дати рекомендації, а також може знадобитися і для управління архітектурою системи. Це зовсім інша гра ролі, в якій більш широке розуміння наявних технологій має вирішальне значення, оскільки це може зробити величезну зміну для замовника не лише в плані можливості отримати проект з місця, але і в плані довгострокових потреб замовника та стійкості самого проекту.

Хоча це правда, що більша частина проектування програмного забезпечення по суті однакова, незалежно від використовуваної технології, завжди є сфери, де дизайн буде впливати на вибір технології. Вибір платформи може впливати на вибір мови та API, тоді як наявність експертизи, підтримки та навіть витрат також матиме вплив на зроблений вибір. Отже, з одного погляду, частина вашої позиції виправдана тим, що фактичний аналіз повинен проводитися без впливу якоїсь конкретної технології, однак використання аналізу для визначення дизайну завжди вимагатиме більш широких технологічних знань, щоб аналітик міг давати рекомендації що дозволить застосувати конструкції, призначені для задоволення потреб замовника.

Кожна технологія має обмеження та обмеження, тому аналітику є сенс розглянути ці межі. З іншого боку, аналітик, який добре знає .net, але Java не бачив з кінця дев'яностих, швидше за все, розробить рішення .net - використовуючи .net термінологію та шаблони дизайну - навіть якщо Java (або RoR тощо) краще підійде до проблеми. Пізніше реалізувати таку конструкцію в іншій технології порівняно важко.

Тому я вважаю, що аналітик повинен бути агностиком, коли технологія ще не була обрана, але має досвід у тих випадках, коли вибір вже зроблений.