Айтишники больше не нужны. ВСЁ!

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

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

Что происходит?
Во многих компаниях внешний найм полностью или частично поставлен на паузу.
Фризы, заморозка ставок, согласование каждой новой позиции через три круга ада. Хорошо, если дадут закрыть текущую вакансию. Про новые роли зачастую даже не заикаются.

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

Личный пример.
В октябре я открыл резюме примерно на месяц.
Если год назад, как писал в первой части, мне стабильно писали по 3 рекрутёра в день в течение пары недель, то сейчас за весь месяц набралось… ну где-то 5-7 сообщений из которых до тех собеса дошло только одно.

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

Рок-звёзды вышли в тираж. Флексить офферами стало заметно сложнее.

Почему это происходит?
Если коротко, то всё сразу.

1. Страшный ИИ пришёл и всех заменяет
К РФ это, конечно, применимо в меньшей степени.
У нас всё-таки не такая глубокая автоматизация в IT, как во многих крупных компаниях.
Но хайп вокруг ИИ сделал своё дело.

Руководители начали задаваться вопросом:
«А ЧО ВОН ДАВАЙТЕ АЙЯЙ ПОСТАВИМ НОВЫЙ МОДНЫЙ СЭКОНОМИМ ДЕНЯК»
Денег же конечно никто не сэкономил🌚

Один из самых громких кейсов в РФ за последнее время на эту тему был про сокращения и оптимизацию ролей в сбере.

Я, если честно, в историю «ИИ реально заменит людей» верю слабо. По крайней мере пока.
Это больше похоже на аккуратный и социально приемлемый повод оптимизировать косты и сократить кучу людей, чтобы было не так больно и стыдно.

Да и большинство же пользовалось нейронками.
Можно ли прямо сейчас заменить ими такое количество людей?
🙂

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

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

Еще пару лет назад я не раз слышал от продуктов в кулуарах:
«Ну проект не взлетел, про***ли n миллионов. Ничего, сделаем новый😎».

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

3. Перенасыщение рынка
Во время ковида открылось огромное количество курсов и школ.
Все массово пошли учиться и «вкатываться в IT».

Ковид закончился, спрос на обучение вроде бы снизился, но нарратив остался:

«В айти много денег и можно особо не напрягаться».

«Вон у меня тесть погромистом работает, такие баблища зашибает, может мне оно тоже туда к вам вайти надо?»

«Подруга жены аналитиком работает. Чето весь день балакает там по своему кампутеру. Вот она лафа, я тоже так хочу»

В итоге появилось ещё больше курсов, школ, больше джунов, больше «мидлов с 3+ годами», больше "крутого опыта в резюме".

Из-за чего найм превратился в голодные игры, где кушать хотят все)

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

IT АНАЛитика | Подписаться

Отменяем отмену айтишников!

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

А что делать-то?
Глобально - ничего принципиально нового.
Волшебной пилюли, к сожалению, не будет☹️.

1. Прокачивать софты.
2. Прокачивать харды.
3. Читать книги и статьи.
4. Прокачивать экспертизу на разных задачах.
5. Ходить на собесы, если есть такая возможность.

ВСЕ ТОЖЕ САМОЕ, ЧТО И РАНЬШЕ.
ЧТОООООООО?

Да. Именно так.

Вакансии никуда не исчезли. Люди по-прежнему увольняются, сокращаются, меняют работу. Старые проекты закрываются, новые открываются. Компании всё так же хотят зарабатывать деньги.

Просто конкуренция выросла, а денег на кальян и раф на лавандовом в переговорку стало меньше.
Теперь за пару недель вы вряд ли соберёте веер из офферов.

Оффер «за красивые глазки» станет легендой.
Теперь недостаточно быть просто «не дурачком».
Ошибки стали стоить очень дорого.

Спутали PUT и PATCH? - мы вам перезвоним
Но не вам, а тому, кто еще и дешевле стоит

Что будет дальше?
Компании никуда не денутся.
Какие-то закроются, какие-то пересоберутся, какие-то, наоборот, появятся.
IT как отрасль не исчезает - она эволюционирует.

Хорошие специалисты по-прежнему нужны.
Продукты, легаси и запуск новых направлений никуда не делись.
Кто-то же должен развивать «енто ваше айти».

Вся эта история сильно напоминает мне бум на юристов.
Еще до айти хайп и флекс был пойти и стать юристом. Модно, молодежно и много денег.

Потом юристов стало ну слишком много.
Рынок перегрелся, ожидания упали.
Что сейчас с юристами?
Да все норм, профессия жива. Просто остались те, кто реально нужен.

