🧐 ИЗ ЧЕГО СОСТОИТ ТЗ? 🧐
Чаще всего ТЗ содержит следующие информационные блоки:
1️⃣ Введение
Где представлена общая информация о проекте, его целях, контексте и описанием текущей проблемы или потребности.
2️⃣ Список участников проекта
То есть тех, кто принимает участие в проектировании решения. Зачастую достаточно заказчика, менеджера проекта, ответственного аналитика и разработчика.
3️⃣ Глоссарий
с указанием терминов и сокращений, которые используются в документации, — так читатели ТЗ будут в едином контексте.
4️⃣ Основные требования
Список основных функций, возможности, ограничения и взаимодействие с другими системами, а также требования к производительности, безопасности, масштабируемости и другим особенностям продукта.
5️⃣ Требования к документации
Где фиксируется, что будет разработан пакет руководств-инструкций, ПМИ, протокол ПСИ и так далее.
6️⃣ Архитектура и дизайн.
В этой части — общая архитектура системы, используемые технологии, платформы, инструменты, описание модулей, интерфейсов и так далее.
7️⃣ Интеграции и взаимодействия
Где указаны требования и протоколы для взаимодействия с другими системами, API, форматы данных и схемы коммуникации.
8️⃣ Порядок контроля и приёмки,
который содержит тестовые сценарии, ожидаемые результаты и критерии приёмки.
9️⃣ Стадии и этапы разработки, а также сроки их выполнения.
🔟 Возможные риски
Где описаны сложности или негативные последствия, которые могут повлиять на проект. Тут же указаны планы по их снижению или управлению.
Также ТЗ может содержать приложения с артефактами в виде диаграмм, прототипов, описания API и другой документации. В зависимости от правил оформления ТЗ в компании, а также от сложности проекта, вам понадобятся все блоки из списка или только их часть.
🧐 ПРО СТАНДАРТЫ ТЗ 🧐
Шаблон для написания ТЗ в разных компаниях отличается, но часто он базируется на каком-то из стандартов. Всего существует три группы стандартов:
❣️ Международные (ISO, IEEE)
❣️ Российские (ГОСТ 19, ГОСТ 34)
❣️ Стандарты из областей знаний (BABOK, Вигерс, RUP и другие)
Все они специализируются на разных предметных областях, поэтому брать можно как готовый стандарт, так и его адаптированную версию.
Чаще всего ТЗ содержит следующие информационные блоки:
1️⃣ Введение
Где представлена общая информация о проекте, его целях, контексте и описанием текущей проблемы или потребности.
2️⃣ Список участников проекта
То есть тех, кто принимает участие в проектировании решения. Зачастую достаточно заказчика, менеджера проекта, ответственного аналитика и разработчика.
3️⃣ Глоссарий
с указанием терминов и сокращений, которые используются в документации, — так читатели ТЗ будут в едином контексте.
4️⃣ Основные требования
Список основных функций, возможности, ограничения и взаимодействие с другими системами, а также требования к производительности, безопасности, масштабируемости и другим особенностям продукта.
5️⃣ Требования к документации
Где фиксируется, что будет разработан пакет руководств-инструкций, ПМИ, протокол ПСИ и так далее.
6️⃣ Архитектура и дизайн.
В этой части — общая архитектура системы, используемые технологии, платформы, инструменты, описание модулей, интерфейсов и так далее.
7️⃣ Интеграции и взаимодействия
Где указаны требования и протоколы для взаимодействия с другими системами, API, форматы данных и схемы коммуникации.
8️⃣ Порядок контроля и приёмки,
который содержит тестовые сценарии, ожидаемые результаты и критерии приёмки.
9️⃣ Стадии и этапы разработки, а также сроки их выполнения.
🔟 Возможные риски
Где описаны сложности или негативные последствия, которые могут повлиять на проект. Тут же указаны планы по их снижению или управлению.
Также ТЗ может содержать приложения с артефактами в виде диаграмм, прототипов, описания API и другой документации. В зависимости от правил оформления ТЗ в компании, а также от сложности проекта, вам понадобятся все блоки из списка или только их часть.
🧐 ПРО СТАНДАРТЫ ТЗ 🧐
Шаблон для написания ТЗ в разных компаниях отличается, но часто он базируется на каком-то из стандартов. Всего существует три группы стандартов:
Все они специализируются на разных предметных областях, поэтому брать можно как готовый стандарт, так и его адаптированную версию.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15
This media is not supported in your browser
VIEW IN TELEGRAM
Сообщество GetAnalyst - здесь вы будете тем специалистом, который знает, что делает😄
Верьте в себя и свои навыки! 🚀
Верьте в себя и свои навыки! 🚀
❤14
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20🤔1
BPMN - Получение предоплаты.png
146.4 KB
BPMN (Business Process Model and Notation) — это стандартная нотация для описания бизнес-процессов в виде диаграмм.
Это единый визуальный язык, на котором могут договориться о работе бизнес-процессов:
+ бизнес,
+ системные и бизнес-аналитики,
+ разработчики и тестировщики.
👉 Ключевые элементы нотации BPMN
Минимальный набор, который нужен аналитику для работы:
◽️ Пулы и дорожки (pool / lane) — кто участвует в процессе
Клиент, оператор, внешняя система, наш backend.
◽️ Задачи (task) — что конкретно делает участник
«Проверить оплату», «Создать заказ», «Отправить письмо».
◽️ События (event) — старт, конец, ошибка, таймаут
Заказ создан, оплата не прошла, истёк срок ожидания.
◽️ Шлюзы (gateway) — развилки по условиям
Оплата прошла / не прошла, товар есть / нет.
👉 Зачем BPMN-диаграммы нужны для проекта?
✅ Общий язык с бизнесом
Показываешь схему и спрашиваешь:
«Вот так клиент оформляет заказ. Где я ошибся?»
Проще посмотреть картинку, чем 10 страниц текста.
✅ Выявить дыры в логике
Как только рисуешь BPMN, сразу всплывает много нюансов:
+ а что, если клиент передумал на шаге оплаты?
+ а если банк подтвердил платёж, а у нас товара на складе уже нет?
+ и т.д.
✅ Связать процессы с требованиями и API
Сначала — BPMN-процесс AS-IS / TO-BE,
потом на его основе:
+ требования к интерфейсу,
+ методы REST / события Kafka,
+ интеграции, обработка ошибок.
✅ На основе BPMN-диаграмм могут работать реальные процессы в системе - через оркестратор как Camunda.
BPMN — каркас архитектуры процессов, а не просто «диаграмма для красоты».
Подборку ключевых элементов и примеров бизнес-процессов добавили на картинках к посту.
Дополнительные материалы для изучения:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11🤩4👍1🔥1
🎓 Системный аналитик: с нуля до опыта работы на проекте 🎓
Давно планируете сменить профессию на СА, но знаний не хватает или делаете всё «по наитию»?
Эта практическая программа для вас 👇
🎓 Системный аналитик: с нуля до опыта работы
🔗 Подробности и запись
Обучение только началось, и сейчас идеальный момент, чтобы присоединиться и успеть наверстать все важные темы. Это классная возможность освоить новые знания и навыки, которые помогут в будущем!
🧭 Наши выпускники
👉 Бухгалтеры, учителя, работники госслужб и другие специалисты, кто переходит в IT
👉 Бизнес-аналитики
👉 Junior/Начинающие СА
👉 Тестировщики
👉 Техписы
👉 Специалисты техподдержки
👉 PM
🎯 Цели
+ Получить профессию
+ Нужны системные знания
+ Нужна уверенность в работе
+ Выстроить сильную базу в аналитике
🧱 Что делаем на проекте
+ Собираем, анализируем и документируем требования
+ БТ, НФТ, ФТ, Use Cases, User Stories
+ Проектируем БД: концептуальную, логическую и физическую модели (ER-диаграммы)
+ Создаем реальную БД на основе вашей модели
+ Делаем SQL-запросы в ней
+ Проектируем архитектуру
+ Проектируем REST API (JSON) с нуля
+ Тестируем REST API в Postman; SOAP API (xml) в SoapUI
+ Ставим задачи на БД, Backend, Frontend, Интеграции
Работаем с Confluence, Jira, Figma, Miro, Draw io, DevTools, Postman, DBeaver и другими необходимыми для работы инструментами
🗓 Формат и темп
10 месяцев глубокой онлайн-практики.
Каждое занятие — практика с разбором ваших результатов работы.
+ Можно учиться ускоренно: 3, 6 или 10 мес
+ Индивидуальный план под вашу цель: вход в профессию / рост
🔥 Почему поток 2025–2026?
Потоки раз в год.
Этот — последний в полном формате, с большим количеством онлайна и индивидуальной работы.
Со следующего года количество встреч будет сокращено.
👉 Это ваша возможность успеть на «полную версию»
🏁 Итоги для вас
+ Опыт работы в команде с индивидуальной зоной ответственности
+ Понимание «как делать правильно», ваши шаблоны документации и уверенность на собеседованиях
+ 80% выпускников прошлого потока уже перешли в новые роли и нашли первую работу в IT 🙌
Больше подробностей тут.
Вопросы можно писать @getanalyst 🤝
Ждём вас в команде СА! 😉
Давно планируете сменить профессию на СА, но знаний не хватает или делаете всё «по наитию»?
Эта практическая программа для вас 👇
🎓 Системный аналитик: с нуля до опыта работы
🔗 Подробности и запись
Обучение только началось, и сейчас идеальный момент, чтобы присоединиться и успеть наверстать все важные темы. Это классная возможность освоить новые знания и навыки, которые помогут в будущем!
🧭 Наши выпускники
👉 Бухгалтеры, учителя, работники госслужб и другие специалисты, кто переходит в IT
👉 Бизнес-аналитики
👉 Junior/Начинающие СА
👉 Тестировщики
👉 Техписы
👉 Специалисты техподдержки
👉 PM
🎯 Цели
+ Получить профессию
+ Нужны системные знания
+ Нужна уверенность в работе
+ Выстроить сильную базу в аналитике
🧱 Что делаем на проекте
+ Собираем, анализируем и документируем требования
+ БТ, НФТ, ФТ, Use Cases, User Stories
+ Проектируем БД: концептуальную, логическую и физическую модели (ER-диаграммы)
+ Создаем реальную БД на основе вашей модели
+ Делаем SQL-запросы в ней
+ Проектируем архитектуру
+ Проектируем REST API (JSON) с нуля
+ Тестируем REST API в Postman; SOAP API (xml) в SoapUI
+ Ставим задачи на БД, Backend, Frontend, Интеграции
Работаем с Confluence, Jira, Figma, Miro, Draw io, DevTools, Postman, DBeaver и другими необходимыми для работы инструментами
🗓 Формат и темп
10 месяцев глубокой онлайн-практики.
Каждое занятие — практика с разбором ваших результатов работы.
+ Можно учиться ускоренно: 3, 6 или 10 мес
+ Индивидуальный план под вашу цель: вход в профессию / рост
🔥 Почему поток 2025–2026?
Потоки раз в год.
Этот — последний в полном формате, с большим количеством онлайна и индивидуальной работы.
Со следующего года количество встреч будет сокращено.
👉 Это ваша возможность успеть на «полную версию»
🏁 Итоги для вас
+ Опыт работы в команде с индивидуальной зоной ответственности
+ Понимание «как делать правильно», ваши шаблоны документации и уверенность на собеседованиях
+ 80% выпускников прошлого потока уже перешли в новые роли и нашли первую работу в IT 🙌
Больше подробностей тут.
Вопросы можно писать @getanalyst 🤝
Ждём вас в команде СА! 😉
❤5
📚 «Анатомия заблуждений» — книга, написанная российским философом и психологом, в которой исследуются причины и механизмы возникновения заблуждений в мышлении человека.
Автор анализирует различные типы ошибок, которые люди совершают в процессе восприятия и интерпретации информации, а также предлагает методы для их преодоления.
Книга сочетает в себе элементы философии, психологии и социологии, что позволяет глубже понять, как формируются наши убеждения и как они могут влиять на поведение✔️
Основная идея заключается в том, что осознание собственных заблуждений — первый шаг к более рациональному мышлению и принятию решений.
Написана простым доступным языком, поэтому рекомендуем к прочтению🙌
#hwGetAnalyst
Автор анализирует различные типы ошибок, которые люди совершают в процессе восприятия и интерпретации информации, а также предлагает методы для их преодоления.
Книга сочетает в себе элементы философии, психологии и социологии, что позволяет глубже понять, как формируются наши убеждения и как они могут влиять на поведение
Основная идея заключается в том, что осознание собственных заблуждений — первый шаг к более рациональному мышлению и принятию решений.
Написана простым доступным языком, поэтому рекомендуем к прочтению🙌
#hwGetAnalyst
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11
GetAnalyst_7_шаблонов_проектирования_архитектуры_для_СА.pdf
1.5 MB
📚 7 видов архитектуры, которые важно знать СА 📚
В простых проектах аналитикам не надо разбираться в архитектуре.
Но в сложных продуктовых компаниях, как банки, маркетплейсы, страховые и т.п., где преобладают сервисная (SOA) и микросервисная (MSA) архитектуры, аналитикам важно разбираться в этом вопросе.
Понимание видов архитектуры нужно, чтобы грамотно проектировать новые функции и правильно интегрировать их в существующую инфраструктуру.
👉 7 шаблонов проектирования архитектуры, которые важно знать и понимать СА:
1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)
Вопросы по ним уже почти всегда задают на собеседованиях для Middle и выше аналитиков.
📚 В мини-книге к посту вы найдёте:
+ описание каждого подхода,
+ связи между ними,
+ картинки,
+ примеры.
Сохраняйте и пользуйтесь!
P.S. А если интересно погрузиться в архитектуру для кода, то рекомендую послушать подкаст про Чистую архитектуру
#hardGetAnalyst
В простых проектах аналитикам не надо разбираться в архитектуре.
Но в сложных продуктовых компаниях, как банки, маркетплейсы, страховые и т.п., где преобладают сервисная (SOA) и микросервисная (MSA) архитектуры, аналитикам важно разбираться в этом вопросе.
Понимание видов архитектуры нужно, чтобы грамотно проектировать новые функции и правильно интегрировать их в существующую инфраструктуру.
👉 7 шаблонов проектирования архитектуры, которые важно знать и понимать СА:
1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)
Вопросы по ним уже почти всегда задают на собеседованиях для Middle и выше аналитиков.
📚 В мини-книге к посту вы найдёте:
+ описание каждого подхода,
+ связи между ними,
+ картинки,
+ примеры.
Сохраняйте и пользуйтесь!
P.S. А если интересно погрузиться в архитектуру для кода, то рекомендую послушать подкаст про Чистую архитектуру
#hardGetAnalyst
🤩7❤2👍2
🗓 [29.11 - 02.12] Хореография и оркестрация микросервисов: открытый урок 🗓
Когда на Backend не один большой монолит, а десятки микросервисов, главный риск прячется не внутри сервисов, а между ними. Стоит допустить ошибку во взаимодействиях — и запросы «теряются», рассинхронизируются данные, неожиданные сбои...
Мы готовим открытый урок для системных аналитиков, чтобы подробно погрузить вас в подходы к интеграции микросервисов:
💎 Хореография и оркестрация микросервисов: практика проектирования процессов
🗓 29 ноября - 2 декабря [сб-вт]
🕘 Время на обучение: ~4 часа
📚 Урок в записи, смотрите в удобное время
🔗 Зарегистрироваться
👉 План:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
Это не просто демо-урок, где узнаете 5% от реального объема знаний, а полноформатное обучение, после которого получите реальные инструменты и знания, которые помогут значительно поднять планку вашей карьеры.
Прокачивайте понимание архитектуры систем!
Регистрируйтесь и смотрите занятие в удобное время с 29 ноября по 2 декабря 🙌
-----
Урок проводится в качестве вводного занятия к практической программе "Проектирование архитектуры" для системных аналитиков.
Когда на Backend не один большой монолит, а десятки микросервисов, главный риск прячется не внутри сервисов, а между ними. Стоит допустить ошибку во взаимодействиях — и запросы «теряются», рассинхронизируются данные, неожиданные сбои...
Мы готовим открытый урок для системных аналитиков, чтобы подробно погрузить вас в подходы к интеграции микросервисов:
💎 Хореография и оркестрация микросервисов: практика проектирования процессов
🗓 29 ноября - 2 декабря [сб-вт]
🕘 Время на обучение: ~4 часа
📚 Урок в записи, смотрите в удобное время
🔗 Зарегистрироваться
👉 План:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
Это не просто демо-урок, где узнаете 5% от реального объема знаний, а полноформатное обучение, после которого получите реальные инструменты и знания, которые помогут значительно поднять планку вашей карьеры.
Прокачивайте понимание архитектуры систем!
Регистрируйтесь и смотрите занятие в удобное время с 29 ноября по 2 декабря 🙌
-----
Урок проводится в качестве вводного занятия к практической программе "Проектирование архитектуры" для системных аналитиков.
❤4
This media is not supported in your browser
VIEW IN TELEGRAM
🔮 Микросервисная архитектура (МСА) — современный подход к разработке высоконагруженных приложений.
Ключевые компоненты, которые используются для его реализации:
✅ Клиенты — это Frontend-приложения или другие системы, которые взаимодействуют с Backend (сервер-приложениями).
✅ CDN (Content Delivery Network) — сеть серверов, стратегически распределенных по всему миру. Они кэшируют и доставляют статические ресурсы (изображения, скрипты и т. д.) пользователям с ближайшего сервера, оптимизируя время загрузки.
✅ API Gateway — единая точка входа для всех клиентов API. Он маршрутизирует запросы на нужные микросервисы, благодаря чему клиентам не надо думать о том, к какому сервису обратиться для вызова конкретной функции.
Он также может управлять аутентификацией, ограничением количества запросов (rate limiting) и другими доп. функциями.
✅ Микросервисы — это независимые компоненты, каждый из которых выполняет свою конкретную бизнес-логику.
Они взаимодействуют между собой с помощью легковесных протоколов, таких как HTTP (REST), gRPC или через асинхронные сообщения.
✅ Брокер сообщений — обеспечивает асинхронное взаимодействие между микросервисами.
Развязка сервисов через брокер (например, Kafka, RabbitMQ) делает систему более гибкой и отказоустойчивой, позволяя микросервисам работать независимо.
✅ Базы данных — в МСА действует принцип "база данных на сервис". Этот принцип предотвращает жёсткие связи между сервисами и позволяет использовать разные технологии хранения данных (polyglot persistence), выбирая оптимальные решения под конкретные задачи.
✅ Identity Provider — отвечает за аутентификацию (проверку личности пользователя) и авторизацию (определение прав доступа).
✅ Service Registry and Discovery — динамический каталог, в котором микросервисы регистрируются и находят друг друга.
✅ Service Coordination — инструменты, которые помогают управлять координацией и синхронизацией распределенных сервисов, обеспечивая их бесперебойную работу и согласованность данных.
#hardGetAnalyst
Ключевые компоненты, которые используются для его реализации:
✅ Клиенты — это Frontend-приложения или другие системы, которые взаимодействуют с Backend (сервер-приложениями).
✅ CDN (Content Delivery Network) — сеть серверов, стратегически распределенных по всему миру. Они кэшируют и доставляют статические ресурсы (изображения, скрипты и т. д.) пользователям с ближайшего сервера, оптимизируя время загрузки.
✅ API Gateway — единая точка входа для всех клиентов API. Он маршрутизирует запросы на нужные микросервисы, благодаря чему клиентам не надо думать о том, к какому сервису обратиться для вызова конкретной функции.
Он также может управлять аутентификацией, ограничением количества запросов (rate limiting) и другими доп. функциями.
✅ Микросервисы — это независимые компоненты, каждый из которых выполняет свою конкретную бизнес-логику.
Они взаимодействуют между собой с помощью легковесных протоколов, таких как HTTP (REST), gRPC или через асинхронные сообщения.
✅ Брокер сообщений — обеспечивает асинхронное взаимодействие между микросервисами.
Развязка сервисов через брокер (например, Kafka, RabbitMQ) делает систему более гибкой и отказоустойчивой, позволяя микросервисам работать независимо.
✅ Базы данных — в МСА действует принцип "база данных на сервис". Этот принцип предотвращает жёсткие связи между сервисами и позволяет использовать разные технологии хранения данных (polyglot persistence), выбирая оптимальные решения под конкретные задачи.
✅ Identity Provider — отвечает за аутентификацию (проверку личности пользователя) и авторизацию (определение прав доступа).
✅ Service Registry and Discovery — динамический каталог, в котором микросервисы регистрируются и находят друг друга.
✅ Service Coordination — инструменты, которые помогают управлять координацией и синхронизацией распределенных сервисов, обеспечивая их бесперебойную работу и согласованность данных.
#hardGetAnalyst
❤5👍1
Очередь сообщений — это структура данных,
которая хранит сообщения до тех пор, пока их не заберёт получатель.
Брокер сообщений — это программное обеспечение,
которое управляет обменом сообщений между приложениями.
Он может включать в себя множество очередей сообщений и дополнительно поддерживать топики, маршрутизацию, обработку и механизмы гарантии доставки.
Вопросы с подвохом, которые вы можете встретить на собеседованиях для Middle+ Системного аналитика:
👉 1. Если у нас есть очередь сообщений, зачем нужен брокер?
👉 2. Может ли очередь работать без брокера?
👉 3. Могу ли я использовать брокер без очередей сообщений?
👉 4. Если я использую очередь сообщений, могу ли я гарантировать доставку сообщения?
👉 5. Очередь всегда работает по принципу FIFO (первое пришло - первое вышло из очереди)?
👉 6. Может ли очередь работать с несколькими производителями и потребителями?
Подробная статья:
#hardGetAnalyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1
Делимся впечатлениями о программе «Проектирование архитектуры» от системного аналитика Татьяны. #студентыGetAnalyst
Татьяна решила пройти обучение, так как были пробелы в знаниях и хотелось их заполнить.
В картинках далее слова Татьяны🙌
Татьяна решила пройти обучение, так как были пробелы в знаниях и хотелось их заполнить.
В картинках далее слова Татьяны🙌
❤9