SA | IT | Александр Турченко

Если накопилось что сказать про работу системного аналитика, вот повод. 🫣 Что вызывает больше всего вопросов? Какие темы кажутся сложными? Чего не хватало вам, когда только начинали изучать системный анализ? Анкета на 5 минут, буду признателен за честные ответы: Ссылка тут 😄 🎁В качестве благодарности за заполнение вы получите полезное видео от меня «Как правильно составлять резюме»

Если бы меня спросили, какими навыками должен обладать человек, чтобы стать системным аналитиком, я бы назвал эти 5 пунктов.⬇️ 1⃣ Умение слушать и задавать вопросы Не принимать требование как единственно верное, а разбираться в сути проблемы. Постоянно задавать вопросы: «Почему?», «Для чего это нужно?», «Какую проблему мы решаем?». Иногда выясняется, что задачу можно упростить или она вообще не нужна. Пример: Заказчик просит «сделать уведомления по email при каждом статусе заказа». Аналитик уточняет, сколько статусов и правда важны получателю. Выясняется, что важны только 2 из 7 статусов, остальные — техническая информация, которая только спамит и не нужна пользователю. 2⃣Презентация/умения объяснять Уметь понятно доносить информацию до разных участников проекта: разработчиков, тестировщиков, стейкхолдеров. Включает согласование решений и защиту своей позиции, если предложенный вариант проще или правильнее. Пример: Стейкхолдер настаивает на добавлении сложной функции прямо перед релизом. Аналитик показывает на конкретных цифрах, сколько времени займёт доработка и тестирование, и к чему приведёт спешка. Приводит аргумент: перенос функции на следующий этап даст время сделать её качественно, не жертвуя стабильностью текущего релиза. 3⃣ Умение договариваться Часто у заказчика, разработки, менеджмента и других участников проекта разные интересы и ожидания. Аналитик должен находить компромисс и помогать команде прийти к решению, которое устроит всех и будет реализуемо. Пример: Маркетинг хочет выпустить новую функцию как можно быстрее, а разработчики говорят, что для этого потребуется месяц. Аналитик помогает найти компромисс: определить минимально необходимый функционал для первого релиза, а остальное перенести на следующий. 4⃣ Структурное мышление Умение превращать большой объем информации в понятную структуру. Выделять главное, систематизировать требования, строить схемы процессов и оформлять документацию так, чтобы она была понятна всей команде. Пример: После часовой встречи, где обсуждали сразу пять разных доработок вперемешку, аналитик раскладывает всё по пунктам, что критично сейчас, что можно отложить, как эти задачи связаны между собой, и оформляет это в понятный документ. 5⃣ Адаптивность В проектах требования и задачи могут меняться. Заказчик передумал, появились новые вводные, приоритеты сдвинулись. Аналитику важно быстро перестраиваться, учитывать изменения и актуализировать требования. Пример: Команда неделю прорабатывала требования к одной фиче. Затем бизнес меняет приоритет, в фокус попадает другая задача. Аналитику нужно быстро разобраться в новых требованиях, зафиксировать их и объяснить команде, что изменилось и почему. А какие навыки назвали бы вы?? 🤔

🤩🤩🤩🤩 Сегодня разбираем CQRS: что это за паттерн, какие у него плюсы и минусы, и когда его действительно стоит внедрять. 😊

🔥🔥🔥🔥🔥🔥 🔥 У меня на канале есть рубрика, где авторы из разных IT-каналов делятся своей экспертизой. Собрал всё в одном посте, чтобы ничего не потерялось. 🔥 Не читали? Исправляем 🔥 🔣Кластерная БД 🔣ER-диаграмма в работе СА 🔣UC vs US 🔣Файлы для подготовки к собеседованиям СА 🔣Polling vs Long polling 🔣Подходы и инструменты UX/UI прототипирования для СА 🔣Проксирование 🔣Kafka UI

Сегодня разбираем RBAC и ABAC, две популярные модели управления доступом. В карточках: 🤩что такое управление доступом 🤩что такое RBAC 🤩что такое ABAC 🤩примеры использования 🤩сравнение RBAC и ABAC А вы знакомы с этими моделями? ☺️ — да, знаком(а) 🦆 — нет, слышу впервые

