🎯 Почему сопровождение в проектных системах - это отдельная профессия

Слово «сопровождение» часто трактуют как угодно: от L1-поддержки до «ну подправьте нам что-нибудь раз в месяц».
Но на самом деле есть две кардинально разные модели.

🟦 Продуктовая модель (SaaS, коробки, онлайн-продукты)

Один продукт - много клиентов.
Логика общая, изменения общие, ошибка у одного - исправление у всех.

В данном случае, сопровождением занимается сам продуктовая команда.

🟪 Проектная / кастомная модель (например СЭД)

Один продукт - но каждый клиент живёт в своём уникальном мире.
Внедрение выполняет прикладную разработку под каждого клиента ➡️ команда уходит на следующий проект ➡️остаётся система, которую нужно понимать, развивать и не ломать.

Здесь продуктовая команда не подходит, а команда внедрения уже на новом проекте.

Поэтому появляется отдельная роль - аналитик сопровождения, который держит контекст, логику клиента, архитектуру и последствия изменений.

И это уже не просто поддержка.

🧩 Суть в двух предложениях

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


❓ Какая роль у вас ближе по факту: аналитик сопровождения или всё-таки L2?

👀 Сопровождение глазами аналитика: что мы делаем каждый день

Мы с вами уже говорили, что про сопровождение часто думают так:
что-то сломалось → починили → закрыли обращение (он же тикет).

На практике всё сильно шире 👇

🛠 Гарантийная поддержка после внедрения
Когда система только вышла в прод, проведена ОПЭ, и она ещё «осваивается» в реальной жизни.

🚨 Инцидентная поддержка
Ошибки, сбои, странное поведение системы.
Важно не просто починить, а понять причину и последствия.

🔁 Запросы на изменение
Бизнес меняется → процессы меняются → система тоже должна меняться.

🧾 Запросы на обслуживание
Пользователи, роли, справочники, настройки, регламенты.
Рутина, без которой система просто не живёт.

🏗 Анализ и изменения архитектуры
Чтобы решение не превратилось в «лоскутное одеяло» через год.

⬆️ Обновления до новых версий
Не «поставили и забыли», а анализ влияния и адаптация под кастомизацию и процессы заказчика.

💬 Консультационная поддержка
Вопросы, сомнения, сценарии «а если мы сделаем вот так».

📌 Суть простая:
сопровождение - это не поддержка системы, а поддержка её ценности для бизнеса.

Если этим никто не управляет - система деградирует, даже если формально «работает».

❓А теперь вопрос-затравка на следующий пост:
Что из этого списка у вас чаще всего недооценивают?

Что чаще всего недооценивают в работе аналитика 🤯

Со стороны кажется, что аналитик - это:
📄 собрал требования
🗂 оформил
➡️ передал дальше

На практике - всё немного иначе.

Вот что почти всегда недооценивают (и во внедрении, и в сопровождении):

🗣 Перевод с «человеческого» на «системный»

Заказчик говорит словами.
Система живёт логикой.

Аналитик - переводчик между этими мирами:
▪️ожидания ↔️ ограничения
▪️желания ↔️ последствия
▪️«хочу» ↔️ «что реально получится»

⚖️ Работа с неопределённостью

Часто требований ещё не существует.
Есть ощущения, гипотезы, страхи и «давайте пока так».

И аналитик:
▪️формирует структуру из хаоса
▪️помогает принять решение
▪️берёт на себя ответственность за выбор

Это сильно выматывает - и почти никогда не видно со стороны.

🔄 Поддержание целостности решения

Каждая маленькая правка:
▪️влияет на процессы
▪️цепляет архитектуру

Недооценивают, что аналитик постоянно держит в голове всю систему, а не одну задачу.

😮‍💨 Эмоциональная нагрузка

Переговоры. Давление сроков. Конфликты интересов.
«Почему так долго?», «А раньше работало», «Вы же аналитик - разберитесь».

Это не soft skills «по желанию».
Это часть профессии.

💡 Поэтому аналитика нельзя мерить количеством документов или закрытых задач.
Его работа - в том, чтобы система в итоге работала и развивалась, а не просто была «сделана».

❓Какой из этих пунктов у тебя «отъедает» больше всего энергии?

🎄 С наступающим Новым годом, коллеги-аналитики и все, кто живёт в сложных системах

