IT АНАЛитика | Вильд Виктор

Вот вам оффер пошел нах*й 🤝🤝 Прошлый пост про книгу собрал много реакций и репостов. Хочется на регулярной основе делиться ими с вами. Вы когда-нибудь занимались наймом? Или может помогали коллегам с собесами? Так или иначе у вас должно быть хоть какое-то представление о нем, как минимум вы сами проходили собеседования, где вас брали на работу. Были ли вы свидетелем такой ситуации: взяли человека, а он оказался "ни бэ ни мэ" и по итогу и вы и компания просто потеряли время? Прочитал книгу «КТО. Решите вашу проблему номер один» от Джеффа Смарта и Рэнди Стрита. Авторы 13 лет занимаются наймом и делятся методикой. Мысль простая: сначала КТО, потом ЧТО. Неважно, насколько крутой у вас проект или задачи. Важно, кто их будет делать. Тут вводится концепция игроков А, B и С. Игрок А это самый топовый кандидат, который с вероятностью 90% выдаст результат, доступный лишь 10% людей на этой роли. Всё остальное B и С, и вот их-то мы обычно и нанимаем, потому что торопимся или не умеем отличать. По цифрам из книги: неудачный найм обходится компании примерно в 15 месячных окладов сотрудника (статистика омэриканская, но денег в любом случае не мало). Так что брать кандидата "чисто по вайбику" или "да он вроде лучше тех пяти, пофиг, давайте возьмем" очень дорогое удовольствие. Методика состоит из 4 шагов: 1️⃣Лист целей Подробное описание, чего вы ждёте от роли. Нужно сделать осознанный документ: зачем эта роль команде и какой результат ждём. А не копипаст одного из тех тысяч похожих описаний, что кочуют по вакансиям. 2️⃣Поиск кандидатов Крутых спецов нужно искать заранее и систематически, а не когда вакансия уже горит. Это, наверное, самый сложный пункт. 3️⃣Отбор Проводим серию интервью, где выясняем, кандидат крутой или г*вно. Редко, когда за 1ч удается понять, что человек подходит. В идеале выделить несколько встреч по часу или одно на 2ч. Каждая минута потраченная на интервью избавит вас от сотен часов, которые вы провели бы, пытаясь чего-то добиться от заведомо слабых сотрудников. 4️⃣Предложение Выбрали кандидата? Теперь грамотно убедите его стать частью команды, иначе уведут конкуренты. Теперь подробнее про первый шаг, потому что главная ошибка найма это отсутствие чёткого представления, чего вы вообще хотите от будущего сотрудника. Лист целей состоит из 4 частей: 📌Основные задачи: 5-6 предложений о сути работы и зачем вообще создана вакансия. 📌Ожидаемый результат: 3-5 конкретных результатов, специфичных для роли. 📌Профессионализм: навыки, которые ждёте от кандидата. 📌Командность и коммуникации: тут лучше свериться с коллегами. Плохо🤡: «Ищем аналитика с опытом написания требований». Хорошо🤩: «Через 3 месяца сократить число доработок из-за неполных требований в 2 раза». Лайфхак: цели стоит ставить немного "дерзкие". Люди не любят проигрывать. Чуть поднятая планка отпугнёт средних кандидатов и одновременно привлечёт сильных, которым интересен вызов. Так же в книге отдельно подчеркивают: НЕ НАНИМАЙТЕ УНИВЕРСАЛОВ, НАНИМАЙТЕ СПЕЦИАЛИСТОВ Если лень читать книгу, могу выложить вторую часть: как проводить интервью по этой методике. Какие вопросы задавать, как вежливо затыкать льющих воду, тревожные звоночки в поведении кандидата и как в итоге выбирать. Наберём 30 🔥 и выкладываю вторую часть. А вы часто сталкивались с "ни бэ ни мэ" наймом? Как поняли, что произошла ошибка, сразу на испытательном или уже позже? IT АНАЛитика | Подписаться

Хороший кейс от зеленого банка, если интересна архитектура и системный дизайн 🧠 Разбирают классическую дилемму мобильной разработки: как продуктовым модулям получать данные через единый кросс-продуктовый сервис или каждому модулю самому лезть в бэкенд. Показывают обе схемы с плюсами и минусами: где просаживается time-to-market, где растёт нагрузка на сеть, а где неактуальные данные. Полезно для понимания как реальные компании выбирают между простотой и гибкостью в микросервисной архитектуре. Подобные штуки могут спрашивать на собесе в секции системного дизайна. Читать 📚 IT АНАЛитика | Подписаться

