Практикум системного анализа

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Аналитику Архитектору Руководителю Техническому писателю

Что уточнять при поступлении задачи?

1. Ценность и цель (Зачем?)

Без этого нельзя оценить приоритет и корректность решения.

Какую бизнес-проблему решает эта задача? Не «что сделать», а «почему это важно сейчас».
Какой измеримый результат ожидается? Метрика, KPI, критерий успеха. Если метрики нет — задача не верифицируема.
Что произойдёт, если задачу НЕ делать? Понимание стоимости бездействия помогает калибровать приоритет.
Кто конечный бенефициар? Конкретная роль/группа, не абстрактный «пользователь».
Соответствует ли задача текущим стратегическим целям проекта/продукта? Если нет — почему она появилась?

Стоп-сигнал: Если стейкхолдер не может ответить на «зачем» или отвечает «потому что я сказал» / «так принято» — задача требует эскалации или возврата на доработку. Не принимайте в работу.

2. Контекст и границы (Что именно?)

Определяет объём работы и предотвращает scope creep.

Каковы явные границы (In Scope)? Что конкретно входит в задачу.
Что явно исключено (Out of Scope)? Без этого границы размоются. Фиксируйте письменно.
Есть ли существующие решения/аналоги? Legacy-код, сторонние сервисы, предыдущие итерации. Не изобретайте велосипед.
Какие зависимости существуют? От других задач, команд, внешних систем, данных, регуляторики.
Есть ли временные ограничения? Дедлайн, окно запуска, сезонность. Откуда взялся дедлайн — обоснован или произволен?

3. Требования и критерии приёмки (Как проверить?)

Без этого задача не готова к разработке.

Сформулированы ли критерии приёмки? Конкретные, проверяемые условия. Если нет — уточните или верните задачу.
Описаны ли альтернативные сценарии и ошибки? Happy path — только 20% реальности. Что происходит при сбоях, пустых данных, нестандартных входах?
Есть ли нефункциональные требования? Производительность, безопасность, доступность, совместимость. Часто забываются, но определяют архитектуру.
Достаточна ли детализация для оценки? Если команда не может оценить задачу — требования неполны.
Верифицированы ли требования со стейкхолдерами? Устные договорённости ≠ требования.

4. Риски и ограничения (Что может пойти не так?)

Проактивное выявление проблем.

Какие технические риски вы видите? Неизвестные технологии, сложная интеграция, legacy-код без тестов.
Какие бизнес-риски существуют? Изменение регуляторики, зависимость от третьего лица, неопределённость требований.
Есть ли ограничения по ресурсам? Люди, инфраструктура, бюджет, лицензии.
Каковы последствия неудачи? Что сломается, если реализация будет некорректной? Это определяет уровень тестирования и ревью.

5. Организационные вопросы (Как работаем?)

Логистика выполнения.

Кто принимает результат? Конкретное лицо, не «команда» или «бизнес».
Каков формат сдачи? Демо, документация, код-ревью, UAT.
Есть ли доступы и среды? Dev/stage/prod, тестовые данные, учетные записи. Отсутствие доступов = блокировка.
Кому эскалировать проблемы? Если задача заблокирована или требования противоречивы.

Чек-лист готовности задачи к работе

Задача готова к принятию в спринт/работу, если:

Бизнес-цель ясна и измерима
Границы (In/Out of Scope) зафиксированы
Критерии приёмки определены и согласованы
Зависимости выявлены и управляемы
Команда может дать оценку (или задача помечена как spike)
Риски идентифицированы и есть план митигации
Принимающее лицо определено
Доступы и среды доступны

Если хотя бы один пункт не выполнен — задача не готова. Возвращайте на доработку или переводите в статус «Needs Refinement».

Техники уточнения

Ситуация	Техника
Стейкхолдер даёт решение, не проблему	5 Whys, «Что изменится, если это сделать?», «Как вы поймёте, что проблема решена?»
Требования расплывчаты («быстро», «удобно»)	Количественные критерии, бенчмарки, прототип для калибровки
Противоречивые требования от разных лиц	Совместная сессия, визуализация противоречий, эскалация на уровень выше
Задача слишком большая	Декомпозиция по User Story Mapping, выделение MVP, spike для исследования
Нет доступа к стейкхолдеру	Анализ документации/кода/тикетов, формулировка гипотез с пометкой «требуется подтверждение»
Стейкхолдер торопит, пропуская уточнения	«Если мы начнём без уточнения X, риск Y возрастёт на Z%. Вы принимаете этот риск?»

Антипаттерны при уточнении

