Профессия Системный и Бизнес-аналитик: от инженера ПТО до IT-специалиста

1. Основы разработки ПО: переход от строительных процессов к SDLC и методологиям Agile

Основы разработки ПО: переход от строительных процессов к SDLC и методологиям Agile

Приветствую, коллега! Если вы читаете этот курс, значит, вы решили сменить каску и чертежи в AutoCAD на ноутбук и диаграммы в Jira. Как инженер ПТО (производственно-технического отдела), вы уже обладаете системным мышлением, умеете работать с документацией и понимаете, что такое сроки и бюджет. Это отличный фундамент.

В строительстве цена ошибки колоссальна: если фундамент залит неправильно, здание может рухнуть. В IT «материал» — это код, он пластичен. Однако без правильной организации процесса (менеджмента) даже самый лучший код превратится в долгострой, который никому не нужен.

Сегодня мы разберем, как создается программное обеспечение, чем это похоже на стройку, и углубимся в тему API, которую вы сейчас изучаете.

Жизненный цикл разработки ПО (SDLC)

В строительстве есть четкие этапы: Изыскания Проектирование (Стадия П, Стадия Р) СМР (Строительно-монтажные работы) Сдача в эксплуатацию. В IT это называется SDLC (Software Development Life Cycle) — жизненный цикл разработки ПО.

Давайте проведем параллели:

!Сравнение этапов строительства здания и разработки программного обеспечения

Как видите, структура процессов очень похожа. Ваша задача как аналитика — быть связующим звеном между «Заказчиком» (бизнесом) и «Прорабами/Рабочими» (разработчиками).

Методологии: Waterfall vs Agile

В ПТО вы привыкли работать по Waterfall (Каскадная модель). Сначала полностью утверждается проект, потом смета, потом начинается стройка. Нельзя начать класть крышу, пока не готов фундамент. Нельзя внезапно решить добавить еще 5 этажей, когда здание уже построено.

Плюсы Waterfall: * Четкие сроки и бюджет. * Понятная документация.

Минусы Waterfall: * Долгое время до получения результата. * Высокая цена ошибки на ранних стадиях.

В IT часто используется Agile (Гибкая методология). Представьте, что вы строите не дом, а модульный городок. Заказчик хочет жить там уже через 2 недели. Вы строите сначала одну бытовку (MVP — минимально жизнеспособный продукт), заселяете его. Потом пристраиваете кухню. Потом меняете бытовку на коттедж.

Основные принципы Agile:

Люди и взаимодействие важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации (в ПТО это звучит как ересь, но в IT это норма).

Сотрудничество с заказчиком важнее согласования условий контракта.

Готовность к изменениям важнее следования первоначальному плану.

В рамках Agile самой популярной методикой является Scrum. Работа делится на короткие отрезки — Спринты (обычно 2 недели). В конце каждого спринта команда выдает готовый кусочек продукта.

Для оценки трудозатрат в Agile часто используют не человеко-часы, а относительные единицы (Story Points). Это похоже на то, как в сметах используют коэффициенты сложности.

Формула расчета производительности команды (Velocity) выглядит так:

Где — средняя скорость команды (Velocity), — сумма Story Points, закрытых в -ом спринте, а — количество прошедших спринтов. Эта метрика помогает прогнозировать, сколько работы команда сможет выполнить в будущем.

API: Ваши «Инженерные сети» в IT

Вы упомянули, что сейчас проходите тему API. Для инженера ПТО это одна из самых понятных тем, если подобрать правильную аналогию.

API (Application Programming Interface) — это программный интерфейс приложения. Это набор правил, по которым одна программа общается с другой.

Аналогия с инженерными сетями

Представьте, что вы строите жилой комплекс. Чтобы в доме была вода, вам нужно подключиться к городскому водоканалу. * Вы не знаете, как устроены насосы на станции водоканала (вам это и не нужно). * Вам нужно Техническое Условие (ТУ): диаметр трубы, давление, точка врезки.

В IT: * Ваше приложение (Дом) хочет получить данные о погоде (Воду). * Сервис погоды (Водоканал) предоставляет API (Точку врезки). * Документация API (ТУ) описывает, как именно нужно запросить данные.

!Визуальная метафора работы API как инженерного подключения

Как это работает технически: Клиент-Серверная архитектура

Взаимодействие через API обычно происходит по протоколу HTTP (как мы открываем сайты). Это всегда диалог:

Request (Запрос): Клиент (например, мобильное приложение) просит данные.

Response (Ответ): Сервер (база данных) отдает данные или ошибку.

Представьте, что вы отправляете форму КС-2 (Акт выполненных работ) заказчику на подпись.