С IT будет ровно так же.
Да, станет сложнее, требования вырастут, «просто войти» больше не получится.
За малейшую ошибку на собесе с вами не будут сюсюкаться и отдадут предпочтение другому кандидату.
Спрос на хороших специалистов по-прежнему будет, но нужно будет реально СТАРАТЬСЯ и готовиться, чтобы вас взяли на желаемую позицию.

Правила игры поменялись.
Вы были и остаетесь вашим самым ценным активом. Качайте свою экспертизу, не сидите на месте. Идеального момента для шага вперед никогда не будет.
Если не вы получите классный оффер, значит его получит кто-то другой.
А чем вы хуже?

Все получится🤗

IT АНАЛитика | Подписаться

Ты почему время в задачу не списал?

Один из вечных бичей всего IT - списывание времени и трекинг активности по задачам.

Весной у меня было собеседование в один аутсорс.
И там сразу говорят:

«У нас есть программа, которую надо поставить. С утра включаешь, вечером выключаешь, в обед ставишь на паузу, чтобы мы трекали время. Ты не подумай, это чисто формальность» 🥴

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

И это сразу напомнило мне первые годы в IT.

Когда работал в саппорте, задачи прилетали в Service Desk, и ты их просто разгребаешь.
Твоя главная метрика - SLA и сколько времени задача висит в работе.
Если задач от пользователей нет, сидишь спокойно, чилишь, занимаешься своими делами.

Потом я перешёл в бизнес-анализ.

Там уже нужно было списывать время в Jira и обязательно писать комментарий, что именно ты делал.
А у нас при этом было два разработчика на шесть аналитиков.
И бывали дни, когда за день ты объективно особо ничего не сделал, максимум пара встреч.
А время в задачу всё равно списывать надо🙂

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

Сейчас и уже довольно давно я просто списываю время в задачу.
И всё.

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

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

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

А вы как считаете?
Нужен ли трекинг времени и активности или это просто иллюзия контроля?

IT АНАЛитика | Подписаться

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

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

Читать 📚

IT АНАЛитика | Подписаться

Айтишники, аналитики - газ отмечать Новый год⛄️

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

Год для IT был неспокойный. Много неопределённости, тревоги и вопросов. Но мы как-то справились и продолжаем двигаться дальше.

От себя хочу пожелать:
🌟 работы, которая приносит кайф, а не только деньги
💫 интересных задач и новых офферов
🌟 почаще отдыхать и ходить в отпуск (я проверял, это реально работает).

Спасибо, что вы здесь и остаетесь на канале.
С наступающим 🎄

IT АНАЛитика | Подписаться

Идемпотентность - это та самая штука, про которую все вроде слышали, про которую любят спрашивать на собесах, но в реальных проектах о ней чаще вспоминают уже после первого инцидента 😐

Годная статья от Яндекса, где на живых примерах разбирают, как повторные запросы могут ломать бизнес-логику, приводить к дублям и странным багам и что с этим делать на уровне API и архитектуры.

Читать📚

IT АНАЛитика | Подписаться

Прибейте меня, я делаю интеграцию. Часть 1 🍑

Вы - аналитик.
И вам говорят:
«Нужно интегрироваться с другой системой».

А можно я в очередной раз опишу задачу на покраску кнопочки?🥺

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

Но одними фичами сыт не будешь, и работа с интеграциями - неотъемлемая часть жизни аналитика.

В прошлом году я уже делал серию постов про ведение проектов с нуля:

Как вести проекты с нуля?
Как вести проекты с нуля? 2
Как вести проекты с нуля? 3
Как вести проекты с нуля? 4
Как вести проект с нуля? 5
Как вести проект с нуля? 6
Как вести проект с нуля? 7

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

Ща всё будет «hold my beer», или чай, если вы не пьёте, как я ☕️

Что вообще такое интеграция?
Интеграция - это когда две или больше системы обмениваются данными или событиями, чтобы бизнес-процесс работал целиком.

По-простому:
✅ одна система что-то создает;
✅ другая это принимает;
✅ и между ними есть договорённости, формат, правила и ответственность.

Пример

Допустим, у нас есть новая система, которая отвечает за работу с клиентами.
Пока что она умеет только одно - создавать клиента.

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

А потом приходит бизнес и говорит:
— клиенту нужно создать счет (это делает другая система);
— клиента нужно проверять в системе проверок;
— часть данных нужно отправлять в систему отчётности.

И вот тут внезапно появляется сразу несколько интеграций.
Если хоть одно звено отвалиться, то бизнес-процесс ломается.

