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

Когда-то я уже писал статью на Хабре: "Как эффективно решать проблемы в 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 АНАЛитика | Подписаться

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

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

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

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

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

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