Когда “таблица требований” — это уже не аналитика, а архитектура
Коллеги, давайте расставим акценты.
На старте проекта аналитик и архитектор могут работать с одним и тем же набором артефактов: таблицы, схемы, диаграммы, Excel. Визуально это одно и то же — но смыслы уже начинают расходиться.
~ Аналитик отвечает на вопрос: что нужно бизнесу.
~ Архитектор отвечает на вопрос: как это должно работать в системе.
И вот момент, когда таблица требований перестаёт быть аналитическим инструментом и становится элементом архитектурного проектирования:
— Когда появляются ограничения среды: что можно, а что нельзя реализовать в системе.
— Когда надо учесть масштабируемость: что будет, если в справочнике будет не 100 строк, а 10 тысяч.
— Когда возникает интеграция: что станет с процессом, если его половина — в SAP, а другая — в 1С.
— Когда одно решение влияет на несколько модулей и любое изменение надо сначала “провести по рёбрам”.
С этого момента таблица уже не просто “описание требований”, а основа будущей логики системы. И ответственность за неё меняется.
Архитектор должен:
— Видеть не только “как должно быть”, но и “что будет, если это реализуют именно так”.
— Прогнозировать последствия: не только функциональные, но и эксплуатационные.
— Вписывать требования в архитектуру системы с учётом текущего состояния, технического долга и будущих доработок.
Если вы работаете в команде и держите в руках “таблицу требований” полезно задать себе вопрос:
Это ещё аналитика? Или уже проектирование архитектуры❓
От этого зависит, насколько точен должен быть ваш взгляд.
И насколько критично будет ваша ошибка.
Еще больше информации про работу ФА на нашем Дзен-канале.
Лаборатория цифровых решений | @erplab