🔥 Мини-задача Есть рюкзак и набор вещей для похода. Что нужно сделать: 🔣положить в рюкзак все вещи, кроме фонарика 🔣заменить бутылку воды на термос 🔣положить аптечку в рюкзак 🔣проверить, все ли нужные вещи лежат в рюкзаке 🔣достать карту из рюкзака Вопрос: какие HTTP-методы вы бы использовали для каждого действия? Пишите свои варианты в комментариях ↘️

Как вы считаете, как часто нужно менять работу? И что должно быть поводом для смены: отсутствие роста по ЗП, выгорание, отсутствие интересных задач, токсичная команда или просто прошло 1–3 года и пора двигаться дальше?

Наткнулся на сервис, где архитектуру можно не только нарисовать, но и проверить в деле. 😲 paperdraw.dev — это интерактивный браузерный симулятор и инструмент для проектирования архитектуры. Что можно делать: 🟠моделировать взаимодействие между сервисами 🟠добавлять базы данных, очереди, кеши, CDN, балансировщики и т.д 🟠смотреть, как по системе проходит трафик 🟠симулировать задержки и нагрузку 🟠ломать части системы и проверять, что будет дальше И да, теперь можно легально ломать прод. Правда, только воображаемый. 🤣 Ссылка: https://paperdraw.dev/ ⬅️

Название звучит как начало мексиканского фильма, но речь пойдет о рабочем подходе. 🧑‍🌾 3 amigos (Three Amigos) — это встреча перед стартом разработки конкретной задачи, на которой сходятся три точки зрения для обсуждения предложенного решения, выявления возможных альтернативных сценариев, а также для формирования общего понимания контекста. Такая встреча помогает до начала разработки проверить полноту требований, согласовать ожидания участников и заранее обнаружить возможные риски, ограничения или спорные моменты. 🔣Кто входит в команду «3 amigos»? 🔣Бизнес — отвечает за бизнес-контекст, цели, ценность функционала и ожидания пользователей. 🔣Разработка — оценивает решение с технической точки зрения, выявляет ограничения и предлагает варианты реализации. 🔣Тестирование — смотрит на требования с точки зрения проверяемости, тестовых сценариев, рисков и возможных edge cases. Состав встречи не обязательно ограничивается тремя ролями, всё зависит от задачи, затронутых систем и участников, которые нужны для её проработки. 🔣 Как проходит? 1. Подготовка к встрече Перед встречей важно подготовить базовый контекст по задаче: 🔣описание задачи и цели изменений; 🔣основные требования и сценарии; 🔣ограничения, зависимости и спорные моменты; 🔣вопросы, которые нужно обсудить с командой. 2. Проведение встречи На встрече участники вместе разбирают задачу: 🔣обсуждают предложенное решение; 🔣уточняют требования и ожидания; 🔣рассматривают альтернативные сценарии; 🔣выявляют риски, ограничения и неочевидные кейсы; 🔣фиксируют вопросы, которые требуют дополнительной проработки. 3. Итоги встречи По итогам встречи у команды должно быть общее понимание: 🔣что именно нужно реализовать; 🔣какие требования и сценарии согласованы; 🔣какие риски и ограничения учтены; 🔣какие вопросы остались открытыми; 🔣кто и что должен доработать перед стартом разработки. 🔣Главные преимущества 🔣Единое понимание задачи Участники заранее синхронизируются по контексту, требованиям, ограничениям и ожидаемому результату. 🔣Меньше недопонимания в разработке Спорные моменты и неочевидные сценарии обсуждаются до старта реализации, а не во время разработки или тестирования. 🔣Раннее выявление рисков Команда заранее замечает технические ограничения, пробелы в требованиях, сложные edge cases и потенциальные проблемы. 🔣Более точные требования За счёт разных точек зрения требования становятся полнее, понятнее и лучше подготовленными к реализации. 🔣Экономия времени и повышение качества решения Меньше возвратов на доработку, уточняющих вопросов и переделок, а команда может заранее выбрать более подходящий вариант реализации. Делитесь, какие подходы вы используете в команде ⬇️⬇️