Этот год был разный.
Где-то - внедрения без документации.
Где-то - сопровождение без истории решений.
Где-то - ожидания «быстро и просто» для задач, которые так не работают.

Мы много думали, задавали неудобные вопросы, откладывали ответы «на потом», держали контекст и спасали системы от деградации - часто незаметно, но очень вовремя.

Пусть в новом году:
▪️требования будут формулироваться чуть яснее 🧩
▪️решений «на коленке» станет меньше ⚙️
▪️паузы на анализ будут восприниматься как сила, а не слабость 🧠
▪️а сопровождение наконец будут считать полноценной аналитической работой, а не «после внедрения само как-нибудь» ✨

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

С Новым годом.
Пусть системы будут устойчивыми, а вы - в ресурсе 🍷

Про НДС, дедлайны и почему прод лучше не трогать под Новый год 🎄⚠️

С 1 января в России вступили в силу новые ставки НДС.
И это тот случай, когда изменение в законе мгновенно превращается в изменение в IT-системах.

Особенно у тех, кто:
▪️обменивается первичными документами через сервисы ЭДО
▪️интегрирован с внешними площадками
▪️работает не «в вакууме», а в цепочке из нескольких систем

📌 Фактически у всех таких заказчиков:
🔹поменялись форматы документов
🔹обновились правила валидации
🔹потребовались изменения в расчётах
🔹сломалась обратная совместимость со старыми версиями

И всё это - в кратчайшие сроки.
Потому что с 1 января документы с «не той» ставкой просто не проходят.

Что это значит на практике 🧩
🔸обновления пришлось делать массово и синхронно
🔸правки касались не одного места, а всей цепочки: от БД до интеграций
🔸любое расхождение = ошибка у контрагента
🔸поддержка 1–2 линии тут бессильна - нужна аналитика в контексте конкретной системы

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

И главный вывод 👇

Обновления продуктива перед новогодними праздниками - плохая идея.

Почему:
▫️команда в отпуске или на минимальном составе
▫️бизнес не готов к сбоям
▫️откат делать некому
▫️а изменения часто всплывают уже на реальных данных

Но реальность такова, что законодательство не ждёт удобного момента.
И именно поэтому сопровождение - это не “поддержка”, а управление рисками.

❓ Вопрос к вам:
А на вас как-то отразились изменения в законодательстве?

Честно: иногда просто нет сил

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

Думаю состояние, знакомое многим в IT:
▪️ откладываешь простые задачи
▪️ сложно начать, даже когда понимаешь что делать
▪️ нет ощущения «втягивания» в работу
▪️ любое действие требует непропорционально много усилий

Мы привыкли:
➖ держать темп
➖ быть постоянно включёнными
➖ быстро думать и быстро отвечать

Это не выгорание «по учебнику». Скорее накопленная усталость и перегруз головы.

Самое странное, что со стороны это выглядит как прокрастинация.
А изнутри - как необходимость чуть притормозить, чтобы не поехать дальше на автомате.⛔️

❕Я возвращаюсь в канал без резких стартов.
Дальше снова будут посты про аналитику, сопровождение и реальные кейсы.
Просто в нормальном, человеческом ритме.

Иногда лучший способ остаться в форме - вовремя дать себе паузу.

❓ Вопрос напоследок:
А ты сейчас больше про «разгоняться» или про «чуть притормозить»?

Как понять, что система «поплыла», даже если формально всё работает?

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

Но аналитик уже чувствует: что-то не так.

Вот несколько признаков, что система начала деградировать, даже если внешне всё «зелёное» 👇

🧩 Каждое новое изменение обсуждается дольше, чем реализуется
Потому что никто уже до конца не понимает, на что это повлияет.

🩼 Появляются “временные решения”, которые остаются навсегда
Костыль для одного кейса → зависимость для всей системы.

🧠 Знания о системе живут в головах, а не в документации
И каждый уход человека - это риск.

💣 Любое обновление вызывает страх
Не потому что сложно, а потому что последствия непредсказуемы.

🌀 Похожие запросы каждый раз решаются по-разному
Потому что целостной логики уже нет.

Самое опасное здесь то, что:
❗ система может работать так месяцами и даже годами, медленно теряя управляемость.

И чаще всего это не техническая проблема.
Это проблема отсутствия аналитического контроля и архитектурного мышления в сопровождении.

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