Вот это и есть интеграция.

Поставщик и потребитель
В любой интеграции всегда есть минимум две роли.

Поставщик (provider) - это система, которая:
➡️ владеет данными;
➡️ их создаёт или обновляет;
➡️ отвечает за их корректность.

Потребитель (consumer) - это система, которая:
➡️ получает эти данные;
➡️ использует их в своих процессах;
➡️ живёт с последствиями, если данные приехали криво.

Очень частая ошибка не договориться на старте:
🧐кто владелец данных;
🧐кто имеет право их менять;
🧐кто вообще отвечает, если всё сломалось.

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

Зачем тут вообще аналитик?
Потому что именно он:
👍видит бизнес-процесс целиком;
👍 понимает, зачем вообще нужна эта интеграция;
👍 переводит хотелки бизнеса на человеческий язык для команды;
👍 фиксирует договорённости между системами.

В следующей части поговорим про виды интеграций.

А пока расскажите в комментариях:
с какой самой странной или болезненной интеграцией вам приходилось сталкиваться?👇

Вторая часть

IT АНАЛитика | Подписаться

Прибейте меня, я делаю интеграцию. Часть 2 🍑

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

И казалось бы всё, тимлид, давай задачку, ща спроектируем-нах*евертим 💃
Но тут важно понимать одну вещь:

Интеграции бывают разные.
И если выбрать не ту модель, могут быть проблемы.

Начнем с того, что мы их можем разделить по двум направлениям:
1. С кем мы интегрируемся.
2. Как мы это делаем.

1. С кем: внутренние и внешние

🏠Внутренняя интеграция (Internal)
Когда мы связываем наш сервис с другим сервисом внутри компании.

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

Зачастую это более простой вариант:
🤗 Все свои. Можно дойти до соседней команды или написать в личку;
🤗 Быстрее договориться о доработках;
😳 Более быстрый разбор ошибок.

Из минусов:
😒 Знания часто живут в головах и может быть плохо описанная документация;
💬 У другой команды свой бэклог и задачу могут взять в работу не так быстро, как хотелось бы;
🤓 Могут выкатить правки без предупреждения и молча сломать вам прод.

🌐 Внешняя (External)
Когда мы интегрируемся с системой вне нашей компании.

Пример:
У нас есть сервис авторизации и мы хотим, чтобы пользователь мог войти через Госуслуги или Google (внешние сервисы).

Из плюсов:
😋 Обычно есть подробная документация, которую можно изучить самому;
🔺 Есть чёткие правила и форматы данных, которые меняются не так часто.

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

2. Как: синхрон или асинхрон

📞 Синхронная интеграция (Request–Response)
Самый популярный вариант - REST, gRPC, SOAP.

Логика простая:
Запрос → Ожидание → Ответ. Пока мы не получим результат от другой системы, дальше не идем.

Пример:
Создали клиента → отправили запрос в систему проверок → ждем 5 секунд → получили статус «Одобрено» → создали личный кабинет.

Плюсы:
🎉 Всё просто: отправил - получил. Легко проектировать.
😊 Сразу понятно, на каком этапе возникла ошибка.
😌 Дернул метод через Postman и сразу увидел результат.

Минусы:
😅 Если вторая система упала, то процесс встал;
🤨 Любая задержка бьёт по пользователю.

Когда использовать:
👉 Ответ нужен здесь и сейчас (например, проверка баланса или авторизация);
👉 Пользователь смотрит в экран и не может продолжать работу без этих данных.

📨 Асинхронная интеграция (Event-Driven / MQ)
Kafka, RabbitMQ и другие брокеры сообщений.

Логика простая:
Отправили → Забыли. Нам не важно, когда именно другая система обработает данные. Главное, что мы зафиксировали событие и пошли дальше.

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

Плюсы:
😏 Система не «тупит» в ожидании ответа, пользователь доволен скоростью.
😋 Если сервис почты упал, заказ всё равно оформится. Сообщение полежит в очереди и долетит позже, когда сервис поднимется.
👍 Можно легко добавить ещё пять систем-потребителей, и основной процесс от этого не замедлится.

Минусы:
🥲 Сложнее тестировать: приходится прыгать по логам разных систем, чтобы понять, где и почему застряло сообщение.
😉 Аналитику нужно продумать кучу нюансов: что делать с дублями сообщений (идемпотентность) и как не перепутать их порядок.

Самое простое объяснение:
Синхрон - вы звоните в ресторан.
Пока вам не подтвердят бронь, вы держите трубку.

