Беклог и приоритеты не спасут. Почему без моделирования требований архитектура ломается каждый раз

Вы наверняка слышали эти отговорки:

Звучит знакомо? Давайте разберемся, почему эти аргументы разрушительны для проекта, и при чем тут вообще приоритеты.

Модель всегда проще системы, которую она описывает. Это аксиома. Если вы не в состоянии справиться со сложностью модели из 5–7 блоков, как вы собираетесь управлять сложностью системы с сотнями микросервисов и тысячей бизнес-правил? Модель — это ваш компас. Без неё вы идёте в туман.

Забудьте про бесконечное вычитывание 50-страничных ТЗ в Word или Confluence в попытке найти логические противоречия глазами. Время на моделирование сопоставимо со временем на написание этого документа, но эффективность — на порядок выше.

Вместо того чтобы читать текст в поисках ошибок, начинайте рисовать:

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

Моделирование — это инструмент аналитика (или разработчика) для работы с требованиями. Его польза распространяется:
📈 Вверх — на архитектуру. Плохая модель требований рождает неправильную архитектуру. Исправляя требования через диаграммы сейчас, вы спасаете архитектуру от фундаментальных ошибок в будущем.
💻 Вниз — на код. Модель ищет смысловые ошибки в логике, которые программист мог бы закодить. Программист, получив четкую непротиворечивую схему, напишет правильный код с первого раза.
Инвестиция в моделирование требований на старте — это страховка от хаоса, дорогих доработок и сорванных дедлайнов на финише.

Если модель требований построена плохо (ошибочна), то архитектор спроектирует неправильную структуру. Исправляя требования через диаграммы сейчас, вы спасаете архитектуру от фундаментальной ошибки в будущем. Модель требований ищет смысловые ошибки в логике, которые программист потом закодит.

Не ищите ошибки в тексте и не ждите, пока их найдут в коде. Дайте ошибкам проявиться на диаграммах. Пока это стоит всего лишь стрелочки. Модель — это дешёвый черновик архитектуры. Перерисовать стрелочку на диаграмме стоит 5 минут. Переписывать архитектуру из-за того, что разработчик не нарисовал эту стрелочку — стоит недель и нервов клиентов.

Моделирование — это не один инструмент, а целая экосистема. У каждого инструмента своё место. Если перепутать или пропустить уровень — появятся дыры.

Вопрос: «Как именно работает бизнес, какие шаги, кто за что отвечает?»

Вопрос: «Из каких объектов состоит система, как они общаются и как меняются состояния?»

Вопрос: «Как именно хранить данные и как принимать решения?»

Если вы слышали про UML, BPMN и ERD, вот как они ложатся в эту схему:

Итог: BPMN — для разговора с заказчиком. UML — для архитектуры. ERD — для хранения данных. Пропустите один — получите дыру.

«У нас маленькая команда, мы не тратим время на аналитику. Разработчик сам кодит и сам набрасывает требования в блокноте».

Звучит как экономия времени. На деле — это инвестиция в постоянные боли.

Цепочка событий:

Где ошибка? Ошибку искали в коде, когда система уже работала (или не работала). Но корень зла был не в коде, а в голове разработчика, который не перевел свои мысли в четкую модель требований.

Если бы этот разработчик потратил 2 часа в начале спринта и нарисовал DFD или диаграмму состояний, он бы увидел, что:

Модель — это дешевый черновик. Перерисовать стрелочку на доске дешевле, чем переписывать 500 строк кода и оправдываться перед клиентом.

«Разработчик читает требования заказчика. Задачи попадают в беклог. Команда их берёт, делает, релизит. Но каждый раз архитектура ломается. Я думала, проблема в приоритетах — может, не те задачи выбираем или слишком много берём. Но, видимо, есть ещё одна глубокая проблема...»

В чём она? Разработчик сам пишет себе ТЗ. Он прочитал требования заказчика, понял их «на своё усмотрение» и пошёл кодить. Диаграммы? Нет времени. Модель потоков данных? Зачем, я и так всё помню.

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

1. Разработчик сам пишет себе ТЗ — он читает требования заказчика и интерпретирует их «как понял».

2. Разработчик сам решает, рисовать ли диаграммы — чаще всего не рисует, потому что «время поджимает» или «я и так всё помню».

3. В итоге каждый разработчик строит свою локальную логику, не сверяясь с целостной моделью системы.

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

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

Вывод:

Приоритеты — это про «что делать первым». Моделирование — это про «как эти задачи лягут в единую логику системы, как это соединить».

Если вы не построили модель требований ДО того, как пошли в код, вы не узнаете об ошибке, пока тестировщик не уронит систему. А это значит, что вы ищете ошибки не в том месте и не в то время.

Без моделирования вы просто ускоряете хаос, беря больше задач. Это как строить этажи дома без фундамента и чертежа — важность этажа не спасёт, если дом рухнет.

Вернёмся к разработчику, который сам пишет ТЗ и сам кодит. Что он чаще всего пропускает?

Результат: бизнес-логика не согласована, архитектура не продумана, БД не оптимизирована. Приоритеты правильные, а система всё равно сыпется.

«Когда разработчик сам себе аналитик, он берёт на себя две роли:

Беклог и приоритеты не спасут, если у вас нет модели. Разработчик, который пишет себе ТЗ в голове и не рисует диаграммы, закладывает ошибки на этапе “ничего не сделано”. Тестирование лишь покажет, где эти ошибки взорвались. Моделирование — единственный шанс увидеть их до того, как они стали багами в коде.

«ТЗ может быть текстом. Но суть метода в том, что вы изначально моделируете, а не пишете текст и не ищете потом баги в коде. Ошибки находятся на этапе моделирования, а не на этапе тестирования готовой системы. Это и есть главная экономия.»