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


IT АНАЛитика

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

Если вы работаете с API, то, скорее всего, слышали от разработчиков фразы вроде:
"Настроили новую MAPI", "Надо глянуть логи в MAPI" и т. д

Но что это вообще такое и зачем это знать аналитику?

Что такое MAPI?😠

MAPI (Management API) — это инструмент для управления API без изменений в коде. Он позволяет настраивать доступы, отслеживать запросы, включать новые версии API и распределять нагрузку централизованно, без доработок в каждом сервисе.

Что можно делать через MAPI?😞

👉Ограничивать нагрузку – настраивать rate limiting, чтобы один клиент не перегружал API.
👉Контролировать доступ – выдавать API-ключи, настраивать авторизацию и ограничения.
👉Менять версии API – плавно переключать пользователей со старых версий API на новые.
👉Логировать и мониторить – отслеживать ошибки и собирать метрики по запросам.

Почему это может быть важно для аналитика?🤝

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

1⃣Интеграции
Если ваш сервис работает с внешними API, MAPI может управлять этими подключениями. Например, отключать неактуальные сервисы или переключать трафик на другие эндпоинты без доработок в коде.

2️⃣Контроль версий API
Некоторые API работают сразу в нескольких версиях (например, v1, v2).
MAPI позволяет гибко управлять переходом на новые версии – это важно, если у вас есть интеграции, которые нужно переносить с устаревших API.

3️⃣ Управление доступами
Аналитик желательно понимать, какие сервисы могут обращаться к API и как настроены права доступа. Через MAPI настраивают токены, ключи API и уровни привилегий, что критично для безопасности.

4️⃣ Мониторинг и ошибки
Если интеграция работает нестабильно, в MAPI можно посмотреть логи запросов, метрики и статус сервисов. Это помогает быстрее понять, проблема в API или в вашей системе.

Аналитику не нужно глубоко копать в MAPI, но понимать, как оно влияет на интеграции, доступы и стабильность API — полезно.

Если в вашем проекте куча микросервисов и сложные интеграции, возможно, MAPI уже используется, просто вы об этом не знали. 😏

А вы сталкивались с MAPI в работе? Где оно у вас применяется? Делитесь в комментариях.➕


IT АНАЛитика

Скоро весна коллеги, держимся🤟
#поддержка


IT АНАЛитика

Жизнь или смерть без нормальной документации?💀

Недавно посмотрел лекцию Яндекса для продактов (скидывать не буду — для аналитиков там пользы мало и идёт еще 2ч).
Но были хорошие тейки в защиту документации, и я понял, что пост "Как выглядит хорошая документация?" можно раскрыть еще больше.

Что дает хорошая документация?👍

👆 Ускоряет тайм-ту-маркет
Разработчики сразу понимают, что и как делать, а не пишут тебе с «Блииииин, а давай созвонимся, я не поняль».

👆Бизнес🤝разработка
Бэклог приоритизируется легче: понятно, сколько стоит фича и какую пользу приносит.

👆Гарантирует согласованность на всех платформах
Никаких «на iOS работает так, на Android эдак, а на Web вообще по-другому».

👆Экономит время
Избавляет от повторяющихся вопросов и 100500 переписок с разработчиками и стейкхолдерами — вся нужная информация уже собрана в одном месте.

Что будет, если документации нет или она плохая?😭

🤯Исправление косяков после релиза
Фичи выходят с багами, потому что изначально требования были неясными. Приходится дорабатывать и выкатывать повторно.

🤯Бесконечные переписки
Разработчики и стейкхолдеры задают одни и те же вопросы, а информацию приходится вылавливать по чатам и задачам.

🤯Размытые цели
Аналитику приходится по сто раз объяснять одни и те же вещи разным людям.

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

Когда нужно начинать писать документацию?
Сразу. Как только пришла задача, даже если это всего два-три предложения. Лучше создать страницу и зафиксировать мысли, чем потом по крупицам вспоминать, что вообще обсуждали.

Как часто нужно обновлять документацию?
Краткий ответ — всегда.

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

А как у вас с этим? Всё чётко, или тоже бывает, что бизнес говорит одно, разработка делает другое, а в итоге выходит третье?🔥

IT АНАЛитика

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

Что интересного было в феврале?

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

Интересные статьи
26 паттернов микросервисов
Откуда есть пошла аналитика и что отличает DS, DA, BA и SA

Мемы
Мем
Мем посмешнее

#итоги_месяца


IT АНАЛитика

Дорогие дамы, с 8 марта!

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

Вы — самая ценная система, без которой всё бы рухнуло!

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