📣 Как аналитик может остановить деградацию системы, не ломая всё сразу?

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

Проблемы начинаются позже - когда каждое новое изменение становится дорогим, рискованным и непредсказуемым.

Переписывать систему целиком в этот момент уже поздно.
И именно здесь появляется реальная зона ответственности аналитика.

1️⃣ Зафиксировать реальное состояние системы, а не проектное

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

Это не аудит ради аудита.
Это восстановление фактической модели системы.

2️⃣ Выделить точки деградации, а не «всё плохое сразу»

Важно понимать:
не всякая сложность - проблема.

Аналитик отделяет допустимую сложность от деградации, которая создаёт риски

Критерии простые:
• рост стоимости изменений
• рост числа ошибок
• зависимость от конкретных людей
• страх перед обновлениями

Если хотя бы два пункта совпадают - это зона внимания.

3️⃣ Перевести технический долг из абстракции в управляемые решения

«Технический долг» сам по себе ничего не значит.
Пока он не:
• привязан к конкретным рискам
• описан в терминах последствий
• встроен в приоритеты изменений

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

4️⃣ Встраивать улучшения в поток обычных изменений

Самая частая ошибка - ждать отдельного проекта на «разбор полётов».

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

Маленькие шаги стабилизируют систему лучше любых революций.

5️⃣ Работать с ожиданиями, а не с иллюзией идеала

Аналитик не обещает «сделать красиво».
Он объясняет:
• какие риски снимаются
• какие остаются
• почему некоторые решения - компромисс

Это снижает давление «давайте быстро и идеально» и возвращает контроль над системой.

6️⃣ Удерживать целостность как постоянную задачу

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

Эта работа редко видна, но именно она делает систему устойчивой.

❗️Итог

Аналитик не спасает систему одним большим решением.
Он делает так, чтобы система перестала ухудшаться,
а значит - получила шанс развиваться дальше.

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

Куда я пропал и что происходило 🤔

В канале было тихо.
Причём дольше, чем планировал (аж с 6 февраля)😅

Не потому что закончились темы.
Скорее наоборот - их стало слишком много, а ресурса на «сесть и написать» не хватало.

Последние недели были в режиме:
🔥 работа
🧠 мысли
📉 посты - «потом»

За это время:
— плотно занимался проектами
— готовил материалы и подавался на конференции для аналитиков
— выступал с докладом на гильдии аналитиков Directum (напишу отдельный пост про это)

И вот интересный момент 👇

Когда начинаешь готовить доклад, вдруг понимаешь, сколько всего ты делаешь в работе «на автомате»…
и даже не считаешь это чем-то сложным.

А потом пытаешься это объяснить - и такой: «так, а это вообще как словами описать?» 😄

В какой-то момент ловишь себя на мысли:
аналитика - это не про требования. И даже не про системы.

Это про то, что у тебя в голове постоянно крутится куча связей, контекста и последствий… и ты уже перестал это замечать как «работу».

В общем, я вернулся 🙂
Дальше снова будут посты про аналитику, сопровождение и реальные кейсы.
Материала накопилось нормально.

Как прошло моё первое выступление (и почему я зря переживал) 🎤

Недавно выступал на гильдии аналитиков Directum с докладом:
«Как выстроить аналитическую экспертизу в отделе сопровождения»

Если коротко - это было про:
— кто такой аналитик сопровождения
— чем он отличается от аналитика внедрения
— какую реальную ценность он даёт
— и как вообще выстраивать эту роль в компании

Немного честности 😅

Это было моё первое выступление такого формата.
Онлайн, ~75 человек.

Готовился около двух недель.
И самое сложное было не собрать материал, а структурировать то, что у тебя уже в голове есть.

Перед началом было волнение.
И не из серии «чуть-чуть», а прям нормально так - голос дрожал где-то до середины доклада 😄

Что в итоге

Прошло… лучше, чем ожидал.

И самый ценный момент был даже не сам доклад, а то, что было после 👇

— вопросы
— обсуждения
— живая реакция

Стало понятно, что тема сопровождения реально откликается.
И у аналитиков здесь много своих болей, о которых редко говорят вслух.

Главный вывод

То, что кажется тебе «ну это база», для других может быть полезным и ценным.

И наоборот - ты не всегда понимаешь, насколько твой опыт релевантен, пока не начнёшь им делиться.