* Метод (Method): Что вы хотите сделать? * GET — Получить данные (Запросить статус подписания КС-2). * POST — Создать данные (Отправить новую КС-2). * PUT / PATCH — Обновить данные (Внести правки в КС-2). * DELETE — Удалить данные (Аннулировать акт).

* Код ответа (Status Code): Реакция заказчика. * 200 OK — Все хорошо, акт подписан. * 400 Bad Request — Ошибка в документе (неверно заполнена шапка). * 401 Unauthorized — Вы не тот, за кого себя выдаете (нет пропуска на объект). * 404 Not Found — Документ не найден (потеряли папку). * 500 Internal Server Error — Проблемы на стороне заказчика (у них сломался принтер).

JSON: Формат передачи данных

В строительстве мы обмениваемся данными через Excel или сметные программы. В веб-разработке стандартом является JSON (JavaScript Object Notation). Это просто текстовый формат, понятный и человеку, и машине.

Пример ответа API (информация о сотруднике):

Как аналитик, вы будете проектировать такие контракты. Вы будете писать в документации: «Фронтенд должен отправить на бэкенд id сотрудника, а бэкенд должен вернуть его position».

Заключение

Переход из инженера ПТО в системные аналитики — это эволюция, а не революция. Вы меняете инструменты (AutoCAD на Draw.io, Гранд-Смету на Jira), но суть остается прежней: создание сложного продукта по определенным правилам в условиях ограничений.

API — это просто способ коммуникации между системами, как трубы и провода соединяют части здания. SDLC — это ваш график производства работ. Agile — это способ строить быстрее и гибче.

В следующих статьях мы углубимся в написание требований и работу с базами данных.

2. Бизнес-анализ: выявление требований, моделирование процессов в BPMN и написание ТЗ

Бизнес-анализ: выявление требований, моделирование процессов в BPMN и написание ТЗ

Приветствую, коллега! В прошлой статье мы разобрали, как стройка похожа на разработку ПО, и узнали, что такое API. Теперь пришло время погрузиться в самую суть работы аналитика — работу с требованиями.

В вашей практике инженера ПТО это сравнимо с этапом сбора Исходно-разрешительной документации (ИРД) и получением Задания на проектирование. Если заказчик говорит: «Хочу построить здание», вы не бежите сразу заливать бетон. Вы спрашиваете: «Какое назначение? Какая этажность? Какие грунты? Какой бюджет?». В IT всё точно так же.

Сегодня мы научимся превращать абстрактные «хотелки» заказчика в четкие инструкции для разработчиков, используя современные нотации и стандарты.

Пирамида требований: от «Зачем» до «Как»

В строительстве есть иерархия целей: Инвестор хочет прибыль ГИП (Главный инженер проекта) придумывает конструктив Прораб реализует узлы. В IT требования делятся на три уровня:

Бизнес-требования (Business Requirements)

Это уровень Инвестора. Зачем нам этот проект? Какую проблему бизнеса мы решаем? Пример:* «Сократить время согласования актов КС-2 на 30%».

Пользовательские требования (User Requirements)

Это уровень Начальника участка. Что конкретно пользователь будет делать в системе? Пример:* «Инженер ПТО должен иметь возможность загрузить скан акта и отправить уведомление технадзору».

Функциональные требования (Functional Requirements)

Это уровень Рабочего/Чертежа. Как именно система должна отреагировать на действия? Пример:* «При нажатии кнопки 'Отправить', система проверяет заполнение обязательных полей и меняет статус документа на 'На согласовании'».

Отдельно стоят Нефункциональные требования (Non-functional Requirements). Это ваши СНиПы и ГОСТы: надежность, скорость, безопасность. Например, «Система должна выдерживать 1000 одновременных пользователей» (аналог несущей способности).

Выявление требований: Интервью и Воркшопы

Выявление (Elicitation) — это не просто запись под диктовку. Заказчик часто сам не знает, чего хочет, или предлагает решение вместо описания проблемы (как если бы заказчик просил «поставить здесь колонну», хотя на самом деле ему просто нужно опереть перекрытие).

Основные техники:

* Интервью. Личная беседа с заинтересованным лицом (стейкхолдером). * Анализ документов. Изучение существующих регламентов, Excel-таблиц, старых инструкций. * Наблюдение. Вы садитесь рядом с бухгалтером и смотрите, как он сейчас проводит платежи.

Приоритизация требований

Ресурсы разработки всегда ограничены. Вы не можете построить всё и сразу. Для оценки приоритетности задач часто используют скоринговые модели. Одна из популярных — RICE.

Формула расчета приоритета задачи:

