Сравнение популярных CMS: WordPress, Joomla и Drupal в контексте цифровой трансформации — это уже не спор «что удобнее для сайта», а выбор операционной платформы для контента, данных и клиентского опыта. В 2026 году контент должен быстро попадать в омниканальные воронки, поддерживать персонализацию, интегрироваться с CRM/ERP и выдерживать требования к безопасности и соответствию регуляторике.
Проблема в том, что у каждой CMS разная «сила тяжести»: WordPress выигрывает экосистемой и скоростью запуска, Joomla — балансом админки и гибкости, Drupal — архитектурой для сложных, интегрированных и регулируемых сред. Ниже — практическое, точное сравнение, ориентированное на лидеров цифровой трансформации, IT и маркетинг.
Key Takeaways
- Для цифровой трансформации важнее не «удобство CMS», а архитектура: интеграции, модель контента, безопасность, жизненный цикл и TCO.
- WordPress оптимален для быстрого time‑to‑market и контент‑маркетинга, но требует дисциплины в плагинах, обновлениях и безопасности.
- Drupal чаще выигрывает в сложных интеграциях, комплаенсе, мультисайтах и структурированном контенте — ценой более высокой инженерной сложности.
- Joomla — прагматичный компромисс для организаций, которым нужна сильная админка «из коробки» и предсказуемая кастомизация без избыточной сложности.
- Лучший выбор — тот, который поддерживает ваш целевой цифровой продукт, процессы поставки (DevOps) и дорожную карту данных на 18–36 месяцев.
Почему выбор CMS — это решение по цифровой трансформации, а не «про сайт»?
В цифровой трансформации CMS становится центром управления контентом, интеграций и клиентского опыта: она влияет на скорость экспериментов, качество данных и безопасность. WordPress, Joomla и Drupal могут решать похожие задачи, но по‑разному поддерживают масштабирование, интеграционные паттерны и управление изменениями. Поэтому сравнение нужно вести через бизнес‑сценарии и архитектуру.
Если раньше CMS выбирали по шаблонам и «красоте админки», то теперь — по способности быть частью цифрового контура: CRM, CDP, PIM, DAM, аналитика, маркетинговая автоматизация, SSO и CI/CD. Важно, как CMS хранит структуру контента, насколько она дружит с API и как переживает постоянные релизы. Это напрямую влияет на KPI: скорость вывода кампаний, конверсию, стабильность и стоимость владения.
Практический ориентир: если ваш сайт — это витрина, требования одни; если это «фронт» к продукту, партнерскому порталу или личному кабинету — требования другие. В таких случаях CMS становится частью платформенной стратегии, и тут полезно заранее договориться о принципах разработки и поставки — например, через подходы Agile для привязки разработки к бизнес-целям.
Насколько популярны WordPress, Joomla и Drupal — и почему это важно для рисков?
Популярность влияет на доступность специалистов, зрелость экосистемы и скорость реакции сообщества на уязвимости, но не гарантирует «лучшую безопасность». По данным книги WordPress, в 2019 году WordPress обеспечивал 43% веб‑сайтов, тогда как Joomla — 2,9%, а Drupal — 1,9% (источник). Для трансформации это означает разные профили кадровых и операционных рисков.
Большая доля WordPress обычно означает широкий рынок плагинов, тем и подрядчиков — и одновременно более «шумную» поверхность атаки из‑за массовости и неоднородного качества расширений. Drupal и Joomla реже встречаются в малом бизнесе, но часто выбираются организациями, где важны управляемость, структура и предсказуемость. В результате «популярность» нужно трактовать как фактор стратегии найма, поддержки и контроля качества.
Важно не смешивать два разных показателя: долю всех сайтов и долю сайтов, которые используют CMS. В материале Joomla отмечается, что Joomla используется на 2,6% всех веб‑сайтов с системами управления контентом, что составляет 1,8% от всех веб‑сайтов (источник). Эти цифры полезны не для «соревнования», а для оценки доступности компетенций и зрелости рынка.
Какая CMS лучше для B2B и корпоративных сценариев в 2026?
Для B2B в 2026 нет универсального победителя: WordPress чаще выигрывает в контент‑маркетинге и быстрых запусках, Drupal — в сложной структуре контента, интеграциях и комплаенсе, Joomla — в сбалансированных корпоративных сайтах и порталах со зрелой админкой. Правильный выбор зависит от модели данных, регуляторики и требуемой скорости изменений.
B2B‑команды обычно живут в режиме «параллельных потоков»: маркетинг запускает кампании, продукт развивает кабинет/портал, IT управляет интеграциями и безопасностью. Поэтому CMS должна поддерживать ролевую модель, редакционные процессы, версионирование, интеграции и надежный выпуск изменений. На практике выигрывает та платформа, где вы можете стандартизировать контент‑модель и интеграционные контракты.
- Если KPI — скорость публикаций, SEO и контент‑воронки: чаще подходит WordPress (при строгой политике плагинов).
- Если KPI — единая платформа для порталов, мультисайтов и сложных сущностей: чаще подходит Drupal.
- Если KPI — «корпоративный сайт + разделы/портальные функции» без тяжелой инженерии: часто разумен Joomla.
- Если KPI — интеграции и данные: выбирайте CMS после проектирования API и модели контента, а не наоборот.
Чтобы не выбирать «в вакууме», полезно сначала зафиксировать целевой стек и принципы разработки: где будет бизнес‑логика, что уйдет в микросервисы, как будет устроена аналитика. В качестве опоры смотрите как выбрать стек технологий для B2B‑разработки в 2026 — это помогает сформулировать требования к CMS как к компоненту платформы.
WordPress в цифровой трансформации: сильные стороны и ограничения
WordPress — сильный выбор, когда важны скорость запуска, богатая экосистема и удобство для редакторов, а архитектура допускает «плагинный» подход. В цифровой трансформации он хорошо работает как контент‑хаб для маркетинга и коммуникаций. Ограничения проявляются при росте сложности: интеграции, строгий комплаенс и контроль качества расширений требуют зрелых процессов.
Экосистема и time‑to‑market
WordPress часто выбирают за быстрый time‑to‑market: типовые страницы, редакторские сценарии, большое количество готовых решений. Это удобно для команд, где маркетинг и контент‑операции должны выпускать изменения ежедневно. Но скорость «из коробки» нужно подкреплять правилами: стандарты тем, контроль зависимостей, тестирование и регулярные обновления.
Интеграции: от форм до корпоративных API
В трансформации WordPress часто выступает фронтом для лидогенерации и контентных воронок, а данные уходят в CRM и аналитику. Технически интеграции можно строить через плагины, вебхуки и собственные сервисы, но важно избегать «комка» из десятков расширений. Лучше выделять интеграционный слой и фиксировать контракты API, чтобы смена CRM или CDP не ломала редакционные процессы.
Безопасность и управление обновлениями
Ключевой риск WordPress — не сама платформа, а качество и актуальность плагинов/тем, а также дисциплина обновлений. В корпоративном контуре нужны: отдельные среды, автоматизированные проверки, контроль прав и журналирование. Если у вас повышенные требования, заранее планируйте модель поставки: кто отвечает за патчи, как быстро вы обновляете зависимости и как тестируете обратную совместимость.
Joomla в цифровой трансформации: когда это рациональный компромисс
Joomla часто оказывается сильным компромиссом между удобной админкой, гибкой структурой сайта и предсказуемой кастомизацией без чрезмерной сложности. В цифровой трансформации она подходит организациям, которым нужен управляемый корпоративный сайт/портал с понятными ролями и контент‑типами. Ее выбор особенно оправдан, когда вы хотите избежать «переплаты» за избыточную архитектуру.
Админка, роли и редакционные процессы
Для многих команд ценность Joomla — в практичной админке и управлении контентом «без сюрпризов». В корпоративных сценариях это снижает зависимость от разработчиков: редакторы могут работать в пределах заданной структуры. Важно заранее описать контент‑модель, роли и согласования, чтобы CMS поддерживала процесс, а не заменяла его хаотичными правками.
Экосистема и устойчивость сообщества
Joomla остается заметным игроком: в материале к 18‑летию сообщества отмечается ее доля среди сайтов на CMS и доля среди всех сайтов (источник). Для корпоративного заказчика это означает: есть рынок расширений и специалистов, но часто важнее другое — насколько вы можете стандартизировать разработку и поддержку у одного или нескольких надежных подрядчиков.
Сигналы зрелости: безопасность и признание
Показательно, что Joomla участвовала в совместной работе четырех крупных CMS (Drupal, Joomla, Typo3 и WordPress) вокруг Закона ЕС о киберустойчивости (источник). Это не «гарантия безопасности», но важный сигнал: экосистема вовлечена в обсуждение требований к киберустойчивости и ответственности поставщиков ПО.
Также сообщество отмечало признание на отраслевых наградах: 2 марта Joomla получила награду «Лучшая бесплатная CMS» на CMS Critics Awards (источник). Для бизнеса это скорее индикатор живости проекта и сообщества, чем критерий выбора, но в сумме такие сигналы снижают риск «платформы без будущего».
Drupal в цифровой трансформации: платформа для сложных систем и комплаенса
Drupal чаще выбирают, когда требуется сложная структура контента, масштабирование, строгие роли, много интеграций и долгий жизненный цикл. В цифровой трансформации он хорошо подходит как основа для композитной архитектуры и корпоративных порталов. Цена — более высокий порог входа и необходимость зрелой инженерной практики.
Почему Drupal «про архитектуру»
Drupal исторически силен там, где контент — это не страницы, а набор сущностей, связей и правил доступа. Это удобно для организаций с несколькими брендами, регионами, языками и разными аудиториями. В таких задачах выигрывает способность платформы поддерживать сложную модель данных и управлять ею без постоянных обходных решений.
Drupal 10 и миграции как часть трансформации
Drupal 10 был выпущен 14 декабря 2022 года и позиционируется как версия с новыми технологиями и улучшениями скорости и безопасности (источник). Для бизнеса важен вывод: миграции между мажорными версиями нужно планировать как программу изменений, а не как «технический долг на потом». В трансформации это связывается с дорожной картой функций, интеграций и комплаенса.
Интеграции, мультисайты и управление доступом
Drupal часто оправдан, когда у вас мультисайт‑ландшафт, сложные права доступа, партнерские зоны и контент, который должен переиспользоваться между каналами. Здесь критичны workflow, модерация и аудит изменений. В таких сценариях платформа становится «контентным ядром» и снижает хаос, который возникает при попытке решить те же задачи набором разрозненных плагинов.
Сравнение по ключевым критериям цифровой трансформации (таблица)
Если сравнивать CMS через призму цифровой трансформации, нужно смотреть на управляемость, интеграции, безопасность, редакционные процессы и TCO. Ниже — практическая таблица, которая помогает провести первичную оценку без мифов. Итог почти всегда зависит от того, что вы считаете «ядром»: контент, данные, процессы или продукт.
Таблица сравнения (обобщенная): 1) Time‑to‑market: WordPress — высокий, Joomla — высокий/средний, Drupal — средний. 2) Сложная модель контента: WordPress — средняя (часто через плагины), Joomla — средняя/высокая, Drupal — высокая. 3) Интеграции на уровне предприятия: WordPress — средняя, Joomla — средняя, Drupal — высокая. 4) Управление доступом и workflow: WordPress — среднее, Joomla — высокое, Drupal — высокое. 5) Риск «плагинной энтропии»: WordPress — высокий без governance, Joomla — средний, Drupal — ниже при правильной архитектуре.
Headless, composable и API-first: какую CMS выбрать под современную архитектуру?
Для headless и composable подходов важны API‑контракты, структурированный контент и дисциплина интеграций. Drupal чаще удобнее как «контентный бэкенд» для нескольких фронтендов, WordPress может быть headless, но требует аккуратного проектирования и контроля расширений, а Joomla подходит для гибридных сценариев, где часть сайта остается традиционной.
Когда headless действительно нужен
Headless имеет смысл, когда один и тот же контент должен питать сайт, мобильное приложение, партнерский портал, email‑шаблоны и внутренние витрины. Также он полезен, если вы хотите независимо развивать фронтенд (например, на React/Vue) и редакционную часть. Но если у вас один сайт и простая структура, headless может увеличить стоимость и сроки без пропорциональной выгоды.
Composable: разнести ответственность по сервисам
Composable‑подход обычно означает: CMS отвечает за контент и редакционные процессы, PIM — за продуктовые данные, DAM — за медиа, а поиск и персонализация — отдельные сервисы. Тогда CMS выбирают по способности быть хорошим «гражданином» интеграционной архитектуры: стабильные API, события, очереди, логирование. Это напрямую связано с тем, как вы строите интеграции — иногда стоит подключать услуги по системной интеграции, чтобы не превратить CMS в монолит.
Практика: контрактно-ориентированные API
Независимо от CMS, в 2026 выигрывают команды, которые фиксируют API‑контракты (схемы, версии, SLA) и тестируют интеграции как продукт. Это снижает риск, что обновление модуля или плагина «сломает лиды» или аналитические события. Хорошая практика — описывать контент‑сущности как доменную модель и уже затем отображать их в CMS.
Безопасность и соответствие: что реально важно для бизнеса?
Безопасность CMS в трансформации — это сочетание платформы, расширений, хостинга и процессов: управление уязвимостями, обновления, права доступа, аудит и резервное восстановление. Ни WordPress, ни Joomla, ни Drupal не «защищают сами по себе», если нет governance. Выбор CMS должен учитывать ваши требования к комплаенсу и операционной зрелости.
Киберустойчивость как тренд (и почему это не только про ЕС)
Показательно, что четыре основные CMS (Drupal, Joomla, Typo3 и WordPress) объединились для совместной работы над Законом ЕС о киберустойчивости (источник). Для компаний вне ЕС это тоже сигнал: требования к управлению рисками цепочки поставок ПО и ответственности поставщиков будут усиливаться. Поэтому важны SBOM‑подходы, контроль зависимостей и прозрачные процессы обновлений.
Практический минимум: политика обновлений и доступов
- Ввести политику обновлений: окна релизов, приоритеты безопасности, критерии отката.
- Разделить среды: dev/stage/prod, запретить прямые правки на production.
- Ограничить права: принцип минимально необходимых привилегий для редакторов и админов.
- Включить аудит: журналы входа, изменения контента, изменения конфигурации.
- Регулярно проверять расширения: актуальность, репутация, частота обновлений, наличие поддержки.
Если ваша команда не готова поддерживать такой минимум, лучше выбрать более простую архитектуру или передать поддержку надежному партнеру. Для многих организаций критично не «какая CMS безопаснее», а «насколько мы умеем управлять изменениями и зависимостями». Здесь помогает зрелая разработка и сопровождение — например, через разработку и поддержку корпоративного ПО с понятными SLA.
Производительность и масштабирование: где возникают реальные узкие места?
Производительность CMS чаще упирается не в «движок», а в архитектуру: кеширование, качество кода темы/модулей, запросы к БД, изображения, поиск и внешние интеграции. WordPress может быть быстрым, как и Drupal/Joomla, но при росте функциональности важнее дисциплина разработки. Для трансформации стоит измерять производительность как часть продукта: метрики, бюджеты, наблюдаемость.
Типовые причины деградации скорости
- Слишком много плагинов/модулей без контроля зависимостей и профилирования.
- Тяжелые темы и конструкторы страниц, которые генерируют избыточный DOM и скрипты.
- Отсутствие многоуровневого кеша: HTTP‑кеш, объектный кеш, CDN.
- Неоптимизированные медиа: большие изображения, отсутствие современных форматов и адаптивной загрузки.
- Интеграции «в синхроне»: внешние API тормозят рендер и публикации.
Практика: производительность как часть CI/CD
Зрелые команды добавляют проверки производительности в пайплайн: базовые тесты, лимиты на размер бандла, контроль критических страниц. Это особенно важно, если вы развиваете дизайн‑систему и часто меняете фронтенд. В таком случае полезно синхронизировать CMS‑стратегию с UI‑подходами — см. тренды UI‑дизайна B2B‑приложений в 2026, чтобы не «убить» скорость визуальными решениями.
Управление контентом и редакционные процессы: что важнее функций?
Для цифровой трансформации важнее не количество кнопок в админке, а управляемый процесс: роли, согласования, шаблоны, переиспользование контента и контроль качества. WordPress часто удобен редакторам, Joomla сильна в практичной админке, Drupal — в сложных workflow и структурированном контенте. Побеждает CMS, которая поддерживает ваш операционный контент‑процесс.
Контент-модель: сначала сущности, потом страницы
Частая ошибка — строить сайт «страницами», а потом пытаться извлечь из них данные для персонализации, поиска и аналитики. В трансформации лучше проектировать сущности: продукт, отрасль, кейс, событие, эксперт, документ, и задавать связи. Тогда CMS становится инструментом управления структурированным контентом, который легче масштабировать и переиспользовать.
Workflow и качество: редакционный контроль как актив
Если у вас несколько команд и регионов, вам нужны правила: кто создает, кто утверждает, кто публикует, кто отвечает за юридическую проверку. Это можно реализовать в любой CMS, но разной ценой. Важно, чтобы workflow был прозрачен, а публикации — воспроизводимы, иначе вы получите конфликт между скоростью маркетинга и требованиями комплаенса.
TCO и операционная модель: сколько стоит владение CMS на горизонте 3 лет?
TCO (total cost of ownership) CMS включает не только разработку, но и поддержку, обновления, безопасность, хостинг, интеграции, обучение редакторов и стоимость изменений. WordPress может быть дешевле на старте, но дороже при росте «плагинной» сложности; Drupal часто дороже в разработке, но предсказуемее в сложных корпоративных сценариях; Joomla нередко дает сбалансированный профиль затрат.
Компоненты TCO, которые чаще всего недооценивают
- Поддержка и обновления ядра и расширений (включая тестирование совместимости).
- Безопасность: мониторинг, реагирование, резервное восстановление, аудит.
- Интеграции: сопровождение коннекторов, изменение API у внешних систем.
- Контент‑операции: обучение, регламенты, контроль качества, миграции контента.
- Технический долг: «временные» решения, которые становятся постоянными.
Выбор операционной модели: in-house, подрядчик или гибрид
Для трансформации важно заранее решить, кто владеет платформой: внутренняя команда, агентство или гибрид. WordPress часто поддерживают маркетинговые команды с внешними подрядчиками; Drupal чаще требует сильного внутреннего техлида или надежного партнера; Joomla хорошо ложится на гибрид. Если вы выбираете подрядчика, фиксируйте SLA на обновления и безопасность, а также правила управления расширениями.
Практические сценарии: какая CMS лучше в типовых задачах трансформации?
Сценарный подход помогает избежать религиозных войн. Ниже — 5 мини‑кейсов: некоторые иллюстративные (гипотетические), но основаны на реальных паттернах внедрений. Используйте их как шаблон для своих требований: каналы, интеграции, права доступа, скорость изменений и риски.
Сценарий 1 (иллюстративный): B2B‑контент‑хаб и лидогенерация
Компания запускает контент‑хаб: статьи, вебинары, кейсы, лендинги под кампании, формы и интеграция с CRM. Часто побеждает WordPress за счет скорости, удобства редакторов и широкой экосистемы, но при условии строгого списка плагинов и централизованной аналитики. Критично сразу определить события, UTM‑правила и схему передачи лидов.
Сценарий 2 (иллюстративный): государственный/регулируемый портал с ролями
Организации нужен портал с жесткими ролями, модерацией, аудитом изменений, несколькими редакционными группами и повышенными требованиями к безопасности. Здесь чаще подходит Drupal из‑за сильной модели сущностей и управления доступом, а также удобства построения сложных workflow. Важно заложить план обновлений и миграций как обязательную часть жизненного цикла.
Сценарий 3 (иллюстративный): корпоративный сайт + разделы для партнеров
Нужен корпоративный сайт с новостями, продуктами, документами и закрытым разделом для партнеров (материалы, заявки, контакты). Здесь Joomla часто оказывается практичным выбором: сильная админка, понятные роли, достаточная гибкость без тяжелой архитектуры. Ключевой риск — не платформа, а отсутствие четкой модели доступа и контент‑регламентов.
Сценарий 4 (иллюстративный): мультисайт для группы брендов и регионов
Группа компаний управляет несколькими брендами и регионами: разные домены, языки, локальные команды, но единые шаблоны и переиспользуемые блоки. В таких задачах часто выигрывает Drupal, потому что проще удерживать единые правила и структуру контента. WordPress тоже возможен, но потребует более жесткого governance по темам, плагинам и деплою.
Сценарий 5 (иллюстративный): headless‑витрина для продукта + мобильное приложение
Компания развивает продукт и мобильное приложение, а сайт — это витрина и база знаний, которые должны переиспользовать контент. Здесь разумно рассмотреть Drupal как headless‑бэкенд или WordPress в headless‑режиме при аккуратной архитектуре. Если мобильная стратегия ключевая, синхронизируйте требования к CMS с roadmap приложений — см. тренды мобильной разработки 2026 для iOS и Android.
Как выбрать CMS: практический фреймворк оценки (без мифов)
Чтобы выбрать между WordPress, Joomla и Drupal, используйте фреймворк из трех уровней: бизнес‑цели, архитектура и операционная модель. Он помогает отделить «хотелки» от требований, а также заранее увидеть стоимость владения. Ниже — последовательность, которую можно применить за 2–4 недели до старта проекта.
Шаг 1: зафиксируйте бизнес-результаты и ограничения
- Опишите 3–5 ключевых KPI: скорость публикаций, конверсия, снижение стоимости лида, качество данных, стабильность.
- Определите ограничения: регуляторика, требования к хранению данных, SSO, аудит, доступность.
- Сформируйте карту каналов: сайт, личный кабинет, партнерский портал, мобильное приложение, email.
- Зафиксируйте критичные интеграции: CRM, ERP, PIM, DAM, аналитика, маркетинговая автоматизация.
Шаг 2: спроектируйте контент-модель и домены данных
До выбора CMS набросайте сущности и связи: какие типы контента, какие поля, какие таксономии, какие правила доступа. Это быстро выявляет, будет ли ваш проект «страничным» (часто WordPress/Joomla) или «сущностным» (часто Drupal). Такой подход также улучшает качество аналитики и персонализации, потому что данные становятся структурированными.
Шаг 3: оцените операционную зрелость (люди и процессы)
Спросите честно: кто будет поддерживать обновления, тестировать изменения и отвечать за безопасность? Если у вас нет процесса релизов и контроля расширений, «самая гибкая CMS» превратится в источник риска. Иногда правильнее выбрать более простую платформу и инвестировать в процессы — или привлечь партнеров через разработку корпоративных веб‑решений с регламентом поддержки.
Типовые ошибки выбора CMS (и как их избежать)
Ошибки выбора CMS в трансформации почти всегда связаны с недооценкой операционных расходов и интеграций. Команды выбирают платформу «по привычке», а затем компенсируют архитектурные ограничения дорогими костылями. Ниже — наиболее частые ошибки и практичные способы их предотвратить.
- Выбор по «популярности», а не по целевой архитектуре и требованиям к доступам/аудиту.
- Ставка на десятки плагинов вместо проектирования интеграционного слоя и контент‑модели.
- Отсутствие плана обновлений: миграции откладываются, риск растет, стоимость изменений увеличивается.
- Смешение ролей: редакторы получают админские права, а разработчики правят прод вручную.
- Нет владельца продукта: никто не отвечает за дорожную карту CMS и качество данных.
Хорошая профилактика — пилот на 2–3 ключевых сценариях: один контентный поток, одна интеграция (например, CRM), один сложный тип контента и один workflow согласования. Пилот покажет реальную стоимость изменений и выявит ограничения раньше, чем вы перенесете весь контент. Также полезно заранее обсудить облачную стратегию и KPI — см. анализ влияния облачных технологий на KPI.
Чек-лист внедрения: следующие шаги для выбора и запуска CMS
Ниже — практический чек‑лист, который можно использовать как план работ на 4–12 недель: от требований до запуска и первых итераций. Он одинаково применим к WordPress, Joomla и Drupal, но помогает учесть то, что чаще всего «всплывает» после старта. Используйте его как основу для бэклога программы цифровой трансформации.
- Сформировать матрицу требований: каналы, интеграции, роли, комплаенс, SLA, мультисайт, языки.
- Описать контент‑модель (сущности/поля/таксономии) и правила переиспользования контента.
- Определить архитектуру: традиционная, гибридная или headless; где живет бизнес‑логика.
- Согласовать операционную модель: владельцы, процесс релизов, политика обновлений, ответственность за безопасность.
- Собрать «белый список» расширений/модулей и правила их оценки (поддержка, обновления, риски).
- Настроить CI/CD и среды (dev/stage/prod), резервное копирование и план восстановления.
- Встроить аналитику: события, цели, согласование схемы данных, контроль качества тегов.
- Сделать пилот на 2–3 сценариях, измерить скорость изменений и стоимость поддержки.
- Запустить MVP, затем итеративно расширять, удерживая governance и стандарты качества.