Если ты думаешь выступить, но откладываешь

Вот самый простой совет 👇

👉 Просто решись

Дальше правда становится проще.

И точно не стоит думать:
«да что я им буду рассказывать, они и так всё знают»

Скорее всего - не знают.
Или знают, но по-другому.

Я, честно, зря столько переживал 🙂
Опыт точно хочу повторить и уже даже есть перспективы для этого!

Ого, меня тут 2 месяца не было 🙈
Зато новости и приколы накопились, которыми поделиться можно!
Сегодня постараюсь начать писать обо всем (но не обещаю😃).

🎤 В июне буду выступать на ЛАФ 2026

Это первая новость, про которую хотел рассказать ещё вчера!

13–14 июня выступаю с докладом на конференции ЛАФ 2026 на тему:

«Сопровождение ≠ поддержка. Как аналитик помогает бизнесу получать ценность от системы после внедрения»

И если честно - для меня это немного больше, чем просто доклад 🙂

Ровно год назад я был на ЛАФ как обычный участник:
сидел в зале, слушал спикеров, записывал мысли и смотрел на людей, которые выступают на сцене.

И именно тогда впервые поймал себя на мысли: «А ведь я тоже хочу здесь выступить»
Тогда это казалось чем-то очень далёким 😄

А сейчас я уже сам готовлю доклад для этой конференции.

И если вдруг будете на ЛАФ - буду рад увидеться и пообщаться!

P.S.: На картинке то, как по версии ИИ я выступаю на конференции 😂

Чему сопровождение учит лучше внедрения

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

Но со временем пришло другое понимание.

Сопровождение учит тому, чему невозможно научиться на внедрении.
Оно учит видеть последствия решений.

Во время внедрения мы работаем с будущим.
Проектируем процессы.
Продумываем архитектуру.
Принимаем решения.

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

Именно здесь становится видно:

🧩 Какие решения действительно были удачными.
⚠️ Какие временные решения неожиданно стали постоянными.
📚 Какие недокументированные изменения превратились в проблему.
🏗 Какие архитектурные компромиссы начинают мешать развитию системы.

—————————————————

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

Наверное, именно поэтому аналитики сопровождения часто становятся осторожнее.
Потому что они уже видели, как решения стареют.

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

—————————————————

Для меня одна из главных ценностей сопровождения именно в этом.
Оно показывает не только то, как создавать решения.
Оно показывает, как потом с ними жить.

🤔 Сталкивались ли вы с моментами, когда решения в ваших проектах спустя время оказались очень дорогими по последствиям?

🎤 ЛАФ 2026: от участника до спикера за один год

Пришло время рассказать о том, как прошел для меня ЛАФ 2026 (будет много текста, запаситесь терпением😃)

На прошлогодний ЛАФ я приехал как обычный участник.
Слушал доклады, записывал мысли, знакомился с опытом других аналитиков и старался впитать как можно больше информации.

Именно тогда появилась мысль:

💭 «А ведь однажды я тоже хочу выступить здесь со своим докладом».

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

«Сопровождение ≠ поддержка. Как аналитик помогает бизнесу получать ценность от системы после внедрения»

⸻⸻⸻⸻⸻

Перед выступлением было ОЧЕНЬ волнительно.

Настолько, что во время выступления голос заметно дрожал 🙈

Но постепенно волнение ушло.
Точнее, отпустило оно только тогда, когда начались вопросы из зала.
Их оказалось много.

Причём большинство вопросов были не про теорию, а про практику:

🧩 Как устроено сопровождение у нас?
🧩 Как мы действуем в сложных ситуациях?

Для меня это стало подтверждением того, что тема действительно интересна и востребована.

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

⸻⸻⸻⸻⸻

Ещё один интересный момент.

Когда я был участником, я концентрировался на содержании докладов:

📚 что рассказывают
📚 какие идеи можно забрать себе
📚 какие практики попробовать

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

⸻⸻⸻⸻⸻

Главный вывод после ЛАФ 2026:

🚀 хочу выступать ещё.

Этот опыт показал мне, что знаний и практики уже достаточно, чтобы делиться ими с профессиональным сообществом.
А значит, дальше нужно прокачивать следующий навык - ораторское мастерство.

⸻⸻⸻⸻⸻

И если бы я мог вернуться на прошлогодний ЛАФ и дать себе один совет, он был бы таким:

👉 Слушай не только о чём говорят, но и смотри, как об этом говорят.

Спасибо всем, кто пришёл на доклад, задавал вопросы и участвовал в обсуждении 🤝

📊 Как расставлять приоритеты в бэклоге: 3 рабочих способа

«Просто расставьте приоритеты» - звучит легко, пока не открываешь список из огромного количества задач, где всё «важно» и «горит».

Вот три способа, которые реально работают. Не как единственно верный, а как разные инструменты под разные ситуации.

1. MoSCoW - раскладываем по важности

Берёте каждую задачу и решаете: без неё нельзя (Must), хорошо бы, но не критично (Should), можно сделать при наличии времени (Could), пока не делаем (Won’t).
Никакой математики - просто раскладываете по 4 корзинам.

Быстро согласовать с заказчиком или командой. Хорошо ложится на сопровождение, где приоритет часто уже понятен по SLA.

Ловушка: соблазн запихнуть всё в «без неё нельзя». С этим приходится бороться отдельно, метод сам не спасает.

2. RICE - считаем по формуле

Берёте каждую задачу и оцениваете: скольких пользователей коснётся (Reach), насколько сильно повлияет (Impact), насколько вы уверены в своей оценке (Confidence), сколько сил уйдёт (Effort). Считаете и сравниваете числа.

Подходит, когда есть данные (статистика использования) и команда готова тратить время на оценку, а не решать на глаз.

Ловушка: если оценки занижать «на всякий случай» - метод превращается в красиво оформленное гадание.

3. Kano - делим доработки по типу ценности

Есть вещи, которые просто должны работать (их отсутствие бесит, а наличие не радует, - это базовые характеристики). Есть вещи, где чем больше - тем лучше (перформанс-характеристики). А есть то, чего не ждали, но за что скажут спасибо (восхищающие характеристики).

Подходит для вопроса «что вообще делать», а не «что делать быстрее». Для сопровождения актуально редко - там чаще уже понятно, что делать, вопрос только в очерёдности.

🧐 Как выбирать

Операционный бэклог сопровождения → MoSCoW.

Развитие продукта, есть данные → RICE.

Стратегические решения про продукт → Kano.

Можно и комбинировать: сначала разложить по MoSCoW, а внутри «Should have» - посчитать по RICE.

—————————————————

❓ Как расставляете приоритеты вы?

💬 «Мы же всё обсудили на созвоне»

Знакомая фраза?
Вот и мне знакома. И каждый раз, когда её слышу, внутри что-то ёкает - потому что дальше обычно начинается веселье.

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

И вот вы втроём сидите и пытаетесь вспомнить, кто что говорил 21 день назад.
Спойлер: никто не вспомнит точно. Память - не диктофон, она достраивает то, что «должно было быть сказано», а не то, что было сказано на самом деле.

И дело не в том, что кто-то невнимательный или недоговороспособный. Просто устная речь по умолчанию неточная, а мы почему-то ждём от неё точности письменного ТЗ.
Работает только одно: после созвона - текстом. Даже одна строчка «правильно понимаю, что…» в чат. Не потому что так положено, а потому что это единственный способ поймать расхождение сразу, а не через несколько недель.

Разговор - это черновик. Текст - это версия, с которой можно работать.

———————————————————

❓ А у вас как — фиксируете созвоны сразу, или тоже иногда «на память» надеетесь?

🎯 Три ошибки почти каждого аналитика в первый год

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

Разбираем три самые частые.

1. Брать запрос заказчика как готовое требование

Заказчик говорит:

Сделайте отчёт с фильтром по дате.

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

Разница между «записать, что сказали» и «понять, зачем это нужно» - это разница между исполнителем и аналитиком.

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

2. Бояться сказать «нет» или «не сейчас»

Запрос прилетает - новичок берёт в работу. Прилетает ещё один - тоже берёт.
К концу недели пять параллельных задач, ни одна не сделана нормально, и объяснить заказчикам, почему так вышло, куда сложнее, чем было бы сразу сказать «беру в такую-то очередь».

Первый год часто держится на страхе разочаровать. Только это не помогает. Разочарование просто откладывается и становится больше.

3. Считать, что документация - это формальность «для галочки»

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

Что объединяет все три:

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

———————————————————

❓ Какую из трёх вы узнали в себе на старте или какая четвёртая просится в список?