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

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

Для аналитика это, в целом, плюс.
Но когда в работе 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 АНАЛитика | Подписаться

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

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

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

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

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

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