Выкрутим качество в абсолют и скажем, что идеальная система — это система, которой нет, но её функции выполняются.

1. Много кода хуже, чем мало кода.
2. Простой алгоритм лучше, чем сложный алгоритм.
3. Много пользы лучше, чем мало пользы.

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

И для того, чтобы перейти от (часто) субъективной оценки к конкретике применяются два понятия:

• SLI (Service Level Indicator) — численное значение важного для нас показателя
• SLO (Service Level Objective) — целевое значение показателя, к которому стремимся всеми силами

Как перейти от субъективных оценок к числам и метрикам прочитаешь в этом материале.

Как сформулировать критерии "качества"

Как и в концепции "Быстро-Дешево-Замечательно" можно выбрать только 2, так и в описании качества "Быстро-Стабильно-Функционально" в один момент времени не получится получить всё:

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

И чтобы всё-таки выйти за рамки "треугольника", можно на качество посмотреть со стороны "что если всё будет плохо" — рисков, наша недоступность/медленная/нефункциональная система может привести к:

1. (прямым) Финансовым потерям. Например, медленная работа регистрации уменьшает количество пользователей
2. Юридическим последствиям. Например, собираем больше персональных данных, чем декларируем.
3. Репутационным потерям. Например, так часто падаем, что конкурент решил от нас уйти.

И уже зная что значит "плохо", можно превратить это в числа. Например:

1. Доступность приложения меньше 99% времени в течение месяца — плохо
2. Скорость загрузки страниц больше 5 секунд — плохо
3. Невозможность выдержать "черную пятницу" (x5 к обычной нагрузке) — плохо

Основные концепции