test Flashcards
(32 cards)
Как ты начал работать системным аналитиком?
Вообще всё началось ещё в театре, где я работал. Мы как-то начали автоматизировать работу через AmoCRM — заявки, расписания, финансы. И вот пока я этим занимался, понял, что мне реально нравится разбираться, где узкое место, как упростить работу и что можно улучшить с точки зрения логики. Начал изучать системный анализ, втянулся — и стало понятно, что это именно то, что мне по душе.
Почему выбрал именно системный анализ? Чем он понравился?
Потому что здесь сочетается логика, структура и работа с людьми. Мне всегда нравилось копаться в процессах, искать слабые места, улучшать. А в системном анализе как раз всё это есть: ты и с бизнесом общаешься, и с разработкой, и думаешь, как всё связать. Это очень живое и интересное направление.
Где получал знания и навыки по системному анализу?
Я прошёл обучение на GeekBrains по аналитике данных, брал курсы по SQL на LearnDB, смотрел видео на YouTube, использовал ChatGPT и другие ИИ для практики. Когда стал разбираться глубже, начал читать методологии, книги, разбирать кейсы.
Где ты работал системным аналитиком?
В театральной студии «Постскриптум», в которой я раньше был замдиректора. Мы как раз запустили внутренний IT-проект, где я выступал системным аналитиком. Всё начиналось с инициативы, а потом уже выделили команду, разработчиков и начали делать полноценную систему StageManager.
Кто работал с тобой в команде? Как взаимодействовал с командой и как распределялись задачи?
Команда была небольшая, но слаженная: тимлид, ПМ, бэкендер, фронтендер и я как аналитик. На грумингах я презентовал требования и схемы, мы вместе обсуждали задачи. ПМ декомпозировал их и распределял. С разработчиками часто общался напрямую — объяснял логику, интерфейсы, детали API. Делали стендапы каждый день, чтобы держать всех в курсе.
Что ты делал на работе? Конкретно, по пунктам
— Собирал и документировал требования
— Описывал бизнес-процессы AS-IS и TO-BE
— Проектировал интерфейсы (Figma, Balsamiq)
— Делал диаграммы BPMN, UML
— Описывал API, составлял спецификации
— Создавал задачи в Jira и сопровождал их
— Проверял результат, участвовал в демонстрациях заказчику
Что был за проект? Какое ПО разрабатывали?
Мы делали внутреннее веб-приложение StageManager — расширение AmoCRM. Это была система для управления клиентами, расписанием, педагогами, оплатами и аналитикой. Под театр — специфики было много, поэтому готовое решение не подошло. Делали кастом, который в будущем можно будет масштабировать на франшизу.
Расскажи подробно про функционал ПО: что можно в нем делать и какие функции оно выполняет?
Основные функции:
— Автоматическая обработка заявок из CRM
— Автонапоминания об оплате через SMS, Telegram, WhatsApp
— Гибкое расписание занятий
— Отчёты по педагогам, аналитика retention
— Дашборды по посещаемости, оплатам, вовлечённости
— Управление группами, договорами и платежами
. Из чего состояла архитектура и как взаимодействовали компоненты?
Клиент-серверная архитектура. Основа — монолит на Django, фронт на React. Отдельно выносили микросервисы: уведомления, аналитика, платежи. Между собой — REST API и RabbitMQ для очередей. Вся интеграция — по JSON. Данные шли от фронта в бэк, оттуда — в микросервисы и обратно. Надёжно, гибко и масштабируемо.
Какие ещё виды архитектуры тебе знакомы?
Монолитная, микросервисная, событийно-ориентированная (Event-driven), клиент-серверная, трёхзвенная (3-tier), серверless. На практике сталкивался в основном с клиент-серверной и микросервисной, но по теории знаю и другие подходы.
В чем отличие микросервисной архитектуры и монолитной? Что лучше и почему?
Монолит — всё в одном. Просто разрабатывать сначала, но сложно масштабировать. Микросервисы — каждый компонент отдельно. Можно обновлять частями, проще масштабировать. Лучше — зависит от задачи. Мы начали с монолита, но выносили микросервисы по мере роста нагрузки.
Что такое API?
API — это интерфейс для взаимодействия между системами. По сути, набор правил, по которым одна программа может обращаться к другой. Мы использовали REST API — через него фронт и микросервисы общались с бэком, плюс были внешние API (AmoCRM, ЮKassa и др.).
- Какие ещё есть способы интеграции?
Кроме REST API:
— SOAP (XML, используется в более старых системах)
— Webhooks (событийная модель)
— GraphQL (гибкий запрос нужных данных)
— Очереди (RabbitMQ, Kafka)
— Прямой доступ к БД (редко, но бывает)
Что такое User Story? А Use Case? Примеры
User Story — сценарий от лица пользователя: «Как менеджер, я хочу получать уведомления, чтобы не забывать про клиента».
Use Case — более детальное описание: шаги, альтернативы. Например, «Регистрация клиента»: форма > CRM > уведомление менеджеру.
Что такое UML? Какие UML-диаграммы знаешь? Какие составлял, по каким процессам?
UML — универсальный язык моделирования. Я использовал:
— Диаграммы прецедентов (Use Case)
— Диаграммы последовательности
— Диаграммы состояний
— Диаграммы классов
Например, Use Case — для расписания, последовательности — для отправки уведомлений, классов — для базы данных.
Для каких процессов составлял схему бизнес-процесса в BPMN?
Описывал процессы регистрации клиента, оплаты занятий, составления расписания. Использовал элементы: участники, задачи, шлюзы, события. Строил схемы AS IS и TO BE. Это помогало команде и заказчику видеть, что меняется и зачем.
Чем отличается схема бизнес-процесса BPMN от диаграммы последовательности UML?
BPMN — это про бизнес-процессы: кто что делает, в каком порядке, какие роли участвуют. UML-последовательности — это техническое взаимодействие между объектами. BPMN — выше по уровню абстракции, UML — ближе к реализации.
Какая была база данных? Что там хранилось?
PostgreSQL — реляционная. Там были таблицы пользователей, заявок, платежей, групп, посещаемости, расписания. Также отдельные базы для микросервисов. Хранили личные данные, статусы заявок, финансы, роли и т.д.
Чем реляционная база данных отличается от нереляционной?
Реляционная — таблицы, связи (например, PostgreSQL, MySQL). Хорошо для чёткой структуры. Нереляционная — JSON-документы, графы (MongoDB и др.) — гибче, но хуже для сложных связей. Мы использовали реляционную из-за логики и надёжности.
Что такое нормализация?
Это процесс структурирования данных так, чтобы убрать дубли, обеспечить целостность и упростить сопровождение. Есть нормальные формы (1НФ, 2НФ, 3НФ и т.д.). Например, вынос связанной информации в отдельные таблицы (учитель — отдельно, курсы — отдельно).
- Зачем использовал SQL?
Для анализа данных, отчётов, проверки связей в таблицах. Примеры: подсчёт студентов на преподавателя, анализ платежей, выгрузка по группам. Использовал SELECT, JOIN, WHERE, агрегаты и оконные функции.
Чем JOIN-ы отличаются?
JOIN — объединяет таблицы. Бывают:
— INNER: только пересечения
— LEFT: всё из левой, + что нашлось справа
— RIGHT: наоборот
— FULL: всё отовсюду. Зависит от задачи.
. Зачем использовал JSON/XML?
JSON — основной формат обмена. Использовали в API, при отправке данных между фронтом, бэком и микросервисами. XML не применяли — он устаревший и громоздкий. JSON легче читается и лучше поддерживается на фронте.
Расскажи про одну-две интеграции
Интеграция с Telegram API: по триггеру система отправляла сообщение о занятии. JSON-запрос включал chat_id и текст. Отправка шла через POST.
Интеграция с ЮKassa: по REST API создавался платёж. Возвращался статус, ID, дата. Мы сохраняли это в таблицу Payments.
