Системный Аналитик

Проходить собеседования — это навык. Если в 2024-м вы хотите — меньше волноваться на собесах, — эффективнее отвечать на вопросы и грамотно задавать их, читайте канал про собеседования в IT, где собран опыт и кандидата, и работодателя. —————— 🔹Булат ходит на собесы из азарта и интереса и пишет, что да как: какие были этапы, какие задавали вопросы. Лонгрид раз — про интервью к поставщику и разработчику технологий для бирж Два — про интервью в финтех Три — в Medtech 🔹Булат сам нанимает сотрудников и рассказывает, почему кандидату отказали. Лонгрид раз — про закрытые ответы Два — про улыбку и болтовню Три — про кандидата, который спорил ————— ✅Подписывайтесь, чтобы быть готовыми к собеседованию, а в случае отказа — сохранять здравую самооценку. https://t.me/tryoutonadancefloor 👆

✍️ Постановка задачи на разработку: этапы, отличие от ТЗ Понятия постановки задачи на разработку и техническое задание часто путают меду собой, но это разные вещи. 🔸Техническое задание — это документ, который определяет, что должно быть реализовано и как это должно работать (функциональные требования) и насколько это должно быть быстро/безопасно/отказоустойчиво/дружелюбно/отслеживаемо (нефункциональные требования). ТЗ возникает как результат обработки бизнес-требований, и их перевода на системный уровень. 🔹Постановка задачи на разработку — описание конкретных задач, которые должны быть выполнены разработчиками для реализации ТЗ. Когда постановка задачи должна быть представлена как отдельный артефакт Постановка задачи на разработку нужна всегда, но не всегда должна быть оформлена как отдельный артефакт. Иногда достаточно ТЗ, если оно содержит нужные детали для разработки. Случаи, когда необходимо описать постановку задачи отдельно: 💩Когда задача на доработку, а не на разработку с нуля. Есть одна большая спецификация на кусок функционала, и в это ТЗ дописываются требования по доработкам. ПЗ помогает выделить и описать конкретные изменения, которые нужно внести в существующую систему. 💩Когда задача составная и требует декомпозиции. В постановке можно разбить задачу на более простые подзадачи, тогда как ТЗ описывает реализацию функционала в целом без привязки на то, в рамках каких конкретных задач на разработку это будет реализовываться, сколько будет таких задач, кто их будет делать, какова оценка трудозатрат и т.д. Постановка задачи на разработку может содержать следующие пункты: 💩Введение, цель: Необходимо описать бизнес-контекст, почему задача возникла. Например, компания столкнулась с проблемой неэффективного учета заказов и хочет улучшить этот процесс. 💩Описание решения: способ и границы реализации (ТЗ, Use Case, статусные модели, макеты UX/UI, описание интеграций) 💩Ключевые источники информации: спецификации API, HLD, глоссарий, стандарты и т.д. 💩Диаграммы: например, UML sequence, activity, бизнес-процесс в BPMN, схемы данных 💩Заинтересованные стороны: перечень людей, влияющие на принятие решений 💩 Критерии приемки: критерии, по которым будет оцениваться успешное завершение проекта. 💩НФТ и ограничения решения: производительность, масштабируемость, доступность и т.д. 🆚 Отличие постановки задачи на разработку (ПЗ) от ТЗ 💩(утрируя) ТЗ — это текст в Confluence, ПЗ — описание в Jira 💩ТЗ описывает требования к функциональности в целом, а постановка направлена на реализацию функционала в рамках конкретных задач 💩Одно ТЗ может быть декомпозировано на несколько задач, при этом каждая может иметь свою постановку на разработку 💩Иногда в ТЗ уже содержится и постановка задачи, но лучше понятия не смешивать и всё равно прописывать постановку задачи отдельно ⭐️ Подборки материалов по этой и другим темам доступны в закрытом канале #требования

Как понять, что хочет заказчик? Элементарно, Ватсон! Шерлок в IT - канал про системный анализ, где Юля - аналитик из финтеха, проявляет чудеса дедукции и пишет просто о сложном. Читай канал 5 минут ежедневно и прокачивай hard и soft скиллы! Подписывайся и становись лучше с каждым днём 👉🏻 @ItSherlock

