Почему аналитику недостаточно только требований

Аналитика слишком часто воспринимается как роль, которая собирает требования, описывает процессы и передаёт результат дальше: архитекторам, разработке, инженерам эксплуатации. Формально это звучит аккуратно. На практике именно в этой точке система начинает распадаться на куски. Каждый следующий участник получает не контекст, а только свой фрагмент задачи. В итоге архитектура проектируется отдельно от реальных сценариев, разработка реализует то, что можно понять из текста, а инженеры потом пытаются удержать это в жизни.

Проблема не в том, что аналитик “должен стать архитектором” или “обязан думать как разработчик”. Проблема в другом: сложные системы не проектируются по цепочке. Они проектируются через синхронизацию ролей. Требования, архитектурные ограничения, инженерная реализуемость и эксплуатационные риски должны встречаться достаточно рано, иначе система начинает мстить уже после запуска. И чтобы не было недопонимания: требования нужны — без них проектировать нечего. Просто они не финальный артефакт, который передают дальше «через стену», а вход в совместное проектирование.

Поэтому полезно смотреть на аналитика не как на автора документов, а как на участника архитектурного контура — того, кто видит, где безобидная на первый взгляд формулировка на уровне требований позже превратится в дорогую интеграцию, хрупкую схему данных или неподъёмный SLA. В первой статье серии мы зафиксировали рамку кейса — проектируем не базу как сооружение, а её цифровой контур управления и наблюдения. Здесь смотрим на ту же базу глазами аналитика, и кейс удобен тем, что ограничения видны особенно отчётливо: энергия ограничена, связь нестабильна, ошибки дороги, а цена несинхронизированных решений слишком высока.

В статье

• Почему одного списка требований почти никогда не хватает
• Что аналитик видит раньше архитектуры
• Лунная база как кейс конфликтующих ограничений
• Где появляется синергия между ролями
• Что происходит, если каждая роль работает отдельно
• Короткий checklist для первой архитектурной синхронизации
• Что дальше

Почему одного списка требований почти никогда не хватает

Список требований почти всегда выглядит убедительно в момент написания. В нём есть use cases, роли, ограничения, интеграции, иногда даже нефункциональные требования. Но он почти никогда не отвечает на вопрос, что именно будет определять форму системы.

Например, формулировка “база должна работать автономно при потере связи с Землёй до 8 часов” может выглядеть как одно из требований среды. Но на самом деле это уже архитектурный драйвер. Она влияет на:

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

То есть требование уже перестаёт быть просто текстом. Оно начинает диктовать:

• где будут границы подсистем;
• какие взаимодействия могут быть синхронными, а какие нет;
• где нужна eventual consistency;
• где критична автономность;
• где человеческое решение вообще не должно ждать round-trip до внешнего контура.

Если аналитика в этот момент ограничивается только “корректной фиксацией требования”, то архитектура начинает догонять смысл слишком поздно.

Что аналитик видит раньше архитектуры

У аналитика обычно раньше других появляется доступ к нескольким важным слоям:

• к исходной проблеме, а не только к будущему решению;
• к конфликтам между бизнес-целями и реальностью исполнения;
• к цепочкам действий пользователей и операторов;
• к зависимости между процессами, которые на схеме потом будут выглядеть как отдельные сервисы и подсистемы;
• к “неудобным” вопросам, которые ещё никто не хочет решать на уровне архитектуры.

Именно здесь появляется первая настоящая польза от аналитического участия в проектировании. Не в том, чтобы заранее выбрать Kafka или PostgreSQL, а в том, чтобы вовремя увидеть:

• что система будет жить в режиме частичной недоступности;
• что операторы на месте и удалённый центр управления видят разные куски реальности;
• что часть данных требует строгой консистентности, а часть переживает задержки;
• что инженерное обслуживание и логистика модулей не менее важны, чем “основная функция” системы.

Хороший аналитик приносит в архитектурный разговор не “ещё больше текста”, а более точную картину ограничений.

Лунная база как кейс конфликтующих ограничений

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

• жизнеобеспечение;
• энергосистема;
• логистика запасов и расходников;
• управление роботизированными платформами;
• медицинский контур;
• научная телеметрия;
• наземный контур планирования и координации.

На уровне требований всё может выглядеть почти спокойно:

1. база должна поддерживать автономную работу экипажа;
2. расходники должны пополняться и учитываться;
3. робототехника должна помогать в транспортировке и наружных операциях;
4. наземная команда должна видеть состояние базы и управлять поставками;
5. критичные инциденты должны обнаруживаться и эскалироваться.

Но если смотреть глубже, быстро появляются конфликтующие ограничения:

• связь не всегда стабильна;
• энергобюджет ограничен;
• человеческий ресурс экипажа ограничен ещё сильнее;
• часть решений должна приниматься локально;
• часть данных можно доставить позже;
• часть команд нельзя исполнять без подтверждения;
• часть процессов должна переживать деградацию соседних подсистем.

То есть уже на первом шаге видно: это не “набор фич”, а система, в которой аналитика, архитектура и инженерная эксплуатация должны собраться в единую картину.

