💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

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

Посты
Как принять задачу от бизнеса и не страдать?
Как выглядит хорошая документация?
Прибейте меня, я веду проект с нуля. Часть 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 АНАЛитика

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

В прошлый раз мы разложили проект по полочкам — выделили user story и накидали оценки.

Теперь главный вопрос: а что делать в первую очередь?
И вот тут нам может помочь MVP.

Что такое MVP?🤔

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

Зачем вообще нужен MVP?😐

💡 Проверить гипотезу — нужен ли наш продукт или фича вообще кому-то? Если мы не уверены, что фича действительно нужна пользователю, MVP позволяет это быстро проверить без долгой и дорогой разработки.

⚠️ Снизить риски - если проект или большая задача окажется "не очень хорошей", MVP поможет понять это раньше, а не через год, когда уже всё сделано и поздно плакать.

💸 Сэкономить деньги - меньше задач → меньше затрат → Уже не так обидно🤡.

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

Как выделить MVP из User Story Map?

♥️ Берём happy-path — сценарий, где пользователь делает всё правильно и ничего не ломается.

♥️ Проходимся по шагам и спрашиваем:
👉 “Если этого не будет — дойдёт ли пользователь до цели?”
❌ Нет → оставляем.
✅ Да → выпиливаем.

♥️ Всё, что осталось — это и есть наш MVP.

♥️ Проверяем: Сможет ли пользователь решить свою задачу с таким набором?
Если да — супер. Если нет — докидываем минимум.

♥️ Показываем бизнесу и согласовываем.

MVP и аналитик🧠

Если повезло, и рядом есть крутой продукт или менеджер, MVP спроектируют за вас — а вам останется только проработать задачи.

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

Главное правило: Если фича делает жизнь пользователя удобнее, но без неё всё равно можно достичь цели — это не MVP.

А как вы определяете MVP? Делаете всё сами или у вас есть классный продукт/менеджер?
Делитесь в комментариях👇

IT АНАЛитика