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

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

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

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

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

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

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

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

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

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

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

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

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

IT АНАЛитика

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


IT АНАЛитика