Давайте представим, что меня пригласили...

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

Что нужно сделать? 1. Выбираем рандомную вакансию на hh.ru. 2. Читаем требования

Отлично! У нас есть список, к которому нужно подготовиться за 3 дня. Почему 3 дня? Это среднее количество времени, которое уходит на то, чтобы ваш отклик был увиден и в случае положительного ответа, вы были бы приглашены на интервью.

Давайте распишем план подготовки. Поделюсь своими заметками в данном случае.

3.Рассматриваем каждый пункт отдельно.
Вспоминаем все, что было по SQL:

- SQL для начинающих. DML, DDL, DCL, TCL (https://telegra.ph/SQL-dlya-nachinayushchih-DML-DDL-DCL-TCL-09-13)

- SQL для начинающих. Функции и операторы (https://telegra.ph/SQL-dlya-nachinayushchih-Funkcii-i-operatory-09-14)

- Условия и способы фильтрации данных (https://teletype.in/@stoic_ftr/1e4_TPbjaeZ)

Этого должно хватить для того, чтобы пройти собес по SQL. Если у вас в вакансии будет строчка включая индексы, то советую прочитать следующие статьи:

1. https://habr.com/ru/companies/ruvds/articles/724066/

2. https://habr.com/ru/articles/247373/

Читаем дальше. Описание контрактов интеграций (REST, ESB)

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

Контракты интеграций (integration contracts) — это соглашения или договоренности между системами, сервисами или компонентами, определяющие, как именно они будут взаимодействовать друг с другом. Такие контракты фиксируют, какие данные, форматы и методы будут использоваться для успешного обмена информацией. Цель — гарантировать совместимость и предсказуемость работы систем, даже если одна из них развивается или обновляется.

Что включает контракт интеграции?

Контракт интеграции обычно включает:

Структуру данных: какие поля будут в передаваемых данных, их типы и значения по умолчанию.
Форматы данных: формат обмена, например JSON, XML, Protobuf и др.
Протоколы: определяет, как данные будут передаваться — через REST API, GraphQL, gRPC и т.д.
Ограничения: валидность данных, например, минимальные и максимальные значения.
Версионность: управление версиями, чтобы можно было обновлять контракт без ломки существующих интеграций.
Обязательные и необязательные поля: указывает, какие поля должны присутствовать в каждом запросе/ответе, а какие — опциональны.

Простой пример контракта интеграции

Представьте, что у нас есть интернет-магазин и служба доставки. Чтобы передавать данные о заказах, они заключают контракт интеграции.

Пример контракта интеграции:

Формат обмена: JSON
Протокол: REST API (через HTTP POST-запросы).
Тело запроса:json

{ "order_id": "string (обязательное)", "customer_name": "string (обязательное)", "customer_address": "string (обязательное)", "delivery_date": "string (дата в формате YYYY-MM-DD, обязательное)", "items": [ { "item_id": "string (обязательное)", "quantity": "integer (обязательное)", "price": "float (обязательное)" } ] }

Ошибки: служба доставки возвращает код 400, если обязательные поля отсутствуют или имеют некорректный формат, и код 200 — если заказ принят.
Версионность: параметр v1 указывается в URL, чтобы при необходимости службы могли перейти на новую версию, не нарушая старую интеграцию.

Зачем нужны контракты интеграций?

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

Итог: контракты интеграций — это четкое соглашение о правилах взаимодействия между системами, позволяющее избегать проблем совместимости и обеспечить предсказуемость и стабильность работы.

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

1.Клиент-серверная архитектура. HTTP-запросы, HTTP- ответы (https://teletype.in/@stoic_ftr/ozO6MBmRYyn)

2. REST, JSON (https://teletype.in/@stoic_ftr/5t4UP4M1Uzo)

3. В чем разница между REST и SOAP? Что такое SOAP? Самые популярные вопросы на собеседовании (https://teletype.in/@stoic_ftr/xsV8d9WQ86m)

4. Postman. Что это? Зачем это? Какой функционал? Когда использовать нужно, а когда не нужно? (https://teletype.in/@stoic_ftr/tVszPclkTbU)

Что такое ESB? В это случае тоже лучше узнать определение и легкий пример.

ESB (Enterprise Service Bus) — это инфраструктурная платформа, которая помогает различным приложениям в компании обмениваться данными и работать вместе, даже если они написаны на разных языках программирования, используют разные форматы данных или работают на разных платформах. ESB объединяет их, предоставляя общую «шину» для передачи данных и команд.

Основные функции ESB:

Интеграция: подключение разных систем и приложений.
Маршрутизация сообщений: отправка сообщений между системами на основе определенных правил.
Трансформация данных: преобразование данных из одного формата в другой (например, XML в JSON).
Оркестрация: управление порядком выполнения сервисов или задач.
Обработка ошибок: централизованное управление ошибками и журналирование событий.

Простой пример использования ESB:

Представьте компанию, у которой есть несколько систем:

ERP-система для управления запасами.
CRM-система для работы с клиентами.
Интернет-магазин для онлайн-продаж.

Эти системы должны обмениваться информацией: если клиент заказывает товар на сайте, информация о заказе должна поступить в CRM для обработки и в ERP для обновления запасов.

С ESB эти системы подключаются к единой шине, через которую передаются сообщения. При оформлении заказа интернет-магазин отправляет информацию о заказе в ESB, которая:

Маршрутизирует заказ в CRM для регистрации данных клиента.
Преобразует данные заказа в нужный формат и отправляет в ERP-систему для обновления склада.

ESB упрощает интеграцию, так как вместо прямых связей между системами (каждая система должна "знать" и интегрироваться с другой) все они просто взаимодействуют с ESB, который уже распределяет и преобразует сообщения.

Окей, с ESB разобрались. Что это мы знаем, как это используется мы знаем. Можем ли мы за 3 дня получить более глубинные знания? Вряд ли. Записываем это в наш блокнот дальнейших планов развития. Далее у нас идет описание бизнес-процессов в нотации BPMN. Здесь советую посмотреть: Краткий конспект по нотации BPMN 2.0 (https://teletype.in/@stoic_ftr/HdyLMhiN7sQ)

Что нужно для того, чтобы с уверенностью сказать, что ты сможешь отвечать на вопросы по бизнес/системному анализу? Тут поможет небольшая шпаргалка:

1. Знание ключевых понятий и подходов

Бизнес-анализ: Уметь объяснить цели и основные этапы бизнес-анализа, начиная от выявления потребностей бизнеса до разработки рекомендаций и внедрения решений.
Системный анализ: Понимать, как анализировать технические и функциональные требования, а также концепции построения архитектуры и интеграции систем.

2. Опыт работы с основными инструментами и техниками

Техники сбора и анализа требований: интервью, анкетирование, воркшопы, анализ процессов, модели “As-Is” и “To-Be”.
Методологии и фреймворки: Agile (Scrum/Kanban), Waterfall, BABOK. Умение ориентироваться в этих методологиях, знание их плюсов и минусов.
Диаграммы и модели: Умение создавать и читать BPMN, UML (диаграммы классов, последовательностей), ERD, use cases, и user stories.

3. Понимание жизненного цикла разработки ПО и роли анализа в нем

Понимание того, как требования меняются по мере прохождения через стадии анализа, разработки, тестирования и внедрения. Знание, как работать с изменениями требований (управление изменениями).

4. Навыки документооборота и разработки требований

Опыт написания различных документов: спецификаций требований (SRS), документации к API, описания процессов, инструкций для пользователей.
Знание стандартов и шаблонов для документации, таких как IEEE для требований.

5. Опыт работы с системами и базами данных

Базовое понимание SQL и работы с реляционными базами данных.
Понимание основ архитектуры приложений и систем, работы с API, особенностей REST и SOAP.

6. Коммуникативные и аналитические навыки

Умение задавать правильные вопросы, выделять ключевые моменты из интервью и требований заказчика, представлять результаты анализа команде и стейкхолдерам.
Способность упрощать сложные концепции и адаптировать свои объяснения под разную аудиторию.

7. Постоянное обучение и практика

Изучение современных практик, прохождение курсов, чтение специализированной литературы и применение знаний на практике. Например, BABOK Guide для бизнес-анализа, курсы по SQL и базам данных для системного анализа, а также кейсы для закрепления навыков моделирования и анализа.

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

Ну, и наконец пункт с разработкой проектной, приемо-сдаточной и эксплуатационной документации. Тут проще - нужно просто выучить.

Проектная, приемо-сдаточная и эксплуатационная документация – это типы документов, которые сопровождают жизненный цикл проекта, особенно когда речь идет о технических системах и разработке программного обеспечения. Для понимания этих видов документации важно знать их назначение, содержание и место в процессе разработки.

1. Проектная документация

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

Основные компоненты:

Техническое задание (ТЗ): содержит цели и задачи проекта, требования к функциональности, сроки и бюджет.
Спецификация требований (SRS): документирует требования к системе. Охватывает функциональные, нефункциональные и системные требования.
Архитектурная документация: описывает архитектуру системы, используемые технологии, компоненты, их взаимодействие и интеграции.
Диаграммы и схемы: UML, DFD (Data Flow Diagrams) или другие схемы, которые показывают структуру системы, связи между компонентами и основную логику.
План тестирования: основные подходы к тестированию, контрольные точки и критерии приемки.

Пример: Архитектурная схема проекта с описанием интерфейсов, используемых компонентов и их взаимодействия в системе учета заказов.

2. Приемо-сдаточная документация

Назначение: Документы для передачи системы заказчику. Они подтверждают выполнение всех требований и успешное завершение работ. Эти документы нужны для демонстрации готовности системы к эксплуатации и для юридического закрепления сдачи-приемки работ.

Основные компоненты:

Акт приемки-передачи: документ, который подписывается обеими сторонами и подтверждает, что заказчик принял выполненную работу.
Протоколы испытаний и тестов: фиксируют результаты тестирования и показывают, что система работает в соответствии с требованиями.
Заключение о соответствии требованиям: резюме, которое показывает, что система соответствует всем требованиям, описанным в техническом задании.
Инструкции и отчеты по проверкам: пошаговые инструкции для проверки работы системы или проведения интеграционных тестов.

Пример: Заказчик подписывает акт приемки, подтверждая, что программное обеспечение удовлетворяет заявленным требованиям и успешно прошло все предусмотренные тесты.

3. Эксплуатационная документация

Назначение: Инструкции для эксплуатации, администрирования и обслуживания системы после ее запуска. Эта документация важна для конечных пользователей, администраторов и обслуживающего персонала.

Основные компоненты:

Руководство пользователя: инструкции по работе с системой для конечных пользователей, включая описание интерфейсов, команд и операций.
Руководство администратора: включает в себя настройки, учетные данные, процессы администрирования, резервного копирования и восстановления данных.
Руководство по установке и настройке: пошаговое описание, как установить и настроить систему, чтобы она корректно функционировала.
Документация по обслуживанию и техподдержке: включает процедуры диагностики, устранения проблем, обновления и мониторинга системы.

Пример: Руководство пользователя, описывающее, как работать с интерфейсом системы для создания отчетов.

Основные вопросы, которые могут задать на собеседовании

В чем отличие между проектной, приемо-сдаточной и эксплуатационной документацией?

Ответ: Проектная документация описывает технические решения и структуру системы, приемо-сдаточная подтверждает соответствие требованиям и готовность к эксплуатации, а эксплуатационная ориентирована на пользователей и поддержание системы.

Какие основные документы входят в состав проектной документации?

Ответ: Это техническое задание, спецификация требований, архитектурные схемы, диаграммы, и план тестирования.

Как оформляется акт приемки-передачи?

Ответ: Акт включает описание выполненных работ, их соответствие требованиям, подписи обеих сторон (исполнителя и заказчика) и фиксирует передачу объекта заказчику.

Какие типы руководств входят в эксплуатационную документацию?

Ответ: Руководства для пользователей, администраторов, по установке, настройке и техподдержке.

Как документировать требования в проектной документации?

Ответ: Требования документируются в спецификации требований (SRS), включающей описание функциональных, нефункциональных, системных требований и ограничений.

Советы для подготовки:

Изучите примеры этих документов, если есть возможность, чтобы знать их структуру и содержание.
Потренируйтесь объяснять каждый тип документа в одном предложении, чтобы легко передать суть и назначение.
Приводите примеры из личного опыта или кейсов, если работали с подобными документами, поскольку это поможет показать ваш практический опыт.