Оценка проектов технических решений (или Technical Solution Assessment / Design Review) — это процесс анализа и экспертизы предлагаемой архитектуры, кода или инфраструктурных изменений до того, как они будут реализованы и внедрены в промышленную среду.

Простыми словами: это взгляд со стороны на то, КАК команда разработки планирует решить задачу, описанную в требованиях.

Почему это важно делать?

Если этого не делать, команда рискует получить систему, которая:

1. Будет тормозить (не выдержит нагрузки).

2. Будет ломаться (слабые места в архитектуре).

3. Будет дорогой (неоптимальное использование ресурсов облака или серверов).

4. Не будет соответствовать ожиданиям бизнеса (техническое решение не покрывает все сценарии использования). 

Зачем это делать системному аналитику?

Многие ошибочно полагают, что оценка техрешений — это зона ответственности только тимлида или архитектора. Однако участие аналитика в этом процессе критически важно.

Вот основные причины:

1. Проверка соответствия требованиям (Traceability)

Разработчики могут предложить элегантное техническое решение, которое, однако, решает задачу лишь на 80%. Например, они могут автоматизировать только «стандартные» случаи, оставив «сложные 20%» на ручную обработку, о чем «забудут» сказать.
Задача аналитика: Проверить, покрывает ли предлагаемая техническая реализация все функциональные требования и пользовательские сценарии (включая исключительные ситуации), которые были задокументированы.

2. Обнаружение скрытых допущений

В технических решениях часто присутствуют разделы «Допущения» (Assumptions). Например: «Мы предполагаем, что справочник данных будет обновляться не чаще раза в месяц».

Задача аналитика: Если бизнес планирует обновлять справочник ежедневно, на этапе оценки это нужно заметить. Аналитик видит риск несоответствия бизнес-ожиданий и технических допущений.

3. Анализ влияния на пользовательский опыт (UX)

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

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

4. Полнота сценариев ошибок и исключений

Техническое проектирование часто фокусируется на «счастливом пути» (Happy Path). Аналитик же мыслит исключительными ситуациями.

Задача аналитика: Задать вопрос: «Что будет, если сервис оплаты упадет в момент подтверждения заказа? Какое сообщение увидит пользователь? Будет ли у него инструкция, что делать?» Без аналитика разработчик может просто уронить приложение с ошибкой 500, что неприемлемо для бизнеса.

5. Целостность данных и бизнес-логика

Аналитик лучше всех понимает предметную область и правила вычисления показателей.

Задача аналитика: Проверить, правильно ли в техническом решении заложена бизнес-логика. Например, если по требованиям «скидка не суммируется с другими акциями», аналитик должен убедиться, что в проекте БД или коде это правило учтено, а не просто написано «скидка = сумма корзины * 0.9».

6. Нетехнические риски (Legal & Compliance)

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

Задача аналитика: Выявить такие риски на берегу, так как он держит в голове контекст регулирования отрасли.

Вывод:

Для системного аналитика оценка технических решений — это мостик между миром «как надо» (требования) и миром «как сделаем» (реализация).

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

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

Рассмотрим один из вариантов выполнения оценки: 

1. Определить критерии оценки

Перед оценкой необходимо зафиксировать ключевые критерии:

• Функциональность (соответствие требованиям заказчика);
• Техническая реализуемость (возможность внедрения с учетом технологий и ресурсов);
• Сроки и трудоемкость (оценка времени и усилий на реализацию);
• Бюджет (стоимость разработки, лицензий, инфраструктуры);
• Риски (технические, организационные, compliance);
• Масштабируемость и поддержка (возможность развития системы);
• Безопасность (соответствие стандартам защиты данных).

2. Выбрать метод для оценки

2.1. Метод-1: Сравнительный анализ альтернатив

• Составляется матрица решений, где сравниваются несколько вариантов по заданным критериям.
• Используются взвешенные оценки (каждому критерию присваивается вес).

Пример:

2.2. Метод-2: Оценка трудозатрат (Estimation)

• Аналогии – сравнение с похожими проектами.
• Экспертные оценки – опрос разработчиков и архитекторов.
• Декомпозиция – разбиение на задачи и оценка каждой.

2.3. Метод-3: Анализ рисков

• SWOT-анализ (сильные/слабые стороны, угрозы, возможности).
• FMEA (Failure Mode and Effects Analysis) – оценка отказов и их влияния.
• Матрица вероятности/влияния (риски ранжируются по уровню критичности).

2.4. Метод-4: Оценка экономической эффективности (ROI, TCO)

• ROI (Return on Investment) – расчет окупаемости.
• TCO (Total Cost of Ownership) – полная стоимость владения (разработка + поддержка + лицензии).

3. Задокументировать оценку

Результаты оформляются в виде отчета или презентации, включающей:

• Краткое описание проекта и целей;
• Анализ альтернатив и обоснование выбора;
• Оценку трудозатрат, бюджета и сроков;
• Риски и способы их минимизации;
• Рекомендации по реализации.

4. Инструменты для оценки

• JIRA, Confluence – для учета трудозатрат и документации.
• Excel, Notion, Miro – для сравнительных таблиц и матриц.
• Visio, Lucidchart – для архитектурных диаграмм.
• COCOMO, Function Points – для оценки сложности.

Вывод:

Оценка ПТР требует комплексного подхода: анализ требований, сравнение вариантов, расчет экономики и рисков. Главное – обосновать выбор решения перед заказчиком и командой.