IT АНАЛитика | Вильд Виктор

Фронтенд без боли: шаблон ФТ для аналитика

Часто внимание аналитиков сосредоточено на бэке: маппинги, методы, алгоритмы, интеграции — всё расписано до мелочей. А вот фронт остаётся в тени. Если повезёт — будут макеты. Если нет — максимум пара строк вроде «кнопка делает пыщ-пыщ».
Что именно делает? Когда? Как себя ведёт?
😎Догадывайся сам, разработчик.

По итогу возникают ошибки, а разработчики и тестировщики тратят время на уточнения. Чтобы этого избежать, поделюсь базовым подходом к фронтовым ФТ.

Что важно в задаче для фронта?

1⃣Точки входа
Как пользователь попадает в функционал? С каких экранов или кнопок?
👉 Можно добавить скриншоты со стрелочками или хотя бы описать алгоритм перехода между экранами.

2⃣Бизнес-требования
Кратко фиксируем: зачем нужна фича, какие роли задействованы, что будет на выходе.
👉 тут я уже писал подробнее про постановку задач

3⃣ Пользовательские сценарии (Use Cases)
Пошагово: что делает пользователь, как реагирует система.
👉 На простых задачах можно пропустить.

4⃣ Архитектура
Sequence diagram с вызовами API и логикой переходов.
👉 Если задача простая — не перегружайте. Но для новых экранов или сложных взаимодействий must have.

5⃣ Дизайн экранов и элементов
Прикладываете ссылку на макеты, которые проработали вместе с дизайнером + описание каждого элемента.

Шаблон гибкий — берите нужные столбцы и собирайте под свой проект.
📎 Кину его в комментарий — сохраняйте в закладки, потом скажете спасибо.

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

Коллеги, кто?

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

Что такое окно авторизации?😳
#поддержка

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

Ты новый аналитик на проекте — что делать?

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

А иногда — мрак, боль и десяток заявок, чтобы просто посмотреть БД.

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

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

💡 Условно есть два сценария:

📌 1. У тебя есть другой аналитик на проекте
Это считай easy mode: задаёшь вопросы, постепенно погружаешься в проект, изучаешь процессы, системы, материалы.

Конечно качество старта зависит от онбординга:
Где-то вас будут вести за ручку и дадут четкий план.
А где-то сразу бросят в костёр и просто скажут "спроси у Васи".

Но если ты не один — это уже половина победы.

📌 2. Ты на проекте один
Тут и посложнее, и поинтереснее.

Скорее всего, тебе придётся самому выстраивать свою роль и доказывать ценность.

Вот поможет на первых порах:

1. Не теряйся и будь на связи📞
— Оперативно отвечай на сообщения
— Не пропускай встречи и не опаздывай
— Постарайся как можно быстрее получить доступы и разобраться в продукте

📝 Чем ты активнее, тем быстрее тебя начнут воспринимать как полноценного участника команды.

2. Договаривайся и фиксируй😈
Новая команда, куча инфы — легко что-то упустить.
Фиксируй договорённости в комментариях к задачам, письмах или документации.
Вёл встречу? Пришли протокол. Лучше перестраховаться, чем потом слышать «НЕ БЫЛО ТАКОГО ВЫ ВСЕ ВРЕТИ».

3. Показывай свою ценность 💻
Если задач пока мало — не сиди и не жди.
Предложи инициативу, помоги с бэклогом или документацией.

Ты уже полноценный член команды.
Не бойся брать на себя лишнего: так ты быстрее освоишься.

4. Говори, что ты делаешь🙀
У меня уже был пост про качественный обмен достижениями.
Но на старте это особенно важно.

Мало сказать на дэйлике "Ну я там доступы делал, проходил онбординг, какую-то доку почитал".

Лучше пока рассказывать все подробно по классике:
— С кем общался
— Что выяснил
— Где застрял
— Что на очереди

5. Разберись, что именно от тебя ждут😮
Возможно, от тебя хотят, чтобы появилась документация.
Или чтобы ты спроектировал новый процесс.
Или просто держал в порядке требования.

👉 Не бойся задать прямой вопрос тимлиду или менеджеру:

— «Что сейчас самое приоритетное для меня?»
— «Где могу подключиться, чтобы принести максимум пользы?»

🤝Лично мне больше импонирует приходить в команду без аналитика. Можно наводить порядок с нуля, внедрять best practices, не следовать чужим шаблонам и брать все процессы сразу под свое крыло.

А как было у вас?
Пришли на все готовенькое — или с 0 делали конфетку?

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

Из аудитора в аналитика

С недавних пор на канале появилась рубрика Fuck UP — про ошибки и провалы. Присылайте свои истории в личку или анонимно
А вот эта история — скорее про level up.

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

Я попросил его рассказать, как всё прошло. Делюсь историей — с его разрешения:

Бэкграунд — аудитор в одной энергетической компании. Системы, процессы, документы — всё близко, но не совсем IT.
Решил двигаться в сторону аналитики, прошёл годовой курс по системному анализу в одной из онлайн школ.

⚠️ Что было дальше?
— Обучение пройдено, диплом на руках
— В резюме — “Джун СА”
— 3 месяца откликов — 0 офферов
— Один собес длился 3 часа (!), дали 65 из 85 баллов — и всё равно отказ

💬 «Понял, что рынок не ищет “джунов”, а требует опыт. Даже если позиция так называется.»

Что сделал:
🔧 Перелопатил резюме с помощью GPT и советов от коллег
📌 Трансформировал опыт аудита и работы по ГПХ в формат релевантного BA/SA
📌 Указал 4 года релевантного опыта — не наврал, но грамотно подал

