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

Я примерно понимаю разницу, к 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 АНАЛитика | Подписаться

Аналитик не подключился и нах*евертили

Дали мне как-то проект на проработку новой системы. Всё шло ровно, пока не дошли до этапа согласования макетов с бизнесом.

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

На что бизнес говорит: «НУ НЕЕЕЕЕТ НАМ НЕ НРАВИЦА»

😐 Почему?

Оказалось, они с дизайнером полгода (!) пилили макеты без аналитика. За это время в голове уже засела чёткая картинка, а любые предложения воспринимаются как покушение на святое.

Переубедить кое-где конечно удалось и что-то мы поправили.
Но глобально — половина интерфейсов осталась такой, какой её нафантазировали изначально.

Проект в итоге мы довели до разработки и передали коллегам. Но осадочек остался.

Вывод?

🏎Если вы продукт или проджект — подключайте аналитика как можно раньше. Особенно если проект большой. Потому что переделывать потом — боль.

🏄‍♂️Если вы аналитик — не забывайте про макеты. Старайтесь присутствовать на всех встречах и не игнорируйте предложения в формате "А МОЖЕТ СЮДА ЕЩЕ КНОПКУ Е*АНЕМ, ЧТОБЫ ПОКРАСИВШЕ БЫЛО?"

Макеты — это не просто картинки. Это полноценный артефакт, который должен соответствовать системным требованиям и быть user friendly.

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


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

И такое бывает😊
#поддержка


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

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

Админ отдохнул на майских, а потом еще бахнул 2 недели отпуска. Сейчас будем поднимать актив🚬

Посты
Как справиться с любой задачей?
Должен ли аналитик читать код?
Аналитик не подключился и нах*евертили

Интересные статьи
Про важность понимания архитектуры своего проекта

Мемы
Пукали в систему
Имя Ибрагим вам о чем-то говорит?

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


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

Кто победит: Перфекционино Бобрино или правило Парето? 🦫⚖️

Я люблю писать документацию. Чтобы каждый пункт был логичным, понятным и ювелирно выверен. Ставь лайк, если тоже страдаешь перфекционизмом😘.

Для аналитика это, в целом, плюс.
Но когда в работе 3–4 задачи, времени на идеал может просто не быть.

И вот тут к нам на помощь приходит правило Парето.
Вы наверняка уже слышали про него, если нет — то коротко:

Итальянец Вильфредо Парето заметил, что 20% усилий приносят 80% результата и наоборот, 80% усилий принесут вам — всего 20% результата.

И оно работает практически везде:

💛20% багов вызывают 80% проблем.

💛20% пользователей создают 80% обращений.

💛20% фич приносят 80% пользы.

💛20% написанной аналитики закрывают 80% вопросов от разработки

Как применить это правило в работе?

⌨️ В документации
Не нужно сразу писать талмуд на 10 страниц.
Начните с happy-path, ограничений и базовой логики — этого хватит, чтобы запустить разработку.
Остальное допишите позже или по мере необходимости.

📚 В обучении
Не надо сразу пытаться изучить всё.
Достаточно охватить ключевые темы — чтобы войти в контекст и начать применять знания.

💬 В общении с бизнесом
Иногда 1–2 сильных аргумента работают лучше, чем десяток средненьких.


👉 Главное — делайте хорошо, но не зацикливайтесь на идеале.

Сосредоточьтесь на том, что принесёт максимальный результат с минимальными усилиями.

Остальное — по мере сил и времени.

Кто победил?
😭 - Перфекционино Бобрино
🦄 - правило Парето

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

Согласен с Артёмом, и хочу добавить со стороны работы аналитика:

👉Видишь риски? Подсвечивай их сразу. Даже если они не в твоей зоне ответственности, ты тот, кто может связать всех и заранее предупредить.

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

😱 Ситуация из жизни:
Делаем личный кабинет клиента.
Один из ключевых функционалов — онлайн-чат со специалистом банка.
Онлайн-чат — не наш. Его делает другая команда.
Они обещали релиз в дату X.
Наша контрольная точка чуть позже - в дату Y.

Спойлер: сразу было понятно, что смежная команда не успеет сделать чат к нашей КТ.

С нашей стороны бизнес слышит: «Всё идёт по плану».

🧠 И бизнес живёт в уверенности:
«Если у нас всё хорошо, значит и у команды чата тоже».

Но я каждый раз на созвонах повторял бизнесу:

«Учитывайте риск — чата может не быть».

⏳ Что в итоге?
Другая команда не успевает.
Чат не попадает в релиз.

⚠️ Но!
Бизнес был готов.
Они знали о риске заранее.
Никто не устраивал разбор полётов. Всё спокойно.

👀 А кто был бы виноват, если бы про это узнали в последний момент?
— Другая команда? Отчасти.
— Менеджер? Он мог и не знать.
— Аналитик, который промолчал? 🤡

💬 Одна из задач аналитика - уметь управлять ожиданиями заказчиков.

Теоретически, можно было сказать "ну это их функционал, моя хата с краю".

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

Именно это и отличает просто исполнителя от сильного аналитика.

Узнали? Согласны?

Fuck UP №1🔥

Запускаю новую рубрику на канале — про факапы.
Буду делиться своими историями, чтобы показать: ошибки — это не конец света.

Вы тоже можете поучаствовать. Присылайте свои истории в личку @tako_man или анонимно — вот форма.

Почему вообще об этом?

Многие боятся ошибаться.

“А что подумают коллеги?”
“Теперь все узнают, что я не тяну…”
"Тимлид думает я чмоня..."

Именно из таких мыслей часто и вырастает то, что знакомо многим айтишникам — синдром самозванца.

Но на деле ошибки — это нормально. Более того, это один из главных двигателей роста.

«Я не потерпел неудачу. Я просто нашёл 10 000 способов, которые не работают.»
— Томас Эдисон

И на мой взгляд, страшнее не сама ошибка, а когда на неё просто забивают и не делают выводов.
А потом повторяют снова 🤡

Когда я только начинал как аналитик, сам для себя это сформулировал так:

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

Моя история
Не сказать, что это прям дикий факап, но осадочек остался.

Ко мне приходит PO в лице бизнеса и спрашивает:
— Вот эта СМС, которую мы шлём клиентам — она чья?

Я, не особо задумываясь, отвечаю:
— Не наша.

Где-то в голове это чётко отложилось, плюс вроде кто-то из разрабов так говорил.

Через пару часов PO возвращается — уже на эмоциях:
— Я всех обошла, навела суету, все на меня смотрели как на дуру.
А СМС оказалась нашей. Она была реализована на проекте до меня и не была задокументирована

Мы, конечно, всё порешали спокойно.
Но с тех пор у меня правило:
Не доверяй себе на слово. Проверяй. Всегда.

Даже если «точно помнишь» — проверь ещё раз.

🤔 А у вас бывали факапы, после которых вы всерьёз поменяли подход к работе?
Пишите в личку или присылайте свои истории — можно анонимно.

#FuckUP

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

Надеюсь у вас сегодня ничего не перевернется и вы хорошо отдохнете на выходных 💀


Со времен тех.поддержки осталось много забавного от пользователей. Улыбнуться можно по тэгу #поддержка


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

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

Если вы часто работаете с API или микросервисной архитектурой, наверняка слышали от разработчиков:

👨‍💻«Ну тут просто маппим в DTO и отправляем»,
или
🧑‍💻«Опа, сюда нужна ещё одна дтошка для фронта».

На первый взгляд — чисто девелоперская тема.

Но DTO — одна из тех базовых вещей, которые реально стоит понимать аналитику.
Особенно если вы участвуете в проработке интеграций.

Что такое DTO?🧱
DTO (Data Transfer Object) — это “коробка с данными”, которую одна часть системы отправляет другой.

📦Внутри — только нужные поля: например, name, email, status.
❌Логики нет
✅ Просто структура, чтобы передать информацию между слоями или сервисами.

Пример🧪
У вас есть REST API, которое возвращает данные о клиенте.
В базе данных — всё подряд: адреса, история заказов, флаги, дата регистрации и т.д.
Но фронту нужны только name, email, status.

📤 Для этого на бэке создают CustomerDto, в котором — только нужные поля.

DTO помогает не вытаскивать наружу всё подряд, а отдавать только то, что действительно нужно.

Зачем это знать аналитику? 🤔
1️⃣ Часто именно аналитик описывает, какие данные должны приходить и уходить — по сути, проектирует DTO.

2️⃣ Если нужно мапить данные между системами, то проще, когда ты понимаешь, что и где лежит.

3️⃣ Чтобы понимать, о чём говорят разработчики — и быть с ними в одном контексте.

А вы часто ли работаете с DTO в своих проектах?

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