«Потом разберёмся». Принятие задачи с надеждой, что детали прояснятся в процессе. Они не проясняются — они взрываются.
Уточнение ради уточнения. Бесконечные вопросы без цели. Определите timebox на уточнение. Если за время не получили ответов — принимайте решение на основе имеющейся информации с фиксацией рисков.
Принятие чужих предположений за факты. «Наверное, имеется в виду...» — всегда верифицируйте.
Уточнение только happy path. 80% багов живут в альтернативных сценариях. Всегда спрашивайте «А что если?».
Страх задать «глупый» вопрос. Лучше спросить сейчас, чем переделывать потом. Профессионализм — в полноте понимания, не в имидже всезнайки.
Устная договорённость без фиксации. Если не записано — не существует. Резюме встречи/переписки обязательно.

Адаптация под контекст

Контекст	Адаптация алгоритма
Agile / зрелая команда	Уточнение встроено в Refinement. Чек-лист используется как Definition of Ready. Многие вопросы уже покрыты DoR.
Waterfall / внешний заказчик	Формальный этап сбора требований. Уточнение документируется в протоколах. Изменения — через Change Request.
Поддержка / инциденты	Приоритет: воспроизведение + влияние. Бизнес-цель часто очевидна (восстановить работу). Уточнение фокусируется на симптомах и окружении.
Внутренний техдолг / рефакторинг	Бизнес-ценность формулируется через риски и стоимость поддержки. Критерии приёмки — метрики качества кода/системы.
Исследовательская задача (Spike)	Цель уточнения — определить, можно ли и сколько стоит. Результат — знание, не код. Timebox обязателен.

Как определять этапы выполнения задачи

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

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

Алгоритм декомпозиции задачи

Шаг 1: Верификация входа

Прежде чем делить, убедитесь, что задача понятна.

Критерии приёмки определены? Если нет — вернитесь к уточнению (см. предыдущий ответ).
Границы (In/Out of Scope) зафиксированы?
Зависимости выявлены?
Есть ли доступы, среды, документация?

Правило: Не декомпозируйте то, что не понимаете. Сначала — уточнение, потом — разбиение.

Шаг 2: Определение результата (Definition of Done для задачи)

Сформулируйте конечное состояние в проверяемых терминах. Не «сделать интеграцию», а:

API эндпоинт POST /orders принимает валидный JSON и возвращает 201.
Тесты покрытия > 80%.
Документация обновлена в OpenAPI spec.
Код прошёл ревью и смержен в main.

Конечное состояние — это ваш компас. Каждый этап должен приближать к нему.

Шаг 3: Декомпозиция сверху вниз

Разбивайте задачу на уровни, пока каждый элемент не станет оцениваемым и выполняемым за один фокус-блок (обычно 2–4 часа для разработки, 1–2 дня для анализа).

Уровни декомпозиции:

Фазы (высокоуровневые блоки): Исследование → Проектирование → Реализация → Верификация → Сдача.
Подзадачи (внутри фаз): Конкретные единицы работы с чётким результатом.
Шаги (внутри подзадач): Атомарные действия. Фиксируются только если подзадача сложная или исполнитель неопытен.

Критерий достаточной декомпозиции:

Каждый элемент можно оценить с точностью ±20%.
Прогресс по каждому элементу бинарен: сделано / не сделано (не «на 70%»).
Элемент имеет проверяемый результат (артефакт, тест, подтверждение).
Зависимости между элементами ясны.

Шаг 4: Выявление зависимостей и порядка

Не все этапы линейны. Определите:

Блокирующие зависимости: B нельзя начать, пока A не завершено (например, «спроектировать БД» → «написать миграцию»).
Параллелизуемые элементы: C и D могут идти одновременно после завершения A.
Внешние зависимости: Ожидание доступа, ответа от другой команды, поставки оборудования. Фиксируйте явно + план митигации при задержке.
Рисковые элементы: Неизвестные технологии, сложные интеграции. Ставьте их раньше, чтобы получить обратную связь быстро. Не оставляйте на конец.

Шаг 5: Визуализация и фиксация

Структура должна быть видна. Форматы:

Чек-лист с подзадачами (Jira, YouTrack, GitHub Issues) — для линейных задач.
Канбан-доска с колонками фаз — для визуализации потока.
Диаграмма Ганта / Dependency Graph — для задач с сложными зависимостями и параллелизмом.
User Story Map — для продуктовой разработки (горизонталь = пользовательский поток, вертикаль = приоритет).

Шаг 6: Верификация декомпозиции

Перед началом работы проверьте:

Все критерии приёмки исходной задачи покрыты этапами.
Нет «скрытых» этапов (документация, тесты, ревью, деплой часто забываются).
Оценка каждого элемента реалистична.
Рисковые элементы стоят рано.
Внешние зависимости имеют владельцев и сроки.
Команда согласна с декомпозицией (если задача командная).

