Как оценивать свои архитектурные услуги

Оценивать свои архитектурные услуги стоит как продукт: фиксируйте границы работ, проверяйте качество решений по артефактам, измеряйте результат метриками, а цену обосновывайте экономическим эффектом и рисками. Практичный подход - единая чек‑линия: что проверяем, где доказательство, какой вывод (да/нет) и какой комментарий для улучшения.

Контрольная карта оценки архитектурных услуг

• Зафиксированы границы услуги: входы/выходы, допущения, исключения, ответственность сторон.
• Качество подтверждено артефактами: ADR, модели, схемы, требования, трассировка решений.
• Есть измеримые критерии приемки: KPI, пороги, метод измерения и периодичность.
• Проверка документации выполнена по чек‑листу: полнота, согласованность, реализуемость, безопасность.
• Цена/ценность обоснованы: эффект, затраты, риски, план снижения неопределенности.
• Запущен цикл обратной связи: замечания → правки → повторная оценка → фиксация изменений.

Определение объема и границ услуг

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

Проверить	Да	Нет	Комментарий
Определен тип услуги (консалтинг/ревью/целевое проектирование/сопровождение реализации)	Да	Нет	Если смешано - разделите на пакеты и отдельные результаты
Сформулированы входы (BRD/PRD, ограничения, текущая архитектура, нефункциональные требования)	Да	Нет	Если входов нет - сначала этап discovery (таймбокс)
Согласованы выходы (набор артефактов, решения, варианты, рекомендации, план миграции)	Да	Нет	Выходы должны быть проверяемыми и перечисленными
Прописаны исключения (что не делаете) и зависимости (кто предоставляет данные, доступы)	Да	Нет	Уменьшает спорные зоны и "ползущий" объем
Определены точки приемки (кто принимает, по каким критериям, как фиксируются правки)	Да	Нет	Без приемки оценка превращается в субъективное мнение

Критерии качества архитектурных решений

Чтобы оценка была защищаемой, нужны: единые критерии качества, доступ к контексту (люди/системы/ограничения), и эталонный формат артефактов. Минимум инструментов - репозиторий документации (Confluence/Docs), диаграммы (PlantUML/Mermaid/Draw.io), трекинг задач, и место для ADR (вики или git).

Проверить	Да	Нет	Комментарий
Есть нефункциональные требования (SLA/SLO, безопасность, масштабирование, соответствие регуляторике)	Да	Нет	Если нет - зафиксируйте хотя бы приоритеты и допущения
Доступ к текущему ландшафту (контуры, интеграции, зависимости, ограничения платформы)	Да	Нет	Иначе оценка будет на уровне абстракций и рисков
Определен формат решений (ADR, архитектурный обзор, диаграммы контекста/контейнеров/компонентов)	Да	Нет	Единый формат = сравнимость между проектами
Есть процедура ревью (кто рецензирует, как фиксируются замечания, сроки реакции)	Да	Нет	Без ревью качество деградирует до "вкусовщины"
Определены критерии реализуемости (стек, компетенции команды, ограничения времени/бюджета)	Да	Нет	Оценивайте не только идеальность, но и внедряемость

Метрики и KPI для объективной оценки

Мини-чеклист подготовки перед расчетом метрик

• Зафиксируйте цель оценки: контроль качества, обоснование стоимости или сравнение вариантов.
• Согласуйте период измерения (например: на релиз/квартал) и источник данных (мониторинг, трекер, постмортемы).
• Определите, кто владеет метриками и кто подтверждает результаты (заказчик/тимлид/владелец сервиса).
• Уберите спорные слова из критериев ("удобно", "оптимально") и замените на измеримые условия.
• Заранее запланируйте, как будете трактовать "неизмеримое" (например, экспертная шкала 1-5 с примерами).

1. Сформируйте карту результата: что именно вы продаете

   Переведите услугу в проверяемые результаты: артефакты + решения + ограничения + план внедрения. Для каждого результата укажите владельца и критерий приемки.

   • Пример: "ADR на ключевые решения" + "диаграмма интеграций" + "план миграции".
2. Выберите 5-9 метрик, иначе ими перестанут пользоваться

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

   • Если данных мало - используйте шкалы 1-5 с якорями (что значит 1, 3, 5).
3. Задайте пороги и правила интерпретации

   Без порогов метрики не работают как критерий приемки. Там, где нельзя честно поставить число, фиксируйте правило "красный/желтый/зеленый" и что делать в каждом случае.

   • Пример расчета: итоговый балл = 0,5×качество решения + 0,3×реализуемость + 0,2×риск‑контроль (все по 1-5).
4. Привяжите метрики к артефактам и источникам данных

   Каждая метрика должна иметь ссылку на доказательство: документ, репозиторий, дашборд, протокол ревью. Это снижает спорность оценки.

5. Проведите пилот на одном кейсе и уточните формулировки

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

6. Зафиксируйте регулярность пересмотра и контроль изменений

   Определите, когда метрики пересматриваются (например, после крупных релизов или смены контекста), и где хранится история изменений (версионирование).

Проверить	Да	Нет	Комментарий
Для каждой метрики определены: владелец, источник данных, период, порог, действие при отклонении	Да	Нет	Без действия метрика превращается в "наблюдение ради наблюдения"
Метрики разделены на: качество / процесс / эффект (не все в одну корзину)	Да	Нет	Так проще объяснять заказчику и команде
Есть правило, как оценивать при недостатке данных (шкала 1-5 с примерами)	Да	Нет	Укажите якоря, иначе оценки будут "по настроению"
Порогов не слишком много и они реалистичны для контекста команды	Да	Нет	Слишком жесткие пороги демотивируют и провоцируют "подгонку"

Пошаговая проверка проектной документации

