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

В продолжении поста про 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 АНАЛитика

Аналитик в банке — это так, для души. На самом деле, я админ Telegram-канала. 😎

Но если серьёзно, это уже 100-й пост! Спасибо, что читали, репостили, комментировали и ставили реакции. 1000 подписчиков — это пока так, разогрев. Обнимаю каждого! ❤️

В следующем году планов много, так что stay tuned, как говорится.

От себя хочу пожелать:
🐈 Новый оффер, если вы в поиске.
💰 Больше зп, если оно вам нужно.
🤟Баланс между работой, которая приносит кайф, и жизнью, которая радует ещё больше. Но лучше вообще не работать.

С Наступающим! 🎄🎉

IT АНАЛитика

Врываемся в первую рабочую неделю! Два дня всего💬
#поддержка


IT АНАЛитика

Яндекс ********* или как я проиграл UX/UI

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

Дано:
📱Старый телефон.
📱Новый телефон.
👴Батя, которому нужна Яндекс Музыка на новом телефоне.
💻Яж программист аналитик, который всё подключит.

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

Реальность:
1️⃣ Авторизовались.
2️⃣ На аккаунте, где точно была подписка, её почему-то нет.
3️⃣ Два дня пытаюсь понять, почему так.

Тут можно взять паузу и высказать догадки.
Итог:
1️⃣ После авторизации по номеру телефона яндекс не увидел привязанную учетку и предложил ввести имя и фамилию.
2️⃣ Ввёл, как есть.
3️⃣Оказалось, что при регистрации имя было в другом падеже. Теперь, когда я ввёл его по-другому, система решила, что это чужой человек, и создал новую учётку на тот же номер.
4️⃣На старом телефоне имя и фамилия нигде не показывались, так что пришлось угадывать.
5️⃣ Сгорела жопа.

Как думаете, почему так? Почему просто не привязать авторизацию к существующей учётке?


IT АНАЛитика

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

В прошлой части мы разобрали, с чего вообще начинается работа аналитика, на новом проекте.

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

Когда всё обсудили, уточнили и вроде даже договорились — надо не просто держать это в голове или чатах, а оформить в структурированный документ, чтобы:

🙄 Бизнес понимал, что получит в итоге.
😿 Команда работала без сюрпризов, зная границы проекта и его объём.
💩 Не получилось «ой, а давайте ещё вот это добавим» за неделю до релиза.

Что такое BRS и зачем он нужен?
📌 BRS (Business Requirements Specification) — документ, который фиксирует ожидания бизнеса от проекта. Это базовая точка, которая не даёт проекту разрастись и превратиться в снежный ком неопределённости скатиться в говно.

Что должно быть в BRS?
🔤 Цель проекта — какую проблему решаем?
🔤 Область применения — кто будет пользоваться системой и как?
🔤 Границы проекта — что делаем, а что не делаем?
🔤 Ключевые бизнес-правила — ограничения, регуляторные требования, KPI.
🔤 Функциональные требования — какие возможности должна дать система бизнесу?
🔤 Нефункциональные требования — интеграции, производительность, ограничения.

Важно понимать, что BRS — это не технический документ. Здесь нет API, БД или схем архитектуры. Это про что и зачем, а как — это уже будем разбирать позже.

Что дальше?
BRS — это только первый шаг. Дальше его нужно детализировать и перевести в конкретные требования для разработки. В следующей части поговорим про SRS и как превратить бизнес-требования в рабочую спецификацию без боли.

Прикрепил к посту свой шаблон BRS, пользуйтесь.

А как у вас фиксируют договорённости с бизнесом? Делитесь в комментах! 🤔

IT АНАЛитика

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

В статье ниже разбирают, почему так происходит (выборка там не то чтобы вау, но всё равно любопытно) - читать📚.

📌 Чаще всего использую BPMN в трёх ситуациях:

1️⃣Когда бизнес-процесс создаётся с нуля.
Его нужно спроектировать, согласовать и показать бизнесу. Затем добавляю в документацию, чтобы процесс не терялся и всегда был доступен для потомков.

2️⃣При доработке существующего процесса.
Если процесс не был описан — описываю. Если уже есть — дорисовываю недостающие шаги.

3️⃣Если задача большая и сложная.
Похоже на пункт 2 из статьи: «В схему никто, кроме рисующего, не смотрит».
В сложных задачах легко что-то упустить — не завести нужную задачку или пропустить важный шаг. В таких случаях рисую BPMN "чисто для себя" (но и в документацию тоже прикладываю), чтобы идти по шагам, а не держать всё в голове как абстракцию.

👀А вы используете BPMN? В каких кейсах?


IT АНАЛитика

Чей коллега, признавайтесь?😱
#поддержка


IT АНАЛитика

Как принять задачу от бизнеса и не страдать?😊

Бывало ли у вас такое, что на демо звучит фраза:
— А почему вы не сделали вот это?😡

А вы в душе не е**ете, о чём вообще речь. Задачу могли скинуть голосовым, написать в чате, а вы не заметили.
Или ещё вариант: приходит задача с непонятным заголовком и описанием «НАДО СДЕЛАТЬ ВЧЕРА», без контекста, без деталей. В итоге первым делом ставишь встречу, чтобы хотя бы понять, о чём речь.

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

Как решить проблему?💻

1️⃣ Объясните бизнесу, почему это важно.
Из-за плохо поставленных задач теряется время не только у аналитика, но и у бизнеса, потому что придётся тратить его на бесконечные уточнения.

2️⃣Договоритесь об общем шаблоне.
Чётко зафиксируйте, в каком формате принимаются задачи. Если задача оформлена криво — не берём в работу, пока не будет нормального описания.

3️⃣Настройте шаблон в таск-трекере.
В Jira и других системах можно сделать так, чтобы при создании задачи автоматически появлялись нужные пункты для заполнения. Либо просто разошлите шаблон коллегам, чтобы они его вставляли вручную.

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

А как вам ставят задачи? Или приходится вылавливать их в переписке и голосовых? Делитесь в комментах!👉


IT АНАЛитика

Раньше в вакансиях к СА частенько привязывали обязанности DA и DS. Не путайте😠
📌 Читать статью


IT АНАЛитика

Как выглядит хорошая документация? 📄

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

Бывает, открываю документ, а там:
🚨 Простыня текста без структуры.
Или наоборот — два предложения, и сиди гадай, что, куда, зачем.
😂 Термины, которые никто, кроме автора, не понимает.

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

Жиза?

Как этого избежать?

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

📌 2. Единообразие
Аналитика от одной команды должна выглядеть одинаково в идеале. Оформите единый шаблон, договоритесь об общих обозначениях и правилах.

📌 3. Минимум воды, максимум смысла
«Метод X выполняет Y в микросервисе Z» — никакой двусмысленности, сразу понятно, что, где и зачем.

📌 4. Визуализация
Если задача того требует, приложите BPMN или sequence-диаграмму. Проще один раз взглянуть на картинку, чем разбираться в тексте, а потом тратить время на уточнения в созвоне.

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

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

📌 6. Доступность
Документ должен быть там, где его легко найти. Если его надо «выбивать» у аналитика или рыться в 10 папках, он бесполезен. Договоритесь, где хранится аналитика по задачам, интеграциям и прочему.

📌 7. Словарь терминов
Если в документе встречаются специфические термины, заведите словарь. Иначе тестировщик или разработчик придёт с вопросом.

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

А как у вас с документацией? Всё чётко или приходится искать нужную инфу по чатам?😠


IT АНАЛитика