🔵 5 книг по изучению SQL 💾 Сохраняйте к себе и делитесь с коллегами 1. Изучаем SQL. — А. Болье 2. SQL для чайников — Аллен Тейлор 3. SQL. Сборник рецептов — М. Энтони, де Грааф Роберт 4. SQL для анализа данных — К. Танимура 5. PostgreSQL. Основы языка SQL — Е.П. Моргунов ✔️ А ещё делимся ссылками на подборки материалов по БД: 1. Большая подборка полезных материалов по основам баз данных 2. Памятка по SQL 3. Список бесплатных онлайн-курсов по базам данных и SQL 4. Основные понятия баз данных. Главное 5. Типы связей в БД. Нормализация 6. SQL vs NoSQL: отличие реляционных и нереляционных БД 7. Виды нереляционных БД. Какие бывают NoSQL базы данных 8. Шпаргалка по выбору правильной СУБД #бд #sql

Системный аналитик в команду Яндекс MBA Локация: Москва, Питер Формат: офис, гибрид Команда MBA (Management Business Application) разрабатывает и сопровождает IТ-решения для управления цифровыми сервисами и ресурсами всей компании  (управление финансами, персоналом, закупками, логистикой, складом, взаимоотношениями с заказчиками, казначейскими операциями, отчетностью). Вам предстоит: - собирать и анализировать бизнес-требования, преобразовывать их в ТЗ для разработки - координировать процесс разработки, тестирования, приёмки и ввода в эксплуатацию - формировать документацию для сопровождения доработок Мы ждем, что вы: - в системном анализе 3+ года - уверенно владеете SQL, работали с реляционными СУБД и знаете основы проектирования БД - моделировали бизнес-процессы (BPMN, UML), занимались описанием интеграций - работали с крупными ERP-решениями, такими как OEBS, SAP или 1С Откликнуться

✔️ Критерии приемки (Acceptance Criteria): краткий обзор Критерии приемки (Acceptance Criteria, AC) — это набор условий, которым должна удовлетворять пользовательская история (User Story), чтобы её считали выполненной. Критерии приёмки уникальны для каждой User Story (US) и являются основой для тестирования. ❓Для чего нужны 💩позволяют понять, выполнена ли US и работает ли, как ожидалось 💩определяют негативные сценарии и объясняют, как система должна реагировать на них 💩создают у клиента и команды разработки единое видение как должна быть реализована функциональность 💩помогают выявить проблемы на ранних этапах разработки Критерии приемки должны: ➖быть определены до того, как начнется разработка US ➖иметь четкие формулировки для проверки их выполнения: «принято» или «не принято». AC должны описывать конкретное поведение или результат, который ожидается от функции ➖иметь четкие формулировки для проверки их выполнения. ➖соответствовать ценности и цели пользователя и продукта ✔️ Подходы к составлению критериев приемки 1. Сценарно-ориентированный подход (Scenario-based acceptance criteria) 2. Свод правил или чек-лист (Rule-based acceptance criteria) 1️⃣ Сценарно-ориентированный подход Соответствует формату Дано/Когда/Тогда (Given/When/Then): 💩Given (Дано): чёткое описание контекста, состояние системы в начальный момент времени 💩When (Когда): действие, которое выполняет пользователь или система 💩Then (Тогда): ожидаемый результат Также можно дополнительно использовать: 💩Сценарий — название поведения, которое будет описано 💩И / ИЛИ — для продолжения любого из трех предыдущих утверждений Пример US: Как пользователь, я хочу иметь возможность восстановить пароль от своей учетной записи, чтобы если я забыл пароль, мог получить доступ к своей учетной записи. 💩Сценарий: Забыт пароль 💩Дано: пользователь переходит на страницу входа 💩Когда: пользователь выбирает опцию <забыл пароль> 💩И: вводит действительный адрес эл. почты для получения ссылки на восстановление пароля 💩Тогда: Система отправляет ссылку на указанный адрес электронной почты 2️⃣ Свод правил (чек-листы) Это простой список правил о том, как всё должно работать после реализации требования. Например: 1. Все кнопки должны иметь скругленные углы радиуса 10 2. Пользователь может выбирать способ авторизации с паролем или через получение OTP 3. В случае неправильного ввода пароля два раза подряд система отображает пользователю капчу AC 🆚 DoR 🆚 DoD 💩DoR (Definition of Ready) — это набор условий, которые должны быть выполнены, прежде чем командой может взять US в работу. Например, задача описана и декомпозирована, подготовлены CJ, HLD, прикреплены макеты дизайна, прописаны AC и т.д. 💩DoD (Definition of Done) — набор условий, которые должны быть выполнены, чтобы пользовательская история считалась завершенной. Например, реализация соответствует ТЗ, выполнены AC, пройдены все тест-кейсы, составлена документация, одобрения получены и т.д Главная разница 💩DoD & DoR одинаковые для всех US 💩AC уникальны для каждой US ⚒ Использование Gherkin Gherkin — сценарно-ориентированный язык, который легко читается бизнесом и используется для описания функциональности программного обеспечения. Пример (картинка) Применяется для: ➖ Документирования пользовательских сценариев ➖ Написания автоматизированных тестов ⭐️ Подборки материалов по этой и другим темам доступны в закрытом канале #требования