Проверить	Да	Нет	Комментарий
Контекст описан: границы системы, пользователи/актеры, внешние зависимости, что вне scope	Да	Нет	Если нет - начните с диаграммы контекста и словаря терминов
Есть список ключевых сценариев (use cases) и они трассируются к компонентам/интеграциям	Да	Нет	Иначе архитектура не проверяется на реальных потоках
Решения задокументированы как ADR: проблема, варианты, выбранное решение, последствия	Да	Нет	Без ADR спорные решения будут пересматриваться бесконечно
НФТ учтены в дизайне (безопасность, отказоустойчивость, производительность, наблюдаемость)	Да	Нет	Добавьте явные разделы и критерии приемки по НФТ
Есть интеграционная схема: протоколы, форматы, контракты, версии, обработка ошибок	Да	Нет	Проверьте идемпотентность и стратегии ретраев/таймаутов
Определены данные: источники истины, модели, миграции, владение, политики хранения	Да	Нет	Особо отметьте персональные/секретные данные и доступы
Есть план внедрения: этапы, критерии готовности, обратная совместимость, откат	Да	Нет	Без плана внедрения "хорошая" архитектура часто не доезжает в прод
Риски и допущения перечислены и имеют владельцев (кто снижает риск, к какому сроку)	Да	Нет	Риск без владельца = риск без управления

Оценка экономической эффективности и рисков

• Смешивание стоимости услуги и стоимости реализации. Проверить: ваша оценка включает только архитектурную работу или также разработку/инфраструктуру; комментарий: разделяйте сметы по уровням.
• Обещание эффекта без механизма. Проверить: указан путь "решение → изменение процесса/системы → эффект"; комментарий: эффект без причинно-следственной цепочки не защищается.
• Игнорирование эксплуатационных затрат. Проверить: кто и как будет поддерживать решение (on-call, мониторинг, обновления); комментарий: фиксируйте предпосылки по SRE/DevOps.
• Недооценка цены изменений (change cost). Проверить: есть оценка миграций, обратной совместимости, обучения, документации; комментарий: добавляйте отдельный пункт "стоимость перехода".
• Риски перечислены, но не управляются. Проверить: у каждого риска есть вероятность/влияние (хотя бы низк/средн/высок) и план снижения; комментарий: без плана риск не участвует в решении.
• Подмена критериев: "модные технологии" вместо требований. Проверить: технология выбрана по ограничениям и НФТ; комментарий: требуйте явные причины и последствия в ADR.
• Оценка "в среднем по больнице" без учета зрелости команды. Проверить: учтены компетенции, наличие практик тестирования/релизов/наблюдаемости; комментарий: реализуемость - обязательная часть оценки.

Проверить	Да	Нет	Комментарий
Есть простая модель ценности (например, 3-5 драйверов: скорость поставки, стабильность, безопасность, стоимость владения)	Да	Нет	Если сложно - оцените драйверы по шкале 1-5 с примерами
Риски оформлены как реестр: описание, триггер, вероятность/влияние, владелец, мера снижения	Да	Нет	Минимум: владелец + мера снижения + дата проверки

Процесс обратной связи и пересмотра оценки

• Архитектурное ревью коллегами (peer review). Уместно, когда нужна калибровка качества и снижение субъективности; проверка/да/нет/комментарий фиксируются в протоколе ревью.
• Вариантная оценка (2-3 альтернативы) с матрицей компромиссов. Уместно при выборе платформы/подхода; сравнивайте по одинаковым критериям и фиксируйте, почему победил вариант.
• Таймбокс discovery вместо "большого проектирования". Уместно при высокой неопределенности входных данных; результат - уточненные требования, риски, план следующего шага и обновленная оценка.
• Повторная оценка после изменения контекста (scope change). Уместно при новых ограничениях, смене целей, архитектурных инцидентах; пересчет должен ссылаться на изменившиеся предпосылки.

Проверить	Да	Нет	Комментарий
Есть единый канал и формат обратной связи (шаблон замечаний: что/почему/предложение/приоритет)	Да	Нет	Без формата замечания превращаются в чат и теряются
Изменения в оценке фиксируются версионированием (v1, v2...) и объяснением причин	Да	Нет	Это защищает вас при "ползущем" объеме

Типичные сомнения и краткие профессиональные ответы

Можно ли оценивать архитектурные услуги без точных чисел?

Да: используйте шкалы 1-5 с якорями и обязательные доказательства (ссылки на артефакты). Главное - единые правила интерпретации и повторяемость оценки.

Что делать, если заказчик не дает доступ к текущей архитектуре и данным?

Ограничьте выводы, зафиксируйте риски и предложите короткий discovery‑этап с перечнем нужных доступов. Без контекста корректнее продавать не "решение", а "уточнение требований и вариантов".

Как защититься от расширения объема работ без доплаты?

Пропишите входы/выходы и исключения, а изменения оформляйте как scope change с пересчетом. Версионируйте документы и фиксируйте, какие предпосылки изменились.

Сколько артефактов достаточно, чтобы оценка выглядела профессионально?

Достаточно минимального набора, который покрывает контекст, ключевые решения и план внедрения. Если артефакт не участвует в принятии решения или приемке, его лучше не делать.

Как сравнивать два архитектурных варианта честно?

Сравнивайте по одинаковым критериям (НФТ, реализуемость, риски, стоимость изменения) и фиксируйте компромиссы. Итог должен ссылаться на требования и последствия, а не на предпочтения.

Нужно ли включать безопасность в оценку, если "есть отдельные безопасники"?

Да, хотя бы на уровне требований и архитектурных решений: границы доверия, данные, доступы, журналирование. Иначе вы оцениваете неполный продукт и переносите риск на внедрение.