Где: * — итоговый балл приоритета (чем выше, тем важнее задача). * (Reach) — охват: скольких пользователей это затронет за определенный период. * (Impact) — влияние: насколько сильно это улучшит целевой показатель (3 — массово, 0.25 — минимально). * (Confidence) — уверенность: насколько мы уверены в своих оценках (в процентах, например, 100% или 80%). * (Effort) — трудозатраты: сколько времени займет реализация (обычно в человеко-месяцах или неделях).

Эта формула помогает аналитику обосновать перед бизнесом, почему мы сначала делаем «Авторизацию», а не «Красивые графики».

Моделирование процессов: BPMN 2.0

Текст воспринимается хуже, чем схема. В строительстве язык общения — это чертежи. В бизнес-анализе стандартом де-факто является нотация BPMN (Business Process Model and Notation).

Представьте, что это Технологическая карта процесса. Она показывает, кто, что и в какой последовательности делает.

Основные элементы BPMN:

Пулы и дорожки (Pools & Lanes). Горизонтальные полосы, обозначающие участников процесса (например, «Инициатор», «Руководитель», «Система»).

События (Events). Кружки. То, что происходит мгновенно.

* Тонкий круг — Начало процесса (Старт). * Жирный круг — Конец процесса.

Действия (Tasks). Прямоугольники со скругленными углами. Работа, которую нужно выполнить (например, «Проверить документ»).

Шлюзы (Gateways). Ромбы. Точки принятия решений.

* Шлюз «ИЛИ» (с крестиком внутри) — процесс пойдет только по одной ветке (как стрелка на железной дороге).

!Пример диаграммы BPMN для процесса согласования документа

Ваша задача как аналитика — нарисовать процесс «AS IS» (как есть сейчас, с хаосом и бумажками) и спроектировать «TO BE» (как будет в новой системе, оптимизированно).

Написание ТЗ и постановка задач

Результат работы аналитика — это артефакты. Самый главный из них — Спецификация требований (SRS) или, по-нашему, Техническое Задание (ТЗ).

Хорошее требование должно соответствовать критериям качества. В IT часто используют мнемонику INVEST для задач в Agile, но для классических требований подойдет принцип SMART или критерии непротиворечивости и атомарности.

Структура постановки задачи разработчику (User Story)

В Agile мы редко пишем многотомные ТЗ на 500 страниц (как ПОС или ППР). Мы пишем User Stories (Пользовательские истории).

Шаблон: > Как <роль>, я хочу <действие>, чтобы <ценность>.

Пример: > Как инженер ПТО, я хочу видеть список всех отклоненных актов на главном экране, чтобы оперативно вносить в них исправления.

К каждой истории обязательно прикладываются Критерии приемки (Acceptance Criteria). Это чек-лист, по которому тестировщик (или технадзор) будет проверять работу.

Список отображается в виде таблицы.

Есть фильтр по дате.

При клике на акт открывается карточка редактирования.

Связь с базой данных (ER-диаграммы)

Когда вы описываете сущности (Акт, Договор, Подрядчик), вы фактически проектируете базу данных. В строительстве это спецификация материалов. В IT это ER-диаграмма (Entity-Relationship) — диаграмма «Сущность-Связь».

Вы должны понимать: * Один-ко-многим: У одного Договора может быть много Актов КС-2. * Многие-ко-многим: Один сотрудник может работать на многих объектах, и на одном объекте работает много сотрудников.

Заключение

Переход от инженера ПТО к аналитику — это смена объекта строительства, но не смена мышления. Вы всё так же работаете с требованиями, проектируете процессы и следите за тем, чтобы «здание» (программный продукт) соответствовало ожиданиям заказчика и нормам безопасности.

Теперь у вас есть понимание того, как выявлять требования и рисовать процессы. В следующей части курса мы углубимся в технические детали: SQL и работу с базами данных, чтобы вы могли не только рисовать схемы, но и самостоятельно «залезать под капот» системы.

3. Архитектура и интеграции: глубокое погружение в REST API, SOAP, JSON, XML и Swagger

Архитектура и интеграции: глубокое погружение в REST API, SOAP, JSON, XML и Swagger

Приветствую, коллега! Мы продолжаем наш путь от строительных чертежей к архитектуре программного обеспечения. В прошлой статье мы научились собирать требования и рисовать бизнес-процессы, словно составляли ППР (Проект производства работ). Теперь настало время поговорить о том, как разные части нашей «стройки» взаимодействуют друг с другом.

Представьте, что вы строите не одно здание, а целый микрорайон. У вас есть котельная, трансформаторная подстанция и жилые дома. Чтобы в квартирах был свет и тепло, нужно проложить сети. В IT эти сети называются интеграциями, а правила, по которым трубы стыкуются друг с другом — API.

