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 АНАЛитика | Подписаться

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать📚

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

IT АНАЛитика | Вильд Виктор pinned «За деньги ДА! В прошлом году и немного в этом я проводил консультации. Я специально это не пушу. Свободного времени немного, и после работы хочется либо заняться своими делами, либо просто почилить. Да и консультировать «всех подряд» не самая интересная…»

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

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

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

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

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

IT АНАЛитика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🙃

#поддержка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чей офис коллеги?

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

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

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

Вторая часть

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

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

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

Читать📚

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

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

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

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

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

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

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

За деньги ДА!

В прошлом году и немного в этом я проводил консультации.

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

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

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

👉Ссылка

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

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

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

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

Читать 📚

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