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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

💬 История

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

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

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

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

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

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

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

#FuckUP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

Пропустил июньские итоги — так что тут сразу два месяца разом.
Летом активность немного упала: больше хочется гулять, чем сидеть за ноутом.
Надеюсь, вы тоже не заперты дома и ловите свои тёплые дни ☀️

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

Посты
Кто победит: Перфекционино Бобрино или правило Парето?
Аналитик и риски на проекте
Fuck UP №1
Что такое DTO и зачем это знать аналитику?
Флоу и этапы работы аналитика над задачами
Fuck UP №2
Про книгу System Design. Подготовка к сложному интервью
Из аудитора в аналитика
Ты новый аналитик на проекте — что делать?

Интересные статьи
Годный шаблон функциональных требований
Про транзакции простыми словами
Еще парочка слов про шаблоны
Один день с архитектором

Мемы
Экран перевернулся
Авторизация
Оффер

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

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

Меня позвали поразгонять про требования и работу аналитика в целом.
Поговорим, как делать хорошо — и не делать плохо💻

Если вечер 6 августа у вас свободен — заглядывайте послушать.
А если есть вопросы — вкидывайте в комменты, обсудим в эфире.

🗓 6 августа в 19:00
Трансляция и подробности тут⬅️

Трансляция будет тут⬅️
Если в 19:00 не заняты, приходите послушать.

p.s Запись будет

Первый раз участвовал в таком формате 🎤

Поговорили про работу с требованиями, ИИ и разные фреймворки, которые помогают в работе.
По-моему, вышло вполне годно и информативно.

Кто был на эфире — как вам?
Ниже аудио версия.

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

Слышь согласуй

Согласования — вечная боль.
Отправил письмо заказчику, чтобы что-то согласовать. Проходят дни, недели, месяцы, отпуска.

И потом начинается:
— «Тимлид спрашивает статус по той задаче, а ты уже вообще "забыл", потому что тебе не ответили».
— «Пинаешь заказчика, он говорит: я же отвечал… (а он не отвечал 😐)»
— «Безумно ищешь ТО САМОЕ письмо, ведь ты помнишь, что отправлял его…»

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

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

1. Дата запроса — когда отправили на согласование.

2. Что согласуем — короткое описание, что хотим получить.

3. Инициатор — кто отправил на согласование (важно, если аналитиков несколько).

4. Согласующий — ФИО и роль человека, который должен дать ответ.

5. Ссылка на задачу или эпик — для контекста.

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

7. Статус — “Ждем согласования”, “Согласовано”, “Просрочено”, “Отклонено”.

8. Дата согласования — фиксируем факт получения ответа.

9. Комментарий — любые детали: «в отпуске до 15 числа», «ждём макет от дизайнера».

📌 Почему это удобно:
1️⃣ Видно где застряли — можно не писать в общий чат для поиска крайнего и найти, где проблема.
2️⃣ Есть история — мое любимое, через долгое время не надо осматривать 100500 писем на тему НУ ТАМ ЧЕТО СОГЛАСОВАЛИ НАМ ТОГДА.
3️⃣ Легче управлять рисками — если у нас близится релиз в ПРОД, сразу видишь, что просрочено и где может сорваться срок.

Главное — не забивать на её обновление, иначе это будет еще одна бесполезная страничка.

А вы как отслеживаете согласования? Или потом караулите человека у подъезда?

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