Сегодня мы разберем два главных подхода к прокладке этих сетей (SOAP и REST), форматы данных, которые по ним текут (XML и JSON), и инструмент, который заменяет нам исполнительную документацию (Swagger).

Монолит vs Микросервисы: Генплан застройки

Прежде чем говорить о протоколах, нужно понять, что мы вообще соединяем. В архитектуре ПО есть два глобальных подхода:

Монолит (Monolith). Это как один огромный небоскреб, где всё внутри: и магазины, и жилье, и котельная в подвале, и парковка. Все системы связаны жестко. Если нужно заменить котел, приходится перекрывать воду во всем доме.

Микросервисы (Microservices). Это коттеджный поселок. Котельная — отдельное здание. Магазин — отдельное. Если котельная сломалась, магазин продолжает работать (на своих генераторах). Но зато вам нужно проложить кучу труб и проводов между этими зданиями.

Именно для микросервисов (и связи с внешним миром) нам жизненно необходимы API.

!Слева — Монолит (все в одном), справа — Микросервисы (распределенная система)

SOAP: «Государственный стандарт» и спецсвязь

SOAP (Simple Object Access Protocol) — это «старая школа». Если проводить аналогию с ПТО, то SOAP — это официальная переписка с госструктурами через Почту России с описью вложения и уведомлением о вручении.

Особенности SOAP:

* Строгость. Всё регламентировано. Шаг влево, шаг вправо — ошибка. * Транспорт. Может работать не только через HTTP (интернет), но и через SMTP (почта) и другие протоколы. * Безопасность. Имеет встроенные стандарты шифрования (WS-Security), поэтому его до сих пор любят банки и госучреждения. * Формат данных. Только XML.

У SOAP есть свой «ГОСТ» — файл WSDL (Web Services Description Language). Это как Технические Условия (ТУ) на подключение: там жестко прописано, какие поля обязательны, какие типы данных использовать. Если вы отправите строку вместо числа, сервер даже не станет читать ваше письмо.

REST: Гибкость и современность

REST (Representational State Transfer) — это не протокол, а архитектурный стиль. Это как общение в мессенджере или по электронной почте в свободной форме. Быстро, удобно, понятно.

В отличие от SOAP, где мы вызываем сложные процедуры, в REST мы работаем с Ресурсами. Ресурс — это любой объект: «Сотрудник», «Акт КС-2», «Договор».

Принципы REST:

Клиент-Сервер. Разделение ответственности (как Заказчик и Подрядчик).

Stateless (Без состояния). Сервер не запоминает, что вы спрашивали 5 минут назад. Каждый запрос должен содержать всю необходимую информацию (как будто вы каждый раз заново представляетесь охране на входе).

Единообразие интерфейса. Мы используем стандартные методы HTTP.

Вспомним методы, которые мы упоминали в первой статье, и расширим их понимание:

> * Идемпотентность — это свойство, при котором повторный вызов одной и той же операции не меняет состояние системы. Если вы 10 раз отправите запрос DELETE /act/1, первый раз акт удалится, а остальные 9 раз система скажет «уже удалено», но ничего лишнего не сломает. А вот если вы 10 раз сделаете POST /act, вы создадите 10 одинаковых актов.

Битва форматов: XML vs JSON

Данные по трубам API нужно как-то упаковывать. В строительстве это формы документов (КС-2, КС-3, М-29). В IT это форматы сериализации данных.

XML (eXtensible Markup Language)

Язык разметки, похожий на HTML. Используется в SOAP и старых системах. Он очень многословен, как пояснительная записка к проекту.

Пример (Информация о прорабе):

JSON (JavaScript Object Notation)

Современный стандарт для REST. Легкий, компактный, читаемый. Это как сводная таблица в Excel — только суть.

Тот же пример в JSON:

Математика эффективности

Давайте посчитаем, насколько JSON экономичнее XML. Это важно, когда мы передаем миллионы записей (например, данные с датчиков умного дома).

Эффективность сжатия данных можно оценить по формуле:

Где: * — коэффициент экономии объема данных (в процентах). * — длина сообщения в символах (байтах) в формате XML. * — длина того же сообщения в формате JSON.

В нашем примере выше: * XML (без пробелов): <employee><id>101</id><name>Иван Петров</name><role>Прораб</role></employee> — около 75 символов. * JSON (без пробелов): {"id":101,"name":"Иван Петров","role":"Прораб"} — около 45 символов.

Подставим в формулу:

Мы сэкономили 40% трафика просто сменив формат! В масштабах крупной системы это гигабайты данных и тысячи рублей на серверах.

!Сравнение «веса» и громоздкости форматов XML и JSON

Swagger (OpenAPI): Ваша исполнительная документация

