Ответ.

История вопроса:

В классических проектах нередко возникали конфликты между аналитиками и архитекторами, а также между системными и бизнес-аналитиками: каждый пытался «захватить» или, наоборот, переложить часть обязанностей. Четкое определение границ стало одним из признаков зрелой команды.

Проблема:

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

Решение:

• Определяются артефакты и конечные продукты для каждой роли (например: бизнес-аналитик отвечает за бизнес-цели, системный аналитик — за функциональные спецификации, архитектор — за архитектурные решения)
• На старте проекта проводится workshops/совещания с четким разбором зон ответственности и согласованием регламентирующих документов (RACI-матриц, например)
• Важно регулярно обсуждать и корректировать границы по мере развития проекта и изменения контекста

Ключевые особенности:

• Прозрачное распределение ролей и зон ответственности
• Явное определение артефактов и точек входа/выхода между ними
• Постоянная коммуникация и контроль стыков между задачами

Вопросы с подвохом.

Должен ли системный аналитик выходить на уровень проектирования архитектуры всей системы?

Нет, архитектор отвечает за архитектурные решения. Аналитик уточняет требования, которые архитектор может использовать, но не проектирует архитектуру целиком.

Может ли бизнес-аналитик заниматься описанием технических ограничений напрямую?

Как правило, нет — бизнес-аналитик формирует бизнес-требования. Технические ограничения — сфера системного аналитика или архитектора.

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

Нет, но системный аналитик обязан убедиться, что всё понял верно, и при разночтениях инициировать вопросы.

Типовые ошибки и анти-паттерны

• Перекладывание зон ответственности «по умолчанию»
• Нечеткое описание конечных продуктов (артефактов)
• Конфликты из-за отсутствия регулярного общения между ролями

Пример из жизни

Негативный кейс:

Две команды параллельно прорабатывали одну часть системы: аналитики писали псевдо-архитектуру, а архитекторы — описывали бизнес-процессы. В итоге спецификации расходились, реализация затягивалась.

Плюсы:

• Попытка ускорить работу

Минусы:

• Дублирование, расхождение документов, потеря сроков

Положительный кейс:

Совместный воркшоп на старте, где согласовали, кто за что отвечает, документировали границы и стыки. В дальнейшем на каждом этапе проводили ревизии этих соглашений.

Плюсы:

• Четкая работа, отсутствие конфликтов, быстрое завершение работ

Минусы:

• Требуется больше коммуникаций на старте, но минимизация рисков