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

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

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

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

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

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

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

В прошлый раз мы собрали MVP и согласовали с бизнесом, какие задачи будем делать.

Когда задач становится всё больше, нужен способ следить за их выполнением. И если с 2–3 задачами ещё можно как-то жить, то при 10–15 уже не так просто зайти в бэклог и глянуть статус.

🎯 Почему важно отслеживать прогресс:

1. Понимаем реальный статус проекта.

2. Видим узкие места — где задачи зависли.

3. Можно быстро показать бизнесу, что уже сделано, а что нет.

😨 Что бывает, если прогресс не отслеживать:

1. Никто не понимает, что вообще готово.

2. Задачи теряются и забываются.

3. Срываются релизы и горят сроки.

🧠 Как я слежу за прогрессом:
Конечно, можно ковыряться в бэклоге, прыгать по эпикам и user story. Но если задач становится много — в этом хаосе легко утонуть.

Поэтому я всегда завожу простую табличку в документации проекта.

Что я туда пишу:

1️⃣Название User Story - краткое понятное название. Лучше сразу со ссылкой на задачу.

2️⃣Описание - что конкретно нужно сделать.

3️⃣Критерии приёмки - как поймём, что задача закрыта и всё ок.

4️⃣Приоритет - насколько срочно и важно это делать.

5️⃣Ответственный - кто «тащит» эту историю.

6️⃣Статус - новая, в работе, на тестировании, готово и т.д.

7️⃣Макеты - ссылки на Figma или другие материалы, если есть.

8️⃣Оценка трудозатрат - сколько времени/усилий потребуется

Так гораздо удобнее следить за прогрессом по задачам и не нужно открывать кучу вкладок разом.

✅ Все user story и задачи на виду.
✅ Легко увидеть, где тормозит проект.
✅ Проще обсуждать прогресс с бизнесом.

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

IT АНАЛитика

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

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

Посты
Как работать с задачами, где есть дизайн?
Типы задач, с которыми работает аналитик
Полезный инструмент аналитика - USM
USM на практике
Аналитик и MVP
Как следить за прогрессом на проекте?

Интересные статьи
Про зарубежный рекрутинг
8 полезных принципов при написании документации

Мемы
Боевой настрой
Для многих жиза

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


IT АНАЛитика

Как справиться с любой задачей?🥷

Когда-то я уже писал статью на Хабре: "Как эффективно решать проблемы в IT: 10 шагов для начинающих аналитиков". Если ещё не читали — советую заглянуть.

А сейчас поговорим на похожую тему. Вы ведь наверняка сталкивались с этим: открываешь новую задачу в спринте и сразу хочется закрыть её обратно — знакомо? Опять дали какую-то ху**ю делать, сука тимлид бл*ть за што.

И вот она лежит, пылится, а вы берёте всё что угодно, кроме неё. «Ну не сейчас, чуть позже…» Но время идёт, дедлайн поджимает, и от задачи уже не сбежать. 😩

Так как же с ней справиться? Давайте разложу по шагам. 👇

1⃣Прочитайте задачу внимательно
Не пытайтесь сразу решить её. Просто поймите суть.
Если описание неполное или непонятное — идите к автору задачи и уточните.
Задавайте вопросы:

— Что должно получиться?
— Почему это важно?
— Есть ли ограничения?

2⃣Определите результат
Что должно быть на выходе? Как поймёте, что задача выполнена?
✅ Документ?
✅ Рабочий API?
✅ Согласованный процесс?

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

3⃣Разбейте задачу на шаги
Большая задача пугает? Бу, испугался? Разделите её на кусочки:

— Что нужно сделать в первую очередь?
— Что зависит от других?
— Что можно параллелить?

Когда задача разбита на шаги, она станет понятнее и процесс её выполнения ускорится.

4⃣Найдите примеры
Возможно вы не первый кто сталкивается с такой задачей и кто-то её уже делал.

