SAFe®: что это такое и как внедрить фреймворк в компании

 

Сергей Рогачев и Мария Фокина

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

Координировать процесс разработки одной небольшой команды бывает очень непросто, а теперь представим, что над одним крупным проектом работает десять разных команд. На кону не только ответственность, но и круглые суммы, поэтому от взаимодействия подразделений зависят сроки, достижение цели и окупаемость. В таком случае на помощь приходит фреймворк SAFe®, который синхронизирует десятки разных команд и помогает им не сбиться с пути.

Что такое SAFe и кому он нужен

SAFe (Scaled Agile Framework® — фреймворк для масштабирования Agile. Его цель — объединить работу команд, которые задействованы в одном большом проекте, но при этом используют разные подходы и практики в управлении проектами, даже негибкие

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

SAFe объединяет лучшие практики трёх подходов к управлению проектами:

• Agile отвечает за гибкий подход к работе, учёт обратной связи и быструю реакцию на изменения в проекте
• Lean помогает управлять ожиданиями, устранять потери и контролировать нагрузку сотрудников
• DevOps связывает разработку и эксплуатацию, поддерживая регулярный контроль изменений кода

Как устроен SAFe: команды, роли и планирование

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

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

Роли

В потоке разработки работают один или несколько ART (Agile Release Train) — устойчивое объединение Agile-команд, которые развивают один продукт и следуют общему направлению. Обычно в одном «поезде» от 5 до 12 кросс-функциональных команд. Количество участников — от 50 до 125 человек, которые обладают компетенциями, необходимыми для разработки, проверки и выпуска конкретного продукта.

Кроме ART, в SAFe есть и другие роли. Собрали список с описанием задач ниже.

Вот так схематично может выглядеть процесс разработки SAFe: от потребности пользователя до конечного результата.

Планирование

Все участники ART перед началом работы встречаются на совместном планировании PI, то есть интервала планирования (Planning Interval или PI), размер которого от 8 до 12 недель.

Планирование PI длится около 2 дней. В это время команды ATR разбираются в контексте бизнеса, приоритетах, определяют риски и технические ограничения, которые могут возникнуть на этапе разработки. Здесь же обсуждают, смогут ли команды потянуть объём работы, — то есть определяют их доступную ёмкость с учётом состава и других обязательств.

Далее согласуют цели на ближайший квартал (примерно 12 недель), определяют зависимости и приоритеты задач, а затем разбивают большую работу на короткие итерации и назначают исполнителей. Результат можно выпускать в течение PI, ждать его завершения ради релиза не требуется.

Цели PI должны нести ценность для пользователя, быть понятными каждому участнику рабочего процесса и отображать конкретный результат, желательно с цифрами.

❌ Не ок

Улучшить систему аутентификации

✅ Ок

Сократить время аутентификации пользователя с десяти до пяти секунд

Цели PI, планы работы команд, зависимости, риски и вехи отображаются на общей доске планирования ART (ART Planning Board), благодаря которой команды могут видеть работу других участников и отслеживать процесс. Доска планирования не похожа на привычную Канбан-доску, потому что у неё другое назначение.

Канбан-доска показывает этапы, через которые проходят задачи, а доска планирования ART — зависимости команд, сроки внутри интервала планирования и контрольные точки. Но использовать Канбан-доску для планирования работ никто не запрещает.

Core SAFe и четыре конфигурации SAFe 6.0

Core SAFe — базовые принципы и практики для объединения команд, а четыре конфигурации SAFe — прикладные решения, которые помогут адаптировать фреймворк под задачи и масштабы координации команд.

💡 Ниже — четыре конфигурации SAFe. Применять их одновременно необязательно, потому что это не этапы внедрения

Чем SAFe отличается от Scrum и других подходов

В основе SAFe — Agile-методология, но адаптированная под большую организацию, где над продуктом может работать множество разных команд. Они в свою очередь могут внедрять фреймворки Agile — например Scrum или Kanban-метод.

Scrum описывает, как одна команда работает над сложным продуктом: выбирает цель спринта, создаёт полезный результат, проверяет его и меняет дальнейший план. Kanban-метод отвечает за управление потоком задач, их жизненный цикл и устранение потерь во время рабочего процесса. Фреймворки можно объединять, если считаешь это необходимым.

SAFe смотрит на работу нескольких команд в рамках портфеля: добавляет правила согласования и управления крупными и сложными проектами.

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

Как работает SAFe на примере нескольких команд

Как внедрить SAFe: от диагностики до пилота

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

Шаг 1: определить проблему и поток создания ценности

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

Собери представителей продукта, разработки и эксплуатации и обозначь границы потока. Если причина задержек локальная, сначала попробуй устранить её. Для пилота SAFe нужна проблема, которая требует согласованной работы команд. Мы не собираемся внедрять фреймворк просто так.

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

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

Официальный сайт SAFe приводит пример того, как может выглядеть упрощённая карта потока ценности для компании, которая занимается доставкой.

Отправить посылку (потребность клиента) → оформление доставки → приём или забор посылки (курьером, например) → определение маршрута доставки (пользователю) → передача посылки получателю → сверка взаиморасчётов → прибыль.

Упрощённая схема потока ценности от потребности пользователя до прибыли компании.
Источник: https://scaledagile.com/blog/safe-and-business-architecture

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

Шаг 2: согласовать поддержку руководства и состав пилотного ART

Выбери направление, где можно протестировать SAFe, и собери команды с необходимыми компетенциями — тех, кто будет разрабатывать, тестировать и выпускать решение. Также определись, с какими внешними участниками процесса предстоит договариваться.

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

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

Шаг 3: подготовить роли, приоритеты и первое PI Planning

До планирования обсуди с участниками их полномочия и подготовь их к новым ролям. На PI Planning участники сопоставляют желаемый объём с возможностями и согласуют цели. Результат шага — выполнимый совместный план с зависимостями и рисками. За организацию отвечает RTE, за продуктовые приоритеты — Product Management, за реалистичность командных планов — сами команды.

Пилот можно запланировать в Weeek. Создать рабочее пространство и с помощью режима Доски отслеживать ход работ. Мы решили разделить пилот на три этапа — у каждого из них своя доска с задачами. Вот так это выглядит.

Так можно запланировать пилот на Канбан-доске. Теги обозначают роль ответственного за задачу

Шаг 4: провести PI, проверить результат и скорректировать процесс

В течение PI регулярно проверяй интегрированный продукт. Не откладывай сборку на последние дни: иначе времени исправить несовместимости может не быть. Если меняются условия, обсуждай их влияние на цели и фиксируй корректировки. Делать это нужно регулярно, чтобы ничего не упустить — для этого задачи на созвоны с командами в таск-менеджере можно сделать повторяющимися и выбрать интервал повторения. Например, ежедневно или каждую пятницу.

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

В конце PI подведи итоги — обсудите с командой результат, разберите показатели и причины проблем. Из обсуждения должны появиться конкретные улучшения, которые нужно доработать далее. Например, если команды ждали тестовую среду, её подготовку нужно включить в дальнейшую работу.

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

Как оценить результат и избежать типичных ошибок

Вернись к проблеме, с которой начиналось внедрение. Если выпуск задерживался из-за зависимостей, проверь, сократилось ли время ожидания.

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

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

https://tinyurl.com/4r93xhmu

Agile, Scrum, Kanban и Waterfall: в чём разница между методологиями

 

Дмитрий Ильенков,Виталий Шаров

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

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

Методологии вроде Waterfall, Agile, Scrum и Kanban как раз помогут построить прочный дом 🔨

В статье разберём, как не спутать концепции, на что обратить внимание при выборе и почему гибридные подходы вроде Scrumban иногда спасают даже самые сложные проекты.

Что такое Agile

Agile — это подход к управлению проектами, где главное — адаптироваться к изменениям, а не строго следовать плану. Вот несколько основных принципов:

• Люди и взаимодействие важнее процессов
• Работающий продукт ценнее детальной документации
• Сотрудничество с клиентом важнее формальных договоренностей
• Готовность к изменениям важнее следования изначальному плану

Netflix использует Agile для тестирования новых функций интерфейса, а банки — для разработки мобильных приложений.

Однако Agile применяют не только в IT, но и других сферах. Например, в маркетинге, если надо запустить рекламные кампании, а также в производстве — при создании прототипов продуктов и их дальнейшей доработке после тестирования.

🛋️ Чтобы лучше представить себе Agile, разберём пример. Представь, что ты хочешь обновить интерьер гостиной. По традиционному подходу, нужно заранее составить план, и по нему расставить всю мебель. Но потом можно обнаружить, что диван стоит неудобно, а журнальный столик занимает слишком много места

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

Плюсы и минусы Agile

Что такое Waterfall

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

Преимущества Waterfall — предсказуемость. Чёткие сроки, фиксированный бюджет и минимум недопонимания с заказчиком, ведь всё зафиксировано в документах.

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

🧑‍🏭 И снова пример. Представь, что собираешь новый шкаф по бумажной инструкции. Процесс будет выглядеть примерно так:

1. Читаешь инструкцию

2. Готовишь инструменты и проверяешь, все ли детали на месте

3. Собираешь корпус, дверцы и полки

4. Проверяешь, всё ли прикручено и работает ли дверца

5. Ставишь шкаф на место и начинаешь пользоваться

💡 Если на этапе установки вдруг выяснится, что дверцы перепутаны, придётся возвращаться назад, разбирать и переделывать. Именно так и работает Waterfall: этапы идут строго друг за другом, и вернуться на шаг назад уже сложно

Плюсы и минусы Waterfall

Waterfall vs Agile

Waterfall и Agile отличаются философией управления проектами. Waterfall работает по принципу «спланируй всё заранее», Agile — «адаптируйся по ходу». Для выбора подхода нужно понять, есть ли чётко сформулированные требования уже на старте и насколько критичными будут изменения в процессе.

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

Критерий	Waterfall	Agile
Гибкость	Низкая. Изменения = перепланирование	Высокая. Правки вносятся в каждом цикле
Документация	Детальная на каждом этапе	Минимум, акцент на рабочий продукт
Риски	Ошибки обнаруживаются на поздних этапах	Проблемы решаются сразу в итерациях
Участие клиента	Только на старте и при сдаче проекта	Постоянная обратная связь
Срок/бюджет	Жёстко фиксированы	Гибкие, могут корректироваться

Когда что выбрать

Waterfall подходит для проектов со стабильными требованиями, где изменения маловероятны или недопустимы. Подход актуален, если заказчик не готов участвовать в процессе после того, как ТЗ утвердили.

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

Agile выигрывает в условиях неопределённости, где требования размыты или могут меняться. Например, разработка нового продукта с тестированием гипотез или создание MVP для быстрого выхода на рынок. В таких проектах клиент хочет видеть прогресс и влиять на продукт.

Типичные ошибки при выборе

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

• Agile подходит не везде. Там, где важны чёткие правила и безопасность, гибкость может только навредить. Если каждую неделю менять требования к продукту, можно не пройти аудит: система перестанет соответствовать требованиям регуляторов
• Waterfall — не для стартапов. Представь: команда год пишет идеальное ТЗ для мобильного приложения, а пока они планируют, рынок уже захватывают конкуренты. В мире быстрых изменений такой подход не работает
• Смешивать можно, но с умом. Если у проекта фиксированный бюджет, но задачи постоянно меняются, как в Agile, легко попасть в ловушку: команда буксует, заказчик нервничает, дедлайны летят. Без чёткого понимания, зачем миксовать подходы, получается только хаос

Выбирать подход стоит как инструмент: молотком не закручивают шурупы, даже если он навороченный 🙂

Что такое Scrum

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

Из чего состоит Scrum

В Скраме есть роли, артефакты и церемонии (их ещё называют событиями). Всё вместе помогает команде работать итеративно, слаженно и прозрачно. Давай разберёмся с каждый элементом.

Роли: кто входит в состав Scrum-команды 👇

• Владелец продукта (Product Owner). Определяет требования, формирует бэклог и расставляет приоритеты. Например, выбирает между добавлением кнопки оплаты и исправлением бага
• Scrum-мастер. Устраняет препятствия (например, конфликты с другими отделами) и следит за соблюдением процесса
• Команда разработки. Программисты, дизайнеры и тестировщики, которые самостоятельно решают, как выполнять задачи спринта

Артефакты — инструменты для визуализации прогресса 👇

• Бэклог продукта — список всех требований и задач
• Бэклог спринта — задачи, которые отбираются командой на планировании для выполнения в этом спринте
• Инкремент — готовый и протестированный кусочек продукта, который можно показать пользователям. Он создаётся по итогам каждого спринта

Церемонии или события 👇

• Планирование спринта (Sprint Planning). Команда выбирает задачи из бэклога продукта и планирует работу на ближайший спринт
• Ежедневный стендап (Daily Scrum). 15-минутная встреча команды, где обсуждают, кто что сделал и что будет делать, есть ли препятствия
• Ревью спринта (Sprint Review). Команда показывает, что успела сделать за спринт. Обсуждают обратную связь от заказчиков
• Ретроспектива (Sprint Retrospective). Команда обсуждает, как прошёл спринт: что сработало, что нет, и как можно улучшить процесс

Плюсы и минусы Scrum

Что такое Kanban

Kanban — это визуальный подход к управлению задачами, который напоминает живую карту рабочего процесса. Представь доску с колонками Сделать, В работе, Готово — это и есть Канбан-доска. Каждая задача — карточка, которая перемещается между этапами, пока не завершится. Так команда видит, где возникают заторы, кто чем занят и как оптимизировать поток.

Главный секрет Kanban — WIP-лимиты (ограничения на количество задач в работе). Если в колонке Разработка стоит лимит в 3 задачи, то нельзя взять новую, пока одна из текущих не перейдёт в «Тестирование». Это предотвращает перегрузку и заставляет фокусироваться на завершении, а не на старте.

Плюсы и минусы Kanban

✅ Лови мини-подборку текстов, чтобы освоить Канбан-метод:

• Что такое Канбан — читай здесь
• Как использовать Канбан для личных задач — вот ссылка
• С чего начать запуск Канбана по STATIK — смотри тут
• WIP-лимиты: зачем нужны в Канбане — подробности здесь
• Как вести бэклог по Канбан-методу — инструкция по ссылке
• Лучшие доски для Канбана — подборка здесь

Scrum vs Kanban

Чтобы не запутаться, представь: Scrum подходит для проектов, где нужно регулярно поставлять результат и пересматривать приоритеты (например, запуск нового продукта), а Kanban — для поддержки текущих процессов с непредсказуемым объёмом задач (например, техническая поддержка или оперативная разработка).

Ключевые различия

Чтобы увидеть, какой подход лучше впишется в твой рабочий контекст, сравним Scrum и Kanban ⤵️

Критерий	Scrum	Kanban
Структура	Жёсткие спринты (2–4 недели)	Непрерывный поток задач
Роли	Scrum-мастер, Product Owner	Нет строгих ролей
Планирование	В начале спринта	По мере поступления задач
Изменения	Запрещены во время спринта	Допустимы в любой момент
Метрики	Velocity (скорость команды)	Lead time (время выполнения)

Когда выбрать Scrum, а когда — Kanban?

Выбирайте Скрам, если:

🔹 есть чёткие цели на ближайшие недели. Например, нужно выпустить MVP мобильного приложения к определённой дате

🔹 команда готова к регулярным встречам: ежедневным стендапам и ретроспективам

🔹 требуется строгая дисциплина — Scrum не прощает хаоса и самодеятельности

Канбан подойдёт в таких случаях:

🔹 задачи приходят спонтанно, как в службе поддержки или при работе с багами

🔹 если нужна максимальная гибкость — например, стартап на ранней стадии, где приоритеты меняются ежедневно.

🔹 команда распределённая или часть сотрудников работает неполный день — Kanban не требует синхронизации по спринтам.

Scrum не подходит для потоковой рутинной работы, где нет смысла в спринтах, ролях и ретроспективах. Он лучше работает там, где продукт развивается, а требования меняются. А вот Kanban, наоборот, хорошо справляется с предсказуемыми задачами. При этом он требует настройки и может быть сложен, если управлять большим количеством зависимостей.

Как комбинируют подходы в реальности

Гибридные методологии — это не компромисс, а осознанное решение, когда ни один готовый фреймворк не покрывает все особенности проекта. Так можно адаптировать подход под реальность, а не подгонять реальность под подход.

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

Другой пример — стартапы, которые внедряют Kanban внутри Agile. Команда выпускает релизы по Scrum, а для срочных багов используют Kanban-доску. Пока все заняты спринтом, пара разработчиков разбирает задачи из колонки «Срочно», не сбивая общий ритм. Это помогает избежать простоев из-за мелких ошибок.

Как адаптировать процессы под себя

Ошибка при комбинировании — пытаться объять необъятное. Гибридная методология не должна включать элементы всех фреймворков сразу. Стоит выбрать 2–3 ключевых инструмента (например, спринты + WIP-лимиты + общие стендапы) и отталкиваться от них. Команда должна понимать, что цель не в следовании догмам, а в создании работоспособного процесса.

Сравнение всех подходов: Waterfall, Agile, Scrum, Kanban

Теперь, когда мы познакомились с подходами в управлении проектами, попробуем сравнить эти популярные методологии. Это поможет тебе разложить по полочкам всё, о чём прочитал выше.

	Waterfall	Agile	Scrum	Kanban
Плани-рование	Детальный план на весь проект. Этапы фиксированы	Гибкое планирование с итерациями (спринтами)	Планирование спринтов (2-4 недели). Чёткие цели на каждый цикл	Планирование по мере поступления задач. Фокус на потоке работы
Для чего подходит	Проекты с чёткими требованиями	Проекты с меняющимися требованиями (стартапы, digital-продукты)	Команды, которым нужна структура (разработка ПО, маркетинг)	Процессы с непрерывным потоком задач (поддержка, DevOps, производство)
Гибкость	Низкая. Изменения требуют перепланирования	Высокая. Правки вносятся между итерациями	Средняя. Изменения возможны между спринтами	Высокая. Задачи добавляются/меняются в реальном времени
Участие клиента	Только на этапах согласования ТЗ и сдачи проекта	Постоянное. Клиент участвует в обсуждении результатов каждой итерации	Регулярное (например, на ревью спринта)	Минимальное. Клиент видит прогресс, но не вовлечён в процесс глубоко
Докумен-тация	Обязательная на каждом этапе (ТЗ, проектная документация, тест-кейсы)	Минимум формальностей. Акцент на рабочий продукт	Умеренная (бэклог, цели спринтов)	Минимальная. Визуализация задач на доске — главный инструмент
Сроки и бюджет	Жёстко фиксированы	Гибкие. Могут корректироваться по мере итераций	Фиксированные спринты, но бюджет может меняться	Гибкие. Нет жёстких временных рамок
Риски	Ошибки находят на поздних этапах (например, при тестировании)	Проблемы решаются в рамках коротких циклов	Управляются через ретроспективы и адаптацию процесса	Прозрачность потока задач снижает риски «заторов»
Примеры проектов	Внедрение ERP-системы, запуск спутника	Разработка мобильного приложения, создание MVP	Запуск нового функционала сайта, продуктовые эксперименты	Поддержка IT-инфраструктуры, обработка заявок в службе поддержки

Коротко о главном: как выбрать подход к управлению проектами

В мире проектного менеджмента существует несколько ключевых подходов. У каждого из них свои особенности.

Waterfall — классический последовательный метод, где каждый этап строго следует за предыдущим. Идеален для проектов с чёткими требованиями и предсказуемыми результатами.

Agile — гибкий подход, основанный на итерациях и быстрой адаптации к изменениям. Подходит для динамичных проектов с неопределёнными требованиями.

Scrum — фреймворк внутри Agile-методологии, фокусирующийся на командной работе и регулярных спринтах.

Kanban — метод визуализации рабочих процессов с акцентом на непрерывную поставку ценности.

При выборе подхода важно учитывать:

• стабильность требований проекта
• необходимость гибкости
• особенности команды
• сложность задач
• сроки реализации

🏄 Главное — помнить, что нет универсального решения. В выборе подхода нужно ориентироваться на условия проекта и потребности команды. Иногда эффективнее всего будет сочетание элементов разных методологий.

https://tinyurl.com/hdta7p85