Нас стало больше! 😎
Для всех новеньких и тех, кто пропустил, вот, что можно почитать на канале:

Профессиональный рост и эффективность💼:
Как эффективно решать проблемы в IT: 10 шагов для начинающих аналитиков
Как получить оффер на 180к с помощью ChatGPT?
Дорожная карта тимлида
Нужен ли аналитику SQL?
Всё, что нужно знать про SQL

Введение в IT для начинающих🖥:
У России три пути и один из них IT Часть 1
Резюме дороже денег
Резюме дороже денег 2
Резюме дороже денег 3
Резюме дороже денег 4

Работа в IT📞:
Хорошие и плохие компании
Да кто такие эти ваши Agile, Scrum и Kanban
Возраст в IT: препятствие или преимущество?
Как определить, подходит ли тебе компания?
Интеграции мои интеграции
Про работу с требованиями

Коммуникация и обратная связь🗣:
Качественная обратная связь: Часть 1
Качественная обратная связь: Часть 2

Постановка задач в IT📝:
Хорошо поставленная задача есть? А если найду? : Часть 1 - Почему важно
Хорошо поставленная задача есть? А если найду? : Часть 2 - Общий шаблон задач
Хорошо поставленная задача есть? А если найду? : Часть 3 - Frontend
Хорошо поставленная задача есть? А если найду? : Часть 4 - Backend
Хорошо поставленная задача есть? А если найду? : Часть 5 - Тестировщик
Хорошо поставленная задача есть? А если найду? : Часть 6 - Дизайнер
Хорошо поставленная задача есть? А если найду? : Часть 7 - Архитектор

Так же не забудьте посмотреть все посты под хэштегом #поддержка

IT АНАЛитика

Хорошо поставленная задача есть? А если найду? 🕵️‍♂️: Часть 9 — Аналитик

Итак, финал… правильная постановка задачи для аналитика:

А никак. Достаточно лишь небольшого заголовка и аналитик сам, как цепной пес возьмет след и все разузнает по задаче😂

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

История о том, как HR смог перейти в системные аналитики! Читать📖

Честно, не представляю, каково это — вкатиться в аналитику без техбэкграунда⚰️.

А как у вас?
Если тоже вкатывались, как гуманитарий и смогли освоиться, делитесь своими историями в комментариях — интересно, как прошёл ваш путь!☠️

Виды АНАЛитиков💬

Когда меня спрашивают, кем я работаю, я обычно отвечаю: «Аналитик». Если человек не из IT, объяснять, что ты системный аналитик, и бизнес-аналитик, да и вообще-то фулстак, ноооо и еще частично задачи дата-аналитика выполняешь — душно.

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

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

1. Системный аналитик 🔍
Лучший друг команды разработки. Он всегда знает, как надо делать. Отлично понимает, как устроена система изнутри, и делает так, чтобы весь новый и старый функционал работал четко. Так же анализирует требования, создает документацию и иногда общается с бизнесом. Роль для тех, кто не боится «покопаться в кишках» системы и всегда ищет, как улучшить её работу.

2. Бизнес-аналитик 🤝
Правая рука бизнеса. Он всегда знает, что надо делать. Собирает требования, описывает процессы, глубоко погружен в работу компании. Похож на системного аналитика, но без глубокого погружения в технические детали. Человек, который переводит хотелки бизнеса в понятные для команды задачи.

3. Фулстак аналитик 😆
Человек-оркестр. Знает, что и как делать на проекте. Держит всё под контролем, в равной степени общаясь с бизнесом и разработкой. Такой аналитик совмещает в себе роли системного и бизнес-аналитика, а иногда и других.

Чаще всего эдакий универсал — мечта любого работодателя. Даже если в вакансии написано другое ищут всегда его.

"А почему бы не взять и системного, и бизнес-аналитика?" — спросит юный читатель

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

4. Дата-аналитик (Data Analyst)🤓
SQL-мастер и гуру отчётов. Его задача — собирать, обрабатывать и анализировать данные, чтобы бизнес мог видеть реальные цифры и принимать решения по своим задачам. Работает с SQL, Excel, BI-инструментами и превращает данные в красивые картинки.

5. Продуктовый аналитик🍎
Сосредоточен на продукте и пользователях. Исследует, как продукт используется, анализирует метрики и помогает команде понимать, что улучшить. Главный кореш продуктовых команд, который помогает принимать решения на основе данных.

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

6. Data Scientist 🤖
Киборг-убийца, который выходит за рамки обычного анализа данных. Строит прогнозные модели, работает с ML и помогает компании видеть будущее. Это роль для тех, кто не боится математики и любит моделей данных🥰

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

IT АНАЛитика

🔤🔤🔤🔤🔤: что это и зачем знать аналитикам?

В последнее время всё чаще слышу от разрабов фразы вроде: «Ну мы дергаем их фейн…», «Там фейн запросы делает…». Кажется, что в контексте диалога всё понятно — особенно когда тебе шарят экран и вы обсуждаете задачу.

Но если попытаться объяснить своими словами, выходит что-то вроде: «Ну, это такая штука в коде…» 🤔

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

Что такое Feign?
Feign — это декларативный HTTP-клиент для Java, который придумали в Netflix, чтобы упростить взаимодействие с RESTful веб-сервисами. С Feign можно написать пару строк кода вместо полноценного запроса, оставляя остальную логику библиотеке. Всё делается через аннотации в интерфейсах, так что работать с внешними API становится намного проще.

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

@FeignClient(name = "credit-history-client", url = "https://api.creditcheck.com")
public interface CreditHistoryClient {

