Одна из самых дорогих ошибок в проектировании — слишком быстро договориться, в чём именно проблема. Команда видит неприятный симптом, называет его проблемой, строит вокруг него решение и только потом обнаруживает, что лечила не причину, а внешний эффект.
В кейсе лунной базы это выглядит просто. Наземная команда замечает, что данные по запасам приходят с задержкой. Первая реакция логична: ускорить доставку телеметрии. Но через несколько вопросов выясняется, что проблема не в скорости передачи — критичные сигналы и обычная диагностика идут одним потоком, локальный контур слишком зависит от внешней синхронизации, а метрики не различают опасное рассогласование и просто поздний приход некритичных данных.
В прошлой статье мы говорили, что аналитик входит в архитектурный контур раньше, чем появляется схема. Первый инструмент этого входа — точная постановка проблемы. Без хорошего problem statement архитектура быстро начинает решать не ту задачу. В этой статье разберём, как формулировать постановку проблемы так, чтобы она помогала отделить симптом от причины, а наблюдаемую метрику — от реального архитектурного драйвера.
В статье
- Почему симптом почти никогда не равен проблеме
- Что такое хороший problem statement
- Лунная база: как выглядят ложные постановки проблемы
- Как доходить до причины, а не останавливаться на первом объяснении
- Почему метрики нужны до архитектурного решения
- Какие метрики действительно помогают
- Сквозной пример: от симптома к драйверу
- Короткий шаблон для первой формулировки
- Что дальше
Почему симптом почти никогда не равен проблеме
Симптом — это то, что команда замечает первой. Он видим, неприятен и чаще всего уже влияет на пользователей или операционную работу. Но симптом редко объясняет, почему система пришла именно в это состояние.
Примеры:
- “данные о запасах расходников приходят на Землю с опозданием”;
- “операторы часто получают противоречивую телеметрию”;
- “управление роботизированной платформой иногда зависает”;
- “планирование поставок слишком долго пересчитывается”;
- “экипаж слишком часто делает ручные подтверждения”.
Все эти формулировки могут быть правдой. Но они ещё не говорят, в чём проблема на самом деле. Возможные реальные причины:
- неправильная модель синхронизации;
- отсутствие приоритизации данных;
- слишком жёсткая связность между подсистемами;
- неверная декомпозиция доменных контуров;
- конфликт между безопасностью, автономностью и UX;
- плохой набор метрик, из-за которого команда лечит не тот участок.
Если симптом принять за проблему, архитектура начинает проектироваться вокруг эффекта. Это обычно приводит к локально логичному, но системно слабому решению.
Что такое хороший problem statement
Хороший problem statement не обязан быть длинным. Но он должен отвечать хотя бы на несколько базовых вопросов:
- Что именно наблюдается?
- На кого и на что это влияет?
- В каком сценарии это особенно критично?
- Какая метрика или наблюдаемый эффект делает проблему измеримой?
- Почему это не просто локальная неприятность, а системная задача?
Плохой problem statement:
У нас плохая синхронизация данных.
Хороший problem statement:
При потере канала связи локальный контур базы и наземный контур расходятся по данным о критичных запасах, из-за чего планирование поставок и решение по режиму потребления опираются на несовместимые состояния. Это увеличивает вероятность ошибочного решения в сценарии дефицита ресурсов.
Во втором варианте уже видно:
- где проблема проявляется;
- какие контуры затронуты;
- чем это опасно;
- почему это вопрос не только интеграции, но и архитектуры.
Лунная база: как выглядят ложные постановки проблемы
Кейс лунной базы хорошо показывает, насколько легко ошибиться уже в начале разговора.
Ложная постановка 1
Нужно ускорить доставку телеметрии на Землю.
Это может быть не проблемой, а попыткой лечить эффект. Возможно, проблема не в “скорости доставки”, а в том, что:
- поток данных не ранжирован по критичности;
- критичные сигналы идут в одном канале с низкоприоритетной диагностикой;
- наземный контур зависит от данных, которые вообще не должен ждать синхронно;
- локальная автоматика недостаточно автономна и слишком часто ждёт внешнего решения.
Ложная постановка 2
Нужно снизить количество ручных действий экипажа.
Звучит разумно, но без контекста это опасно. Часть ручных подтверждений может быть избыточной, а часть — критически важной с точки зрения безопасности. Тогда настоящая проблема не “слишком много ручных шагов”, а плохое разделение:
- штатных операций;
- опасных операций;
- аварийных режимов;
- действий, допускающих локальную автоматизацию.
Ложная постановка 3
Нужно сделать систему более надёжной.
Это вообще не problem statement, а декларация. Надёжность чего именно?
- связи?
- локальной обработки?
- хранения телеметрии?
- управления энергосистемой?
- восстановления после сбоя?
Без ответа на этот вопрос команда неминуемо начнёт делать “архитектуру для надёжности вообще”, а это почти всегда путь к переусложнению.
Как доходить до причины, а не останавливаться на первом объяснении
Самый полезный приём на старте — не верить первой формулировке, даже если она звучит правдоподобно.
Базовая рабочая логика:
- Зафиксировать наблюдаемый симптом.
- Уточнить, в каком сценарии он возникает.
- Понять, кто страдает от него первым.
- Связать это с метрикой или наблюдаемым операционным эффектом.
- Несколько раз спросить: “что должно быть устроено иначе, чтобы этот симптом исчез?”
Техника 5 Why здесь полезна не как ритуал, а как дисциплина отказа от слишком быстрого объяснения.
Пример:
- Симптом: данные по запасам на Земле устаревают.
- Почему? Потому что телеметрия приходит пачками и с задержкой.
- Почему? Потому что канал связи ограничен и часть данных буферизуется.
- Почему? Потому что вся телеметрия отправляется единым потоком без приоритизации.
- Почему? Потому что доменная модель данных не разделяет критичные сигналы и обычную диагностику.
- Почему? Потому что на уровне требований не был зафиксирован разный эксплуатационный приоритет информации.
На этом шаге видно, что проблема уже не в “медленной интеграции”, а в связке:
- требований;
- модели данных;
- архитектуры pipeline;
- и операционного понимания того, какие сигналы критичны.
Одна оговорка про 5 Why: в сложных системах у симптома редко бывает ровно одна «истинная причина». Цепочка выше — не единственная: тот же симптом может одновременно тянуться и от энергобюджета, и от модели ответственности между контурами. Поэтому относитесь к технике как к способу не остановиться на первом объяснении, а не как к поиску единственного корня. Если ветвей несколько — это нормально и обычно ближе к реальности, чем красивая линейная цепочка.
Почему метрики нужны до архитектурного решения
Очень частая ошибка — обсуждать архитектуру раньше, чем команда договорилась, что именно она считает улучшением.
Если метрик нет, разговор быстро уходит в:
- “сделаем надёжнее”;
- “ускорим”;
- “снизим нагрузку”;
- “сделаем удобнее операторам”.
Все эти фразы звучат разумно, но не позволяют выбирать между вариантами. Архитектурное решение почти всегда trade-off. Чтобы сравнить варианты, нужно понимать, по каким критериям они оцениваются.
В кейсе лунной базы это могут быть, например:
- время доставки критичной телеметрии;
- доля решений, которые локальный контур может принять автономно;
- время восстановления после потери связи;
- точность данных о критичных запасах;
- количество ручных подтверждений в штатном режиме;
- доля инцидентов, которые оператор может диагностировать без ручного обхода нескольких подсистем.
Метрики полезны не для красивого dashboard. Они полезны потому, что заставляют команду договориться:
- что вообще важно;
- что является ухудшением;
- что является достаточным улучшением;
- где у архитектуры действительно есть задача.
Какие метрики действительно помогают
В начале лучше разделять хотя бы три уровня метрик.
1. Симптомные метрики
Показывают, что боль существует:
- задержка доставки телеметрии;
- время подтверждения операции;
- количество несогласованных записей;
- частота ручных override действий.
2. Архитектурные метрики
Помогают понять, где система упирается в форму решения:
- время синхронизации между контурами;
- глубина очередей и буферов;
- количество деградационных режимов;
- доля операций, зависящих от внешнего канала;
- время восстановления после отказа отдельного контура.
3. Продуктовые и операционные метрики
Показывают, даёт ли система полезный результат:
- устойчивость жизнеобеспечения;
- сохранность критичных ресурсов;
- время реакции на аварийный сценарий;
- нагрузка на экипаж;
- предсказуемость работы наземного контура.
Чаще всего архитектуру ломает именно второй уровень: команда фиксирует симптом (уровень 1) и сразу прыгает к продуктовому результату (уровень 3), пропуская архитектурные метрики — и в итоге не понимает, почему решение не помогает.
Метрика — это ещё не цель
Для архитектуры важно не только название метрики, но и целевой порог. «Время доставки критичной телеметрии» — это пока не критерий: по нему нельзя сказать, стало лучше или хуже. Критерий появляется, когда есть число и условие:
- не «время доставки критичной телеметрии», а «95% критичной телеметрии доступно контуру принятия решений за ≤ 2 секунды»;
- не «автономность», а «база работает без связи с Землёй ≥ 8 часов без деградации жизнеобеспечения»;
- не «время восстановления», а «после потери связи контуры сходятся по критичным данным за ≤ 30 секунд».
Без порога метрика не помогает выбирать между вариантами — а именно ради выбора она и нужна.
Плохой problem statement даже с метрикой
Метрика не спасает автоматически. Постановка остаётся плохой, если:
- метрика vanity — растёт и радует глаз, но ни на какое решение не влияет (например, «объём собранной телеметрии»);
- метрика мерит удобное, а не важное — то, что легко снять, вместо того, что действительно болит;
- метрика подталкивает к вредной оптимизации — «снизить число ручных подтверждений» можно, убрав в том числе критичные для безопасности, и формально цель будет достигнута.
Поэтому к каждой метрике полезно задавать контрольный вопрос: какое архитектурное решение изменится, если эта цифра сдвинется? Если ответа нет — метрика декоративная.
Плохая метрика — та, которая красиво выглядит, но не меняет архитектурного разговора. Хорошая — та, которая помогает выбрать между двумя разными решениями.
flowchart LR
A["Симптом"] --> B["Problem statement"]
B --> C["Измеримая метрика"]
C --> D["Архитектурный драйвер"]
D --> E["Решение"]
F["Нет метрики"] --> G["Разговор уходит в мнения"]
G --> H["Решение выбирают по интуиции"]
Сквозной пример: от симптома к драйверу
Соберём всё вместе на сквозном сценарии серии: связь с Землёй пропала на 40 минут, а энергобюджет просел. Пройдём его по шагам.
- Симптом. «Во время разрыва связи экипаж жалуется, что система тормозит с подтверждением операций».
- Плохой problem statement. «Нужно ускорить подтверждение операций». — Лечит эффект: непонятно, каких операций, почему медленно и при чём тут разрыв связи.
- Хороший problem statement. «В сценарии потери связи с Землёй (до 40 минут) часть операций ждёт подтверждения наземного контура, хотя относится к критичным для жизнеобеспечения. Это задерживает решения экипажа в момент, когда внешний контур недоступен, и повышает риск в режиме дефицита энергии».
- Метрика + порог. «100% операций из заранее классифицированного перечня critical-life-support исполняются локально без round-trip к Земле; время локального подтверждения ≤ 1 секунды при недоступном канале».
- Архитектурный драйвер. Отсюда уже следует форма: разделение операций на локально-автономные и требующие внешнего подтверждения, локальный контур принятия решений, деградационный режим при просадке энергобюджета.
Обратите внимание: архитектурный вывод появился не из «сделаем быстрее», а из точной постановки и измеримого порога. Это и есть та цепочка, которую следующая статья серии превращает в полноценные архитектурные ограничения.
Короткий шаблон для первой формулировки
На старте можно использовать очень простой шаблон:
В сценарии X система демонстрирует симптом Y, что влияет на Z.
Это важно, потому что приводит к <операционному или продуктному эффекту>.
Проблему считаем значимой, если она измеряется через <метрику + порог>.
Предполагаемая причина сейчас — A, но она требует проверки.Важна именно последняя часть: причина требует проверки. Хороший problem statement не делает вид, что команда уже всё поняла. Он просто достаточно точно фиксирует:
- что болит;
- почему это важно;
- как это наблюдать;
- и где начинается гипотеза, а не установленный факт.
Что дальше
Когда проблема поставлена точно и измеримо, появляется материал, из которого рождается форма системы. Следующая статья серии — требования как архитектурные драйверы — про то, как из problem statement и метрик вырастают ограничения, которые уже напрямую формируют архитектуру.
Комментарии