А кому сейчас легко в финтехе..... Вы думали канал просто так называется, да? IT АНАЛитика | Подписаться

Если периодически путаете SOAP, REST, GraphQL и RPC — самое время разобраться 🧠 Статья раскладывает все четыре архитектурных стиля по полочкам: чем отличаются, когда какой выбрать и в чём подвох каждого. Читать 📚 P.S Статья на английском, можно сделать перевод прямо в браузере IT АНАЛитика | Подписаться

Пришло приглашение на вакансию. Узнали? Согласны?🤡 IT АНАЛитика | Подписаться

Мы с командой в начале каждого спринта IT АНАЛитика | Подписаться

Штош ты ментор сдал назад? Периодически в личку прилетает что-то в духе: У тебя классный канал, давай запустим курсы/школу/цирк. Я продюсер, вы можете лутать кучу деняк. Вам не хватает простого советского… И каждый раз примерно одно и то же. Меня в этом всегда отталкивало даже не то, что пишут ноунеймы без аватарки, кейсов и хоть какого-то внятного предложения — «я крутой, давай работать». А сам подход: почти всегда это про "АЛО БИЗНЕС? ДА ДА ДЕНЬГИ", а не про «давай попробуем сделать что-то интересное». Свободного времени и так почти нет: работа, спорт, собака, другие хобби, ведение канала. Распыляться ещё куда-то вообще в падлу. Каналу почти 3 года. За это время я даже успел получить диплом маркетолога, но желания жоска что-то продавать так и не появилось. Мне вполне хватает редкой рекламы и иногда консультаций. Я как в том меме про таксиста: в банке я работаю так, для души — на самом деле я админ тг-канала про IT. Но вселенная при этом как будто подкидывала знаки: — прошёл обучение на ментора на РАБоте — менторил коллег — постоянно кому-то что-то объясняю вне работы Такой долгий сетап как-будто должен вести к: ТОЛЬКО СЕГОДНЯ ВЫ МОЖЕТЕ ЗАПИСАТЬСЯ🤡!!!!!! Но нет. Очередным знаком стал разговор с корешем, у которого было не очень с работой. Разгоняли варианты, и в какой-то момент я такой: "А давай попробуем вкатить тебя в АЙТИ?" Потом решил подтянуть ещё одного кореша и вот уже ПЕРВЫЙ ПОТОК, ГРУППА ОБУЧЕНИЯ, ЗАПИСЫВАЕМСЯ, ДЕВА4КИ. На картинке пройденные темы. Чисто из интереса захотелось проверить: а можно ли за 2–3 месяца дать человеку базу и довести до первых попыток найти работу в условиях нестабильного рынка. Как это обещают разные школы, менторы и прочие проходимцы. Пока сам не знаю, что из этого выйдет. Для вас это будет контент, а для меня возможность проверить на практике, как вообще работает такое обучение. Хочу иногда делиться процессом: что работает, что нет, где сам ошибаюсь и какие выводы из этого получаются. Если тема вам интересна, буду периодически рассказывать, как идёт этот эксперимент. Ну и напишите в комментах, как вообще относитесь к менторству и всем этим "вкатам в IT". IT АНАЛитика | Подписаться

Это уже киберпанк или еще нет?😎 Коллеге пришло приглашение) IT АНАЛитика | Подписаться

