Прибейте меня, я веду проект с нуля. Часть 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 АНАЛитика

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

В прошлых частях мы разобрали, с чего начинается работа аналитика и как зафиксировать бизнес-требования. Теперь переходим к следующему этапу — АНАЛитике описанию системы.

Если BRS отвечает на вопрос "что хочет бизнес?", то SRS — это уже про "как это должно работать?".

Что такое SRS и зачем он вообще нужен?🤔

System Requirements Specification — это документ, который связывает бизнес-требования с технической реализацией. Он описывает, как должна работать система: какие у неё функции, ограничения, интеграции, сценарии работы пользователей.

Он нужен для того, чтобы:
😕 Разработчики понимали, как должна работать система.
🐈Аналитик мог завести user story и сформировать понятные задачи.
🙄 Бизнес видел, как его хотелка будет работать.

Что должно быть в SRS?💡
1⃣ Как должна работать система.
2⃣ Какие у неё функции, ограничения и интеграции.
3⃣ Как с ней взаимодействуют пользователи.

У вас этот документ может называться по другому, но суть всегда одна: SRS — это инструкция для разработки.

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

📽Если этот пост соберёт 30 реакций, дропну шаблон, который сам использую в работе.

IT АНАЛитика

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


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 АНАЛитика