Масштабирование Agile: SAFe и LeSS

← назад к разделу

Scrum и Kanban придуманы для одной команды: по Scrum Guide это обычно десять человек или меньше, один backlog, одни ежедневные встречи. Но крупный продукт редко делает одна команда. Банковское приложение, маркетплейс, ERP — это десятки, а то и сотни разработчиков. И тут возникает вопрос: как заставить 10, 20 или 50 команд двигаться в одну сторону, не превратив всё в хаос? Ответ пытаются дать фреймворки масштабирования Agile — SAFe, LeSS и другие.

Почему Scrum одной команды не масштабируется сам по себе

Когда над продуктом работает одна команда, все договорённости умещаются в голове. Все знают, кто что делает; если задача зависит от другой задачи — люди просто поговорили и разрулили.

Добавьте вторую команду — и появляются зависимости. Команда A не может закончить свою функцию, пока команда B не выдаст нужный API. Команда B не в курсе, что кого-то заблокировала, потому что у неё свой backlog и свои приоритеты. Умножьте это на десять команд — и получите ситуацию, где никто не видит общей картины, релизы срываются, а половина времени уходит на выяснение «а вы это уже сделали или нет».

Три главные боли масштабирования:

• Зависимости между командами. Одна ждёт другую; блокировки всплывают в последний момент.
• Общий backlog и приоритеты. У продукта один список задач, но команд много — кто решает, что важнее?
• Синхронизация. Если команды работают в разном ритме и релизят вразнобой, собрать из их кусков цельный продукт тяжело.

Фреймворки масштабирования — набор правил и церемоний против этих трёх болей; отличаются они тем, сколько надстроек добавляют поверх обычного Scrum.

Когда масштабироваться действительно пора

Две команды на продукт — это ещё не повод для фреймворка. Чаще всего они прекрасно живут на прямой договорённости: два человека раз в неделю сверяются за пятнадцать минут, и этого достаточно. Фреймворк, введённый в этот момент, добавляет церемоний и не решает ничего, потому что решать пока нечего.

Порог — не в числе команд, а в том, когда прямая договорённость перестаёт работать. Признаки, по которым это видно:

• Число связей растёт быстрее числа команд. Двум командам нужна одна договорённость, трём — три, четырём — шесть, шести — пятнадцать. Держать в голове три связи можно, пятнадцать — нет. Практический порог обычно проходит между четырьмя и шестью командами.
• Блокировки всплывают в последний момент. Не «мы знали и ждали», а «выяснилось на демонстрации». Это означает, что канал договорённости уже не справляется.
• Одну и ту же информацию рассказывают по третьему разу. Признак того, что общей картины нет ни у кого.
• Приоритеты расходятся. Для команды A эта задача первая, для команды B, от которой она зависит, — седьмая. Спор решается не на уровне команд, потому что решать нечем: у каждой свой список.
• Выпуск начинает ждать. Готовое лежит, потому что собирается только вместе с чужим куском, и дату выпуска назвать никто не может.
• Больше половины совещаний — про согласование. Не про работу, а про то, кто кого ждёт.

Важная проверка перед решением: это проблема координации или проблема границ? Если команды ждут друг друга потому, что правят один и тот же код и одну и ту же базу, никакой фреймворк не поможет — он сделает очередь видимой и плановой, но не короче. Тогда порог пройден не для фреймворка, а для разделения кусков продукта.

И обратная сторона: масштабироваться вниз тоже нужно. Продукт сократился, команд стало три вместо девяти, а планирование на два дня раз в квартал осталось. Церемонии почти никогда не убирают сами собой — это отдельное решение, и его стоит принимать по тем же признакам, только в обратную сторону.

SAFe: тяжёлый фреймворк с уровнями

SAFe (Scaled Agile Framework) — самый популярный и самый «тяжёлый» из подходов. Его идея: раз команд много, нужны отдельные уровни управления, каждый со своими ролями и церемониями.

Уровней обычно три:

Ключевые понятия SAFe:

• Agile Release Train (ART) — «поезд релизов». Это группа из 5-12 команд (50-125 человек), которые работают над общей целью и релизят синхронно. Все едут в одном поезде и по одному расписанию.
• PI Planning — большое общее планирование раз в 8-12 недель, где все команды поезда собираются вместе (очно или онлайн) и на два дня согласуют, кто что делает и как разруливать зависимости. Это сердце SAFe — и самая дорогая его часть: поезд из ста человек на два дня стоит около двухсот человеко-дней за квартал, не считая дороги и подготовки.