IT АНАЛитика

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

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

Для закрепления давайте разберёмся, в чём ключевое отличие BRS от SRS и почему их нельзя мешать в одном документе.

❗️ Частая ошибка: всё в одной куче

Иногда аналитики пишут что-то среднее между BRS и SRS, где в одном документе намешаны и бизнес-цели, и технические детали. В результате:

❌Бизнес теряется в потоке технических деталей.
❌ Разработчики не могут понять конкретные требования среди описаний бизнес-целей.

Как правильно?

✅ Сначала BRS — фиксируем, что хочет бизнес и зачем это нужно.
✅ Потом SRS — описываем, как именно это будет работать с точки зрения системы.

Чёткое разделение = меньше хаоса, меньше недопонимания, меньше лишних вопросов.

А как у вас фиксируют требования? Всё чётко разделено или по старинке — одна огромная простыня на всех? Делитесь в комментариях! 👇

IT АНАЛитика

И чё ты мне сделаешь? Я вообще в другой компании работаю🚬

Ранее я уже писал про ламоду, профи.ру и яндекс.

Кажется, пора выносить это в отдельную рубрику, потому что я снова кое-что принёс.

Я, конечно, слышал легенды про легаси в телекоме... но чтобы настолько? 😂

Это баг? Или так задумано?

IT АНАЛитика

Кто тоже не может работать с черным фоном рабочего стола?😂
#поддержка


IT АНАЛитика

Дизайн и ошибки 🎨

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

А потом начинается классика:
🤡 А почему эта кнопка тут, а не там?
🤡 Не все сценарии проработали — логика развалилась
🤡 И вечное: “А мы вообще хотели по-другому…”

Ставь лайк, если жиза

Как работать с задачами, где нужен дизайн?

1⃣Ставите задачу дизайнеру
Про этот этап я уже писал отдельно. Если есть возможность — накидайте черновик: простую схему, wireframe или даже скетч от руки. Главное — передать идею. Это сэкономит время и вам, и дизайнеру.

2⃣Проверяете макеты по требованиям Прорабатываете все состояния, сценарии, ошибки. А главное — логику переходов. Что происходит при нажатии? Что, если ошибка? Как выглядит лоадер, модалка?

3⃣Согласовываете с бизнесом
Один из самых важных (и часто самых сложных) этапов. Нужно убедиться, что всё, что нарисовано, отвечает целям задачи и бизнес ожиданиям. Лучше потратить пару дней на согласование, чем неделю на переделки.

4⃣Отдаете в разработку
Про это тоже есть отдельный пост. С понятной логикой, финальными макетами и зафиксированными сценариями.

5⃣Сами проверяете в бою (по желанию)
Зашли на стенд, потыкали кнопки, посмотрели, как это работает вживую.
Раньше я частенько сам тестил свои задачи — и это реально помогает прокачать насмотренность, замечать мелочи и лучше понимать, как макеты превращаются в интерфейсы.

Макет — это не просто "чтобы красиво".
Это полноценная часть требований, такая же важная, как и другие артефакты.
Если не проконтролировать этап макетов, это легко превращается "ГАЛЯ У НАС ОТМЕНА, БИЗНЕС СНОВА НЕ СОГЛАСОВАЛ"

А как у вас с макетами? Всё чётко или тоже бывает фристайл от фронта? Делитесь в комментах👇

IT АНАЛитика

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

Что интересного было в марте?

Посты
Жизнь или смерть без нормальной документации?
Прибейте меня, я веду проект с нуля. Часть 4
И чё ты мне сделаешь? Я вообще в другой компании работаю

Интересные статьи
Шаблон для описания микросервиса

Мемы
Смешной мем про документацию
Рекрутёр с приколом
Депрессивный рабочий стол
Идеальный вариант проведения дэйлика
Снова неугомонные рекрутёры


#итоги_месяца


IT АНАЛитика

Первая задача — это ты, а вторая — все твои мечты 🐈‍⬛

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

🐒Маленькая задачбка
То, что уходит в разработку:
— с конкретикой,
— с понятной формулировкой,
— и с нужным контекстом под каждого участника команды.

Если хочется примеров — вот весь цикл:

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

📦 User Story — задачбка побольше
User story — это часть функционала, которая решает конкретную задачу пользователя.
И внутри неё почти всегда:
— фронт,
— бэк,
— дизайн,
— тестирование,
— аналитика.

🤣 Классическая форма:

Я, как КТО, хочу ЧТО, чтобы ЗАЧЕМ.

👀 Пример:

Я, как клиент, хочу видеть последние 5 операций на главной,
чтобы быстро проверить движение по счёту.

User story может завести как аналитик, так и product owner — зависит от процессов.
Главное — чтобы она была и была понятной.

🧊 Эпик — вообще большая задача жестб
С эпика всё начинается. Это хотелка бизнеса или идея на уровне «хотим новый процесс / продукт / модуль».

В нём ещё нет конкретных сценариев — есть только цель и боль.
Тут АНАЛитик и вступает в игру.

🧠 Как это выглядит в жизни?
1) Бизнес заводит эпик.
2) Аналитик берёт его в работу.
3) Погружается, собирает требования, оформляет BRS и SRS.
4) Делит на user story — понятно, по смыслу.
5) По каждой user story формирует задачи — уже для команды.

👉 В следующий раз расскажу про один удобный инструмент, который помогает выделить user story и не утонуть в хаосе.
С него удобно начинать декомпозицию и переходить к задачам.

Пишите, как у вас организована работа с эпиками и user story. Работает?😅


IT АНАЛитика

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

В прошлых частях мы разобрались с требованиями, написали BRS и SRS, зафиксировали хотелки бизнеса и логику системы. Вроде бы можно отдавать в разработку…

🍺Hold me beer

Сначала нужно разложить проект на кусочки, чтобы команда поняла, что именно делать.
И вот тут на сцену выходит: User Story Map.

🧠 Зачем он нужен?

Когда просто заводишь задачи в бэклог, легко что-то упустить.
А User Story Map помогает разложить всё по полочкам:

— понять, что делает пользователь,
— где он получает ценность,
— и какие user story это обеспечивают.

🎯 Плюс — видно, что пихать в MVP, а что можно спокойно перенести в будущие релизы.

👨‍🎨 Как это выглядит?

📌 Сверху — путь пользователя (user journey):

«Зашёл → Выбрал товар → Оформил заказ → Получил подтверждение»

📌 Ниже — user story под каждый шаг:

«Хочу увидеть список товаров», «Хочу отфильтровать по цене», «Хочу выбрать доставку»

📌 Ещё ниже — обычные задачи для реализации:

Дизайн, фронт, бэк, тесты, аналитика.

😳 Как с этим работать?

1⃣ Определяем шаги пользователя — от входа до финальной цели.
2⃣ Под каждый шаг — добавляем user story (что пользователь хочет сделать).
3⃣ Декомпозируем на задачи: кто и что делает, чтобы реализовать эту историю.
4⃣ Зовём команду на оценку.
5⃣ А потом приходит бизнес и не согласовывает такую оценку, потому что — А вы не ахуели так долго такой простой функционал делать? У нас нет столько денег.

Чем полезна карта?
✅ Видно, где что упускаем.
✅ Удобно делить по релизам.
✅ Упрощает декомпозицию
✅ Можно сразу выделить и согласовать MVP
✅ Можно быстро прикинуть объём и трудозатраты

User Story Map — может показаться каким-то дедовским способом, но тема реально рабочая.
Даже если проект сложный, вы легко поймете, с чего начать и что в него будет входить.

Пробовали USM или используете что-то другое? Или просто: «давайте прикинем, чё надо, и вперёд»?
Делитесь опытом👇

IT АНАЛитика

К посту выше был комментарий:

Я примерно понимаю разницу, к Usm мы скоро должны прийти.

Я представляю процесс построения как некий коллективный брейншторм. На доске в офисе или в Мирошке, вы это так делаете?

Инструмент можно использовать по-разному и адаптировать под себя.

Давайте чуть подробнее расскажу, как это работает у меня:

Работаем удалённо — показываю карточки на доске или просто задачи на экране.
Если офлайн — используем доску в переговорке.

1️⃣Получил какую-то большую задачу или проект.

2️⃣В процессе анализа выделяю, из каких крупных кусков он состоит.

3️⃣Каждый кусок декомпозирую на более мелкие задачи.

⭐️Где-то ставлю предварительные оценки сам, если уже делали подобное.

5️⃣Ставлю встречу с командой. Разбираем каждую задачу, команда накидывает оценки. В процессе может всплыть, что где-то нужно добавить задачи, а где-то, наоборот, — убрать лишнее или объединить.

6️⃣Если после встречи остались вопросы — иду доуточнять, потом собираю команду повторно.

7️⃣Когда всё готово — дооформляю задачи и закидываю в бэклог.

Там же в комментариях есть пример, как выглядит такая USM.

А как у вас происходит оценка и декомпозиция? Делитесь в комментариях👇

IT АНАЛитика