Чтобы это не осталось абстракцией, вернёмся к сквозному сценарию серии: связь с Землёй пропала на 40 минут, а энергобюджет просел. Хороший аналитик до всякой архитектуры задаёт по нему очень конкретные вопросы:

• какие нагрузки критичны, а какие можно отключить или отложить;
• кто принимает решение об отключении — экипаж локально или наземный центр;
• какие данные обязаны сохраниться, даже если канал недоступен;
• какие команды нельзя исполнять без подтверждения, а какие допустимо исполнить локально;
• что считается «штатной деградацией», а что уже аварией.

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

flowchart TD
  A["Требования и сценарии"] --> B["Автономность"]
  A --> C["Безопасность"]
  A --> D["Связь с Землёй"]
  A --> E["Энергобюджет"]
  A --> F["Логистика и обслуживание"]

  B --> G["Локальные решения\nи деградационные режимы"]
  D --> H["Асинхронные взаимодействия\nи буферизация"]
  E --> I["Приоритеты нагрузки\nи отказоустойчивость"]
  F --> J["Доменная модель\nи процессы снабжения"]
  C --> K["Контуры управления\nи критичные команды"]

  G --> L["Архитектура системы"]
  H --> L
  I --> L
  J --> L
  K --> L

Где появляется синергия между ролями

Синергия между аналитикой, архитектурой, разработкой и инженерными командами возникает не на абстрактном лозунге “надо больше разговаривать”, а в очень конкретных точках.

Аналитика + архитектура

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

Архитектура + разработка

Здесь проверяется цена решений. Можно нарисовать красивую схему с автономными контурами, event-driven взаимодействием и тонкой моделью приоритетов команд. Но разработка очень быстро возвращает в реальность: сколько это стоит реализовать, как тестировать, где будет сложность состояния, где начнутся race conditions, где потребуется сложный rollout.

Аналитика + разработка

Здесь требования проходят проверку на однозначность и тестируемость. Разработка задаёт аналитику неудобные, но спасительные вопросы: что значит «связь нестабильна» в цифрах, какие edge cases у «частичной деградации», как звучит acceptance criteria, которое реально можно проверить тестом.

Хороший пример — формулировка «команда должна подтверждаться». Конкретикой она становится только в этом диалоге: кем подтверждаться, в какой срок, что происходит при отсутствии подтверждения. Без пары «аналитика + разработка» такие неоднозначности всплывают уже в коде — самой дорогой точке для их исправления.

Архитектура + инженеры эксплуатации

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

• что будет при частичной потере связи;
• как обслуживать систему после обновления;
• как диагностировать “серые” состояния;
• что будет, если локальный контур видит одно, а внешний — другое;
• как восстанавливаться после отказа, когда у команды мало времени и плохая наблюдаемость.

Аналитика + инженеры домена

Это особенно важно в сложных системах. Аналитика должна понимать не только “что хочет заказчик”, но и реальный operational язык домена. В кейсе лунной базы это может означать разницу между:

• запасами и критичными резервами;
• телеметрией и данными для принятия решений;
• штатным режимом и режимом выживания;
• удалённым управлением и локальной автономией.

Именно здесь рождается общая понятийная база, без которой ни хорошей доменной модели, ни хорошей архитектуры не получится.

Что происходит, если каждая роль работает отдельно

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

• Аналитика описывает “что нужно”, не проговаривая цену автономности и деградации.
• Архитектура рисует схему, не до конца понимая реальные сценарии эксплуатации.
• Разработка реализует куски требований, компенсируя недосказанность локальными решениями.
• Инженеры эксплуатации получают систему, где многое “логично на схеме”, но плохо восстанавливается, слабо наблюдается и дорого сопровождается.

В лунной базе это выглядело бы особенно жёстко:

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

Это не “ошибка одной команды”. Это эффект отсутствия общей архитектурно-аналитической синхронизации.

Короткий checklist для первой архитектурной синхронизации

Перед тем как уходить в детальный дизайн, полезно вместе ответить хотя бы на несколько вопросов:

1. Какие требования в задаче реально являются архитектурными драйверами?
2. Где у системы ожидаются конфликты между автономностью, безопасностью, задержками и стоимостью?
3. Какие процессы критичны для выживания системы, а какие просто важны?
4. Где допустима отложенная согласованность, а где нет?
5. Какие сценарии деградации система обязана переживать?
6. Какие решения нельзя принимать без участия инженеров домена и эксплуатации?
7. Какие ограничения нужно выразить в числах: задержка связи, время автономной работы, RTO/RPO (время восстановления / допустимая потеря данных), энергобюджет?
8. Что именно разработка должна подтвердить как реалистичное до того, как схема станет “официальной”?

Если этих ответов нет, то архитектура ещё не началась по-настоящему, даже если диаграмма уже нарисована.

Что дальше

Мы увидели, что аналитик участвует в архитектуре раньше, чем появляется схема. Но и до требований есть шаг, который часто перепрыгивают: точно поставить задачу. Следующая статья серии — problem statement: симптомы, причины и метрики — про то, как не перепрыгнуть сразу к решению и отличить симптом от настоящей причины.