SAFe даёт структуру и предсказуемость, но платит за это весом: много ролей (Release Train Engineer, Product Manager, System Architect и другие), много церемоний, много документов. Критики говорят, что SAFe рискует превратить Agile обратно в тяжёлый управленческий процесс с большим числом менеджеров. Поэтому его чаще выбирают крупные корпорации, которым важнее контроль и предсказуемость, чем гибкость.

Тройка уровней — из ранних редакций SAFe (4.x), и названия в разных материалах расходятся: уровень программы в последних версиях зовётся ART (конфигурация Essential), а буквы PI там расшифровываются как Planning Interval, а не Program Increment. Устройство при этом то же, меняются подписи — сверяйтесь с версией, по которой работает ваша компания.

За что SAFe действительно выбирают

Раздел выше легко прочитать как критику, а это разбор. У SAFe есть две вещи, которых нет ни в LeSS, ни в самоорганизации, и именно за них его берут крупные компании — не из-за любви к контролю.

Единый календарь на сто команд и выше. Когда над продуктом работают сто человек, главная проблема не «как команде работать», а «как всем знать одну дату». Планирование раз в 8–12 недель даёт то, чего в непрерывном потоке нет: единый горизонт. Все команды, продавцы, маркетинг, поддержка и обучение знают, что в конце интервала будет готово вот это. Смежники могут планировать свою работу от этой даты. Двухдневное планирование стоит дорого, но альтернатива — сто человек, которые выясняют сроки поштучно.

Понятный бюджетный цикл. В большой компании деньги выделяются не на «продукт вообще», а на направления, с обоснованием и отчётностью. Уровень портфеля в SAFe сделан ровно под это: он переводит стратегию в поток работы и обратно — в отчёт о том, куда ушёл бюджет. Это единственный из подходов к масштабированию, который прямо отвечает на вопрос финансового директора. LeSS на этот вопрос не отвечает вовсе — и это одна из настоящих причин, по которым его не выбирают в корпорациях, хотя он проще.

Есть и третья, менее возвышенная, но честная причина: SAFe даёт готовый язык и путь внедрения. Роли описаны, церемонии описаны, есть обучение и сертификация, есть кого позвать. Для организации на тысячу человек это значит, что изменение можно запланировать и провести, а не «собрать команды и договориться». Плата известна — вес, роли, документы; выигрыш — предсказуемость, которой у сотни команд без общего календаря не бывает.

LeSS: Scrum как есть, но для многих команд

LeSS (Large-Scale Scrum) идёт от противоположного принципа: не добавлять надстройки, а оставить Scrum почти нетронутым и растянуть его на несколько команд.

Главные отличия от SAFe:

• Один общий backlog на весь продукт и один Product Owner. Он расставляет приоритеты для всех команд сразу — не появляется отдельного уровня «программы» со своими списками задач.
• Один общий sprint для всех команд. Все стартуют и финишируют одновременно, на общем обзоре показывают единый результат.
• Минимум новых ролей. LeSS не вводит кучу должностей — базовые роли Scrum остаются, просто применяются к нескольким командам.

LeSS работает для 2-8 команд (в варианте LeSS Huge — больше, с делением на области требований). Философия здесь такая: сложность нужно убирать, а не добавлять. Если для координации потребовалось много новых ролей и процессов — значит, проблему решают не в том месте.

Коротко разница: SAFe добавляет уровни и роли поверх команд; LeSS убирает всё лишнее и заставляет команды напрямую договариваться вокруг одного backlog.

Между этими полюсами есть середина, которую на практике берут чаще всего. Nexus — надстройка от авторов самого Scrum на 3-9 команд: один общий backlog и отдельная команда интеграции, которая следит, чтобы куски собирались в один инкремент. Scrum@Scale — подход Джеффа Сазерленда, где Scrum масштабируют «матрёшкой»: над командами появляется команда из их представителей, над ней при необходимости следующая.

Spotify-модель: пример, а не фреймворк

Часто в разговорах о масштабировании всплывает Spotify-модель с её squads, tribes, chapters и guilds. Важно понимать: это не фреймворк, а рассказ о том, как в одной компании была устроена работа в определённый момент.

Термины простые:

• Squad — маленькая автономная команда, аналог Scrum-команды, отвечает за свой кусок продукта.
• Tribe — группа squad'ов, работающих в близкой области.
• Chapter — люди одной специальности (например, все backend-разработчики) внутри tribe, чтобы делиться практиками.
• Guild — сообщество по интересам через всю компанию (например, все, кому интересно тестирование).

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

Между одной командой и фреймворком

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

