Привет. Я Артём Поляков, системный аналитик, пять лет в профессии. Работаю в «ИТ Контакт» и я решил собрать этот гид для коллег и тех, кто хочет уверенно расти или войти в аналитику. Я собрал в одном месте то, чего часто не хватает на проектах, когда времени мало, а вопросов много. Здесь есть уровни роста от junior до senior, простые примеры, рабочие чек-листы и понятные артефакты. Для наглядности я сделал роадмап на https://roadmap.sh/r/system-analyst-pj7k8, он помогает увидеть, что важно знать сначала, что подтянуть дальше и что добавить по мере опыта.
Что вы получите:
- базу по IT, чтобы говорить с разработчиками на одном языке;
- рабочие техники сбора и фиксации требований;
- UML и BPMN без перегруза, с понятными схемами;
- подходы к интеграциям и API, которые реально работают;
- основы архитектурного мышления и C4 для диалога с архитекторами;
- данные и SQL на уровне, нужном в проектах;
- практику тестирования и критерии качества;
- правила живой документации, которой пользуются, а не откладывают.
Шаг 1. Фундаментальные знания
Прежде чем погружаться в BPMN, API и сложные интеграции, системный аналитик должен выстроить базовое понимание того, как устроен мир IT. Эти знания не делают из него программиста или администратора, но позволяют говорить с разработчиками и архитекторами на одном языке.
1. Основы программирования
Что это?
Базовое знание хотя бы одного языка программирования (чаще всего Python или JavaScript).
Зачем это аналитику?
• Чтобы понимать логику кода и не путаться в терминах «функция», «объект», «массив».
• Чтобы корректно описывать правила трансформации данных.
• Чтобы грамотно составлять псевдокод или SQL-запросы для проверки гипотез.
Как это выглядит на практике?
Допустим, заказчик говорит: «При загрузке файла нужно проверить, чтобы в нём не было дубликатов». Если аналитик не понимает, как устроены циклы, коллекции и фильтрация данных, он опишет требование размыто. А если знаком с кодом — то зафиксирует алгоритм проверки пошагово, так что разработчику не придётся «догадываться».
Подводные камни
• Не нужно пытаться стать разработчиком: глубокий уровень владения кодом — избыточен.
• Главная цель — понимать, как думает программист.
Градация знаний
Junior
• Знает базовые конструкции: переменные, условия, циклы.
• Может прочитать простой код на Python/JavaScript и понять, что он делает.
• Умеет составить псевдокод для бизнес-правила (например, «проверка уникальности значения»).
Middle
• Уверенно читает и объясняет чужой код, включая простые функции и работу с коллекциями.
• Может самостоятельно описать алгоритм трансформации данных (например, нормализация дат, фильтрация по условию).
• Пишет простые SQL-запросы и корректно использует JOIN/группировки.
Senior
• Разбирается в парадигмах (ООП, функциональное программирование) на концептуальном уровне.
• Может предложить оптимальный алгоритм или структуру данных для конкретной задачи.
• Понимает, как ограничения языка или базы данных влияют на реализацию требований.
• Способен в диалоге с разработчиком найти компромисс между «бизнес хочет» и «реализуемо».
Где учить?
• Бесплатные курсы по Python (Stepik, Coursera).
• Книга: "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin (обновленное издание 2025) — базовые принципы кода для аналитиков, без глубокого программирования.
• JavaScript — отличный выбор, если часто работаете с веб-проектами.
2. Компьютерные сети
Что это?
Протоколы (HTTP, TCP/IP, DNS, HTTPS), работа клиент-серверных систем, запросы и ответы.
Зачем это аналитику?
• Чтобы описывать интеграции (какой сервис запрашивает данные, какой отвечает, что будет в случае ошибки).
• Чтобы понимать ограничения (например, почему важен timeout или лимиты API-запросов).
• Чтобы корректно описывать нефункциональные требования (скорость ответа, безопасность).
Как это выглядит на практике?
Когда аналитик документирует интеграцию между интернет-магазином и платёжной системой, он должен понимать, что происходит «под капотом»: отправка HTTP-запроса, получение JSON-ответа, обработка ошибок.
Подводные камни
Многие новички ограничиваются только знанием «есть запрос и ответ». Но аналитик обязан понимать больше: коды ошибок, ретраи, шифрование.
Градация знаний
Junior
• Знает базовую схему работы клиент–серверных приложений.
• Понимает, что такое HTTP-запрос и ответ, зачем нужны методы GET/POST.
• Может объяснить простым языком, что такое DNS и HTTPS.
Middle
• Знает основные протоколы (HTTP, TCP/IP, DNS) и умеет разбирать структуру запроса/ответа.
• Понимает коды ошибок (2xx, 4xx, 5xx) и умеет описывать логику ретраев.
• Может составить схему интеграции с указанием точек отказа и ограничений (таймауты, лимиты запросов).
Senior
• Разбирается в архитектуре распределённых систем и знает, как сетевые ограничения влияют на дизайн решений.
• Может оценить нефункциональные требования (latency, SLA, безопасность передачи данных).
• Умеет предлагать оптимальные способы взаимодействия сервисов (синхронное/асинхронное взаимодействие, очереди, шифрование, кеширование).
• Способен «перевести» сложные технические детали для бизнеса и объяснить риски.
Где учить?
• Книга «Компьютерные сети» Таненбаума, статьи и курсы по API.
• Книга: "Computer Networking: A Top-Down Approach" by James Kurose (8-е издание, 2025) — для понимания сетей и протоколов.
• Практика с Postman и Wireshark.
3. Основы операционных систем
Что это?
Принципы работы Linux и Windows Server: файловая система, процессы, права доступа, порты.
Зачем это аналитику?
• Чтобы описывать системные требования: где будут храниться данные, какие права нужны, какой сервер использовать.
• Чтобы понимать ограничения интеграции с внешними системами.
• Чтобы не путаться в терминах «сервис», «демон», «процесс».
Как это выглядит на практике?
Когда клиент хочет интеграцию с бухгалтерской системой, аналитик должен знать, где будет стоять сервис — в Linux или Windows, и какие ограничения это накладывает.
Подводные камни
Не нужно становиться системным администратором. Важно понимать концепции, а не команды наизусть.
Где учить?
• Практика: развернуть виртуальную машину с Ubuntu.
• Книги: «Современные операционные системы» (Таненбаум).
• Онлайн-статьи и курсы по API и протоколам.
4. Git и системы контроля версий
Что это?
Инструменты для хранения и версионирования кода и документации.
Зачем это аналитику?
• Чтобы работать вместе с разработчиками и хранить свои артефакты рядом с кодом.
• Чтобы документировать изменения требований (особенно в agile).
• Чтобы уметь читать историю изменений.
Как это выглядит на практике?
Например, аналитик хранит схему BPMN в Git-репозитории. Когда нужно откатить к предыдущей версии — это делается одной командой.
Подводные камни
• Ошибка новичков — думать, что Git нужен только разработчикам. На самом деле он помогает и аналитикам.
Градация знаний
Junior
• Умеет клонировать репозиторий и обновлять локальную копию (pull).
• Может закоммитить и отправить изменения (commit, push).
• Использует визуальные клиенты (Sourcetree, GitKraken) для простых задач.
Middle
• Работает с ветками (branch, merge), понимает Git Flow или trunk-based development.
• Может разрешать простые конфликты слияния.
• Умеет смотреть историю изменений (log, blame) и откатывать файлы к нужной версии.
• Хранит артефакты аналитики (схемы, документацию, SQL) в репозитории рядом с кодом.
Senior
• Уверенно работает через командную строку без GUI.
• Понимает, как устроен внутренний механизм Git (коммиты как snapshot, дерево, хеши).
• Может настраивать рабочие процессы (pull requests, code review, CI/CD интеграции).
Где учить?
• try.github.io — интерактивные уроки.
• GitKraken, Sourcetree — визуальные клиенты для старта.
• Онлайн-курс: "Git and GitHub for Beginners" на Udemy (обновлен в 2025) — практические уроки по Git
Итог шага 1
Фундаментальные знания — это база, без которой системный аналитик рискует превратиться в «писателя текстов», которого разработчики не воспринимают всерьёз. Освоив программирование, сети, ОС и Git на базовом уровне, вы сможете уверенно разговаривать с технарями, задавать правильные вопросы и формулировать требования так, чтобы они были понятны всем.
Шаг 2. Сбор и формализация требований
Многие думают, что работа аналитика — это «пойти к заказчику, спросить, что он хочет, и записать в документ». На практике всё сложнее. Заказчик часто сам не знает, чего именно он хочет. Его требования могут противоречить друг другу, меняться каждую неделю, быть слишком размытыми или, наоборот, слишком детальными.
Поэтому одна из ключевых задач системного аналитика — это грамотно собрать требования, структурировать их и превратить в артефакты, понятные как бизнесу, так и разработке.
1. Интервью и воркшопы
Что это?
Методы взаимодействия с заказчиком и пользователями для извлечения информации о том, как должна работать система.
Зачем это аналитику?
• Чтобы выявить истинные потребности, а не только то, что «на поверхности».
• Чтобы зафиксировать требования разных стейкхолдеров (и увидеть, где они противоречат друг другу).
• Чтобы построить доверие: заказчик должен чувствовать, что его слышат.
Как это выглядит на практике?
• Индивидуальное интервью: вы задаёте вопросы конкретному пользователю (например, бухгалтеру), чтобы понять, как он работает с документами.
• Групповой воркшоп: собираете несколько участников (например, юриста, бухгалтера и менеджера), обсуждаете процесс «от А до Я» и фиксируете разрывы.
Подводные камни
• Новички часто ограничиваются вопросом «Что вам нужно?». Но правильный подход — задавать поведенческие вопросы («А как вы действуете, если…?»).
• Если в воркшопе нет модерации, он может превратиться в спор между отделами.
Градация знаний
Junior
• Знает базовые методы: интервью, анкетирование, наблюдение.
• Умеет подготовить список вопросов для интервью.
• Фиксирует ответы дословно, без интерпретации.
• Может описать простой «As Is»-процесс.
Middle
• Понимает разницу между функциональными и нефункциональными требованиями.
• Умеет модераторить воркшопы и структурировать обсуждения.
• Применяет техники уточнения («5 почему», user story mapping).
• Фиксирует результаты в понятных артефактах (диаграммы, user stories, backlog).
Senior
• Строит системное взаимодействие со стейкхолдерами (матрица заинтересованных сторон, управление ожиданиями).
• Умеет выявлять скрытые и противоречивые требования.
• Использует продвинутые техники фасилитации (design thinking-сессии, event storming).
• Обучает команду методам сбора требований и задаёт стандарты.
Где учить?
• Книга «Interviewing Users» (Steve Portigal).
• Практика: провести интервью с коллегой и записать «As Is»-процесс.
• Книга: "Interviewing Users: How to Uncover Compelling Insights" by Steve Portigal (2-е издание, 2025).
• Онлайн-курс: "Business Analysis Fundamentals" на Udemy (2025 версия) — сбор требований и приоритизация.
2. Техники сбора требований
Что это?
Структурированные методы фиксации требований: Use Cases, User Stories, Event Storming и др.
Зачем это аналитику?
• Чтобы переводить «разговорный язык» в формализованный.
• Чтобы избежать двусмысленностей.
• Чтобы разные участники проекта одинаково понимали требование.
Как это выглядит на практике?
• User Story: «Как [роль], я хочу [функцию], чтобы [ценность]». Например: «Как покупатель, я хочу видеть историю заказов, чтобы быстро повторять покупки».
• Use Case: описание сценария с шагами и альтернативами (подходит для сложных процессов, например «Возврат товара»).
Подводные камни
• User Stories легко писать, но сложно делать их достаточно конкретными. Ошибка — оставить их слишком абстрактными.
• Use Cases дают детализацию, но могут перегрузить документацию.
Градация знаний
Junior
• Знает базовые форматы: User Story, Use Case.
• Может описать простой сценарий в виде User Story («Как пользователь, я хочу…»).
• Понимает, зачем нужны артефакты и чем они отличаются от «разговорных» требований.
Middle
• Уверенно использует несколько техник (User Stories, Use Cases, Event Storming).
• Умеет балансировать детализацию: не слишком абстрактно и не слишком перегружено.
• Применяет техники на практике для разных типов требований (бизнес-процессы, интерфейсы, интеграции).
• Может связать требования с тестами или acceptance criteria.
Senior
• Выбирает оптимальную технику под задачу и уровень зрелости команды.
• Умеет комбинировать подходы (например, начать с Event Storming, затем оформить Use Cases).
• Настраивает стандарты документирования требований внутри команды/организации.
• Обучает коллег и заказчиков правильному использованию техник, чтобы повысить прозрачность и согласованность.
Где учить?
• «Specification by Example» (Gojko Adzic).
• Практика: описать процесс «Оформление кредита» двумя способами: User Story и Use Case.
• Ресурс: "Understanding Systems Analysis" на Alison — бесплатный курс по требованиям.
3. Фиксация ограничений и нефункциональных требований
Что это?
Не только «что система должна делать», но и как она должна это делать: скорость, безопасность, доступность, интеграции, ограничения.
Зачем это аналитику?
• Чтобы избежать ситуации «система работает, но не так, как ожидали».
• Чтобы учесть реалии бизнеса (например, интернет-магазину важно, чтобы сайт выдерживал 5000 пользователей одновременно).
Как это выглядит на практике?
• Функциональное требование: «Система должна отправлять SMS-подтверждение».
• Нефункциональное: «Время доставки SMS не должно превышать 30 секунд».
Подводные камни
Частая ошибка: игнорировать нефункциональные требования. Но именно они часто «убивают» проект (например, приложение открывается слишком медленно, и пользователи уходят).
Градация знаний
Junior
• Отличает функциональные требования от нефункциональных.
• Может зафиксировать простые ограничения (например, «пароль не короче 8 символов»).
• Умеет включать базовые показатели производительности и безопасности по подсказке разработчиков или бизнеса.
Middle
• Знает основные категории нефункциональных требований (производительность, безопасность, доступность, масштабируемость, совместимость).
• Умеет переводить бизнес-ожидания в измеримые метрики (например, «ответ API ≤ 200 мс»).
• Фиксирует ограничения в структурированном виде (таблицы, чек-листы, отдельные разделы спецификации).
• Понимает, как нефункциональные требования влияют на архитектурные решения.
Senior
• Формирует полный набор нефункциональных требований с учётом стандартов (например, ISO/IEC 25010).
• Может выявить скрытые ограничения бизнеса (SLA, регуляторные требования, compliance).
• Умеет расставлять приоритеты и балансировать «стоимость vs качество» (например, нужно ли обеспечивать 99.999% доступности).
• Настраивает практику фиксации нефункциональных требований в команде и обучает этому других аналитиков.
Где учить?
• Стандарты ISO/IEC 25010 (качество ПО).
• Практика: составить таблицу функциональных и нефункциональных требований для онлайн-банка.
4. Приоритизация требований
Что это?
Методы, которые помогают определить, какие требования реализовывать в первую очередь.
Зачем это аналитику?
• Чтобы заказчик и команда одинаково понимали, что критично, а что можно отложить.
• Чтобы правильно планировать спринты в Agile.
Как это выглядит на практике?
1. MoSCoW: классификация требований на четыре группы:
• Must have — обязательные для реализации.
• Should have — желательные, но не критичные.
• Could have — дополнительные, «хорошо бы иметь».
• Won’t have — не будут реализованы в текущей итерации.
2. Kano-модель: разделение требований по влиянию на удовлетворенность пользователей:
• Базовые — если отсутствуют, вызывают недовольство;
• Ожидаемые — выполняются по стандарту, повышают удовлетворенность;
• «Вау-функции» — неожиданные фишки, которые сильно радуют пользователей.
Подводные камни:
• Если приоритизацию проводит только заказчик, есть риск, что все требования будут считаться «срочными».
• Роль аналитика — помогать оценивать требования с точки зрения ценности для бизнеса и стоимости реализации, чтобы сформировать оптимальный и сбалансированный backlog.
Градация знаний
Junior
• Знает простейшие методы приоритизации (MoSCoW).
• Может классифицировать требования по категориям «обязательно/желательно/можно отложить».
• Фиксирует результаты приоритизации в backlog или таблице.
Middle
• Умеет применять разные техники (MoSCoW, Kano, Value vs Effort, WSJF).
• Понимает, что приоритизация — это не только «что важно заказчику», но и баланс ценности и трудозатрат.
• Умеет фасилитировать сессию приоритизации с несколькими стейкхолдерами.
• Документирует аргументацию выбора приоритетов, чтобы снизить конфликтность.
Senior
• Строит системный процесс приоритизации в команде/организации.
• Учитывает стратегические факторы: ROI, риски, технический долг, регуляторные требования.
• Может выстраивать диалог между бизнесом и разработкой для поиска баланса «ценность vs сложность реализации».
• Обучает продуктовую команду методам приоритизации и помогает внедрять лучшие практики.
Где учить?
• Agile Business Consortium — описание метода MoSCoW.
• Практика: взять список требований к CRM и разложить их по MoSCoW.
5. Артефакты системного аналитика
Что это?
После этапа сбора требований у системного аналитика формируется набор ключевых документов и схем, которые служат основой для дальнейшей разработки и коммуникации с командой:
• Видение продукта (Product Vision): краткое и понятное описание цели и ценности продукта для бизнеса и пользователей.
• Карта пользовательских историй (User Story Map): визуальная схема, показывающая функциональность продукта с точки зрения пользователя и взаимосвязь между историями.
• Диаграммы вариантов использования (Use Case Diagrams): графическое отображение акторов, системных функций и их взаимодействий.
• Таблицы бизнес-правил: формализованное описание правил и условий, регулирующих работу системы.
• Документирование требований в Confluence или Jira: хранение всех требований, user stories и связанных материалов для удобного доступа и отслеживания изменений.
Эти артефакты обеспечивают ясность, согласованность и прозрачность на всех этапах проекта, позволяя команде разработки и стейкхолдерам эффективно взаимодействовать.
Зачем это аналитику?
• Чтобы зафиксировать «единый источник правды» для команды.
• Чтобы можно было проверить полноту требований.
• Чтобы обеспечить прослеживаемость: от требования до релиза.
Как это выглядит на практике?
Например, в Confluence создаётся страница «Регистрация пользователя»:
• описание цели;
• сценарии;
• ошибки;
• ссылки на BPMN-диаграмму и API-документацию.
Подводные камни
• Чрезмерная детализация = никто не читает.
• Слишком поверхностная документация = разработчики додумывают сами.
Градация знаний
Junior
• Умеет фиксировать требования в простом текстовом виде (таблица, Confluence-страница).
• Создаёт базовые артефакты: список требований, простая схема или диаграмма.
• Работает по шаблонам, предоставленным командой или ментором.
Middle
• Уверенно использует разные типы артефактов (User Story Map, Use Case Diagram, бизнес-правила).
• Понимает, какой артефакт выбрать под конкретную задачу.
• Обеспечивает прослеживаемость: связывает требования, сценарии и тесты.
• Умеет поддерживать документацию актуальной и понятной для разных стейкхолдеров.
Senior
• Формирует систему артефактов для проекта или команды (структура в Confluence/Jira, стандарты ведения).
• Балансирует уровень детализации: делает артефакты понятными, но без перегрузки.
• Настраивает практики совместной работы над документацией (review, versioning).
• Обучает коллег работе с артефактами и повышает культуру ведения документации в организации.
Итог шага 2
Сбор и формализация требований — это сердце работы системного аналитика. Ошибки на этом этапе обходятся особенно дорого: если аналитик недопонял заказчика или плохо зафиксировал требования, разработчики создадут не то, что нужно, и исправления будут стоить в разы дороже.
Хороший аналитик — это не тот, кто просто «записал со слов», а тот, кто умеет:
• вытаскивать скрытые потребности;
• фиксировать их в понятной форме;
• выявлять противоречия;
• приоритизировать, чтобы проект двигался по ценности.
Шаг 3. UML и BPMN — язык визуализации
Когда аналитик общается с бизнесом и разработчиками, почти всегда возникает проблема: слова все понимают по-разному. То, что для одного «быстро», для другого — «за пять секунд», а для третьего — «за один клик».
Здесь в игру вступает визуализация. Диаграммы UML и BPMN — это универсальные языки, которые позволяют зафиксировать требования в наглядной форме. Они убирают двусмысленность, помогают согласовать процессы и дают общий язык для общения разных ролей.
1. Зачем аналитику UML и BPMN?
• Для бизнеса: диаграммы позволяют показать процесс без погружения в код. Руководителю проще согласовать «картинку», чем читать 10 страниц текста.
• Для разработчиков: схемы снимают вопросы. Не нужно гадать, кто инициирует процесс, что происходит при ошибке, какие данные хранятся.
• Для тестировщиков: диаграммы помогают строить тест-кейсы и покрывать альтернативные сценарии.
По сути, визуализация — это «страховка» аналитика. Если вы описали процесс словами, заказчик может сказать: «Я думал, будет иначе». А если он видел диаграмму и согласовал её — спорить гораздо сложнее.
2. UML: универсальный язык моделирования
UML (Unified Modeling Language) — это набор стандартных диаграмм, которые позволяют описывать систему с разных сторон.
Основные виды диаграмм для аналитика:
1. Use Case Diagram (диаграмма вариантов использования)
• Показывает, какие роли (актеры) взаимодействуют с системой и какие сценарии доступны.
• Пример: в интернет-магазине акторы «Покупатель» и «Администратор»; сценарии — «Оформить заказ», «Просмотреть историю заказов», «Добавить товар».
• Зачем: помогает на старте показать границы системы и участников.
2. Class Diagram (диаграмма классов)
Описывает структуру данных: какие сущности есть в системе и как они связаны.
Пример: сущности «Заказ», «Покупатель», «Товар», связь «Покупатель делает Заказ».
Зачем: полезно для согласования с разработчиками и базой данных.
3. Sequence Diagram (диаграмма последовательностей)
Показывает, как разные компоненты или пользователи взаимодействуют во времени.
Пример: «Покупатель → Сайт → Платёжный шлюз → SMS-сервис».
Зачем: незаменима для интеграций и сложных процессов (например, авторизация через внешний сервис).
4. Activity Diagram (диаграмма активностей)
Иллюстрирует логику выполнения процесса: ветвления, циклы, условия.
Пример: «Регистрация пользователя»: проверка почты → отправка подтверждения → активация аккаунта.
Зачем: удобно показывать альтернативные сценарии («что, если пользователь не подтвердил e-mail? »).
Подводные камни UML
• Можно «утонуть» в детализации. Новички пытаются описывать абсолютно всё, и диаграмма превращается в кашу.
• Не каждая диаграмма нужна. На реальных проектах обычно хватает 2–3 типов.
• Бизнесу сложнее читать UML, чем BPMN — поэтому для заказчиков лучше использовать BPMN, а UML оставлять для команды.
Градация знаний
Junior
• Знает базовые нотации и понимает назначение основных диаграмм (Use Case, Activity).
• Может построить простую диаграмму вариантов использования или активностей для демонстрации сценариев.
• Использует готовые шаблоны инструментов (Draw.io, Lucidchart, PlantUML).
Middle
• Уверенно владеет несколькими типами UML-диаграмм (Use Case, Class, Sequence, Activity).
• Понимает, в каких случаях применять каждую диаграмму.
• Может согласовать диаграмму классов с моделью данных и использовать диаграмму последовательностей для интеграций.
• Умеет документировать альтернативные сценарии и исключения.
Senior
• Формирует единый подход к использованию UML в команде (правила детализации, стандарты оформления).
• Балансирует уровень сложности диаграмм под разные аудитории (для бизнеса упрощённые схемы, для команды — детализированные).
• Умеет комбинировать UML с другими нотациями (BPMN, ERD) для создания целостной модели системы.
• Наставляет коллег в выборе подходящих диаграмм и обучает эффективному использованию UML.
Где учить?
• Книга: "UML Distilled: A Brief Guide to the Standard Object Modeling Language" by Martin Fowler (4-е издание, 2025).
• Онлайн-курс: "UML Diagram Courses" на Coursera (2025) — создание диаграмм. Ссылка: Coursera.
3. BPMN: язык бизнес-процессов
BPMN (Business Process Model and Notation) — это стандарт для описания бизнес-процессов. Его плюс в том, что он легко читается и бизнесом, и IT.
Основные элементы BPMN:
• События (кружки) — начало, конец, исключения.
• Задачи (прямоугольники) — действия в процессе.
• Шлюзы (ромбы) — развилки по условиям («Да/Нет»).
• Пулы и дорожки — разделение участников процесса (например, клиент, менеджер, система).
Пример применения
Процесс «Оформление кредита»:
1. Клиент подаёт заявку.
2. Система проверяет кредитную историю.
3. Если результат положительный — менеджер одобряет.
4. Если отрицательный — клиент получает отказ.
В BPMN это сразу видно: стрелки, развилки, роли. Никаких длинных текстов.
Зачем BPMN аналитику
• Для бизнеса: показывает реальный процесс «как есть» (As Is) и помогает построить «как должно быть» (To Be).
• Для команды: фиксирует, кто отвечает за каждый шаг.
• Для интеграций: наглядно показывает, где задействованы внешние системы.
Подводные камни BPMN
• Опасность «сделать красиво, но непонятно». Лишние элементы перегружают схему.
• Нужно помнить: BPMN — это не «искусство ради искусства». Его задача — упростить понимание процесса, а не усложнить.
Практика для аналитика
• Нарисуйте BPMN-процесс «Заказ такси».
• Сделайте UML Use Case для «Онлайн-банка».
• Опишите процесс «Регистрация пользователя» через Activity Diagram.
Лучше всего отрабатывать это на реальных сценариях — так схемы будут не формальными, а живыми.
Градация знаний
Junior
• Знает основные элементы: события, задачи, шлюзы, пулы/дорожки.
• Может построить простой процесс «As Is» без сложных ветвлений.
• Использует BPMN как инструмент визуализации для бизнеса и команды.
Middle
• Уверенно моделирует процессы «As Is» и «To Be», включая развилки, исключения, параллельные ветви.
• Умеет фиксировать роли участников через пулы и дорожки.
• Применяет BPMN для описания интеграций и автоматизации.
• Следит за читаемостью схем: балансирует детализацию и простоту.
Senior
• Формирует стандарты моделирования процессов для команды или организации.
• Умеет описывать сложные процессы с несколькими системами, исключениями и нестандартными сценариями.
• Комбинирует BPMN с другими нотациями (UML, C4) для комплексного анализа.
• Обучает коллег и заказчиков понимать и использовать BPMN как инструмент коммуникации.
Где учить?
• BPMN Method and Style (Bruce Silver).
• Онлайн-сервисы: draw.io, Lucidchart, Bizagi Modeler.
• Книга: "BPMN Method and Style" by Bruce Silver
• Практика: сравнивать As Is и To Be процессы в реальном проекте.
Итог шага 3
UML и BPMN — это не просто «рисование схемочек». Это язык общения, который позволяет аналитикам, бизнесу и разработчикам видеть одно и то же.
Хороший аналитик:
• умеет выбрать правильный тип диаграммы под задачу;
• не перегружает схему лишними деталями;
• использует визуализацию как инструмент согласования.
Запомните: одна схема может заменить 10 страниц текста.
Шаг 4. Методологии разработки
Методологии — это не «сухая теория из книжек», а правила игры, по которым работает проект. Для системного аналитика понимание этих правил критически важно: именно они определяют, как будут собираться требования, кто принимает решения, как меняются приоритеты и когда работа считается завершённой.
Многие начинающие аналитики думают: «Ну это же менеджерская история, мне достаточно просто знать термины». Это ошибка. Если вы не понимаете методологии, вы не сможете встроиться в процесс, будете собирать требования не тем способом, в не тот момент и не в том формате.
1. Waterfall (каскадная модель)
Что это?
Классический линейный подход: сначала проектирование, потом разработка, потом тестирование, потом запуск. Всё делается этапами, и вернуться назад почти невозможно.
Где применяется?
• Государственные и тендерные проекты.
• Крупные интеграции, где всё жёстко регламентировано.
• Там, где изменения стоят дорого (например, встраиваемое ПО, банковские системы).
Подводные камни
• Если на старте что-то упущено — в конце проекта это станет катастрофой.
• Заказчику сложно сформулировать всё заранее, но методология требует именно этого.
Роль аналитика
• Junior: фиксирует требования в спецификациях, следует этапам проекта, понимает, что изменения на поздних стадиях трудны.
• Middle: собирает полный набор требований, связывает их с архитектурой и тестированием, прогнозирует риски пропущенных требований.
• Senior: формирует стандарты документирования и процессов, обеспечивает полноту требований, обучает команду внимательности к деталям.
Вывод: Waterfall требует от аналитика высокой внимательности и способности «сразу докопаться до сути».
2. Agile (гибкая разработка)
Что это?
Agile — это целая философия, а не одна методология. Суть: работа делается короткими итерациями, продукт показывается заказчику по частям, приоритеты могут меняться.
Популярные фреймворки:
1. Scrum
• Работа разбита на спринты (обычно 2 недели).
• Есть Product Owner, Scrum Master и команда.
• Результат каждого спринта — готовый инкремент продукта.
Аналитику важно: уметь дробить требования на User Stories и поддерживать Product Backlog.
2. Kanban
• Непрерывный поток задач.
• Визуализация на доске (To Do → In Progress → Done).
• Нет фиксированных спринтов, работа движется постоянно.
Аналитику важно: уметь правильно декомпозировать задачи и управлять потоком.
3. ScrumBan
• Гибрид Scrum и Kanban.
• Часто используется на переходе от хаотичного к более структурному процессу.
Где применяется?
• Стартапы.
• Продуктовые команды.
• Проекты, где важна скорость и можно менять приоритеты «на лету».
Роль аналитика
• Junior: понимает спринты, участвует в планировании и ретроспективах, умеет оформлять требования как user stories.
• Middle: фасилитирует backlog refinement, оценивает user stories с точки зрения ценности и трудозатрат, поддерживает актуальность требований.
• Senior: настраивает процесс работы команды с backlog, управляет приоритетами на уровне продукта, обучает коллег принципам Agile, помогает заказчику формулировать цели.
Подводные камни
• Требования постоянно меняются — аналитик должен быть гибким.
• Есть риск потерять общую архитектурную картину, если сосредоточиться только на спринтах.
Вывод: Agile требует от аналитика умения быстро перестраиваться и мыслить итерациями.
3. SAFe (Scaled Agile Framework)
Что это?
Методология для больших организаций, где работает несколько команд одновременно. SAFe помогает синхронизировать их работу и при этом сохранить гибкость Agile.
Где применяется?
• Крупные корпорации.
• Банки, телеком, госкомпании.
• Там, где несколько команд делают разные части одного продукта.
Роль аналитика
• Работать не только с командой, но и на уровне программы/портфеля.
• Следить, чтобы локальные решения не ломали общую стратегию.
• Поддерживать документацию на разных уровнях (от фич до эпиков).
Подводные камни
• Высокая бюрократия.
• Много уровней согласования.
Вывод: аналитик в SAFe должен быть «связующим звеном» не только между бизнесом и командой, но и между командами.
Какую методологию нужно знать аналитику
• Waterfall — чтобы понимать, как работают госзаказы и большие интеграционные проекты.
• Agile (Scrum, Kanban) — must-have для современного аналитика.
• SAFe — полезно для тех, кто идёт в крупные корпорации.
Ошибки аналитика в работе с методологиями
• Пытаться «придумать свой Agile» без понимания основ.
• Игнорировать методологию («я просто пишу требования»).
• Недооценивать документацию: даже в Agile её никто не отменял.
• Писать требования в неподходящем формате (например, 50-страничный документ в Scrum-среде).
Где учить?
• Agile Manifesto (agilemanifesto.org).
• Книги: «Scrum. Революционный метод управления проектами» (Джефф Сазерленд).
• «Kanban. Successful Evolutionary Change for Your Technology Business» (Дэвид Андерсон).
• SAFe Training (ScaledAgile).
• Практика: участие в проекте, где методология реально применяется.
Итог шага 4
Методология определяет, как именно будет построена работа аналитика.
• В Waterfall вы архитектор, который на старте должен всё продумать.
• В Agile вы исследователь, который постоянно уточняет и дробит требования.
• В SAFe вы связующее звено между командами и бизнесом.
Запомните: аналитик не существует в вакууме. Его работа напрямую зависит от правил игры в команде, а правила эти задаёт методология.
Шаг 5. API и интеграции
1. Что такое API и почему это важно аналитику
API (Application Programming Interface) — это способ, с помощью которого разные системы общаются между собой.
В бизнесе почти нет изолированных решений: CRM нужно интегрировать с телефонией, интернет-магазин — с платёжными сервисами, банковская система — с бюро кредитных историй.
Аналитик здесь играет ключевую роль:
• собирает требования к интеграции;
• описывает, какие данные и в каком формате должны передаваться;
• проверяет, что API соответствует нужному процессу;
• фиксирует ограничения (например, лимиты по запросам или время отклика).
Ошибка многих новичков: считать API чисто «разработческой темой». На самом деле именно аналитик должен заранее понять, получится ли связать две системы без костылей.
2. REST API
Что это?
REST — самый популярный стиль проектирования API. Использует протокол HTTP и стандартные методы:
• GET (получить данные),
• POST (создать),
• PUT/PATCH (обновить),
• DELETE (удалить).
Зачем аналитику?
• Уметь читать документацию (Swagger, OpenAPI).
• Понимать структуру URL и параметры запросов.
• Знать, что REST обычно возвращает данные в формате JSON.
Градация знаний
Junior
• Понимает основные методы HTTP: GET, POST, PUT/PATCH, DELETE.
• Может прочитать простую документацию API (Swagger/OpenAPI) и понять, какие данные возвращаются.
• Умеет отправить простой запрос через Postman и посмотреть ответ в JSON.
Middle
• Уверенно разбирает структуру URL, query-параметры и тело запроса/ответа.
• Понимает типичные коды статуса HTTP и их значение (2xx, 4xx, 5xx).
• Может описать интеграцию в ТЗ с указанием структуры данных и формата.
• Применяет REST для анализа существующих API и проверки гипотез.
Senior
• Понимает архитектурные ограничения REST (stateless, кэширование, версии API).
• Способен предложить оптимальный формат данных для требований и согласовать с разработчиками.
• Умеет работать с несколькими сервисами, комбинируя запросы и описывая сложные сценарии интеграции.
• Наставляет команду аналитиков по использованию REST API и формализации требований.
Практика
• Взять открытый REST API (например, GitHub API).
• Отправить запрос в Postman: GET https://api.github.com/users/{username}.
• Разобрать структуру ответа.
Важно: в ТЗ аналитик должен указывать какие данные и в каком формате нужны, а не только писать «сделать интеграцию».
3. SOAP API
Что это?
Более «старый» и формальный протокол. Использует XML, жёсткие схемы (WSDL).
SOAP до сих пор распространён в банковской сфере, госуслугах, больших корпорациях.
Зачем аналитику?
• Понимать разницу: SOAP гораздо строже, чем REST.
• Уметь читать WSDL-файл и видеть доступные операции.
• Знать, что SOAP требует строгой валидации сообщений.
Градация знаний
Junior
• Понимает базовые отличия SOAP от REST.
• Знает, что SOAP использует XML и WSDL.
• Может прочитать простую WSDL-документацию и увидеть доступные операции.
Middle
• Уверенно разбирает структуру SOAP-сообщений и XML-схем.
• Понимает валидацию сообщений и основные ограничения SOAP.
• Может описать интеграцию через SOAP в ТЗ, указывая операции и структуру данных.
• Понимает, как обработать коды ошибок и исключения SOAP.
Senior
• Понимает архитектурные особенности SOAP и ограничения для крупных интеграций.
• Способен проектировать сложные сценарии обмена данными через SOAP с несколькими сервисами.
• Наставляет команду по работе с SOAP, помогает правильно формализовать требования и планировать сроки интеграций.
• Может сравнивать REST и SOAP и давать рекомендации, какой подход выбрать для проекта.
Пример
Если в REST мы пишем простой запрос GET /users/123, то в SOAP придётся формировать полноценный XML с тегами и пространствами имён.
Подводный камень: если вы недооцените сложность SOAP, сроки интеграции «улетят в космос».
4. GraphQL
Что это?
Современный подход, придуманный в Facebook. Позволяет клиенту самому выбирать, какие данные нужны.
Чем отличается от REST
• В REST есть фиксированные эндпоинты (/users, /orders).
• В GraphQL один эндпоинт, но сложные запросы.
• Данные приходят строго в том виде, в каком клиент запросил.
Зачем аналитику?
• Уметь описывать сценарии: «нужно получить список заказов с деталями пользователя и адреса».
• Понимать плюсы (гибкость, меньше лишних данных) и минусы (нагрузка на сервер, сложность запросов).
Градация знаний
Junior
• Понимает базовые отличия GraphQL от REST: один эндпоинт, запрос по нужным полям.
• Может составить простой запрос в Playground и получить данные.
• Знает, что GraphQL возвращает данные строго по запросу клиента.
Middle
• Уверенно описывает сложные запросы, включая вложенные объекты и фильтры.
• Понимает плюсы и минусы GraphQL (гибкость vs нагрузка на сервер).
• Может формализовать сценарии интеграции в ТЗ и проверять корректность запросов.
• Понимает, как использовать фрагменты и мутации для обновления данных.
Senior
• Способен проектировать интеграцию через GraphQL с несколькими сервисами и сложными связями.
• Наставляет команду аналитиков по описанию требований для GraphQL.
• Может выбирать между REST, SOAP и GraphQL для проекта, аргументируя выбор с точки зрения производительности и удобства.
• Понимает схемы и возможности оптимизации запросов (batching, caching, pagination).
Практика
Попробовать Playground (есть у GitHub API) и составить запрос, который вытягивает сразу данные о репозитории и авторе.
Ошибка: пытаться описывать GraphQL интеграцию «как REST». Это другая парадигма.
5. API Gateway
Что это?
API Gateway — это «шлюз» для всех API компании. Он управляет доступом, безопасностью, логированием, лимитами и маршрутизацией.
Зачем аналитику?
• Понимать, что API напрямую редко «отдаются наружу».
• Уметь описывать требования к безопасности (OAuth, JWT-токены).
• Знать, что Gateway может ограничивать количество запросов (rate limiting).
Пример из практики: если интеграция ломается при нагрузке, возможно, не API проблема, а лимиты на уровне Gateway.
Градация знаний
Junior
• Понимает, что API редко открыты напрямую и проходят через шлюз.
• Знает базовые функции: маршрутизация, аутентификация, базовое логирование.
• Может читать документацию Gateway и понимать, какие ограничения действуют на интеграцию.
Middle
• Уверенно описывает требования к безопасности (OAuth, JWT) и лимитам (rate limiting).
• Понимает влияние Gateway на производительность и доступность API.
• Может участвовать в анализе проблем интеграции и проверять настройки шлюза.
• Может формализовать сценарии использования Gateway в ТЗ.
Senior
• Способен проектировать интеграции через API Gateway с учетом масштабируемости и отказоустойчивости.
• Наставляет команду аналитиков по корректному описанию требований к безопасности и лимитам.
• Понимает внутреннюю архитектуру Gateway и может прогнозировать влияние изменений на бизнес-процессы.
• Умеет выстраивать рекомендации по оптимизации работы API через Gateway.
6. Основные сценарии интеграций
Аналитик должен уметь классифицировать интеграции:
1. Синхронные (онлайн) — ответ приходит сразу (например, проверка платежа). Важно: время отклика, SLA, ошибки.
2. Асинхронные (через очередь или шину) — ответ приходит позже (например, обработка больших данных). Важно: гарантии доставки сообщений, идемпотентность.
3. Файловый обмен (batch) — периодическая выгрузка CSV/XML. До сих пор часто встречается в бухгалтерии, банках.
Аналитик должен чётко фиксировать: какой именно тип интеграции нужен, потому что это напрямую влияет на архитектуру и сроки.
Подводные камни в работе с API
• Игнорирование ограничений (лимиты, таймауты, SLA).
• Слишком общая постановка задачи: «сделать интеграцию».
• Несогласованность форматов (JSON vs XML, разные кодировки).
• Ошибки в безопасности (например, хранение паролей вместо токенов).
• Недооценка тестирования: интеграции ломаются чаще всего именно в стыках.
Где учить?
• Документация: Swagger/OpenAPI, GraphQL.org.
• Инструменты: Postman, SoapUI, Insomnia.
• Практика: написать простую интеграцию между двумя сервисами (например, Google Sheets API + Telegram Bot API).
• Книга: "Designing Data-Intensive Applications" by Martin Kleppmann (2-е издание, 2025) — для API и интеграций. Купить: Amazon.
• Онлайн-курс: "System Design Courses" на GeeksforGeeks (топ-10 курсов 2025) — фокус на API. Ссылка: GeeksforGeeks.
• Ресурс: Postman Learning Center — бесплатные туториалы по API (обновлены 2025).
Итог шага 5
API — это «кровеносная система» любой современной IT-среды.
Задача аналитика — понимать, как устроены эти потоки данных, и уметь их описывать так, чтобы разработчики сразу могли реализовать интеграцию.
• REST — базовый must-have.
• SOAP — по-прежнему нужен в Enterprise и госпроектах.
• GraphQL — тренд, стоит знать.
• API Gateway — реальность крупных систем.
• Типы интеграций — определяют архитектуру проекта.
Запомните: плохое описание API-интеграции от аналитика может убить проект на этапе запуска.
Шаг 6. Архитектурные подходы и C4-модель
1. Зачем аналитику архитектурное мышление
Системный аналитик — это не архитектор. Его задача не в том, чтобы проектировать базы данных или микросервисы, а в том, чтобы:
• понимать, как устроены системы (монолит, микросервисы, распределённые решения);
• разговаривать с архитектором на одном языке;
• помогать бизнесу осознать последствия решений (например, что интеграция в реальном времени невозможна с текущей архитектурой).
2. Базовые архитектурные стили
Аналитику достаточно знать ключевые подходы:
• Монолит — единое приложение, простое, но плохо масштабируется.
• Сервис-ориентированная архитектура (SOA) — модули-сервисы, общающиеся через шину.
• Микросервисы — независимые сервисы, взаимодействующие по API.
• Событийная архитектура — данные распространяются через события и очереди (Kafka, RabbitMQ).
Зачем это знать?
• Чтобы понимать, какие ограничения накладывает архитектура.
• Чтобы верно формулировать требования: «нужна асинхронная интеграция» vs «хотим мгновенный отклик».
• Чтобы уметь объяснять бизнесу, почему решение «сделать по-быстрому» может привести к техническому долгу.
Градация знаний
Junior
• Знает основные архитектурные стили: монолит, SOA, микросервисы, событийная архитектура.
• Понимает базовые ограничения каждого стиля (масштабируемость, сложность поддержки).
• Может читать документацию и понимать, какой стиль использован в проекте.
Middle
• Уверенно объясняет, как архитектура влияет на требования и интеграции.
• Понимает различия между синхронными и асинхронными взаимодействиями.
• Может описывать требования, учитывая ограничения архитектуры (например, latency, transactional boundaries).
• Участвует в обсуждениях выбора архитектурных подходов с командой разработки.
Senior
• Способен оценивать влияние архитектурного стиля на бизнес-потребности и технический долг.
• Наставляет команду по учету архитектурных ограничений при формулировании требований.
• Может проектировать требования и интеграции с учетом масштабируемости, отказоустойчивости и асинхронности.
• Умеет консультировать бизнес и стейкхолдеров по оптимальному архитектурному подходу для конкретного проекта.
3. C4-модель как инструмент аналитика
C4-модель — это метод визуализации архитектуры, придуманный Саймоном Брауном. Она помогает показать систему на четырёх уровнях детализации.
Уровень 1. Контекст (System Context Diagram)
• Показывает систему и её окружение: пользователи, внешние сервисы, интеграции.
• Задача аналитика: показать бизнесу, с кем и чем система взаимодействует.
Пример: интернет-магазин. На контекстной диаграмме будут: покупатель, система магазина, платёжный сервис, курьерская служба.
Уровень 2. Контейнеры (Container Diagram)
• Разделяет систему на крупные блоки (веб-приложение, мобильное приложение, база данных, API).
• Задача аналитика: помочь понять из чего состоит решение.
Пример: магазин делится на фронт (React), бэк (Spring Boot), базу (PostgreSQL), мобильное приложение (iOS/Android).
Уровень 3. Компоненты (Component Diagram)
• Детализирует контейнеры на внутренние части: модули, сервисы, библиотеки.
• Здесь уже активнее работает архитектор, но аналитик должен понимать, какие компоненты за что отвечают.
Пример: внутри бэка есть модуль «Заказы», «Платежи», «Каталог товаров».
Уровень 4. Код (Code Diagram)
• На этом уровне обычно работает архитектор и разработчики.
• Аналитик сюда спускается редко, но может изучить код для уточнения деталей (например, как формируется бизнес-правило).
4. Почему C4 удобен аналитику
• Ясность для разных аудиторий: бизнесу понятен уровень контекста, разработчикам — контейнеры и компоненты.
• Гибкость: можно увеличивать детализацию по мере необходимости.
• Универсальность: C4 не зависит от технологий, подходит и для монолитов, и для микросервисов.
Ошибка: пытаться сразу рисовать на уровне кода. Начинать всегда нужно с контекста.
Практика для аналитика
1. Возьми знакомую систему (например, интернет-банкинг или Telegram).
2. Нарисуй контекстную диаграмму: пользователи, внешние сервисы.
3. Распиши контейнеры: мобильное приложение, API-сервер, БД.
4. Попробуй обозначить ключевые модули (компоненты).
Инструменты: draw.io, Lucidchart, PlantUML, Structurizr.
Подводные камни
• Слишком детально для бизнеса — заказчик не понимает схемы.
• Слишком поверхностно для разработчиков — команда не видит, как реализовать.
• Несогласованность уровней — на контексте одно, на контейнерах другое.
Совет: всегда проверяй диаграммы на двух аудиториях — бизнес и разработка. Если обе стороны понимают, значит, схема хорошая.
Градация знаний
Junior
• Понимает назначение C4 и четыре уровня детализации.
• Может построить простую контекстную диаграмму, показывая систему и внешние взаимодействия.
• Читает диаграммы, созданные архитекторами или коллегами, и понимает основные блоки.
Middle
• Уверенно строит диаграммы контейнеров и компонентов для визуализации системы.
• Объясняет бизнесу и команде состав системы и взаимосвязи между блоками.
• Может использовать диаграммы C4 для обсуждения требований и интеграций.
• Понимает, какие детали стоит отображать на каждом уровне, чтобы не перегрузить диаграмму.
Senior
• Настраивает стандарты использования C4 в команде или проекте.
• Балансирует уровень детализации под разные аудитории (бизнес vs команда разработки).
• Комбинирует C4 с другими визуальными нотациями (UML, BPMN) для целостного представления системы.
• Наставляет коллег в построении диаграмм, проверяет корректность и полноту представления архитектуры.
Где учить?
• Саймон Браун — C4 Model.
• Книги: Software Architecture for Developers (Simon Brown).
• Практика: моделируй даже небольшие системы (например, сервис заметок или ToDo-лист).
Итог шага 6
Архитектурное мышление — это «надстройка» для аналитика. Оно позволяет:
• видеть систему целиком и в деталях;
• общаться с архитекторами и разработчиками на одном языке;
• объяснять бизнесу сложные вещи простыми схемами;
• выявлять ограничения ещё до начала разработки.
Помните: аналитик не должен «проектировать архитектуру», но без архитектурного мышления он не сможет качественно ставить задачи и проверять их реализацию.
Шаг 7. Базы данных и работа с данными
1. Почему аналитик должен разбираться в данных
Данные — это основа любой информационной системы. Без понимания данных аналитик не сможет:
• корректно формулировать требования;
• проверять реализацию бизнес-правил;
• проектировать отчёты и интеграции;
• выявлять потенциальные ошибки и дублирование.
Пример: если в CRM поле «Дата рождения» хранится в текстовом формате, аналитик должен предвидеть, что фильтрация по возрасту будет проблемной.
2. Типы баз данных
Аналитику достаточно знать основные типы:
1. Реляционные базы данных
• SQL, таблицы со строками и столбцами.
• Примеры: PostgreSQL, MsSQL, Oracle.
• Используются для транзакционных систем.
2. Документо-ориентированные базы (NoSQL)
• Хранят данные в формате JSON, BSON, XML.
• Примеры: MongoDB, CouchDB.
• Используются для гибких схем и больших объёмов данных.
3. Основные концепции реляционных баз данных
• Таблицы — хранят данные.
• Строки (records) — отдельные объекты, например «Пользователь».
• Столбцы (fields) — свойства объектов, например, «Имя», «Email».
• Первичный ключ (PK) — уникальный идентификатор строки.
• Внешний ключ (FK) — связь с другой таблицей.
Зачем это аналитикам?
• Чтобы понимать структуру данных, формулировать правильные требования и отчёты.
• Чтобы выявлять дублирующие или лишние поля.
• Чтобы правильно описывать интеграции: «Этот объект связан с этим объектом через FK».
4. Нормализация и денормализация
Нормализация
• Процесс разбиения данных на таблицы для уменьшения дублирования.
• Пример: вместо хранения адреса клиента в каждой покупке, создаём таблицу «Адреса».
Денормализация
• Создание таблиц с избыточной информацией ради быстрого чтения.
• Часто используется в аналитических базах.
Задача аналитика: понимать, где данные нормализованы, а где нет, чтобы корректно строить отчёты и интеграции.
5. Работа с SQL
Аналитику важно уметь:
Базовый уровень:
• Читать запросы SQL — понимать, какие данные извлекаются.
• Писать простые SELECT — фильтры (WHERE), сортировки (ORDER BY), агрегаты (SUM, COUNT, AVG).
• Объединять таблицы (JOIN) — INNER, LEFT, RIGHT, FULL, чтобы получать связанные данные.
• Понимать GROUP BY и HAVING для агрегированных выборок.
• Использовать базовые функции для работы с датами и строками.
Средний уровень:
• Писать подзапросы и использовать их в SELECT или WHERE.
• Создавать временные таблицы или CTE (WITH) для удобного построения сложных аналитических выборок.
• Понимать и применять оконные функции для анализа данных.
• Использовать CASE WHEN для условной логики внутри запросов.
• Оптимизировать запросы — понимать, как индексы влияют на скорость выполнения.
Продвинутый уровень:
• Писать сложные аналитические запросы с несколькими JOIN и подзапросами.
• Понимать структуру базы данных, ключи и связи между таблицами.
• Понимать влияние агрегатов и фильтров на результат анализа.
• Понимать концепцию нормализации и денормализации данных для аналитики.
• Использовать хранимые процедуры и функции для автоматизации повторяющихся аналитических задач.
• Владеть методами оптимизации запросов: EXPLAIN PLAN, индексы, ограничения на выборки.
Аналитик должен понимать:
• Какие таблицы участвуют и как они связаны.
• Какие фильтры и агрегаты применяются и зачем.
• Как оконные функции дают дополнительные метрики по данным.
• Как логика запроса отражает бизнес-задачу.
Пример продвинутого SQL-запроса:
предположим, нужно проанализировать продажи и вывести топ-3 клиентов по сумме заказов за последний месяц с агрегацией.
SELECT c.customer_id, c.name, SUM(o.amount) AS total_amount FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE o.order_date >= DATE_SUB (CURDATE (), INTERVAL 1 MONTH)
GROUP BY c.customer_id, c.name
ORDER BY total_amount DESC LIMIT 3;
6. Моделирование данных
• ER-диаграммы (Entity-Relationship) — показывают объекты и связи.
• UML-диаграммы классов — иногда используются для описания структуры данных в приложении.
Практическое применение: перед проектированием нового функционала аналитик рисует диаграмму, чтобы проверить, корректно ли связаны сущности.
7. Хранилища данных и BI
• Data Warehouse (DWH) — централизованное хранилище для аналитики.
• ETL-процессы — извлечение, преобразование и загрузка данных.
• BI-системы — Power BI, Tableau, Looker.
Задача аналитика: знать, какие данные доступны, как их получать и проверять корректность.
Пример: аналитик формулирует метрики KPI и проверяет, что данные для расчёта поступают корректно.
Подводные камни
• Разные системы используют разные форматы данных.
• Дублирующиеся записи и неконсистентные связи.
• Ограничения целостности иногда нарушаются при интеграциях.
Градация знаний
Junior
• Понимает базовую структуру реляционных баз: таблицы, строки, столбцы, PK/FK.
• Может читать простые SQL-запросы, писать SELECT с фильтрацией, сортировкой и агрегатами (SUM, COUNT, AVG).
• Понимает базовые JOIN (INNER, LEFT) и GROUP BY.
• Может построить простую ER-диаграмму для наглядного понимания связей.
Middle
• Уверенно работает с подзапросами, временными таблицами и CTE (WITH).
• Применяет оконные функции и условную логику CASE WHEN.
• Оптимизирует запросы, понимает влияние индексов на производительность.
• Разбирается в нормализации и денормализации, умеет учитывать это при построении отчетов и интеграций. Знает и руководствуется 4 нормальными формами, где нет иной потребности
• Может строить UML-диаграммы классов или ER для сложных структур данных.
• Знает принципы работы с хранилищами данных (DWH) и BI-системами.
Senior
• Пишет сложные аналитические запросы с множественными JOIN, подзапросами и агрегатами.
• Понимает архитектуру базы данных, связи и ограничения, влияние данных на бизнес-логику.
• Использует хранимые процедуры и функции для автоматизации аналитики.
• Оптимизирует производительность запросов с помощью EXPLAIN PLAN, индексов и ограничений.
• Наставляет команду по моделированию данных и проверке качества данных.
• Консультирует по построению ETL-процессов и интеграции данных для BI.
Где учить?
• Sql-academy.org - практические задания
• 2sql.ru - теория
• DAMA-DMBOK. Свод знаний по управлению данными
Системный аналитик должен:
1. Понимать типы баз данных и их назначение.
2. Читать и писать SQL-запросы на базовом уровне.
3. Понимать связи между таблицами и структуру данных.
4. Моделировать данные и проверять их корректность.
5. Контролировать качество данных для аналитики и отчётности.
Правильное владение данными позволяет аналитикам формулировать требования, строить отчёты и общаться с разработчиками на одном языке.
Шаг 8. Тестирование
Тестирование представляет собой фундаментальный и неотъемлемый этап в жизненном цикле разработки программного обеспечения (ПО), который обеспечивает качество, надежность и соответствие продукта ожиданиям пользователей и бизнеса. Для системного аналитика тестирование выходит за рамки простой проверки работоспособности системы — это мощный инструмент, позволяющий глубоко анализировать и улучшать продукт на всех стадиях его создания. Оно помогает выявлять проблемы на ранних этапах, минимизировать риски и оптимизировать процессы разработки. В частности, для аналитика тестирование служит средством для:
• Выявления несоответствий требованиям на ранних этапах: это позволяет избежать дорогостоящих переработок в будущем, фиксируя расхождения между спецификацией и реализацией еще до перехода к полноценной разработке.
• Проверки корректности бизнес-логики и интеграций: Аналитик может убедиться, что логика процессов соответствует бизнес-требованиям, а интеграции с другими системами работают без сбоев, обеспечивая seamless взаимодействие.
• Сокращения рисков ошибок на продакшене: через систематическое тестирование снижается вероятность инцидентов в эксплуатации, что повышает доверие пользователей и снижает затраты на поддержку.
Аналитик не обязательно пишет сложный код тестов, но должен понимать типы тестирования, уметь составлять тест-кейсы и контролировать качество продукта.
1. Виды тестирования, которые должен знать аналитик
1.Функциональное тестирование
Что это?
Проверка, что система работает согласно спецификации и требованиям.
Зачем нужно:
Позволяет убедиться, что пользовательские сценарии выполняются корректно.
Примеры:
• Проверка формы регистрации (валидность email, обязательные поля).
• Проверка расчётов в финансовой системе.
Роль аналитика:
• Составление тест-кейсов на основе требований.
• Проверка соответствия ожидаемых результатов фактическим.
2. Нефункциональное тестирование
Что это?
Проверка характеристик системы, не связанных напрямую с функциональностью: производительность, безопасность, удобство.
Примеры:
• Нагрузка на систему (Load Testing).
• Скорость отклика интерфейса.
• Безопасность данных.
Роль аналитика:
• Определение критериев качества.
• Описание сценариев нагрузочного тестирования.
3. Интеграционное тестирование
Что это?
Проверка взаимодействия модулей и внешних систем через API или другие интерфейсы.
Примеры:
• Корректность обмена данными с CRM.
• Проверка отправки уведомлений через сторонние сервисы.
Роль аналитика:
• Определение точек интеграции.
• Создание сценариев проверки данных между системами.
4. Регрессионное тестирование
Что это?
Проверка, что новые изменения не нарушили существующий функционал.
Зачем нужно:
• Обеспечивает стабильность продукта после обновлений.
• Позволяет быстрее находить ошибки при доработках.
Роль аналитика:
• Обновление тест-кейсов после изменения требований.
• Контроль прохождения тестов.
Инструменты, с которыми полезно работать аналитикам
1. Jira / TestRail / Zephyr — для управления тест-кейсами и баг-трекером.
2. Postman — для тестирования API.
3. Selenium / Cypress (базовое понимание) — автоматизация функциональных тестов.
4. JMeter / Locust — нагрузочное тестирование.
Примечание: Аналитик не обязательно пишет сложные автоматизированные тесты, но должен понимать их принцип и уметь читать отчёты тестирования.
Практика для аналитика
1. На основе требований создаём тест-кейсы для ключевых сценариев пользователя.
2. Проверяем корректность данных через API (REST/GraphQL).
3. Совместно с QA проверяем интеграции с внешними системами.
4. Отслеживаем баги и проверяем их исправление.
Пример мини-проекта:
• Функциональное тестирование формы заявки: проверка обязательных полей, ограничений на данные, уведомлений.
• Интеграционное тестирование с CRM: данные из формы должны корректно попадать в систему.
• Регрессионное тестирование после исправления ошибок: старые заявки корректно обрабатываются.
Рекомендации аналитикам
• Всегда проверяйте требования перед тестированием.
• Тест-кейсы должны быть понятными и воспроизводимыми.
• Фиксируйте все найденные баги, чтобы избежать повторных ошибок.
• Понимание тестирования повышает ценность аналитика на проекте, помогает выявлять проблемы ещё до их появления в коде.
Градация знаний
Junior
• Понимает базовые типы тестирования: функциональное, нефункциональное, интеграционное, регрессионное.
• Может составлять простые тест-кейсы на основе требований.
• Умеет проверять корректность пользовательских сценариев и фиксировать баги.
• Знает базовые инструменты: Jira, TestRail, Postman, DevTools.
Middle
• Уверенно создает тест-кейсы для интеграций между системами и API (REST/GraphQL).
• Понимает критерии качества нефункциональных характеристик (скорость, безопасность, нагрузка).
• Умеет отслеживать прохождение тестов и контролировать регрессионное тестирование.
• Имеет базовое представление об автоматизации тестов (Selenium, Cypress, JMeter, Locust).
• Может анализировать отчёты тестирования и выявлять повторяющиеся проблемы.
Senior
• Наставляет команду аналитиков по тестированию требований и интеграций.
• Проектирует тестовые сценарии для сложных процессов и масштабных систем.
• Понимает архитектурные и технические ограничения, влияющие на тестирование.
• Может комбинировать функциональное, интеграционное, регрессионное и нагрузочное тестирование для обеспечения качества продукта.
• Способен выстраивать стратегию тестирования на уровне проекта и взаимодействовать с QA и Dev для предотвращения ошибок на ранних этапах.
Где учить?
• Книга: "Lessons Learned in Software Testing" by Cem Kaner (обновленное 2025).
• Онлайн-курс: "Systems Analysis Courses" на Udemy — включает тестирование.
Шаг 9. Документация
Документация — это не просто текстовые файлы с описанием системы. Для системного аналитика она является инструментом коммуникации, который связывает разработчиков, QA, бизнес-пользователей и менеджеров. Хорошо структурированная документация:
• Минимизирует недопонимания между участниками проекта.
• Облегчает поддержку и масштабирование продукта.
• Служит источником истины о требованиях, процессах и логике системы.
1. Основные типы документации
1. Требования и спецификации
Что это?
Подробные описания того, что система должна делать.
Зачем нужно:
• Чётко фиксирует ожидания бизнеса.
• Является основой для тестирования и разработки.
Примеры документов:
• BRD (Business Requirements Document) — требования бизнеса.
• FRD (Functional Requirements Document) — функциональные требования.
• Use Cases / User Stories — сценарии взаимодействия пользователя с системой.
Роль аналитика:
• Сбор и структурирование информации.
• Проверка полноты и логичности требований.
• Актуализация документов при изменениях.
Что это?
Описание процессов, которые поддерживает система, включая бизнес-логики и сценарии.
Зачем нужно:
• Обеспечивает понимание «как работает система» для новых сотрудников.
• Помогает выявить узкие места и оптимизировать процессы.
Примеры:
• BPMN-диаграммы.
• Процессные карты.
• Инструкции по работе с системой.
Роль аналитика:
• Моделирование процессов.
• Составление визуальных схем для понимания сложных процессов.
2. Техническая документация
Что это?
Документы для разработчиков и QA, описывающие архитектуру, интеграции, API и технические ограничения.
Зачем нужно:
• Ускоряет разработку и интеграцию.
• Снижает ошибки при внедрении новых функций.
Примеры:
• ERD (схемы баз данных).
• API Documentation (REST/GraphQL).
• Архитектурные диаграммы.
Роль аналитика:
• Формирование требований к интеграциям.
• Проверка соответствия технической документации бизнес-требованиям.
3. Руководства пользователя
Что это?
Инструкции для конечных пользователей системы.
Зачем нужно:
• Обеспечивает корректное использование системы.
• Снижает нагрузку на службу поддержки.
Примеры:
• Пошаговые инструкции по работе с формами, отчетами, панелями управления.
• Видеогиды и FAQ.
Роль аналитика:
• Понимание пользовательских сценариев.
• Создание структурированных и понятных инструкций.
2. Лучшие практики документации
1. Актуальность: документация должна соответствовать текущей версии системы.
2. Структурированность: разделы, заголовки, таблицы, схемы — всё должно быть логично.
3. Доступность: документы должны быть удобны для чтения и поиска.
4. Визуализация: схемы процессов и диаграммы повышают понимание сложной информации.
5. Коммуникация: документация должна быть инструментом обсуждения, а не просто хранилищем текста.
3. Инструменты для документации
• Confluence / Notion / SharePoint — централизованное хранение и совместная работа.
• Draw.io / Miro / Lucidchart — визуализация процессов и диаграмм.
• Markdown / Git — для совместной работы над технической документацией.
• Jira / Trello — интеграция документации с задачами и процессами разработки.
4. Практика для аналитика
• Подготовка BRD и FRD для нового функционала.
• Создание диаграмм BPMN для ключевых бизнес-процессов.
• Обновление и поддержка документации при изменении требований или релизе новой версии системы.
• Составление инструкций и гайдов для пользователей.
Пример мини-проекта:
• Сбор требований для новой формы кредитного запроса.
• Создание функциональной спецификации и API-документации.
• Моделирование процесса обработки заявки через BPMN.
• Подготовка инструкции для сотрудников, работающих с формой.
Рекомендации аналитикам
• Документация — это живой инструмент, а не архив.
• Проверяйте соответствие документации реальной системе.
• Визуализируйте процессы, чтобы было понятно всем участникам проекта.
• Регулярно обновляйте и пересматривайте документы, особенно после релизов
Градация знаний
Junior
• Понимает назначение основных типов документации: требования, процессная, техническая, руководства пользователя.
• Может подготовить простые BRD, FRD, User Stories на основе требований.
• Умеет создавать базовые BPMN-диаграммы или схемы процессов.
• Знает, как использовать инструменты для документации: Confluence, Draw.io, Notion.
Middle
• Уверенно формирует и поддерживает документацию для интеграций и архитектуры (ERD, API Documentation).
• Создаёт структурированные, визуально понятные документы для команды и бизнеса.
• Обновляет документацию при изменениях требований и релизах.
• Понимает лучшие практики: актуальность, доступность, структурированность, визуализация.
• Интегрирует документацию с задачами и процессами разработки (Jira, Trello).
Senior
• Наставляет команду аналитиков по ведению документации и стандартам качества.
• Проектирует единый «живой» источник правды для всей команды: требования, процессы, технические детали.
• Контролирует согласованность бизнес- и технической документации.
• Способен консультировать бизнес и разработку по оптимальному представлению информации.
• Выстраивает процессы регулярного обновления документации и её использования в обсуждениях и принятии решений.
Где учить?
• Книга: "Building Microservices" by Sam Newman (2-е издание, 2025) — для документации процессов.
• Карл Вигерс — Разработка требований к программному обеспечению
Заключение
Профессия системного аналитика — это уникальное сочетание аналитического мышления, технических навыков и умения понимать бизнес. От точного сбора требований до моделирования процессов, работы с базами данных, API, UML-диаграмм и тестирования — каждая компетенция играет ключевую роль в успехе проекта. Освоив пошаговый роадмап и применяя знания на практике, вы сможете не просто выполнять задачи, а создавать ценные решения, которые реально помогают бизнесу и пользователям.
Этот гид охватывает фундаментальные шаги развития системного аналитика, но каждый путь индивидуален. Практика, проекты, портфолио и постоянное обучение делают специалиста востребованным и успешным. Используйте предложенные ресурсы, пробуйте инструменты, моделируйте процессы, документируйте требования и тестируйте системы — и вы увидите, как ваш профессионализм растет с каждым новым проектом.
Я буду рад услышать ваш фидбек: какие разделы оказались полезными, что можно дополнить или уточнить, чтобы гид стал еще более практичным и понятным. Ваши комментарии помогут сделать этот материал ценным для всех, кто хочет строить карьеру в системной аналитике.