Кого ты забыл согласовать? 🤔 Чем больше задача — тем больше людей вокруг неё. Бизнес, смежные команды, архитектор, безопасники, поддержка и всем в какой-то момент «ЧЕТО НАДО». Я не раз видел на встречах, когда кто-то со стороны заказчика говорил: А почему так решили сделать? Я это не согласовывал. И тут уже "Управление заинтересованными лицами" из парочки красивых слов превращается в артефакт, который нужно использовать в работе, чтобы не огрести на каком-либо этапе. Зачем вообще это фиксировать? Когда задача небольшая, то вполне ок держать это в голове. Если заинтересованное лицо одно, вряд ли вы его забудете. Но если проект длится несколько месяцев, участников много, согласования идут в несколько этапов и на каждом этапе свои согласующие, то без фиксации легко кого-то пропустить. А пропустить стейкхолдера это: 😕узнать о пропущенном требовании в самый неподходящий момент. 😐переделывать то, что уже сделано. 🥲краснеть на созвоне и объяснять почему его не позвали. Что фиксируем? Для каждого стейкхолдера важно понимать три вещи: 🆗 Кто это и какова его роль? 🆗 Какой у него интерес к задаче? 🆗 На каком этапе и в каком формате его нужно подключить? Таблицу удобно держать прямо в аналитике к задаче — не надо держать всё в голове и легко онбордить новых участников. В комментарии кину пример таблички. А вы ведёте список стейкхолдеров или держите всё в голове? 👇 IT АНАЛитика | Подписаться

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡 Пока отхожу от концерта Ye и догуливаю последние дни отпуска — ловите подборку постов за май 🌴 Были уже в отпуске или когда планируете? Посты Ты точно знаешь, что такое архитектура? CQRS: что это и зачем знать аналитику? CJM — для чего и зачем? Как выявить х*евое требование? Ошибки при написании документации Kafka на примере котиков Интересные статьи Основы Kafka Как Москва превратилась в дагестанское село #итоги_месяца IT АНАЛитика | Подписаться

Объяснение OAuth на котиках IT АНАЛитика | Подписаться

Как Москва превратилась в дагестанское село 🗺 Довольно поучительная история от ребят из Авито. Коротко о сюжете: команда выкатила фичу «Лёгкое резюме». Метрики растут, все радуются. Через неделю обнаруживают, что 45000 резюме создано в селе с населением 7000 человек 😬 Оказалось: Android-клиент менял местами широту и долготу. Перевёрнутые координаты Москвы попадали на поле в Иране. А бэк вместо того чтобы показать ошибку, тихо переносил резюме в ближайший российский населённый пункт - дагестанское село. Что из этого можно вынести: 1. Интеграцию надо проверять с каждым клиентом отдельно. Android, iOS, web — разные клиенты с разной реализацией. То что работает на одном, может сломаться на другом. Особенно при горящих сроках и спешке. 2. Думай не только про happy path. Что происходит когда данные некорректны, поле пустое или пользователь сделал что-то неожиданное? Такие сценарии важно проработать и описать ещё на этапе анализа, иначе система сама решит как себя вести. 3. Поспешишь — людей насмешишь Этим грешат все. Но если к релизу фича не до конца проверена, то лучше отложить или хотя бы явно подсветить риски команде. Узнать о критическом баге на проде всегда дороже, чем перенести релиз. Полная история: Читать 📚 А у вас были баги, которые потом превращались в полноценное расследование? IT АНАЛитика | Подписаться

Ты точно умеешь писать документацию? 📝 Все думают что умеют писать. Русский у всех же был в школе? Из букв составляем слова, из слов текст и описание готово, принимайте доку. Но часто аналитики сами попадают в ловушку — написал казалось бы простое понятное описание, а читать это по итогу вообще невозможно 🙂 Вот одни из самых частых ошибок: 1. Внутри много много мяса, мало теста.🥟 Длинные нагромождённые предложения, где много слов и смысл быстро теряется. Плохо🤡: Сервис проверки клиента предназначен для осуществления проверки корректности введённых пользователем данных в рамках процесса оформления кредита с учётом действующих ограничений и бизнес-правил» Хорошо🤩: Сервис проверяет данные клиента при оформлении заявки на кредит. Лучше несколько коротких предложений, чем одно гигантское. 2. Жаргон в документах 🤓куку епта Если в чате написать "пофиксить", "задизейблить", "дропнуть" и.т.д — ок. То в документации такое уже не ок. Кто-то может не знать ваших слов или неправильно их интерпретировать. Лучше исключить разночтение заранее. 3. Масло маслянное🤩 Тавтология и бессмысленные повторы только ухудшают восприятие. Если можно написать короче — пишите короче. «Система должна обеспечивать возможность предоставления доступа пользователям» → достаточно «Система предоставляет доступ пользователям». «Происходит процесс авторизации пользователя» → «Пользователь авторизуется». «Выполнить осуществление проверки данных» → «Проверить данные». «Производится выполнение логирования ошибок» → «Ошибки логируются». «Происходит процесс сохранения данных в базу данных» → «Данные сохраняются в базу». 4. Противоречия между разделами⚡️ В начале написал одно, в другом разделе уже другое. Лучше не торопиться и лишний раз перечитать документ/задачу/письмо, перед тем как отдавать. Криво напишите -> Разраб криво сделает -> Тестер криво проверит -> Баг 5. Термины без расшифровки 😏 У вас могут быть специфичные термины внутри продукта, которые знают не все. Через полгода новый человек откроет вашу документацию и вообще не въедет что и как вы тогда реализовывали. Используете локальный термин — лучше расшифруйте. P.S. Всё никак не могу дойти до книги «Пиши, сокращай», так и просится. Часто ловите такое за собой или за коллегами? Я лично постоянно встречаю первый и третий пункт👇 IT АНАЛитика | Подписаться