Как инженер ПТО, вы знаете: построить объект — это полдела. Нужно еще сдать исполнительную документацию. Без чертежей никто не поймет, где проходят кабели.

В мире REST API роль исполнительной документации играет Swagger (сейчас это часть спецификации OpenAPI).

Swagger — это интерактивный сайт, который автоматически генерируется из кода (или пишется вручную). Он показывает:

Какие есть ручки (endpoints) — например, /users, /orders.

Какие методы к ним применимы (GET, POST).

Какие параметры нужно передать.

Что вернется в ответ.

Самое крутое: в Swagger есть кнопка «Try it out» (Попробовать). Вы можете прямо в браузере отправить запрос к API и увидеть реальный ответ, не написав ни строчки кода. Это как 3D-модель здания, где можно походить и померить расстояния, не выезжая на стройку.

Коды ответов HTTP: Язык светофоров

Мы уже касались кодов ответов, но давайте систематизируем их. Это сигналы, которые сервер подает клиенту.

* 2xx (Success / Успех): Зеленый свет. * 200 OK — Всё штатно. * 201 Created — Объект создан (фундамент залит). * 3xx (Redirection / Перенаправление): Желтый свет. Иди в другое окно. * 301 Moved Permanently — Ресурс переехал навсегда. * 4xx (Client Error / Ошибка клиента): Красный свет. Вы накосячили. * 400 Bad Request — Кривой запрос (не заполнили обязательные поля). * 401 Unauthorized — Нет пропуска (не залогинились). * 403 Forbidden — Пропуск есть, но сюда нельзя (у вас нет допуска по электробезопасности). * 404 Not Found — Нет такого кабинета. * 5xx (Server Error / Ошибка сервера): Авария на объекте. * 500 Internal Server Error — Что-то сломалось внутри, вы не виноваты. * 503 Service Unavailable — Сервер на техобслуживании (обед).

Заключение

Сегодня мы разобрали «инженерные сети» IT-мира. Вы узнали, что: * SOAP — это надежный, но тяжелый бронепоезд с XML. * REST — это легкий и быстрый спорткар с JSON. * JSON экономит трафик и проще читается. * Swagger — это ваша карта местности и инструкция по эксплуатации одновременно.

Понимание этих технологий — это база для системного аналитика. Именно вы будете писать в ТЗ: «Система А должна отправить POST запрос в Систему Б с телом в формате JSON, содержащим поля id и date».

В следующем модуле мы перейдем к самому интересному — хранению данных. Мы изучим базы данных и язык SQL, чтобы вы могли не только передавать данные, но и надежно их складировать и извлекать.

4. Работа с данными: проектирование баз данных, ER-диаграммы и SQL-запросы

Работа с данными: проектирование баз данных, ER-диаграммы и SQL-запросы

Приветствую, коллега! Мы продолжаем наш курс. В прошлых статьях мы разобрали, как управлять процессом разработки (SDLC, Agile), как собирать требования (BPMN) и как системы общаются между собой (API). Теперь пришло время поговорить о самом ценном ресурсе любой IT-системы — о данных.

Если API — это трубы и провода, то База Данных (БД) — это склад материалов, архив исполнительной документации и бухгалтерия в одном флаконе. Как инженер ПТО, вы привыкли работать с огромными объемами информации в Excel. Но Excel — это как хранить кирпичи в багажнике легковой машины: для дачи пойдет, но для строительства небоскреба нужна система посерьезнее.

Сегодня мы научимся проектировать структуру хранения данных, рисовать ER-диаграммы (аналог конструктивных чертежей) и писать SQL-запросы (язык общения со складом).

База данных vs Excel: В чем разница?

Представьте, что вы ведете учет материалов на объекте.

* Excel: Это плоская таблица. Если у вас есть поставщик «ООО Бетон-Строй», и он поставляет бетон на 10 разных объектов, вы 10 раз напишете его название, ИНН и адрес в каждой строке. Если у поставщика сменится адрес, вам придется искать и менять его во всех 10 строках (и вы точно где-то забудете). * Реляционная База Данных (RDBMS): Это набор связанных таблиц. У вас есть отдельная таблица «Поставщики» и отдельная таблица «Поставки». В «Поставках» вы просто указываете ссылку (ID) на поставщика. Сменился адрес? Меняем в одном месте, и он обновляется везде.

В IT это называется Нормализация — процесс организации данных для уменьшения избыточности.

Основные понятия: Таблицы, Строки, Столбцы

Давайте переведем термины БД на язык стройки:

Primary Key (Первичный ключ)

Это фундамент. У каждой записи должен быть уникальный ID. Даже если у вас два «Ивана Петровича Сидорова», в базе данных это будут ID: 101 и ID: 102. В строительстве аналогом является инвентарный номер оборудования или номер договора.