— Есть ли похожие задачи в бэклоге?
— Кто из коллег уже делал что-то подобное?
— Можно ли посмотреть, как это сделано в другом проекте?

5⃣Соберите информацию
Если задача про интеграцию — узнайте, как работает другая система.
Если это про документацию — изучите, какие требования к ней есть.
Не бойтесь спрашивать, если чего-то не знаете. Лучше уточнить сразу, чем потом всё переделывать.

6⃣Выпишите подводные камни
На что стоит обратить внимание? Что может пойти не так?
Если есть риски, сразу их фиксируйте.

7⃣Начните с самого простого
Не нужно пускаться во все тяжкие и сразу пытаться описать 10 методов, БД и спроектировать 2 микросервиса.

✅ Прочтите уже имеющуюся документацию
✅ Создайте страницу в базе знаний
✅ Поставьте встречу с заинтересованными лицами

Потихоньку разгоняйтесь и делайте задачу поэтапно.

8⃣Попросите помощь, если застряли
Не стесняйтесь обращаться к коллегам. Если кто-то может ответить за 5 минут, а вы рискуете потратить час на поиски — выбор очевиден.

9⃣Регулярно фиксируйте прогресс
Для этого конечно есть дэйлики, но если задача большая, можно потеряться в деталях.

✅ Создайте заметку или документ, где будете фиксировать: что уже сделано, что осталось, и какие вопросы ещё нужно уточнить.

💯Помните: любую задачу можно решить
Главное — не паниковать и не пытаться всё сделать сразу.
Двигайтесь шаг за шагом и тогда даже самая душная задача станет понятной и выполнимой.

У вас бывают душные задачи? Как справляетесь?

IT АНАЛитика | Подписаться

Аналитик решил посмотреть код проекта и умер...потому что для этого пришлось оформить 5 заявок.

Должен ли аналитик читать код?🤔

Недавно мне написала подписчица с вопросом:

СА обязан уметь читать код? И ещё, когда пишу тех требования, я должна рыться в коде и сама находить существующие эндпоинты, если их нет в сваггере?

🔥 Вопрос отличный. Сразу скажу: обязанности такой нет (если, конечно, у вас это не прописано прямо в проекте). Но если вы умеете читать код — работать становится намного легче.

🚫 Почему чтение кода не является обязательным:

1️⃣ Основная задача системного аналитика — анализ требований, документирование процессов и взаимодействие с бизнесом и техническими командами.

2️⃣СА должен уметь описывать функциональные и нефункциональные требования, а также обеспечивать их понимание разработчиками.

3️⃣Техническая реализация и написание кода — задача разработчиков.

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

Когда навыки чтения кода становятся полезны:

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

😛Я сам раньше разворачивал себе проект и было удобно где-то самому разбираться. А если разработчики заняты — нужную информацию можно найти самому.

2⃣Общение с разработчиками
Когда вы созваниваетесь и он начинает объяснять, как работает функционал, вы не будете тупить. Разраб не будет думать, что вы "обезьянка для работы с требованиями" — вы говорите на одном языке и сразу понимаете друг друга.

3⃣Тестирование и отладка
Вы сможете быстрее находить причины ошибок, если понимаете, как работает код.
Банально: открыли логи, увидели stack trace, поняли, какой метод упал, и сразу можете объяснить команде.

Понимание алгоритмов поможет быстрее во всём разобраться.

Каких знаний хватит, чтобы разработчик подумал, что вы шарите?

😏Понимать, как устроен код: знать, что такое функции, методы, классы и объекты.

😏Читать и разбирать простую логику: условия, циклы, вызовы функций и обработку ошибок.

😏Основы ООП: понимать наследование, инкапсуляцию, полиморфизм.

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

А как у вас на проекте? Может ли аналитик лезть в код или это строго задача разработчиков? Делитесь в комментариях 👇


IT АНАЛитика | Подписаться