    @GetMapping("/history")
    CreditHistoryResponse getCreditHistory(@RequestParam("userId") String userId);
}

Здесь FeignClient указывает базовый URL, а GetMapping настраивает конкретный запрос. Теперь, чтобы узнать кредитную историю клиента, достаточно вызвать метод getCreditHistory() — Feign автоматически сделает всю работу за кулисами.

Зачем это знать аналитикам? 🤔
✅Во-первых, чтобы быть в одной плоскости с разработчиками и лучше понимать, как работают интеграции между системами.

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

А вы сталкивались с Feign в своей работе? Часто ли вообще приходится смотреть в код? Делитесь опытом в комментариях👇

И снова здравствуйте💋

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

IT АНАЛитика

Тут на примерах с кодом объясняют, что такое микросервисы для аналитиков.

Да, не каждый аналитик будет копаться в коде, но понимать, как работает и выглядит микросервис, а также иметь хотя бы базовое представление об ООП — это must have.

Ознакомиться📕

🔤🔤🔤🔤🔤🔤🔤🔤🔤: что это и зачем?

В продолжении поста про Feign, есть ещё одна вещь, о которой стоит знать аналитикам — ConfigMap. Если вы работаете с проектами, где используется Kubernetes, то наверняка слышали фразу: «Эта настройка лежит в конфигмапе».

Что такое ConfigMap?
ConfigMap — это объект в Kubernetes, который хранит конфигурационные данные приложения. Это ключевой инструмент для управления настройками, такими как:

➡️адреса API,
➡️ключи доступа,
➡️параметры подключения,
➡️другие переменные, которые могут меняться в зависимости от среды (разработка, тестирование, прод).

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

Пример📄
Представьте, у вас есть сервис для отправки уведомлений клиентам. В зависимости от окружения (тест, прод) он должен использовать разные SMTP-серверы для отправки писем. Вместо того чтобы каждый раз менять настройки прямо в коде, эти данные выносят:

apiVersion: v1
kind: ConfigMap
metadata:
  name: smtp-config
data:
  SMTP_SERVER: "smtp.mailserver.com"
  SMTP_PORT: "587"
  SMTP_USER: "noreply@example.com"

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

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

IT АНАЛитика

Иногда конечно бывает смешно, когда в резюме у тебя написано одно, а предлагают совершенно другое😐


IT АНАЛитика

Прибейте меня, я веду проект с нуля. Часть 1🍑

Вы — аналитик, и вам поручили вести новый проект или большую задачу с нуля. Что делать? С чего начать? Объём работы душит, глаза разбегаются, хочется плакать.

Но на самом деле всё не так страшно, как кажется. Недавно на консультации разбирал подобный вопрос, и захотелось сделать серию постов, чтобы разложить всё по полочкам. Let's go🚬

Шаг 1. Первичное погружение 🧐
Хорошо, если у бизнеса есть чёткая постановка. Ещё лучше, если она понятная. И мега кайф, когда он точно знает чего хочет.

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

1. Цели проекта: Зачем он нужен бизнесу? Какую проблему решает?
2. Конечные пользователи: Кто они? Что для них важно?
3. Интеграции: Есть ли системы, с которыми проекту нужно взаимодействовать?

Первичной инфой может поделиться человек давший вам задачу, PO или кто-то непосредственно из бизнеса. Главное — не стесняйтесь задавать вопросы, чтобы собрать максимум контекста на старте.

Шаг 2. Заводим раздел под документацию 📂
Документация — ваш главный бро. Организуйте место, где вы будете:

А. Хранить протоколы встреч.
Б. Описывать функционал.
В. Фиксировать все важные детали проекта.

Используйте Confluence, Google Docs или любую другую систему, удобную для всей команды. Главное, чтобы всё было доступно, структурировано и понятно другим участникам проекта.

Шаг 3. Работаем с требованиями 🙅‍♂️
Мы и до этого с ними считай работали, но теперь все серьезно:

🤟Если требования есть:

1. Тщательно изучаем.
2. Ищем пробелы и неясности.
3. Назначаем встречу с заказчиком для уточнений.

😡Если требований нет:

1. Назначаем встречу с заказчиком.
2. Выясняем его ожидания, цели и текущие проблемы.
3. Фиксируем все подряд — иногда неожиданные комментарии становятся ключевыми.

Шаг 4. Доуточняем и согласовываем требования🔫

⭐️Решаем все нерешенные вопросы - лучше потратить время на уточнения сейчас, чем переписывать всё потом.

⭐️Разделите требования на функциональные и нефункциональные, чтобы было проще работать.

⭐️Согласуйте требования с бизнесом просим расписаться кровью.

В следующей части разберём, как выглядит итоговый документ, и что в нём обязательно должно быть.
А как вы начинаете вести проект? Делитесь своим опытом в комментариях! 🧐

IT АНАЛитика

vot blin😵
#поддержка

IT АНАЛитика

А я вам напоминаю!🍷

Вопрос на собеседовании:
— Какие курсы вы проходили?
— ДА

IT АНАЛитика

Так кто же виноват?🤔

Раскрываю, в чём была проблема:
На аккаунте оказалась неподтверждённая почта. В результате восстановить доступ через десктоп было невозможно — только через мобильное приложение.

Как можно было предотвратить это на разных этапах разработки?

1. Аналитик

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

2. UX/UI-дизайнер

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

3. Разработчик

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

4. Тестировщик

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

И вот вопрос: Чей был косяк? Делитесь своими версиями!

IT АНАЛитика