Связной от команды к команде. У каждой команды есть человек, который отвечает за общение с конкретной соседней командой: знает их планы, приносит свои, первым узнаёт о блокировке. Не отдельная должность, а обязанность у кого-то из команды. Три-четыре таких связки заменяют общее совещание на двадцать человек.

Регулярная короткая сверка представителей. Пятнадцать минут раз в неделю, по одному человеку от команды, один вопрос: кто кого ждёт и что для этого нужно. Это не планирование и не отчёт. Формат работает до шести-семи команд; дальше он перестаёт вмещаться в пятнадцать минут, и это сигнал о следующем шаге.

Общий календарь выпусков. Не общий спринт и не общий поезд, а один календарь на стене: когда какая команда выкатывает, когда стоп-дни, когда заморозка перед крупным событием. Половина зависимостей во времени решается тем, что их просто видно.

Договор об интерфейсах. Команды договариваются не о сроках, а о форме взаимодействия: вот такой запрос, вот такой ответ, вот такое событие. Дальше каждая работает на заглушке, не ожидая соседа. Это самое сильное средство в списке, потому что превращает ожидание готового куска в ожидание одной договорённости.

Общая очередь только на спорное. Один список, куда попадает не вся работа, а только то, где приоритеты команд конфликтуют. Решает его тот, кто отвечает за продукт целиком. Маленький список, который разбирают за двадцать минут раз в две недели, снимает большую часть споров о том, чья задача важнее.

Правило одной страницы. Всё, что команда должна знать о соседях, живёт на одной странице: кто что делает в этом месяце, какие интерфейсы, кто связной, когда выпуски. Страница, которую никто не читает, — признак, что связей стало слишком много и пора к следующему шагу.

Этот набор стоит примерно час в неделю на команду. Если он перестал справляться — тогда фреймворк, и уже с понятной причиной: видно, какая именно связь не держится.

Главный принцип: сначала убрать зависимости, потом добавлять церемонии

Масштабируют не ради масштаба. Все церемонии SAFe и LeSS существуют, чтобы бороться с зависимостями между командами. Но самый дешёвый способ справиться с зависимостью — это её убрать, а не научиться её координировать.

У этого наблюдения есть имя — закон Конвея. Ещё в конце шестидесятых Мелвин Конвей заметил: система получается устроенной так же, как устроено общение людей, которые её делают. Четыре команды, которые вынуждены постоянно договариваться, рано или поздно сделают четыре намертво сцепленных куска. Отсюда и обратный ход, которым пользуются осознанно: сначала решают, какие границы нужны в продукте, и уже под них нарезают команды — границы сервисов и границы команд проектируют вместе, а не по очереди.

Что убирает зависимости в первую очередь:

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

И только когда зависимости объективно остаются (а полностью их убрать в большом продукте нельзя), имеет смысл добавлять координацию — PI Planning, общий backlog, синхронные sprint'ы. Оба выхода — внизу анимации: координация делает очередь видимой и плановой, границы убирают саму очередь. Порядок именно такой: сначала архитектура и границы команд, потом церемонии. Если сделать наоборот — навесить тяжёлый фреймворк на запутанную систему, — вы получите дорогой ритуал по управлению хаосом, а не решение проблемы.

Поэтому выбор фреймворка вторичен. Сначала честно спросите: почему командам вообще приходится так много друг друга ждать? Часто ответ лежит не в процессах, а в устройстве продукта и команд.

Во что упирается автономия на самом деле

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

Общая база данных. Пока две команды пишут в одни таблицы, они не автономны, какими бы отдельными ни были их сервисы: изменение схемы требует согласования, а неудачное изменение ломает соседа. Это самая частая и самая дорогая привязка. Путь известен и медленный: сначала запретить чужие таблицы на чтение через приложение, потом развести владение таблицами по командам, потом физически разделить. Пока это не сделано, автономия остаётся на слайдах.

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

Один общий релизный поезд. Синхронный выпуск всех команд удобен для планирования и вреден для автономии: темп задаёт самая медленная команда, а рискует при откате — вся. Это осознанный обмен, и его стоит называть так, а не считать бесплатным.

Плюс две привязки помельче, которые всплывают позже: общая библиотека, версию которой поднимают все разом, и общий стенд, за который команды стоят в очередь.

Проверочный список автономии на практике — четыре вопроса, на которые нужно четыре «да»: команда может изменить свою схему данных, не спрашивая никого; может выпустить в прод сама; может откатить своё, не откатывая чужого; может проверить своё на стенде, никого не ожидая. Каждое «нет» — это конкретная зависимость с понятной стоимостью устранения, и это гораздо полезнее, чем оценка автономии «в целом».