Foreign Key (Внешний ключ)

Это связь. Когда вы заполняете Акт скрытых работ, вы пишете: «Согласно чертежу № КЖ-12». Вот «КЖ-12» — это внешний ключ, который отправляет нас к другой сущности (Чертежу).

ER-диаграммы: Чертежи ваших данных

Прежде чем создавать таблицы, аналитик должен их спроектировать. Для этого используются ER-диаграммы (Entity-Relationship) — диаграммы «Сущность-Связь».

Это ваш проект КЖ (Конструкции Железобетонные) для данных. Вы рисуете квадратики (Сущности) и соединяете их линиями (Связями).

!Пример ER-диаграммы: Связь Заказчика, Договоров и Актов

Типы связей (Cardinality)

Один-к-одному (1:1).

Пример:* Один прораб — одна каска (условно). В реальности используется редко, обычно данные просто объединяют в одну таблицу.

Один-ко-многим (1:N).

Пример:* Один Договор может иметь много Актов КС-2. Но один Акт КС-2 всегда относится только к одному Договору. * Это самый частый тип связи.

Многие-ко-многим (M:N).

Пример:* Один Сотрудник может работать на многих Объектах. На одном Объекте работает много Сотрудников. Важно:* В базе данных такую связь нельзя сделать напрямую. Нужна промежуточная таблица (например, «Табель учета времени»).

SQL: Язык общения с базой данных

Вы спроектировали базу. Теперь нужно научиться извлекать из нее данные. Для этого используется язык SQL (Structured Query Language).

Представьте, что вы пишете служебную записку кладовщику. Это и есть SQL-запрос.

Основные команды (CRUD)

Мы уже упоминали CRUD в теме API. В SQL это выглядит так:

* Create INSERT (Добавить новую запись). * Read SELECT (Прочитать/Найти записи). * Update UPDATE (Обновить данные). * Delete DELETE (Удалить запись).

Самая важная команда для аналитика — это SELECT. Вы будете использовать ее в 90% случаев, чтобы выгружать отчеты.

Анатомия запроса SELECT

Допустим, мы хотим получить список всех инженеров, которые работают на объекте «ЖК Северный».

Это читается как обычное английское предложение. В отличие от языков программирования (Python, Java), здесь вы говорите системе что вы хотите получить, а не как это сделать.

JOIN: Объединение таблиц

Самая мощная сила SQL — это возможность соединять данные из разных таблиц. В Excel для этого используется ВПР (VLOOKUP), но он работает медленно и неудобно. В SQL используется оператор JOIN.

Представьте, что у вас есть две таблицы:

Acts (Акты): ID, Номер, Сумма, ID_Подрядчика.

Contractors (Подрядчики): ID, Название, ИНН.

В таблице Актов нет названия подрядчика, только его ID. Чтобы получить красивый отчет с названиями, нам нужно их «сджойнить».

Теория множеств в SQL

Понимание JOIN базируется на теории множеств. Давайте представим две таблицы как два круга.

!Визуализация работы JOIN через круги Эйлера-Венна

Математически операцию внутреннего соединения (INNER JOIN) можно выразить как пересечение множеств:

Где — результирующий набор данных, — множество записей в первой таблице, — множество записей во второй таблице, а символ обозначает пересечение (то есть мы берем только те записи, ключи которых есть И в таблице А, И в таблице В).

Если же мы хотим взять все акты, даже если у них не указан подрядчик (или подрядчик удален из базы), мы используем левое соединение (LEFT JOIN):

Где — левая таблица (Акты), — правая (Подрядчики), — разность множеств (есть в А, но нет в В), — объединение, а — пересечение. Проще говоря, мы берем всё множество целиком, и приклеиваем к нему данные из там, где они есть.

Пример запроса с JOIN

Перевод: «Выбери номер акта, сумму и имя подрядчика из таблицы Актов, присоединив таблицу Подрядчиков там, где ID подрядчика в акте совпадает с ID в таблице подрядчиков».

Группировка и агрегация

Начальство любит сводные отчеты. «Дай мне общую сумму выполнения по каждому подрядчику». В Excel вы бы делали Сводную таблицу (Pivot Table). В SQL это делается через GROUP BY.

Основные функции агрегации: * COUNT() — посчитать количество строк (штук). * SUM() — посчитать сумму значений. * AVG() — посчитать среднее арифметическое. * MAX() / MIN() — найти максимум и минимум.

Транзакции: Всё или ничего

В строительстве есть понятие «Скрытые работы». Вы не можете залить бетон, пока не сдали армирование. Это неразрывный процесс.