Как понять, что делать дальше: Навигация в процессе

Декомпозиция — статический план. Реальность динамична. Используйте следующие правила навигации:

Правило 1: Следующий шаг = ближайший незавершённый элемент без блокировок

Не думайте о всей задаче. Смотрите только на текущий уровень декомпозиции. Какой элемент:

Не завершён?
Не заблокирован?
Имеет высший приоритет (рисковый / критический путь)?

Это ваш следующий шаг.

Правило 2: Ежедневная сверка с планом

В начале каждого рабочего блока (день / спринт):

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

Правило 3: Сигналы пересмотра декомпозиции

План нужно корректировать, если:

Обнаружена новая зависимость или требование.
Оценка элемента оказалась неверной (>2x отклонение).
Внешняя зависимость задерживается.
Изменились критерии приёмки.
Появилась новая информация, меняющая подход.

Не цепляйтесь за первоначальный план. Декомпозиция — гипотеза, а не контракт.

Правило 4: Завершение = верификация, не отметка

Этап завершён не когда вы «закончили делать», а когда результат проверен:

Код написан → тесты прошли → ревью получено → смержено.
Документ написан → отрецензирован → утверждён.
Интеграция настроена → smoke-тест пройден → подтверждено смежной командой.

Без верификации этап не закрыт.

Пример декомпозиции

Задача: Реализовать сохранение банковской карты при оплате (US-187 из предыдущего ответа).

Декомпозиция:

US-187: Сохранение банковской карты

├── 1. Исследование
│   ├── 1.1 Изучить API токенизации платёжного шлюза (документация + sandbox)
│   ├── 1.2 Проверить текущую модель UserPaymentMethod в БД
│   └── 1.3 Уточнить требования PCI DSS у security-офицера
│       → Результат: Техническое решение согласовано, риски идентифицированы
│
├── 2. Проектирование
│   ├── 2.1 Обновить ER-диаграмму (добавить таблицу payment_tokens)
│   ├── 2.2 Спроектировать API-контракт сохранения/удаления карт
│   └── 2.3 Написать sequence diagram взаимодействия со шлюзом
│       → Результат: Design Doc утверждён архитектором
│
├── 3. Реализация
│   ├── 3.1 Миграция БД: таблица payment_tokens
│   ├── 3.2 Сервис токенизации: интеграция со шлюзом
│   ├── 3.3 API: POST /users/{id}/payment-methods
│   ├── 3.4 API: DELETE /users/{id}/payment-methods/{token_id}
│   ├── 3.5 UI: чекбокс «Сохранить карту» + отображение сохранённых карт
│   └── 3.6 Обработка ошибок токенизации (AC4)
│       → Зависимости: 3.2 → 3.3, 3.4; 3.1 → 3.2; 3.5 зависит от 3.3
│
├── 4. Верификация
│   ├── 4.1 Unit-тесты сервиса токенизации (coverage > 80%)
│   ├── 4.2 Integration-тесты API (все AC)
│   ├── 4.3 E2E-тест: сохранение + повторная оплата
│   └── 4.4 Security-ревью (PCI DSS compliance)
│       → Результат: Все тесты зелёные, ревью пройдено
│
└── 5. Сдача
    ├── 5.1 Обновить OpenAPI spec
    ├── 5.2 Демо для PO
    └── 5.3 Deploy to staging + smoke-тест
        → Результат: US принята, готова к релизу

Типичные ошибки декомпозиции

Ошибка	Последствие	Решение
Слишком крупные этапы («Реализовать бэкенд»)	Невозможно оценить, прогресс непрозрачен	Дробить до оцениваемых единиц (2–4 ч)
Отсутствие верификации в этапах	«Сделано» ≠ «Работает»	Каждый этап включает проверку результата
Игнорирование нефункциональных этапов	Тесты, документация, ревью добавляются в конце и срывают сроки	Включать в декомпозицию изначально
Линейность там, где возможен параллелизм	Увеличение lead time	Выявлять независимые ветки, назначать разных исполнителей
Рисковые элементы в конце	Открытие проблем перед дедлайном	Ставить неизвестное первым (fail fast)
Декомпозиция без участия исполнителей	Нереалистичный план, отсутствие ownership	Декомпозиция — командная активность
Жёсткая привязка к плану	Игнорирование новой информации	Регулярный пересмотр, адаптация

Адаптация под тип задачи