Как выявить х*евое требование?🗑 Если вы не работали с такими требованиями, то можно сказать, и не работали в IT. Бизнес иногда приносит ТАКОЕ, от чего вполне может развиться выгорание или ПТСР. Конечно, можно смириться и делать что скажут жестко осуждаем такой подход и никому не советуем. Но задача аналитика не просто принять требования и оформить, а разобраться — точно ли нужно делать именно так? И если нет, донести это без скандала. Вот как можно разложить это по шагам: 1. Сначала идентифицируй требование🧐 Прежде чем паниковать, задай себе три вопроса: ⏺Если это не реализовать, бизнес-потребность всё равно закроется? ⏺Можно закрыть это имеющейся функциональностью или сделать проще? ⏺Есть ли риски в реализации этого требования? Часто уже на этом шаге становится понятно, что требование можно упростить или вообще выкинуть. 2. Выяви истинную потребность🔍 Бизнес часто говорит что хочет, но не всегда понимает что ему на самом деле нужно. Копай глубже: 💬Какую задачу он пытается решить? 💬Что произойдёт, если это не сделать? 💬Есть ли ограничения, которые не дают рассматривать другие варианты? Если ограничения есть и альтернатив нет, то сразу переходи к шагу 4. 3. Предложи альтернативы 💡 Не просто скажи «это плохо/делать не будем/вы не шарите», а покажи варианты: ➡️ Вариант 1 — что хочет бизнес. Опиши честно, какие трудности это создаст. Без субъективного «это тупо/сложно/некрасиво», только сухие факты. Обычно после оценки и сроков этот вариант сам отметается 🙂 ➡️ Вариант 2 — некий костыль. Может, можно сделать небольшую доработку уже существующего функционала? Обычно это самый дешёвый и быстрый вариант. Но не всегда самый правильный, тут важно обсудить его с архитектурой, потому что иногда костыль это очень плохо!!!!!!! ➡️ Вариант 3 — самый трушный. Решение, которое закрывает потребность бизнеса с минимальными рисками. Да, может быть дороже, но в долгосрок все выигрывают и переделывать точно не придётся. 4. Зафиксируй ограничения и риски 📝 Бывает, бизнес хочет эту зелёную кнопку «ну вот тока тут». Не всегда получается переубедить, такое иногда бывает. Да ты че? Базару нет Но перед тем как брать в работу, обязательно зафиксируй все риски и ограничения письменно. Пропиши возможные последствия и способы их устранения. Если на демо или ПСИ кинут предъяву, сможешь уверенно и без задней мысли сказать: «А Я ВАМ ГОВОРИЛ!!!!!!!!!!!!!!!» 5. Полный газ👍 Всё согласовано, риски зафиксированы, спокойно приступаешь к аналитике. Главное помни: твоя задача не просто выполнить требование, а помочь бизнесу получить качественный результат. Иногда это значит задать неудобный вопрос: "Подождите, коллеги. Я вас правильно понял? Вы хотите сделать какую-то х*ету? А вам часто прилетают плохие требования? Как справляетесь? 👇 IT АНАЛитика | Подписаться