В базах данных есть понятие Транзакция. Это последовательность действий, которая должна быть выполнена целиком или не выполнена вовсе. Это гарантирует принцип ACID.

Представьте банковский перевод: списать деньги у вас зачислить деньги другу. Если деньги списались, а свет моргнул и другу не зачислились — это катастрофа.

Транзакция гарантирует: если на втором шаге ошибка, первый шаг отменяется (Rollback). Деньги возвращаются вам.

NoSQL: Когда порядок не нужен

Всё, что мы обсуждали выше — это классические реляционные базы (PostgreSQL, Oracle, MS SQL). Но иногда данные слишком хаотичны, чтобы раскладывать их по таблицам. Например, логи с датчиков умной каски или переписка в чате.

Для этого существуют NoSQL базы данных. Они похожи на свалку строительного мусора или на папку «Разное» на рабочем столе. Вы просто кидаете туда JSON-документ (который мы изучили в прошлой статье), и он там лежит. Это работает быстрее, но искать данные сложнее.

Заключение

Базы данных — это фундамент любого приложения. Как аналитик, вы не обязаны быть администратором БД (DBA), но вы обязаны:

Понимать, как данные связаны друг с другом (ER-диаграммы).

Уметь самостоятельно достать данные для анализа, не дергая разработчиков (SQL).

Проектировать структуру хранения для новых фич.

Ваш навык работы с Excel и сметными программами — отличная база. SQL покажется вам очень логичным инструментом, как только вы напишете свои первые 5-10 запросов.

В следующей статье мы поговорим о том, как документировать всё это многообразие, используя нотации UML и инструменты вроде Confluence.

5. Инструментарий и карьера: Jira, Confluence, Git и подготовка к техническому собеседованию

Инструментарий и карьера: Jira, Confluence, Git и подготовка к техническому собеседованию

Приветствую, коллега! Мы прошли долгий путь. Мы разобрали фундамент (SDLC), возвели стены (Требования и BPMN), проложили инженерные сети (API) и обустроили склад материалов (SQL). Теперь, когда вы понимаете суть работы системного аналитика, пришло время поговорить об инструментах, которыми вы будете пользоваться ежедневно, и о том, как «продать» свой опыт инженера ПТО на собеседовании в IT-компанию.

В строительстве у вас были AutoCAD, Гранд-Смета и бесконечные журналы работ (КС-6а). В IT есть своя «святая троица»: Jira, Confluence и Git. Давайте разберемся, зачем они нужны и как с ними работать.

Jira: Ваш цифровой журнал производства работ

Если вы работали с графиками производства работ (ГПР) в MS Project или просто вели ежедневные планерки с прорабами, суть Jira (Атлассиан Джира) вам будет понятна сразу. Это система отслеживания задач (Task Tracker).

В ПТО задача звучит так: «Залить бетоном захватку №1 в осях А-Б». У нее есть статус: «В работе», «Выполнено», «Принято технадзором». В Jira всё точно так же.

Основные сущности Jira:

Project (Проект). Это ваша стройплощадка. Например, «Мобильное приложение банка».

Issue (Задача/Тикет). Единица работы. Это может быть:

* Epic (Эпик): Крупный этап работ (аналог: «Возведение монолитного каркаса»). * Story (История): Конкретная фича (аналог: «Заливка колонн 1-го этажа»). * Bug (Баг): Ошибка (аналог: «Трещина в бетоне, требуется инъектирование»).

Workflow (Жизненный цикл). Путь задачи от создания до закрытия.

Пример:* To Do (Нужно сделать) In Progress (В работе) Testing (На проверке) Done (Готово).

Канбан-доска

Самый популярный вид отображения задач — это доска (Board). Представьте стену в вагончике штаба строительства, на которую наклеены стикеры. Вы берете стикер из колонки «План» и переклеиваете в «В работе».

!Визуальное сравнение интерфейса Jira и бумажного журнала работ

Ваша роль как аналитика в Jira — постановка задач. Вы создаете тикеты, описываете требования (которые мы учились писать ранее) и прикладываете ссылки на макеты. Разработчик не начнет «класть кирпич», пока не увидит тикет в статусе «To Do».

Оценка сроков: PERT

В строительстве сроки берутся из ЕНиР (Единые нормы и расценки). В IT задачи часто уникальны, поэтому точная оценка сложна. Аналитики и менеджеры часто используют метод оценки PERT (Program Evaluation and Review Technique).

Формула расчета ожидаемого времени выполнения задачи:

Где: * (Time Expected) — ожидаемое время выполнения задачи. * (Optimistic) — оптимистичная оценка (если всё пойдет идеально). * (Most Likely) — наиболее вероятная оценка (реалистичный прогноз). * (Pessimistic) — пессимистичная оценка (если всё сломается). * Числа и — это весовые коэффициенты формулы усреднения.