Асинхрон - вы оставили заявку.
Администратор подтвердил её через 2 часа.
Вы не ждали у телефона.

Какой тип интеграций в ваших задачах встречается чаще всего? И что из этого больше всего бесит? 👇

IT АНАЛитика | Подписаться

Прибейте меня, я делаю интеграцию. Часть 3 🍑

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

Как аналитик проектирует интеграцию: 5 шагов 🧠

Шаг 1. Понять зачем
Как и в любой другой задаче — сначала выясни, какую проблему решает интеграция.
Звучит очевидно, но порой от неё можно вовсе отказаться в пользу уже существующего решения. Или окажется, что интеграция уже была и просто никто её не описал 🙂

Шаг 2. Определить стороны
Кто поставщик, кто потребитель, кто владелец данных.
Договорились — зафиксировали письменно. В идеале прикладываем куда-то себе в аналитику, чтобы не потерять.

Шаг 3. Выбрать модель
Один из самых важных шагов.
Если есть архитектор — выбор модели можно дополнительно согласовать с ним.
Нет архитектора? Соберитесь с командой и обсудите варианты вместе.

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

Шаг 4. Описать данные
Какие поля едут, в каком формате, что обязательно, что делать если поле пустое.
Это и есть маппинг — про него у меня есть отдельный пост.

Шаг 5. Договориться об ошибках
Что делает система, если запрос упал? Таймаут? Ретрай? Алерт?
Этот вопрос часто забывают и потом на разборе инцидента кому-то приходится краснеть.

Типичные ошибки, через которые думаю многие проходили 🤦

❌ «Договорились устно»
Вы попросили команду соседнего сервиса сделать доработку, получили ответ «да, без проблем». Никто это не зафиксировал. Через месяц они выкатили релиз без вашей правки и сломали вам прод. Классика.

❌ Не проработали обработку ошибок
Happy path описан на 5 страниц, ручки готовы, диаграммки построены.
А что делать, если внешний сервис вернул 500? Все забили и потом «ой, какая-то ошибка на проде»

❌ Забыли про нефункциональные требования
Сколько запросов в секунду? Какой допустимый таймаут? Без этого интеграция может работать на стенде и падать на проде под высокой нагрузкой.

❌ Не согласовали интеграцию с обеими сторонами
Одну сторону спросили, вторую нет. В итоге маппинг написан под старую версию API.

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

Что зафиксировать в документации 📄
Базовый минимум любой интеграционной доки:
➡️ Цель интеграции и бизнес-контекст
➡️ Участники: кто поставщик, кто потребитель
➡️ Тип интеграции: синхрон/асинхрон, REST/Kafka и.т.д
➡️ Описание запроса и ответа (маппинг полей)
➡️ Обработка ошибок
➡️ Нефункциональные требования: таймауты, нагрузка, доступность
➡️ Ссылки на API-документацию внешней системы

Ну и чеклист готовности интеграции к проду

Сохраняй, пригодится:
✅ Бизнес-цель понята и зафиксирована
✅ Стороны определены, владелец данных назначен
✅ Тип интеграции выбран и обоснован
✅ Маппинг полей согласован с обеими командами
✅ Обработка ошибок описана
✅ НФТ прописаны
✅ Документация актуальна и доступна команде
✅ Тестовый стенд проверен

Раньше интеграции казались мне душной однотипной х*йней, с которой лень разбираться.
Но приняв их, вдумчиво разобравшись и проработав огромное количество становиться проще.

Надеюсь, если вы их и не полюбите, то хотя бы начнёте щёлкать как орешки.

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

А какой пункт из чеклиста вы чаще всего пропускаете? Признавайтесь в комментариях 👇

IT АНАЛитика | Подписаться

Дамы, с 8 марта! 🌷

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

Пусть рядом будут люди, которые ценят вас не только за ум, работу и профессионализм, но и просто за то, какие вы есть.

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

С праздником! ❤️

IT АНАЛитика

7 признаков того, что команде пора брать аналитика.

Я бы добавил ещё один — разработчики занимаются аналитикой вместо разработки.
А у вас такое было? 👇

Читать📚

IT АНАЛитика | Подписаться

Как работать со смежной командой?😐

Для каждого, кто работал со смежной командой, скорее всего будет жиза 🙂

Пишешь такой письмо коллегам:

"Привет, хотели бы с вами вот такую задачу сделать. Когда сможете вернуться?"

Проходит неделя и ТИ ШИ НА.

Чаще всего это не специально (хотя бывает и так). Люди просто не понимают, что вы от них хотите, не знают как помочь или заняты своими задачами. И вот тут твоя задача — сделать так, чтобы им было легче тебе помочь.

