Уровень технологической готовности (Technology Readiness Level, TRL) — девятибалльная шкала зрелости технологии, от первоначальной научной идеи (TRL 1) до полностью подтверждённой промышленной эксплуатации (TRL 9). Шкала даёт общий язык для инженеров, инвесторов и грантовых комитетов, чтобы однозначно понимать, на каком этапе находится конкретная технология — вместо расплывчатых «почти готово» или «работает в лаборатории».
Происхождение и исследовательская база
Первую версию шкалы предложил в 1974 году Стэн Сэдин, инженер Управления авиационных и космических технологий NASA — исходная формулировка включала семь уровней. Более поздняя, привычная сегодня девятиуровневая версия закрепилась в NASA к 1990-м годам и затем была принята Министерством обороны США, Европейским космическим агентством и рядом других стран как стандартный инструмент оценки технологического риска.
В России методика регулируется государственным стандартом ГОСТ Р 58048-2017 «Трансфер технологий. Методические указания по оценке уровня зрелости технологий», а также используется в грантовых программах (Фонд содействия инновациям, Сколково) и системами оценки крупных госкорпораций (например, Росатом ведёт по TRL собственный портфель технологий на основании локальных нормативных актов).
Уточнение по истории. По публикации Стэнли Садина, Фредерика Повинелли и Роберта Розена «The NASA technology push towards future space mission systems» (Acta Astronautica, 1989) шкала готовности технологий включала семь уровней — от «наблюдены и описаны базовые принципы» до «система проверена в космосе». Девятиуровневая версия сложилась в 1990-х годах: в 1995 году Джон Манкинс в «Technology Readiness Levels: A White Paper» добавил уровни 8 и 9 (система завершена и квалифицирована; система подтверждена успешной эксплуатацией). Европейская комиссия ввела шкалу в программу «Горизонт 2020» в 2014 году: в приложении G к рабочей программе 2014–2015 годов даны определения уровней TRL 1–9 для проектов, финансируемых Евросоюзом; в российской практике действует ГОСТ Р 58048-2017.
Документированные кейсы
Кейс 1. GAO (1999): коммерческие компании и оборонные программы по-разному относятся к незрелой технологии
В отчёте «Best Practices: Better Management of Technology Development Can Improve Weapon System Outcomes» (GAO/NSIAD-99-162, 30 июля 1999) Государственное счётное управление США сравнило практики оборонных программ и коммерческих компаний. Вывод: Министерство обороны идёт на больший риск и пытается перевести новые технологии в изделие на меньшей степени зрелости, а использование незрелых технологий повышает общий риск программы — вероятность перерасходов и задержек. В качестве измерительной шкалы GAO использовало TRL; лаборатория ВВС считала TRL 6 приемлемым для входа в стадию определения программы и TRL 7 — для начала инженерной и производственной разработки. Причины, по которым незрелые технологии всё же включали в изделия, — жёсткие требования к характеристикам, которые трудно выполнить существующими средствами.
Как читать. Это один из главных источников идеи «не переходить на следующую стадию, пока технология не достигла заранее определённого уровня»; она позднее вошла в практику оценки технологической готовности и в руководство GAO 2016/2020 годов. Оговорка: отчёт описывает конкретную сферу (оборонные закупки США 1990-х), а его выводы о связи зрелости и результатов программ основаны на анализе выборки программ; для других отраслей пороги придётся определять самостоятельно.
Кейс 2. От NASA к «Горизонту 2020»: шкала выходит за пределы космонавтики
Начав как инструмент управления рисками космических программ, TRL стала общим языком для государственных программ финансирования: Министерство обороны США, Европейская комиссия (с 2014 года), национальные фонды. В проектах, финансируемых Евросоюзом, заявки описывают, с какого TRL проект стартует и на какой заканчивает; это позволяет фонду отличать фундаментальные исследования от демонстрации и внедрения. Одновременно проявились и издержки: разные организации трактуют уровни по-разному, а «долина смерти» (перед TRL 7) остаётся местом, где не хватает финансирования.
Практический смысл: если вы готовите заявку в фонд, начните с формулировок шкалы конкретной программы: те же слова («релевантная среда», «операционная среда») в разных документах могут означать разные требования к испытаниям. Оговорка: приведённая эволюция шкалы — общепринятая версия истории; отдельные детали (например, точные даты внутренних документов NASA) разными источниками указываются по-разному.
Кейс 3. Исследование практики применения TRL: где шкала подводит
Олеховски, Эппингер и Джоглекар в 2015 году (PICMET) опросили специалистов семи организаций и проанализировали отраслевые документы. Они выделили 15 проблем применения TRL в трёх группах и показали, что наиболее острые — на уровне системы: интеграция, интерфейсы, изменение системы после проверки, общая зрелость. Иными словами, шкала хорошо работает для отдельной технологии и хуже — для сложной системы, где риск сосредоточен на стыках.
Практический вывод: рядом со шкалой TRL нужно вести оценку интеграционного риска (например, реестр интерфейсов и испытания на уровне системы). Оговорка: исследование качественное, по небольшой выборке; оно указывает на типичные проблемы, но не на их распространённость.
Ключевые идеи и принципы
Принцип: девять уровней, без пропусков
TRL 1 — зафиксированы и обоснованы базовые научные принципы, лежащие в основе будущей технологии.
TRL 2 — сформулирована конкретная технологическая концепция и предполагаемая область применения.
TRL 3 — получено экспериментальное подтверждение критической функции или свойства концепции (лабораторный эксперимент, макет).
TRL 4 — компонент или макет проверен в лабораторных условиях в связке с другими элементами.
TRL 5 — компонент проверен в модельной среде, приближенной к реальной эксплуатационной.
TRL 6 — продемонстрирован прототип системы или подсистемы в модельной или условно реальной среде.
TRL 7 — прототип демонстрируется непосредственно в реальных условиях эксплуатации.
TRL 8 — система полностью завершена и прошла квалификационные испытания в реальных условиях.
TRL 9 — технология подтверждена успешной реальной эксплуатацией в штатном режиме.
Принцип: нельзя перескакивать уровни
Шкала кумулятивна — технология не может считаться находящейся на TRL 7, если не пройдены и подтверждены документально все предыдущие уровни. Попытка присвоить высокий TRL без реального прохождения промежуточных этапов обесценивает саму методику как инструмент честной оценки риска.
Принцип: три зоны развития и «долина смерти»
Уровни условно группируются в три зоны: TRL 1-3 — формирование и первичная проверка научной концепции; TRL 4-6 — переход от лабораторного макета к работающему прототипу в приближенных к реальным условиях; TRL 7-9 — внедрение и промышленное масштабирование. Переход от TRL 4 к TRL 7 — участок, требующий значительных инвестиций, времени и готовности к риску при том, что технология ещё не приносит прибыли — эту фазу в венчурной и грантовой практике называют «долиной смерти»: множество технологически перспективных разработок не преодолевают именно её из-за нехватки финансирования на этом этапе, а не из-за научной несостоятельности.
Принцип: TRL — метрика зрелости, не метрика пригодности
Ключевое разграничение, которое системно упускают популярные пересказы: TRL измеряет, насколько технология технически отработана и проверена, но НЕ отвечает на вопрос, является ли эта технология вообще правильным решением для конкретной задачи. Технология на TRL 9 полностью готова к применению — но это не означает, что именно она нужна рынку или заказчику; вопрос пригодности решения — отдельная, не покрываемая TRL оценка.
Принцип: TRL не измеряет ни производственную, ни рыночную готовность
Шкала TRL изначально создавалась для оценки зрелости технического ядра в критически важном аппаратном обеспечении (космические и оборонные системы NASA), а не рыночной или производственной готовности. Отсюда — два важных дополняющих понятия, которые серьёзные практики применяют параллельно с TRL:
MRL (Manufacturing Readiness Level) — готовность технологии к масштабному промышленному производству. Технология с TRL 9 (полностью технически подтверждена) при MRL 4 физически не может быть произведена в промышленном масштабе, вне зависимости от того, насколько она технически отработана — TRL и MRL измеряют принципиально разные вещи и не заменяют друг друга.
MRL/рыночная готовность (Market Readiness Level, в некоторых системах — отдельная третья ось) — насколько рынок готов принять решение: спрос, юнит-экономика, регуляторная приемлемость. Использование одного только TRL как единственного показателя готовности венчурного проекта — прямое неверное применение методики за пределами её первоначального назначения.
Серьёзная практика оценки технологии выстраивает трёхмерную матрицу — TRL (техническая зрелость) × MRL (производственная готовность) × рыночная готовность — вместо использования одной только технической шкалы как универсального ответа на вопрос «готовы ли мы к запуску».
Принцип: доказательство и независимая оценка
Практика оценки технологической готовности в государственных программах США закреплена в руководстве GAO по оценке технологической готовности (Technology Readiness Assessment Guide; первая редакция — 2016, переиздание с изменениями — 2020, GAO-20-48G). Его логика: определить критические технологии (те, от которых зависит успех системы и которые новы или применяются в новых условиях), для каждой описать, в каких условиях она проверена, сопоставить с определением уровня, привлечь независимых экспертов и задокументировать основания. Для организации это означает: уровень присваивается не докладом руководителя проекта, а по протоколу с перечнем критических технологий, условиями испытаний (лабораторные, модельные, представительные, реальные) и ссылками на первичные данные.
Принцип: различие «релевантной» и «реальной» среды
Ключевые пороги шкалы — не номера, а смена среды испытаний: от лаборатории (TRL 4) к среде, «релевантной» для применения (TRL 5–6), затем к реальным условиям эксплуатации (TRL 7–9). Полезное упражнение — записать, чем именно испытательная среда отличается от реальной: температура, нагрузки, помехи, квалификация оператора, качество сырья, режимы использования. Пока не названы отличия, уровень 5–6 присваивать нельзя.
Принцип: метрики и сигналы
Для управления программой полезны показатели: время и стоимость прохождения уровня по сравнению с планом; число критических технологий на каждом уровне и доля технологий ниже целевого уровня перед контрольной точкой (например, перед решением о серийной разработке); число откатов на предыдущий уровень после новых испытаний; доля уровней, подтверждённых независимой экспертизой; разница между самооценкой команды и оценкой экспертов. Растущий разрыв между самооценкой и экспертизой — сигнал завышения.
Принцип: целевой уровень для решения
Для каждого решения полезно заранее задать минимально допустимый TRL: например, в описаниях, приведённых в отчёте GAO 1999 года, лаборатория ВВС США считала TRL 6 приемлемым риском для входа оружейной системы в стадию определения программы, а TRL 7 — для стадии инженерной и производственной разработки. Для гражданских проектов пороги задаёт организация: например, «не начинаем разработку серийной конструкции ниже TRL 6», «не заказываем оснастку ниже TRL 7». Явный порог превращает шкалу из описания в инструмент решения.
Принцип: применение в организации (аналогия)
В компании без оборонных процедур шкала помогает вести портфель технологических проектов: для каждого проекта — текущий уровень, документальное основание, ближайший переход, требуемые ресурсы и владелец. Реестр показывает, сколько проектов «застряло» между TRL 4 и 6, где деньги идут на слишком ранние разработки, а где серию планируют раньше, чем проверена технология. Это практическая аналогия использования шкалы, а не требование стандарта.
Ограничения, слепые зоны и критика
TRL — метрика технической зрелости, не метрика пригодности решения задаче: высокий TRL не гарантирует, что технология коммерчески или стратегически востребована.
Шкала не захватывает производственную готовность (для этого нужен отдельный MRL) — технология может быть технически полностью отработана и при этом физически не готова к масштабному производству.
Использование TRL как единственного индикатора готовности венчурного стартапа к инвестициям — распространённая, но методологически неверная практика: изначальный замысел шкалы — оценка зрелости технического ядра в критичном аппаратном обеспечении, а не рыночного спроса, юнит-экономики или качества корпоративного управления компании.
Переход через «долину смерти» (TRL 4→7) системно недофинансирован в грантовых и венчурных экосистемах — технологии с реальным научным потенциалом закрываются не из-за несостоятельности, а из-за нехватки финансирования именно на этом промежуточном этапе.
Управленческие команды, оценивающие проекты по TRL, часто не обладают достаточной технической квалификацией, чтобы корректно верифицировать заявленный уровень, а не принять декларацию заявителя на веру.
Исследование практики применения TRL (Олеховски, Эппингер, Джоглекар, PICMET 2015) построено на полуструктурированных интервью со специалистами семи организаций и документах отраслевых стандартов. Авторы выделили 15 проблем в трёх группах — сложность системы, планирование и проверка, обоснованность оценки — и отметили, что самые критичные, по мнению респондентов, связаны с системой: интеграцией, интерфейсами, изменениями системы и общей зрелостью. Оговорка: выборка невелика и качественная, поэтому результаты показывают типичные проблемы, а не их распространённость.
Шкала создавалась для аппаратных систем (космос, оборона). Для программных продуктов, услуг, биотехнологий и медицинских изделий уровни описываются по-иному, а в ряде отраслей (лекарства, медицинские устройства) существуют собственные последовательности испытаний и регуляторных решений, которые определяют, что считается «испытанием в реальных условиях». При применении вне аппаратной сферы нужны отраслевые формулировки критериев.
Уровень не показывает риск «в деньгах и времени»: два проекта с одинаковым TRL могут отличаться на порядок по стоимости следующего перехода. Для планирования нужна дополнительная оценка трудоёмкости и неопределённости, а не только номер уровня.
Типовые ошибки
Ошибка 1: присвоение уровня без документального подтверждения
Команда заявляет высокий TRL на основе оптимистичной самооценки, а не пройденных и задокументированных испытаний, соответствующих каждому промежуточному уровню.
Как избежать
подтверждать каждый уровень конкретной документацией — техническим заданием, протоколами испытаний, актами верификации, а не декларативным заявлением.
Ошибка 2: перескакивание уровней в описании прогресса
В отчётности технология «перепрыгивает» с TRL 3 сразу на TRL 6, минуя фактическое прохождение и подтверждение промежуточных этапов 4 и 5.
Как избежать
явно проверять последовательность — нельзя достичь TRL 8-9, если не закрыты и не подтверждены более ранние уровни.
Ошибка 3: TRL как единственный критерий инвестиционной готовности
Высокий TRL интерпретируется инвестором или грантовым комитетом как достаточное основание для финансирования, без отдельной оценки рыночного спроса и производственной готовности.
Как избежать
рассматривать TRL как одну из трёх осей оценки (технология/производство/рынок), не единственный и не достаточный сам по себе показатель.
Ошибка 4: путаница TRL и MRL
Готовность к масштабному производству молчаливо предполагается автоматически следующей из высокого TRL, хотя это два разных, независимо оцениваемых параметра.
Как избежать
явно оценивать MRL отдельно от TRL, особенно перед решением о масштабировании производства технически готовой технологии.
Ошибка 5: недооценка ресурсов на переход через «долину смерти»
Бюджет проекта планируется без явного резерва на самый капиталоёмкий и рискованный участок — переход от лабораторного макета (TRL 4) к демонстрации в реальных условиях (TRL 7).
Как избежать
заранее закладывать отдельный, реалистично оценённый бюджет и временной горизонт именно на этот переходный участок, не экстраполировать линейно скорость прохождения ранних уровней на более капиталоёмкие поздние.
Ошибка 6: оценивают компоненты и не оценивают систему.
Каждый компонент имеет высокий TRL, и система объявляется готовой, хотя интеграция, интерфейсы и изменения при сборке не проверены; в исследовании практики применения TRL именно вопросы интеграции, интерфейсов и общей зрелости системы названы респондентами самыми острыми.
Как избежать
оценивать отдельно уровень системы и уровень каждой критической технологии; для интеграции заранее задать испытания на уровне системы и критерии перехода.
Ошибка 7: оценивает только команда проекта.
Самооценка склонна к оптимизму: неудобные результаты испытаний трактуются в пользу проекта, уровень присваивается «по ожиданию».
Как избежать
привлекать независимых экспертов, опираться на письменные критерии и документы (подход руководства GAO по оценке технологической готовности) и хранить протоколы вместе с решением об уровне.
План внедрения
Шаг 1: честная самооценка текущего уровня
Пройти по всем 9 уровням последовательно, для каждого честно проверив, есть ли документальное подтверждение (протоколы, акты испытаний, отчёты), а не интуитивная оценка.
Зафиксировать текущий подтверждённый уровень как отправную точку, не желаемый.
Шаг 2: планирование перехода через «долину смерти»
Отдельно оценить ресурсы (бюджет, время), нужные для перехода TRL 4→7 — не экстраполировать линейно из скорости прохождения более ранних, дешёвых уровней.
Параллельно оценить MRL — готовность к масштабному производству — не полагаясь, что она автоматически следует из технической готовности.
Шаг 3: трёхмерная проверка перед решением о запуске
Оценить рыночную готовность (спрос, юнит-экономика, регуляторная приемлемость) отдельно от TRL и MRL.
Принимать решение о масштабировании только при достаточной готовности по всем трём осям одновременно, не по одной технической.
Далее: пересмотр при смене условий
Пересматривать оценку TRL/MRL/рыночной готовности при значимых изменениях — новых испытаниях, смене регуляторной среды, изменении рыночного спроса, не считать однажды присвоенный уровень зафиксированным навсегда.
Как реализовать этот план с помощью фрейма «Уровень технологической готовности (TRL)» в OrgDevTools
Фрейм в OrgDevTools — бесплатный тренажёр для честной самооценки по шкале TRL. Для каждого из девяти уровней вы отмечаете силу доказательства и прикладываете ссылки на документы. По этим отметкам фрейм сам считает подтверждённый уровень, учитывает критические элементы системы и сравнивает результат с целью.
Вкладка «1. Уровни и доказательства» — Шаг 1: честная самооценка текущего уровня
На вкладке девять строк, от TRL 1 («Наблюдение и описание базовых физических принципов») до TRL 9 («Подтверждена успешной реальной эксплуатацией»). В каждой строке есть выпадающий список статуса доказательства с четырьмя вариантами, у каждого свой цвет:
«нет» — серый, стоит по умолчанию;
«заявлено» — жёлтый;
«задокументировано» — голубой;
«независимо подтверждено» — зелёный.
Если нажать на формулировку уровня, раскроется список документов. Подсказка в поле — «Протокол, отчёт, дата испытания». Рядом с формулировкой видно число непустых записей («N док.»).
Фрейм сам определяет достигнутый уровень: это наивысший уровень, который вместе со всеми уровнями ниже имеет статус «задокументировано» или «независимо подтверждено». Номера достигнутых уровней подсвечиваются зелёным, остальные остаются серыми. Заявленный уровень — самый высокий, у которого стоит хотя бы «заявлено».
Вкладка «2. Критические элементы и цель» — Шаг 2: планирование перехода
Здесь ведётся список критических технологических элементов, то есть компонентов, без которых система не работает. Строка добавляется кнопкой «+ элемент», удаляется крестиком. Для каждого элемента вы пишете название и выбираете TRL от 1 до 9 (по умолчанию стоит «—»). В расчёт идут только элементы, у которых есть и название, и уровень.
TRL системы фрейм считает как меньшее из двух значений: достигнутого уровня и уровня самого незрелого элемента. Это рабочая настройка фрейма. В том же разделе выбирается «Целевой TRL» от 1 до 9, по умолчанию он не задан.
Вкладка «Визуализация» — наглядная сверка шагов 1–2
Слева показана лестница из девяти полос. Каждая полоса окрашена по статусу уровня, текущий TRL системы обведён рамкой, у целевого уровня стоит пометка «← цель». Справа — полосы критических элементов, длина каждой пропорциональна её TRL из 9. Самый незрелый элемент выделен красным, остальные синие. Если элементов нет, выводится «Элементы не заданы».
Вкладка «Итоги» — Шаг 3: решение по технической оси
На вкладке четыре плитки: «заявлено», «подтверждено», «TRL системы», «цель». Ниже — вердикт. Фрейм проверяет условия по порядку и показывает первое сработавшее:
Ни один уровень не отмечен. Фрейм просит отметить доказательства и напоминает, что уровень присваивается только по документам.
Ниже заявленного уровня есть уровень со статусом «нет». Фрейм сообщает: «уровень N пропущен. TRL нельзя перескакивать» и называет достигнутый уровень.
Есть уровни со статусом «заявлено». Фрейм перечисляет их и просит собрать протоколы испытаний.
Какой-то критический элемент ниже достигнутого уровня. Вердикт красный: элемент назван, TRL системы снижен до его уровня, совет — «дозревайте этот элемент первым».
TRL системы ниже цели. Фрейм называет следующий уровень и просит определить критерии выхода и испытание.
TRL 9. Технология подтверждена эксплуатацией.
Во всех остальных случаях фрейм пишет: «Подтверждён TRL N». Если цель задана, добавляет пометку, что она достигнута. Если последний уровень не подтверждён независимо, советует получить такое подтверждение.
Кнопка «Создать задачу» создаёт задачу «Довести технологию до TRL N+1» (не выше 9). В описание задачи подставляется текст вердикта.
Чего фрейм не делает
Не читает документы. Статус выбирается вручную, и «задокументировано» можно поставить даже при пустом списке.
Не проверяет TRL критических элементов: элементу можно указать любой уровень, доказательства к нему не требуются.
Не оценивает MRL и рыночную готовность, поэтому трёхмерную проверку из шага 3 он не заменяет.
Не считает бюджет и сроки перехода TRL 4→7, не выделяет «долину смерти».
Не проверяет, названы ли отличия испытательной среды от реальной.
Не предлагает целевые пороги вроде TRL 6/7: цель вы задаёте сами.
Не хранит историю пересмотров оценки.
Заполнили фрейм? Сохраните, чтобы не потерять
Книги по теме
ГОСТ Р 58048-2017 «Трансфер технологий. Методические указания по оценке уровня зрелости технологий». Официальный российский нормативный документ, адаптирующий методологию NASA под национальную практику оценки готовности технологий к трансферу и коммерциализации.
Джон Манкинс — «Technology Readiness Levels: A White Paper» (NASA, 1995). Документ, в котором к семи уровням добавлены 8 и 9 и оформлена привычная девятиуровневая шкала.
GAO — «Technology Readiness Assessment Guide: Best Practices for Evaluating the Readiness of Technology for Use in Acquisition Programs and Projects» (GAO-20-48G, 2020). Практическое руководство по проведению независимой оценки TRL: шаги, роль экспертов, документирование доказательств.
Алисон Олеховски, Стивен Эппингер, Нитин Джоглекар — «Technology Readiness Levels at 40» (PICMET, 2015). Исследование практики и проблем применения TRL в организациях по интервью со специалистами.
%22%2F%3E%3Ccircle%20cx%3D%22656%22%20cy%3D%22108%22%20r%3D%22153%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22622%22%20cy%3D%22295%22%20r%3D%2281%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22617%22%20cy%3D%22329%22%20r%3D%22109%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.11%22%2F%3E%3Crect%20x%3D%2240%22%20y%3D%2248%22%20width%3D%22124%22%20height%3D%2230%22%20rx%3D%2215%22%20fill%3D%22%234f46e5%22%2F%3E%3Ctext%20x%3D%2258%22%20y%3D%2268%22%20font-size%3D%2215%22%20font-weight%3D%22700%22%20fill%3D%22%23fff%22%20letter-spacing%3D%220.8%22%3E%D0%9C%D0%95%D0%A2%D0%9E%D0%94%D0%98%D0%9A%D0%90%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22150%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E%D0%9F%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B9%20%D1%8F%D0%B7%D1%8B%D0%BA%20%D0%B2%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22198%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E%D0%BA%D0%BE%D0%BC%D0%BC%D1%83%D0%BD%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8%20%D1%81%20%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%BE%D0%BC%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22372%22%20font-size%3D%2215%22%20font-weight%3D%22600%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%22.75%22%3Eorgdevtools.ru%3C%2Ftext%3E%3C%2Fsvg%3E)
%22%2F%3E%3Ccircle%20cx%3D%22298%22%20cy%3D%22-311%22%20r%3D%226%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22127%22%20cy%3D%22-24%22%20r%3D%22-17%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22218%22%20cy%3D%22-231%22%20r%3D%22-1%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.11%22%2F%3E%3Crect%20x%3D%2240%22%20y%3D%2248%22%20width%3D%22124%22%20height%3D%2230%22%20rx%3D%2215%22%20fill%3D%22%234f46e5%22%2F%3E%3Ctext%20x%3D%2258%22%20y%3D%2268%22%20font-size%3D%2215%22%20font-weight%3D%22700%22%20fill%3D%22%23fff%22%20letter-spacing%3D%220.8%22%3E%D0%9C%D0%95%D0%A2%D0%9E%D0%94%D0%98%D0%9A%D0%90%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22150%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%B8%D0%B3%D0%BC%D0%B0%20%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22198%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E%D1%80%D0%B8%D1%81%D0%BA%D0%B0%D0%BC%D0%B8%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22372%22%20font-size%3D%2215%22%20font-weight%3D%22600%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%22.75%22%3Eorgdevtools.ru%3C%2Ftext%3E%3C%2Fsvg%3E)
%22%2F%3E%3Ccircle%20cx%3D%22255%22%20cy%3D%22-243%22%20r%3D%2210%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.05%22%2F%3E%3Ccircle%20cx%3D%22234%22%20cy%3D%22-222%22%20r%3D%2237%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.08%22%2F%3E%3Ccircle%20cx%3D%22119%22%20cy%3D%22-221%22%20r%3D%229%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%220.11%22%2F%3E%3Crect%20x%3D%2240%22%20y%3D%2248%22%20width%3D%22124%22%20height%3D%2230%22%20rx%3D%2215%22%20fill%3D%22%234f46e5%22%2F%3E%3Ctext%20x%3D%2258%22%20y%3D%2268%22%20font-size%3D%2215%22%20font-weight%3D%22700%22%20fill%3D%22%23fff%22%20letter-spacing%3D%220.8%22%3E%D0%9C%D0%95%D0%A2%D0%9E%D0%94%D0%98%D0%9A%D0%90%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22150%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E%D0%9E%D1%81%D0%BE%D0%B7%D0%BD%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22198%22%20font-size%3D%2238%22%20font-weight%3D%22800%22%20fill%3D%22%230f2b3d%22%3E%D0%B1%D0%BB%D0%B0%D0%B3%D0%BE%D1%82%D0%B2%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C%3C%2Ftext%3E%3Ctext%20x%3D%2240%22%20y%3D%22372%22%20font-size%3D%2215%22%20font-weight%3D%22600%22%20fill%3D%22%234f46e5%22%20fill-opacity%3D%22.75%22%3Eorgdevtools.ru%3C%2Ftext%3E%3C%2Fsvg%3E)