Например, разработчик говорит: «Сделаю за 2 дня, если повезет. Скорее всего за 3. Но если база упадет, то буду возиться 8 дней». Считаем: дня. Это число мы и заносим в план.

Confluence: Исполнительная документация и ППР

Если Jira — это оперативная работа, то Confluence — это архив и библиотека знаний. Это «Википедия» вашего проекта.

В ПТО у вас есть папки с ППР (Проект производства работ), Технологическими картами, паспортами на материалы и актами скрытых работ. В IT всё это хранится в Confluence.

Что пишет аналитик в Confluence:

Требования. Те самые User Stories и Use Cases.

Описание API. Таблицы с методами, параметрами и примерами JSON.

Инструкции. «Как развернуть проект», «Как завести тестового пользователя».

Протоколы встреч (Meeting Notes). О чем договорились с заказчиком (аналог протоколов планерки).

Главная фишка: Jira и Confluence интегрированы. Вы можете в задаче Jira поставить ссылку на статью в Confluence с требованиями. Это создает единое информационное пространство, где ничего не теряется (в отличие от бумажных актов, которые вечно пропадают у субподрядчиков).

Git: Управление версиями (не только для программистов)

Это самая сложная тема для новичков, но у инженера ПТО есть идеальная аналогия.

Вспомните, как вы называете файлы чертежей: * Plan_v1.dwg * Plan_v2_ispravlenny.dwg * Plan_v3_FINAL.dwg * Plan_v3_FINAL_TOCHNO.dwg

Это и есть примитивная система контроля версий. Git делает то же самое, но профессионально.

Зачем Git аналитику?

Docs-as-Code (Документация как код). Современный тренд — хранить документацию не в Word, а в текстовых файлах (Markdown) прямо рядом с кодом программы.

Просмотр истории. Вы можете увидеть, кто и когда изменил требования или код.

JSON/XML файлы. Часто аналитику нужно самому положить файл конфигурации или пример JSON-ответа в репозиторий.

Основные понятия Git:

* Repository (Репозиторий). Папка проекта (Архив). * Commit (Коммит). Сохранение изменений. Это как поставить штамп «В производство работ» и дату. Каждый коммит имеет уникальный номер (хэш). * Branch (Ветка). Параллельная версия проекта. Представьте, что вы делаете перепланировку 5-го этажа, но не хотите портить основной чертеж здания. Вы делаете копию (ветку), работаете в ней, а потом, если всё хорошо, переносите изменения в основной чертеж. * Merge (Слияние). Процесс переноса изменений из ветки в основную версию.

!Графическое объяснение работы веток и слияния в системе контроля версий

Подготовка к техническому собеседованию

Вы изучили теорию. Теперь нужно получить оффер. Главный страх инженера ПТО: «У меня нет опыта в IT». Это неправда. У вас есть релевантный опыт, просто он называется иначе.

Перевод опыта с языка ПТО на язык IT

В резюме и на собеседовании используйте правильную терминологию:

Типичные вопросы на собеседовании (Hard Skills)

Вас обязательно спросят по технической части. Будьте готовы ответить на вопросы из нашего курса:

«Чем отличается REST от SOAP?» (Вспоминаем JSON vs XML, легкость vs строгость).

«Что такое JOIN и какие виды бывают?» (Вспоминаем круги Эйлера и объединение таблиц).

«Как вы будете выявлять требования, если заказчик молчит?» (Интервью, анализ документации, наблюдение).

«Нарисуйте процесс покупки товара в интернет-магазине». (Здесь нужно быстро набросать BPMN или блок-схему).

Soft Skills (Мягкие навыки)

Инженер ПТО — это стрессоустойчивый коммуникатор. В IT это ценится на вес золота. Расскажите историю, как вы сдали объект, когда проект был сырой, а материалы задерживали. Это покажет, что вы умеете решать проблемы (Problem Solving).

Заключение курса

Поздравляю! Вы прошли путь от понимания того, как строится ПО, до инструментов ежедневной работы.

Профессия системного аналитика — это не магия. Это та же инженерия, только вместо бетона и арматуры вы используете данные и алгоритмы. Вместо прораба у вас тимлид, вместо заказчика стройки — владелец продукта (Product Owner).

Ваш бэкграунд инженера ПТО — это ваше преимущество. Вы умеете работать с документами, понимаете ответственность и обладаете системным мышлением. Осталось только выучить синтаксис SQL и привыкнуть к интерфейсу Jira.

Удачи на собеседованиях! Стройте надежные системы, коллега!