«Я в режиме реального времени поясняла структуру запросов / ответов в Postman и разбирала документацию в Swagger», — пишет аналитик, который прошел наш курс, а потом два технических собеседования в международные компании. Приятно, конечно ❤️ Если в 2024 году вы хотите: — научиться выбирать стиль интеграции под вашу задачу; — начать проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и других, + брокеры сообщений); — узнать как правильно собирать требования и моделировать в UML; — подготовиться к собеседованию, решив более 100 заданий; — запустить свой API на Python. Значит наш курс для вас! 🚀 Начните с открытых бесплатных уроков — переходите в бот курса и жмите «Старт» 👇 @studyit_help_bot 🚀 Скидка на курс от канала — 1 000₽ на Stepik по промокоду SYSSA до конца мая.

Получите до 76 000 руб. на обучение в сфере ИИ Выберите подходящее обучение от Университета Иннополис с господдержкой. Профессия «Архитектор в области ИИ» 👉 Забронировать место Аналитика данных и машинное обучение 👉 Забронировать место Профессия «Руководитель проектов в области ИИ» 👉 Забронировать место + Удостоверение о повышении квалификации erid: LjN8KRYZj

Матрица компетенций системного аналитика Сделали единую карту компетенций системного аналитика на основе данных из открытых и закрытых источников. Ссылки на матрицу: 💩Mind Map 💩Табличная версия (можно оставлять комментарии) Все навыки разбиты на несколько групп компетенций: 1️⃣Инженерия требований 2️⃣Системное проектирование 3️⃣Интеграция систем и сервисов 4️⃣Моделирование бизнеса и домена 5️⃣Процесс разработки 6️⃣Общие компетенции 7️⃣Смежные навыки 8️⃣Soft Skills Это не финальная версия, поэтому призываем всех активно критиковать и предлагать изменения (желательно в гугл-доке). Давайте совместными усилиями сделаем понятный перечень навыков, чтобы каждый аналитик знал, что ему нужно развивать. P.S. Хотя и есть профстандарт системного аналитика, от компании к компании ожидания от СА сильно разнятся. Наша матрица — попытка привести ожидания от навыков системного аналитика к одному знаменателю. Ссылки на источники 1. Матрица компетенций SE 2. Профессиональные навыки аналитика от Сообщества аналитиков СПБ 3. Что нужно знать системному аналитику уровня Middle и Senior: план развития Hard Skills 4. Матрица компетенций аналитика для самурая в запасе 5. Кто такой системный аналитик? Профессия, требования, зарплата — Денис Бесков 6. Программа курса Системный аналитик. Advanced 7. Программа курса Системный аналитик. Team Lead 8. Матрицы IT-компетенций (и около) 9. Статистика требований к аналитику на HH