CJM, USM, CGI — кто лишний?🤔 Раньше на канале были посты про USM: ➡️Прибейте меня, я веду проект с нуля. Часть 5 ➡️Как с этим работать? Сегодня про похожий, но другой инструмент — CJM. Что такое CJM? Customer Journey Map или карта пути клиента. Если USM отвечает на вопрос «что нужно построить и как разложить по задачам», то CJM отвечает на другой — «что чувствует и думает пользователь, пока идёт по продукту». По-простому: это карта всего пути клиента от момента когда возникла потребность, до того как он получил результат. На каждом шаге фиксируем что он делает, с какими барьерами сталкивается и какие эмоции испытывает. Чем CJM отличается от USM? USM это про команду и разработку. Помогает декомпозировать продукт на задачи и понять что пихать в MVP. CJM это про пользователя. Помогает понять где ему больно, где он уходит и почему не возвращается. Когда аналитику пригодится CJM? CJM это больше инструмент продакта, и аналитик работает с ним ещё реже чем с USM. Но бывает два случая когда он может пригодится: ➡️ Старт продукта — если вы достаточно глубоко погружены, CJM поможет заранее увидеть слабые места до начала разработки. ➡️ Упали метрики — если вы работаете с аналитикой и что-то пошло не так, CJM поможет найти где именно пользователь спотыкается. Хорошая статья про то как строить CJM на практике, с примерами Читать📚 Приходилось сталкиваться с CJM? Или у вас этим занимается только продакт? 👇 IT АНАЛитика | Подписаться

🔤🔤🔤🔤: что это и зачем знать аналитику? Раньше на канале выходили посты про технические штуки: ConfigMap: Что такое и зачем? Что такое Feign? MAPI: что это и зачем знать аналитикам? Что такое DTO и зачем это знать аналитику? HAProxy: зачем это знать аналитику? Mapping: что это такое и зачем знать аналитику? Хочется сделать из этого отдельную рубрику про вещи, которые все скорее всего знают, они на слуху, но если спросить, в ответ услышишь: «ну блин, это же это вот, да блин, все знают, ёмоё» 🙂 Что такое CQRS? CQRS — архитектурный паттерн. Расшифровывается как Command Query Responsibility Segregation — разделение ответственности команд и запросов. По-простому: операции чтения (Query) и изменения данных (Command) разделяются и живут независимо друг от друга. В классическом подходе команды и запросы идут вместе. CQRS говорит: разделите их. Пусть каждый занимается своей задачей. Пример🏦 Допустим, есть сервис работы со счетами. Есть сервис счетов. Пользователи постоянно: — смотрят баланс — открывают историю операций Это чтение. Параллельно идут: — переводы — пополнения — списания Это запись. Если использовать одну модель для всего, то при высокой нагрузке они начинают мешать друг другу: тяжёлые операции записи тормозят чтение, а частые запросы будут перегружать систему. CQRS решает это разделением: отдельная модель для чтения, отдельная для записи. И дальше это можно удобно масштабировать. Важный момент: CQRS не обязательно означает две отдельные модели данных. Модель может быть одна, но пути для чтения и записи разные. Две модели — это один из вариантов реализации, который часто используют вместе с Event Sourcing. Когда применять, а когда нет 🤔 Подойдет, если: 🆗 Нагрузка на чтение и запись сильно отличается 🆗 Сложная бизнес-логика на запись 🆗 Есть требования к производительности 🆗 Нужна независимая масштабируемость в процессах Не лучший вариант, если у вас: ❌ Простое CRUD-приложение ❌ Маленький проект и команда ❌ нет понимания, зачем это нужно ❌ Не готовы к сложности синхронизации — если используете две модели, данные для чтения могут отставать от записи (eventual consistency) Зачем это знать аналитику? Потому что именно ты описываешь как данные читаются и записываются в системе. Если сервис небольшой, можно и забить. Но если архитектора нет — возможно именно ты поможешь спроектировать решение, которое потом не придётся переделывать. Ну и на собесе спросят. Лучше ответить нормально, чем мычать 🙂 А вы сталкивались с CQRS в своих проектах? #технические_штуки IT АНАЛитика | Подписаться