Общий кусок, который убрать нельзя

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

Внутренний контракт вместо заявки. У общего куска есть опубликованный интерфейс, версии и обещание совместимости: старая версия живёт столько-то, о несовместимых изменениях предупреждают заранее. Потребитель читает описание и подключается сам, не переговариваясь. Всё, что в нём не описано, не существует — иначе команды продолжат опираться на внутренности и привязка вернётся.

Команда-платформа с обязательствами. Владелец общего куска перестаёт быть очередью и становится поставщиком с проверяемыми обещаниями: сколько времени идёт ответ на вопрос, за какой срок рассматривается запрос на изменение, какая доступность у сервиса, как быстро выпускается исправление. Обязательства публикуются и измеряются. Это меняет поведение: команда-платформа планирует работу под чужие потребности, потому что за срок отвечает она.

Самообслуживание вместо заявок. Самое действенное. Всё, что потребители просят часто, превращается в кнопку или команду: заведение своего ключа, тестовое окружение, включение флага, доступ к данным. Заявка, которую разбирает человек, — это очередь; кнопка — не очередь. Хороший ориентир: доля запросов, которые потребитель закрывает сам, — и её растят осознанно.

Изменения вносят потребители. Если платёжный контур нужен пятнадцати командам, она не должна делать за них пятнадцать доработок. Правило: потребитель присылает изменение сам, платформа проверяет и выпускает. Требует времени на подготовку кода к чужим правкам, зато снимает главный затор.

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

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

Как масштабируется сама оценка

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

Причина прямо в устройстве меры. Балл — это сравнение с эталоном команды, а эталон у каждой свой. Сложить пятёрку команды A с пятёркой команды B — то же, что сложить рост в двух неизвестных единицах. Ещё хуже — делить: «у них скорость 40, у нас 20» превращается в вывод о людях, которого в числах нет.

Что делают вместо этого:

• Каждая команда прогнозирует свою часть сама, в своих единицах. Наверх отдаётся не число баллов, а срок или вилка сроков. Сроки складываются, баллы — нет.
• Крупное прикидывают единой грубой мерой. Размеры вроде футболок или разбиение на «влезает в интервал / не влезает» работают между командами, потому что не притворяются арифметикой.
• Общий план ведут в кусках работы, а не в баллах. Единица общего плана — функция целиком, с известным набором команд-участников и датой готовности. Внутри каждая считает как хочет.
• Зависимость оценивают обе стороны. Если команда A ждёт интерфейс от команды B, срок даёт B, а не A по своему представлению. Это звучит очевидно и нарушается постоянно.
• Прогноз по счёту готовых кусков. Самый устойчивый способ на нескольких командах: считать не баллы, а завершённые функции за интервал. Мера одинакова для всех, и её нельзя раздуть оценкой.

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

И следствие для церемоний: общее планирование должно работать с датами, зависимостями и рисками, а не с суммой баллов. Слайд «поезд взял 480 баллов» не значит ничего, кроме того, что кто-то их сложил.

Глубже: обратный манёвр Конвеярасширенное

Закон Конвея выше объясняет, почему структура системы повторяет структуру команд. Из него есть практическое следствие, которым пользуются осознанно: если нужна определённая архитектура, сначала перестраивают команды, а система подтянется. Это называют обратным манёвром Конвея.

Работает он так. Хотите сервис оформления заказа с чёткой границей и независимыми выкатами: заведите команду, которая владеет им целиком, от требований до дежурства, и не владеет ничем другим. Хотите, чтобы платформенные вещи (конвейер, наблюдаемость, кластер) были общими и не дублировались: заведите платформенную команду с внутренним продуктом и клиентами внутри компании. Разбивать систему на сервисы при одной команде на всё бессмысленно: границы, которые не совпадают с границами ответственности, стираются через полгода, потому что один человек правит оба сервиса в одном pull request.

Обратная сторона: команда, которой отдали кусок, начинает защищать его границу, и это правильно ровно до тех пор, пока граница совпадает с доменом. Команда, нарезанная по слоям (команда базы, команда API), даст систему, нарезанную по слоям, и это худшая из архитектур для изменений, о чём статья про границы сервисов. Команда на два несвязанных домена даст распределённый монолит.

Практический порядок при масштабировании: сначала карта доменов и границ (по ограниченным контекстам, о чём статьи DDD), потом команды по границам с полной ответственностью, потом сервисы. Фреймворки масштабирования из статьи задают церемонии поверх этого, и ни один из них не заменяет первого шага.

