Архитектурный комитет: настраиваем работу с нуля. Часть 1. Definition of Ready, Definition of Done и статусная модель

⏳ 8 мин | 🟡🟡⚪️

Читать статью | Analyst IT

Салют! Сегодня затронем наболевшую тему многих системных аналитиков «Архитектура ПО для аналитика: зачем разбираться и как применять»

Меня часто спрашивают: «Зачем аналитику знать архитектуру ПО? Ведь это же задача архитекторов и разработчиков».
Отвечу просто: без понимания архитектуры вы будете писать требования вслепую, а это рисковать проектом.

Вот мой развернутый ответ на этот вовпрос:

1️⃣ Зачем аналитику разбираться в архитектуре?

- Говорить на одном языке с разработчиками – чтобы вас понимали, а ваши требования не казались «магией».
- Предвидеть ограничения – если знаешь, что система монолитная, не предложишь микросервисное решение без серьезной причины.
- Оценивать сложность изменений – иногда «простая кнопка» требует перелопачивания половины backend-логики.
- Архитектурно значимые требования – аналитик должен выявлять нефункциональные требования (масштабируемость, отказоустойчивость), иначе система развалится под нагрузкой.

2️⃣ Что нужно знать? (минимум для работы и понимания)

✅ Базовые стили архитектуры:
- Монолит vs Микросервисы – плюсы, минусы, где что применяется.
- Слоистая архитектура (Presentation-Business-Data) – чтобы понимать, в каком слое искать проблему.
- Event-Driven – если система работает на событиях (например, Kafka), аналитик должен уметь описывать сценарии.

✅ Паттерны проектирования:
- MVC, CQRS, Saga – не надо глубоко, но понимать, зачем они нужны, важно.
- Клиент-серверная vs Peer-to-Peer – влияет на требования к сети и безопасности.

✅ Интеграции:
- REST, GraphQL, gRPC – чтобы не путать синхронные и асинхронные API.
- Message Brokers (Kafka, RabbitMQ) – если система обрабатывает потоки данных.

✅ Базы данных:
- Реляционные (PostgreSQL) vs NoSQL (MongoDB) – от этого зависит, как писать требования к хранению данных.

3️⃣ С какими проблемами сталкивалась я?

🔹 Разработчики говорят: «Это невозможно» – а на деле просто сложно, потому что архитектура не позволяет. Если аналитик знает ограничения, он может предложить альтернативу.
🔹 Требования «висят в воздухе» – когда не понимаешь, куда в системе встроить функционал, получается «костыль».
🔹 Неучтенные нефункциональные требования – например, забыли про нагрузку, и система падает при 1000 пользователей.

4️⃣ Мои советы

🔸 Читайте документацию и схемы – если есть архитектурная диаграмма, изучите ее перед написанием требований.
🔸 Задавайте вопросы – «Как этот модуль общается с другим?», «Где будет храниться эти данные?».
🔸 Учитесь на реальных кейсах – разбирайте open-source проекты или спрашивайте у разработчиков, как устроены системы, с которыми работаете.
🔸 Пишите требования с учетом архитектуры – если знаете, что backend медленный, не обещайте пользователю мгновенный поиск.
____________________

Архитектура – это не страшно. Это просто еще один инструмент, который делает вас сильным аналитиком, а не просто «писателем ТЗ».

📎 Пару статей вам в помощь для понимания:

- Как системный аналитик влияет на проектирование архитектуры
- Как стать архитектором в ИТ
- Системный аналитик. Краткий гайд по профессии. Часть 3. Архитектура приложений и их масштабирование
- От требований к постановкам задач на разработку с помощью архитектурного проекта

Источник: @ba_and_sa