⚙️ После этого за 3 недели:
— 20+ первичных собесов с hr
— 9 технических собесов
— 3 оффера: 2 по BA, 1 по SA
— В итоге выбрал BA в одной из строительных компаний

Что понял в процессе:
💬 «Проходил все собесы сам, но в реалтайме иногда спрашивал DeepSeek — очень помогало.»

💬 «Во время собесов понял, что BA — ближе. Меньше углубления в стек, больше про бизнес, логику и людей.»

💬 «Без обучения было бы тяжело — не хватало бы структуры и терминов. YouTube мне не зашёл, нужна чёткая рамка и дедлайны.»

📌 Какие выводы для себя сделал?
— Курсы — это не волшебная таблетка, но вполне хорошая база
— Джунов часто не ищут. Ищут людей с опытом. Но опыт — это то, как ты умеешь рассказывать о том, что уже делал
— Упаковка резюме решает
— Если ты не общительный и не умеешь общаться, будет тяжело
— Важно уметь продавать себя, просто так ты никому не нужен

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

🧱 К слову о том, что архитектор — один из логичных треков роста для аналитика.

С Денисом, кстати, раньше работали вместе. Наш слон🐘

Читать📚

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

Коллеги поделились опытом и шаблонами, как ведут документацию.
Читать📚


Согласны?

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

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

📘 Добил книгу System Design. Подготовка к сложному интервью от Алекса Сюя. Очень годная.
Рекомендую не только аналитикам, но и тимлидам, менеджерам, PO — всем, кто работает с проектированием систем и архитектурой.

Каждая глава — это разбор проектирования какой-то крупной системы: YouTube, поисковик, новостная лента и т.д.

Автор предлагает общий подход к решению таких задач на интервью:

1⃣ Чётко понять задачу и оценить масштаб.
2⃣ Предложить решение и согласовать с интервьюером.
3⃣ Расписать ключевые компоненты
4⃣ Подвести итоги и обсудить компромиссы.

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

Вас вряд ли попросят спроектировать целый YouTube (времени не хватит) — скорее это будет небольшой магазин, библиотека или простенький маркетплейс.

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

В общем рекомендую. Особенно если хотите выходить на новый уровень или готовитесь к собесам.

А кто ещё читал? Как вам?

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

Fuck UP №2🔥
Анонимная история от подписчицы.

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

Сегодня история — про документацию, ГОСТы и боль госпроектов 😬

💬 История

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

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

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

И пошла не просто читать ГОСТы 19 и 34 серии, а создавать внутреннюю базу знаний по этому вопросу.

ГОСТы усвоила на 5+. От бредовых хотелок отбиваться стало в разы проще) если бы изначально пошла таким путём, сроки согласования значительно бы сократились.

Сразу вспоминаю фразу из книги Джима Рона «Сезоны жизни»:
«Всегда нужно находить решение вопроса, а не делать себя частью проблемы.»

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

#FuckUP

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

У аналитика нет цели, только путь

Иногда на собеседованиях могут спросить:

«Опиши путь и этапы работы аналитика по задаче🤔»

Если ты на опыте — такое могут и не спрашивать.
Но если не можешь внятно объяснить, как задача проходит от идеи до прода и твое в ней участие,
то и к твоему “опыту” могут появиться вопросы.

Давайте пройдемся по пунктам👇

1️⃣ Идея в голове бизнеса
У бизнеса с самого начала есть какая-то тактика и он её придерживается.
Появляется задача или проект, под неё выделяют деньги, ресурсы, прописывают контрольные точки.

2️⃣ Подключается аналитик
Аналитику прилетает задача — в разной степени оформленности:
от «есть идея» до «вот письмо на 3 страницы, разбирайся».
Начинается первичный АНАЛиз.

3️⃣ Уточнения и детали
Иногда выясняется, что задача уже реализована в другом виде (бывает и такое).
Или что она технически невыполнима в текущем контексте.

Аналитик собирает встречи, уточняет детали, формулирует цели, оценивает риски, собирает вводные.
Появляется черновое описание, начинается обсуждение с командой.

4️⃣Формализация
Если всё ок — начинается полноценная проработка.
Пишется документация, заводятся задачи.
Иногда подключаются дизайнеры, архитекторы, другие команды.
Аналитик собирает всё воедино.

5️⃣ Груминг и передача в разработку
Задачи готовы — команда собирается на груминг.
Обсуждаем, декомпозируем, уточняем сложные моменты.
После оценки задачи уходят в бэклог и становятся кандидатами в спринт.

6️⃣ Сопровождение реализации
Началась разработка — появляются вопросы🙄.
Аналитик на связи: объясняет логику, синхронится со смежными системами.
Если нужно — корректирует описание по ходу.

7️⃣ Релиз
Если релиз интеграционный — аналитик может:
— подготовить таски для других команд,
— согласовать описания,
— участвовать в ПСИ,
— проверять логику после выката.

📌В зависимости от команды, стеков и масштаба проекта этапы могут отличаться.
Но общий путь примерно такой:
Идея → Анализ → Задачи → ПРОД.

А как у вас проходят задачи от идеи до реализации? Где чаще всего возникают затыки?😑

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 АНАЛитика | Подписаться

Про транзакции часто спрашивают на собесах.
Что это такое, примеры и.т.д

Читать📚

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

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


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


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

Fuck UP №1🔥

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#FuckUP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если пишете ФТ — очень годно.

Ребята выстроили единый шаблон функциональных требований: с точками входа, сценариями, архитектурой и вкладками в Confluence.

Читать📚

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

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

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

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

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

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


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

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


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

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

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

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

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

😐 Почему?

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

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

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

Вывод?

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

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

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

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


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