Глубже: снаружи водопад с датой, внутри спринтырасширенное

«Команды часто смешивают» из статьи про модели требует показать, как. Самый частый случай: регулятор, заказчик или контракт требуют плановую модель (дата, объём, документы, приёмка), а команда хочет работать итерациями. Это не противоречие, а два слоя.

Снаружи. Есть веха с датой и зафиксированным объёмом, документы, которых требует сертификация или договор (требования, архитектура, протоколы испытаний), и приёмка по ним. Этот слой обещают и держат: дата не двигается, объём меняется через соглашение.

Внутри. Объём вехи разложен на истории и идёт спринтами в порядке рисков, а не в порядке документа: сначала интеграции и неизвестное, потом остальное. Документы для внешнего слоя пишут по ходу, из того, что уже сделано и проверено, а не вперёд: архитектурный документ отражает каркас после первых спринтов, протоколы испытаний это выгрузка автоматических тестов. Каждый спринт заканчивается работающей частью системы, которую можно показать заказчику до вехи, и это снимает половину рисков приёмки.

Где стык рвётся. Изменение требований изнутри без внешнего соглашения: команда «улучшила», приёмка не приняла. Лечится тем, что Product Owner ведёт два списка, зафиксированный объём и всё сверх него, и второе идёт только после первого. Регуляторные требования, узнанные на последнем спринте: их читают на первом. И отчётность в двух форматах, диаграмма сгорания для команды и график вех для заказчика, с одного источника данных, чтобы не расходились.

Так живут банковские, медицинские и государственные проекты: сертификация снаружи, спринты внутри, и граница между ними это осознанное решение, а не неудобство.

Коротко

• Scrum и Kanban придуманы для одной команды; при 10+ командах на один продукт появляются зависимости, борьба за общий backlog и проблема синхронизации. SAFe — тяжёлый фреймворк с уровнями «команда / программа / портфель», понятиями Agile Release Train и PI Planning; много ролей и церемоний, выбирают крупные корпорации ради предсказуемости.
• LeSS — «Scrum как есть» для нескольких команд: один backlog, один Product Owner, один общий sprint, минимум новых ролей; философия — убирать сложность, а не добавлять. Spotify-модель (squads / tribes / chapters / guilds) — это пример устройства работы одной компании, а не фреймворк; копировать её структуру вслепую — ошибка.
• Все церемонии масштабирования существуют ради борьбы с зависимостями, а самый дешёвый способ справиться с зависимостью — убрать её: слабо связанная архитектура и автономные команды снимают больше, чем любое общее планирование. Порядок правильный: сначала архитектура и границы команд, потом координационные церемонии — не наоборот.
• Обратный манёвр Конвея: нужную архитектуру получают, сначала перестроив команды по границам доменов с полной ответственностью; команды по слоям дают систему по слоям. Регуляторика и договор снаружи, спринты внутри: веха с датой и документами держится, объём идёт итерациями по рискам, документы пишут из сделанного, два списка у Product Owner.
• Порог масштабирования — не число команд, а момент, когда прямая договорённость перестаёт работать: блокировки всплывают на демонстрации, приоритеты расходятся, выпуск ждёт; обычно между четырьмя и шестью командами.
• SAFe выбирают за единый горизонт на сотню команд и понятный бюджетный цикл, а ещё за готовый язык внедрения; LeSS проще, но на вопрос финансового директора не отвечает.
• Между одной командой и фреймворком есть дешёвая середина: связной к каждой соседней команде, короткая недельная сверка представителей, общий календарь выпусков, договор об интерфейсах, общая очередь только на спорное.
• Автономия упирается в общую базу, общую выкатку и общий релизный поезд: проверка — команда меняет свою схему, выпускает и откатывает своё, проверяет на стенде, никого не спрашивая.
• Общий кусок превращают из очереди в услугу: внутренний контракт с версиями, команда-платформа с измеримыми обязательствами, самообслуживание вместо заявок, изменения от потребителей, открытый список работ.
• Баллы сложности между командами не складываются: наверх отдают сроки и куски работы, крупное прикидывают грубой общей мерой, срок зависимости даёт тот, кто её выполняет, а единая шкала баллов кончается отчётностью и раздуванием.

Что почитать дальше

• Scrum — каркас одной команды, который масштабирование растягивает на многие.
• Kanban — про очередь и ограничение работы в процессе: та же беда, только внутри команды.
• Оценка и планирование — откуда берётся прогноз, который общее планирование обещает.
• Модели разработки — как продукт организовывали до Agile и почему длинные циклы дорого стоят.