🖥 Модель TCP/IP: Краткий обзор и сравнение с OSI Модель TCP/IP — это стек протоколов, которые задают правила передачи данных по сети (локальной(LAN), корпоративной, Интернет и пр.). Основой являются протоколы TCP и IP. На них построен весь Интернет: 🕹 TCP (Transmission Control Protocol)—управляет отправкой данных и следит, чтобы они были гарантированно приняты получателем. 🔗 IP (Internet Protocol) —отвечает за адресацию: выделяет IP-адреса устройств, связывает устройства друг с другом, нарезает данные на пакеты для удобной отправки, строит маршруты доставки пакетов 📶 Уровни модели TCP/IP 4️⃣ Прикладной (Application) Протоколы: HTTP, SMTP (Simple Mail Transfer Protocol). Здесь находятся приложения, предоставляющие сетевые службы. Протоколы обеспечивают взаимодействие между программами на удаленных компьютерах. 3️⃣ Транспортный (Transport) Протоколы: TCP, UDP (User Datagram Protocol) Отвечает за надежную передачу данных между устройствами. TCP обеспечивает управление потоком и надежность, UDP — более быструю, но менее надежную передачу. 2️⃣ Сетевой (Internet) Протоколы: IP, ICMP (Internet Control Message Protocol). Управляет передачей данных между узлами в сети. IP обеспечивает маршрутизацию, ICMP используется для диагностики и сообщений об ошибках. 1️⃣ Канальный (Link) Протоколы: Ethernet, Wi-Fi. Тут происходит организация физического соединения между устройствами в пределах одной сети. Эти протоколы работают с физическими адресами (MAC-адресами) устройств. ⚙️ Процесс работы TCP/IP ▫️Перед отправкой данные разбиваются на пакеты ▫️Каждый пакет получает IP-адрес (уникальный идентификатор устройства в сети), который указывает на конечный пункт назначения. ▫️На транспортном уровне TCP следит за тем, чтобы все пакеты дошли без потерь и в правильном порядке. Также управляет потоком данных, предотвращая перегрузку сети. ▫️На сетевом уровне (IP), каждый пакет получает информацию о том, какие узлы (маршруты) нужно использовать для достижения конечного пункта. ▫️На канальном уровне (например, Ethernet), каждый пакет получает физический адрес (MAC-адрес) для доставки пакета на устройство в пределах сети. ▫️Пакеты отправляются в сеть, проходят через различные маршрутизаторы и коммутаторы, следуя указанным путям. ▫️По достижению конечного устройства, они собираются в правильном порядке и восстанавливают данные. 🛜Применение TCP/IP 🔹Интернет: TCP/IP - фундаментальный стек протоколов. Каждое устройство, подключенное к интернету использует IP-адрес и коммуницирует посредством TCP или UDP. 🔹Локальные сети: Часто используется в локальных сетях офисов и домов. Это обеспечивает согласованное взаимодействие между компьютерами. 🔹Коммуникация между приложениями: Протоколы прикладного уровня, такие как HTTP для веб-сервисов, FTP - передачи файлов и SMTP - почты, работают поверх TCP/IP. 🛠Модель TCP/IP vs OSI Обе модели описывают архитектуру сетевых взаимосвязей. OSI имеет более подробное разделение сетевых функций по уровням, см картинку ▪️Применение OSI: Используется в обучении и теории, но редко применяется на практике. TCP/IP: Широко применяется в реальных сетях, включая интернет. ▪️Управление потоком данных: OSI: Уровень сеансов и транспортный уровень могут управлять потоком данных. TCP/IP: Управление потоком осуществляется только на транспортном уровне (TCP). ▪️Сетевые протоколы: OSI: Протоколы, определенные на каждом уровне, не всегда вписываются в четкую структуру. Например, отдельные уровни для сеансов, представления и прикладного уровня. TCP/IP: Протоколы тесно связаны с каждым уровнем, что делает их более интегрированными. ⭐️ Подборки материалов по этой и другим темам доступны в закрытом канале #сети