Тип задачи	Особенности декомпозиции
CRUD / типовая разработка	Шаблонная декомпозиция (DB → Service → API → UI → Tests). Можно автоматизировать чек-листами.
Исследование / Spike	Декомпозиция по вопросам, на которые нужно ответить. Timebox обязателен. Результат — знание, не код.
Инфраструктура / DevOps	Декомпозиция по слоям (сеть → compute → storage → config → monitoring). Idempotency и rollback-план как обязательные этапы.
Миграция / Рефакторинг	Декомпозиция по стратегиям (Strangler Fig, Branch by Abstraction). Параллельная работа старого и нового. Верификация эквивалентности на каждом шаге.
Аналитика / Дизайн	Декомпозиция по артефактам (BRD → Process Model → Prototype → SRS). Ревью каждого артефакта как gate.
Инцидент / Багфикс	Декомпозиция: Воспроизведение → Локализация → Root Cause → Fix → Regression Test → Postmortem. Не пропускайте Root Cause.

Как проектировать архитектуру решения

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

Универсальный алгоритм проектирования архитектуры

1. Сбор архитектурно-значимых требований

Не все требования влияют на архитектуру. Фокусируйтесь на:

Функциональные: ключевые бизнес-процессы, интеграции, доменные сущности.
Нефункциональные (Quality Attributes): производительность, масштабируемость, доступность, безопасность, сопровождаемость, отказоустойчивость. Именно они определяют архитектурные решения.
Ограничения: бюджет, команда (размер, компетенции), сроки, регуляторика, существующая инфраструктура, стек.
Риски: что может убить проект? Неопределённость в требованиях, новая технология, сложная интеграция.

Инструмент: ATAM (Architecture Tradeoff Analysis Method) или упрощённый workshop по выявлению QA-сценариев. Результат: приоритизированный список атрибутов качества с конкретными метриками.

2. Определение доменной модели

Архитектура должна отражать бизнес, а не технологию.

Выделите ограниченные контексты (Bounded Contexts) по DDD. Каждый контекст = отдельная модель, свои правила, свой язык.
Определите агрегаты и границы транзакций.
Зафиксируйте доменные события — они станут основой интеграции между контекстами.

Результат: Context Map + модель агрегатов. Это фундамент, независимый от платформы.

3. Выбор архитектурного стиля

Стиль определяется требованиями, не модой.

Стиль	Когда уместен	Когда НЕ уместен
Монолит (Modular)	MVP, маленькая команда, простые интеграции, строгие транзакции	Высокая нагрузка, независимый деплой команд, гетерогенный стек
Микросервисы	Независимый скейлинг/деплой, большие команды, полиглотность	Маленькая команда, строгие распределённые транзакции, нет DevOps-зрелости
Event-Driven	Асинхронная интеграция, высокая пропускная способность, слабая связанность	Простые CRUD-системы, строгая консистентность, команда не знает event-sourcing
CQRS	Разделение read/write нагрузок, сложные запросы, audit log	Простые CRUD, команда не готова к eventual consistency
Serverless	Переменная нагрузка, event-driven, минимальная операционная нагрузка	Долгие процессы, холодный старт критичен, vendor lock-in недопустим
Hexagonal / Clean / Onion	Сложная бизнес-логика, тестируемость, независимость от инфраструктуры	Простые CRUD, прототипы, команда не знакома с паттерном

Правило: Начинайте с простейшего стиля, который удовлетворяет требованиям. Усложняйте только при наличии доказанной необходимости. Premature distribution — корень зла.

4. Принятие ключевых технических решений

Для каждого решения зафиксируйте: контекст → варианты → trade-offs → выбор → обоснование.

Типичные решения:

Синхронная vs асинхронная коммуникация
База данных (SQL/NoSQL/NewSQL) и стратегия шардирования
Аутентификация/авторизация (OAuth2, OIDC, RBAC/ABAC)
Кэширование (стратегия, инвалидация)
Observability (логи, метрики, трейсы)
CI/CD pipeline и стратегия деплоя
Управление конфигурацией и секретами

Инструмент: ADR (Architecture Decision Records). Каждое значимое решение = один ADR. Это память проекта.

5. Валидация архитектуры

До написания кода проверьте:

Proof of Concept / Spike: для рисковых решений. Timebox обязателен.
Архитектурное ревью: с участием senior-разработчиков, архитекторов, DevOps. Чек-лист: покрытие QA-требований, соответствие стилю, отсутствие single point of failure.
Load Testing / Chaos Engineering: для проверки нефункциональных требований. Не верьте оценкам на бумаге.
Compliance Check: регуляторика, безопасность, стандарты компании.

6. Документирование и коммуникация

Архитектура существует только если она понята командой.

C4 Model: Context → Container → Component → Code. Четыре уровня абстракции для разных аудиторий.
ADR: история решений.
Живые диаграммы: Mermaid, PlantUML, Structurizr. Код как источник истины, не Visio-файлы.
Onboarding-документ: новый разработчик должен понять архитектуру за день.