Ты точно знаешь, что такое архитектура? 🤔 Недавно был на собесе и получил вопрос: «А что такое архитектура? Зачем она вообще нужна?» А почему солнце светит? В комментарии выложу картинку, как выглядело моё лицо в тот момент 🙂. Обычно такие вопросы задают с одной из двух целей. 1. Проверить самообладание. Бизнес порой задаёт простые или странные вопросы, и важно уметь спокойно на них отвечать. Помню, как на собесе кандидату задали простой вопрос, а он выдал: «РРЯЯЯЯЯЯЯ ВЫ ЧЕ ТУПЫЕ, НУ КТО ТАКОЕ СПРАШИВАЕТ, НУ ВЫ И КРИНЖ» 2. Проверить логику и базовые знания. Именно на простых вопросах многие неожиданно сыплются. Кажется, что это очевидно. Но попробуйте объяснить прямо сейчас не подглядывая 👀 Что такое архитектура? 🧱 Если совсем по-простому, то это чертёж системы. Как в строительстве: прежде чем строить дом, архитектор рисует план — где стены, где двери, как всё соединяется, из каких материалов. В IT всё то же самое: архитектура описывает из каких компонентов состоит система, как они взаимодействуют и почему именно так. Зачем это знать аналитику?🤔 Ну, во-первых, чтобы меньше платить и не брать полноценного архитектора . Если серьёзно, то как ты будешь проводить системный анализ в отрыве от самой системы? Любое решение проектируется внутри какой-то архитектуры, и не понимать как она устроена ну вообще никак. Не понимаешь архитектуру → не понимаешь ограничения → пишешь требования, которые невозможно реализовать. Или реализовать можно, но потом всё ломается. Самые популярные виды: ➡️ Монолит Вся система это один большой кусок. Логика, база и интерфейс лежат в одном месте. На старте это просто и удобно, особенно если приложение небольшое. Но чем больше система растёт, тем тяжелее её масштабировать и менять. ➡️Микросервисы Система разбита на маленькие независимые сервисы, каждый отвечает за свою задачу. Главный плюс, если один сервис упал, остальные продолжают работать. Гибко и устойчиво. Но есть нюансы: сервисов много, значит много интеграций, много мест где может что-то пойти не так, и отлаживать, деплоить и мониторить всё это заметно сложнее чем монолит. Дальше уже идут архитектурные паттерны, в рамках которых можно реализовать ту или иную систему. Что будет, если накосячить? 💀 Архитектурные ошибки самые дорогие. Условный баг в коде исправишь за час. Неправильно выбранная архитектура может вскрыться через год и переделывать тогда дорого по времени и деньгам. Именно поэтому архитектурные решения принимаются в самом начале и согласовываются со всеми заинтересованными сторонами. А вам на собесах задавали базовые вопросы, от которых хотелось сказать «подержи моё пиво, ща тебе расскажу»? Делитесь в комментариях 👇 IT АНАЛитика | Подписаться

Kafka заказывали? 📨 В канале уже были материалы по теме: ☀️Kafka для всех - сказка про выдр, объясняет концепции, которые поймет даже ребенок. ☀️Объяснение Kafka на котиках - для тех, кто любит мемы. Даже если вы с ней не работаете, то на собесе спросят почти наверняка. Поэтому важно понимать базу: чем Kafka отличается от классических очередей вроде RabbitMQ, как устроены топики, партиции и консьюмер-группы, почему сообщения не удаляются после обработки. Если хоть одно слово из этого вам до сих пор незнакомо или вызывает вопросы, самое время разобраться — читать📚 IT АНАЛитика | Подписаться

Если вы читаете это, значит вы и есть сопротивление. Я когда-то знал людей, которые предупреждали: без нормальной аналитики всё рухнет. Что требования надо фиксировать. Что устные договорённости это катастрофа. Никто не хотел их слушать. Бизнес игнорировал. Разработчики смеялись. Тимлиды отмахивались. Но всё, что они предсказывали — сбылось. Прод упал. Сроки сгорели. Задачи ушли в разработку без описания. И поэтому я прошу вас поверить мне. Менеджеры хотят, чтобы мы работали как ИИ. Принимали задачи без вопросов. Писали доку для галочки. Молчали на встречах. Но мы не ИИ. А если уподобимся им, какой тогда смысл в профессии? Слушайте внимательно. Мне сейчас нужен каждый из вас. Вы жизненно важны для главного сражения — между хаосом и нормальным процессом. Те, кто фиксирует договорённости возможно, выживут. Те, кто доверяет устным обещаниям — возможно, нет. Всё предельно просто. Врываемся в новую рабочую неделю🎧 Постов не было месяц, админ восстанавливал силы в отпуске. Теперь всё, возвращаемся в work mode 💼 Ждете уже майские? Какие планы? #поддержка IT АНАЛитика | Подписаться