Вот как я бы выстроил эту работу:

1. Нормально познакомиться 🤝
Не просто «нам нужно от вас вот это». Объясните кто вы, зачем пришли и что от них потребуется на каждом этапе. Люди охотнее помогают тем, кого понимают. В идеале сразу ставьте встречу.

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

3. Фиксируйте все договорённости письменно 📝
Устные «Ало задача? Да, да релиз» — не считаются. После каждой встречи отправляйте короткий итог: кто что делает и в какой срок. Переписка вас спасёт, если кто-то проеб*тся.

4. Помогите им помочь вам 💡
Если смежная команда тормозит — не ждите. Спросите, в чём проблема. Дайте шаблон, гайд, контакт нужного человека и всё сразу пойдёт быстрее.

5. Эскалируйте вовремя 🚨
Если письма уходят в тишину — не ждите. Подключайте руководителей. Но сначала всегда пробуйте решить мягко.

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

А какой пункт у вас чаще всего проседает? 👇

IT АНАЛитика | Подписаться

Если вы читаете это, значит вы и есть сопротивление.

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

Но всё, что они предсказывали — сбылось.
Прод упал. Сроки сгорели. Задачи ушли в разработку без описания.
И поэтому я прошу вас поверить мне.
Менеджеры хотят, чтобы мы работали как ИИ. Принимали задачи без вопросов. Писали доку для галочки. Молчали на встречах.
Но мы не ИИ. А если уподобимся им, какой тогда смысл в профессии?

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

Врываемся в новую рабочую неделю🎧
Постов не было месяц, админ восстанавливал силы в отпуске.
Теперь всё, возвращаемся в work mode 💼

Ждете уже майские? Какие планы?
#поддержка

IT АНАЛитика | Подписаться

Ты точно знаешь, что такое архитектура? 🤔

Недавно был на собесе и получил вопрос:

«А что такое архитектура? Зачем она вообще нужна?»

А почему солнце светит?

В комментарии выложу картинку, как выглядело моё лицо в тот момент 🙂.

Обычно такие вопросы задают с одной из двух целей.
1. Проверить самообладание.
Бизнес порой задаёт простые или странные вопросы, и важно уметь спокойно на них отвечать.
Помню, как на собесе кандидату задали простой вопрос, а он выдал: «РРЯЯЯЯЯЯЯ ВЫ ЧЕ ТУПЫЕ, НУ КТО ТАКОЕ СПРАШИВАЕТ, НУ ВЫ И КРИНЖ»

2. Проверить логику и базовые знания.
Именно на простых вопросах многие неожиданно сыплются.

Кажется, что это очевидно. Но попробуйте объяснить прямо сейчас не подглядывая 👀

Что такое архитектура? 🧱
Если совсем по-простому, то это чертёж системы.

Как в строительстве: прежде чем строить дом, архитектор рисует план — где стены, где двери, как всё соединяется, из каких материалов.
В IT всё то же самое: архитектура описывает из каких компонентов состоит система, как они взаимодействуют и почему именно так.

Зачем это знать аналитику?🤔
Ну, во-первых, чтобы меньше платить и не брать полноценного архитектора .

Если серьёзно, то как ты будешь проводить системный анализ в отрыве от самой системы? Любое решение проектируется внутри какой-то архитектуры, и не понимать как она устроена ну вообще никак.

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

Самые популярные виды:
➡️ Монолит Вся система это один большой кусок. Логика, база и интерфейс лежат в одном месте.
На старте это просто и удобно, особенно если приложение небольшое. Но чем больше система растёт, тем тяжелее её масштабировать и менять.

➡️Микросервисы Система разбита на маленькие независимые сервисы, каждый отвечает за свою задачу. Главный плюс, если один сервис упал, остальные продолжают работать. Гибко и устойчиво.
Но есть нюансы: сервисов много, значит много интеграций, много мест где может что-то пойти не так, и отлаживать, деплоить и мониторить всё это заметно сложнее чем монолит.

Дальше уже идут архитектурные паттерны, в рамках которых можно реализовать ту или иную систему.

Что будет, если накосячить? 💀
Архитектурные ошибки самые дорогие.

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

Именно поэтому архитектурные решения принимаются в самом начале и согласовываются со всеми заинтересованными сторонами.

А вам на собесах задавали базовые вопросы, от которых хотелось сказать «подержи моё пиво, ща тебе расскажу»? Делитесь в комментариях 👇

IT АНАЛитика | Подписаться