Школа
системного анализа
и проектирования

Профессия «Системный аналитик информационных систем для бизнеса»

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

Профессия «Системный аналитик информационных систем для бизнеса»

Раздел IV. Сопровождение аналитиком дальнейших этапов разработки информационных систем

Раздел IV показывает, что после написания «основных» требований и проектирования работа аналитика не заканчивается: ему ещё предстоит участвовать в тестировании, документировании и сопровождать проект в боевом режиме. И вновь не обязательно читать подряд: если вам больно смотреть на нескончаемые баги и надо понять, чем QA-жизнь отличается от обычной, загляните в главу 20 — «тестирование и качество».

Если вы вдруг запутались в том, как оформить и актуализировать документацию, добро пожаловать в главу 21.

Глава 22 расскажет, как системный аналитик может «подружиться» с AI, чтобы собирать требования и анализировать большие массивы данных.

И, наконец, в 23-й главе вы поймёте, почему внедрение и поддержка системы — это не просто «запустить и забыть», а постоянное взаимодействие с DevOps, службой поддержки, бизнесом.

Возможные инсайты: «Ого, оказывается, тестирование — это не в конце, а часть цикла!» и «Так вот, как правильно поддерживать документацию, чтобы её читал не только я».

Глава 20. Введение в тестирование и обеспечение качества

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

В этой главе мы рассмотрим, что включает в себя тестирование, каковы основные виды тестов, зачем нужен контроль качества (QA) и какое место занимает аналитик в процессе обеспечения качества.
20.1. Что такое тестирование
Тестирование — это проверка системы (или её отдельных частей) на соответствие заявленным требованиям и спецификациям, а также на выявление ошибок, дефектов, несоответствий. Цель тестирования — найти и устранить проблемы до того, как систему увидят конечные пользователи, либо до внедрения в продакшн.
Задачи тестирования
  1. Подтвердить правильность реализации: действительно ли система работает по описанным сценариям, выдаёт ли нужные результаты?
  2. Обнаружить дефекты: любые баги, от несоответствия интерфейса до логических ошибок в расчётах.
  3. Проверить нефункциональные аспекты: производительность, безопасность, юзабилити.
  4. Сократить риски: чем раньше выявлены проблемы, тем дешевле их исправлять.
20.2. Основные виды тестирования
Тестирование бывает очень разнообразным по целям, глубине и стадии применения. Ниже перечислены основные виды:

1. Модульное (unit testing)
  • Проверяет отдельные модули или функции в изоляции.
  • Обычно пишется разработчиками, покрывает логику кода, позволяет быстро находить регрессию.
2. Интеграционное (integration testing)
  • Проверяет связку нескольких модулей или сервисов, их взаимодействие и корректный обмен данными.
  • Может использовать тестовые среды, моки или реальные подключения.
3. Функциональное (functional testing)
  • Проверяет, что функциональные требования (user stories, use cases) реализованы верно.
  • Часто выполняется ручным или автоматизированным способом, опираясь на сценарии, составленные по требованиям.
4. Системное (system testing)
  • Проверяет систему целиком (с учётом внешних интеграций, реальной среды, баз данных).
  • Оценивает, как решение работает “из конца в конец”.
5. Регрессионное (regression testing)
  • Регулярная проверка, что новые изменения не «сломали» уже рабочие функции.
  • Часто автоматизируют, чтобы каждый релиз гонять набор регрессионных тестов.
6. Нефункциональное тестирование
  • Производительность (load/stress testing): выдержит ли система пиковую нагрузку, сколько времени ответа при X запросах в секунду.
  • Безопасность (security testing): уязвимости, SQL-инъекции, XSS, защищённость API.
  • Юзабилити (usability testing): насколько интерфейс удобен для реальных пользователей.
7. Приёмочное (acceptance testing)
  • Проверка системы в среде, максимально приближенной к боевой, с участием заказчика или его представителей.
  • Часто называется UAT (User Acceptance Testing), где бизнес-пользователи убеждаются, что решение закрывает их реальные сценарии.
20.3. Роль системного аналитика в тестировании
Хотя непосредственным выполнением тестов занимаются QA-инженеры, у системного аналитика тоже есть важные роли:

1. Определение критериев приёмки
  • Уже на стадии описания задач (user stories) аналитик формулирует «Acceptance Criteria».
  • Это даёт тестировщикам основу для тест-кейсов, а разработчикам — ясность, что считать «выполнением» задачи.
2. Помощь в создании тестовых сценариев
  • Аналитик хорошо знает бизнес-процессы и ключевые use cases, значит, может подсказать, какие сценарии критичны, где возможны сложные ветвления.
  • Иногда аналитик участвует в разработке тест-планов, добавляет важные бизнес-кейсы.
3. Проверка соответствия требованиям
  • На финальной стадии реализации аналитик может участвовать в приёмке, убеждаясь, что решение действительно отвечает исходным требованиям (business rules, user flows).
4. Анализ дефектов
  • Если тестировщики находят баги, аналитик помогает понять: ошибка в реализации или в требовании, либо требование было неполным.
  • В случае необходимости аналитик обновляет документацию и требования, согласовывает изменения с бизнесом.
5. Участие в UAT
  • На этапе User Acceptance Testing аналитик может вместе с бизнес-пользователями проверять систему «сквозными» сценариями, собирая реальный фидбэк.
20.4. Качество vs. тестирование
Тестирование — это лишь один из элементов обеспечения качества (QA). Quality Assurance включает в себя более широкий набор практик:

1. Процессы и методологии
  • Организация правильного workflow в разработке (Agile, DevOps), код-ревью, CI/CD, автоматизация тестирования.
  • Стандарты кодирования, рефакторинг, документация.
2. KPI и метрики качества
  • Количество критических дефектов, процент покрытия тестами, скорость исправления багов, время отклика на инциденты.
3. Профилактика дефектов
  • Вместо того чтобы «ловить» их на стадии тестирования, стараются улучшить процесс анализа требований, проектирование архитектуры, код-ревью, чтобы дефекты вообще не появлялись.
4. Культура ответственности
  • Если команда ориентирована на качество, разработчики сами активно пишут unit-тесты, аналитики детально прописывают критерии, менеджеры не «зажимают» время на тестирование.
Вместе эти меры формируют среду, в которой качество становится встроенным в процесс, а не «пристёгивается» в самом конце.

20.5. Инструменты и автоматизация тестирования
Современные проекты часто используют разнообразные инструменты для автоматизации тестов:
  1. Unit-тесты: JUnit, NUnit, pytest, unittest и др.
  2. UI-тесты: Selenium WebDriver, Cypress, TestCafe.
  3. API-тесты: Postman (Collection Runner), Newman, RestAssured, Karate.
  4. Performance-тесты: JMeter, Gatling, Locust.
  5. CI/CD интеграции: Jenkins, GitLab CI, GitHub Actions, Azure DevOps — прогон тестов при каждом коммите, автодеплой, отчёты о тестировании.

Системный аналитик может не быть экспертом в каждом инструменте, но ему полезно понимать, как формируются тест-сценарии, в каких форматах хранятся данные тестов, как отчёты об ошибках попадают в Jira (или другую систему управления задачами). Это помогает аналитикам быстро реагировать на обнаруженные несоответствия и уточнять требования при необходимости.

20.6. Уровни среды и тестирования
Обычно в проекте выделяют несколько сред для развертывания системы:
  1. Development (dev) — среда, где разработчики «поднимают» приложение на локальных машинах или во внутреннем окружении для первоначальных тестов.
  2. Test/QA — отдельная среда, на которой тестировщики проводят тесты, где «свежий» код собирается из репозитория, иногда с анонимизированными или синтетическими данными.
  3. Staging (pre-production) — максимально приближена к реальной «боевой» среде, используется для финальной проверки и UAT.
  4. Production — рабочая, где системой пользуются реальные пользователи.
Системный аналитик взаимодействует с тест- и staging-средами, проверяя выполнение требований, участвуя в приёмке и собирая фидбэк от стейкхолдеров.
Вывод по главе 20
Тестирование и обеспечение качества — неотъемлемая часть жизненного цикла разработки. Системный аналитик в этом процессе:
  1. Формулирует или помогает формулировать критерии приёмки, помогает QA-специалистам понять бизнес-логику, приоритеты и сценарии.
  2. Верифицирует систему на соответствие исходным требованиям, участвует в анализе найденных дефектов.
  3. Содействует налаженному процессу QA, в котором качество закладывается «с самого начала», а не проверяется «в самом конце».
В результате, при грамотном тестировании и QA, создаётся продукт, в котором:
  • Минимум ошибок и логических несоответствий;
  • Удовлетворяются требования бизнеса и ожидания пользователей;
  • Выявленные проблемы устраняются оперативно и не переносятся в продакшн.
Аналитик, обладающий пониманием QA-процессов, помогает команде достигать высокого уровня качества, а значит, и успешных результатов для проекта и бизнеса.

Глава 21. Введение в документирование систем

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

В этой главе мы рассмотрим, что обычно подразумевается под документированием системы, какие типы документов существуют, какие инструменты используются для хранения и как организовать процесс, чтобы документация оставалась актуальной и полезной.
21.1. Зачем нужна документация
  1. Единое понимание. В крупном проекте много людей (разработчики, аналитики, тестировщики, дизайнеры, поддержка). Документация — это общий «источник истины», где формализованы договорённости и спецификации.
  2. Ускорение онбординга. Новым сотрудникам не нужно «выспрашивать» всё у коллег, если основные процессы и архитектура описаны в доступном виде.
  3. Минимизация ошибок. Когда требования и решения зафиксированы, ниже риск, что разные члены команды пойдут «каждый своим путём».
  4. Исторический контекст. Документы сохраняют логику принятых решений (почему выбрали такой технологический стек, как реализовали определённые правила). Это помогает избегать повторения ошибок.
  5. Соответствие регуляторным требованиям. В некоторых отраслях (банковской, медицинской, гос. сфере) обязательны подробные технические и бизнес-документы для аудитов.
21.2. Основные типы документации
Документацию условно можно разделить на техническую (ориентированную на разработчиков и администраторов) и пользовательскую (ориентированную на конечных пользователей, операторов, бизнес-аналитиков). Также можно классифицировать по стадии или назначению:

1. Vision & Scope / Бизнес-требования
  • Описывают стратегические цели, бизнес-контекст, почему система нужна и что она должна дать организации.
2. Спецификация требований (SRS)
  • Детально фиксирует функциональные и нефункциональные требования, сценарии использования.
  • Может включать диаграммы, схемы, прототипы.
3. Техническая спецификация / архитектурное описание
  • Архитектурные схемы (C4-модель, UML component, deployment, sequence).
  • Описание основных модулей, паттернов, используемых технологий.
  • Интеграционные схемы (API, очереди, микросервисы).
4. Пользовательская документация
  • Руководства, мануалы, справочная система, инструкции для операторов.
  • Часто оформляются в формате wiki, PDF, онлайн-хелпа.
5. Администраторская / эксплуатационная документация
  • Описывает, как разворачивать систему, конфигурировать, мониторить, проводить бэкап и обновления.
  • Включает схемы инфраструктуры, логику DevOps-пайплайна.
6. Документация по тестам
  • Тест-планы, тест-кейсы, чек-листы.
  • Отчёты о проведённом тестировании, покрытии, найденных дефектах.
7. История изменений / Release Notes
  • Краткое описание, что изменилось в каждом релизе: новые функции, исправленные баги, известные ограничения.
8. Architecture Decision Records (ADR)
  • Краткие «протоколы» ключевых архитектурных решений (почему выбрали Kafka, почему отказались от микросервисов и т. д.), чтобы помнить логику выбора.
21.3. Инструменты для документирования
1. Wiki-системы
  • Confluence (Atlassian) — один из самых популярных корпоративных Wiki-инструментов, хорошо интегрируется с Jira.
  • MediaWiki (движок Википедии), GitLab Wiki, GitHub Wiki — бесплатные или встроенные решения.
  • Плюсы: легко редактировать командой, версионировать, создавать структуру страниц и ссылок.
2. Markdown + Git-репозиторий
  • Некоторые команды хранят документацию в формате .md рядом с кодом, чтобы всегда иметь актуальную версию.
  • Плюсы: возможность контролировать версии, делать pull request, вносить правки.
  • Минусы: может быть сложно для бизнес-пользователей, далеких от Git.
3. Специализированные системы управления требованиями
  • Jama, IBM Rational DOORS, Polarion — тяжёлые «enterprise»-продукты для больших проектов.
  • Позволяют делать трассировку требований, связывать их с тест-кейсами и дефектами, управлять версиями.
4. Google Docs / Office 365
  • Для небольших команд или проектов, где не требуется сложная структура, можно вести документы в Google Docs.
  • Важно следить за упорядочением в папках, доступами, чтобы избежать хаоса.
21.4. Организация и поддержка актуальности
Документация быстро теряет смысл, если устаревает. Поэтому важно:
  1. Определить «хранителей» (owners) каждой части документа. Например, техническую документацию поддерживают разработчики, а инструкцию для пользователей обновляет отдел эксплуатации или аналитик.
  2. Включать обновление документов в процесс разработки. Если по задаче изменяется бизнес-логика, нужно добавить пункт «обновить спецификацию/подробный user story».
  3. Периодические ревизии (Documentation Review). Раз в спринт/месяц смотреть, не появилось ли расхождение между реализацией и тем, что записано в документах.
  4. Использовать версионирование (v1.0, v1.1...) Если проект поставляется в релизах, полезно иметь соотнесённую версию документации на каждый релиз.
21.5. «Лёгкая» vs. «тяжёлая» документация
Лёгкая документация (Agile-стиль)
  • Минимум формальных документов, основа — user stories, Wiki-страницы, интерактивные прототипы.
  • Быстро обновляется, подстраивается под изменения требований.
  • Подходит для динамичных проектов, но требует дисциплины, чтобы всё действительно обновлять.
Тяжёлая документация (Waterfall-стиль)
  • Подробные ТЗ, SRS, схемы, толстые документы, подписанные всеми стейкхолдерами.
  • Сложнее поддерживать актуальность, много бюрократии.
  • Иногда неизбежно в «формальных» проектах (госконтракты, оборонка, сертификация).
На практике многое зависит от культуры организации, ожиданий заказчика, регуляторных требований. Системный аналитик должен уметь находить баланс: писать ровно столько, сколько нужно для ясности и стабильности, не создавая «бумажного монстра».
21.6. Автоматизация генерации документации
Есть подходы и инструменты, позволяющие частично автогенерировать документацию, особенно в части технической:
  1. Swagger / OpenAPI — документация для REST-эндпоинтов, формируется на основе аннотаций кода, можно автоматически публиковать интерактивный справочник.
  2. JavaDoc, Docstring в Python — вставляя комментарии в код, можно генерировать HTML-док со структурами классов и методов.
  3. PlantUML, Mermaid — текстовый формат диаграмм, позволяющий хранить диаграммы рядом с кодом (Markdown + PlantUML), и автоматически обновлять при изменениях.
  4. Doxygen — инструмент для C++, C#, Java, который по комментариям строит технические описания классов, функций.
Однако не всё удаётся генерацией. Часть смысловых описаний (зачем, почему, бизнес-логика) пишется человеком. Автоматизация хороша там, где структура и форматы чётко определены (например, API), а смысловой контент всё равно требует «ручного» подхода.

Вывод по главе 21
Документирование систем — это процесс создания и поддержания в актуальном состоянии набора описаний (требований, архитектуры, пользовательских мануалов и т. д.). Системный аналитик играет ведущую роль в формировании тех разделов, которые связаны с:
  1. Описание бизнес-процессов и требований (SRS, Use Cases, BPMN-схемы).
  2. Спецификации для разработчиков (API, интеграционные схемы, критерии приёмки).
  3. Протоколы решений и архитектурные выборы (ADR), согласованные со стейкхолдерами.
Главные принципы качественного документирования:
  • Прозрачность и доступность: все нужные люди легко находят и читают документы.
  • Актуальность: сведения соответствуют реальному состоянию проекта.
  • Структурированность: деление на четкие разделы, понятная навигация, ссылки, взаимные переходы между документами.
  • Баланс между «формальной полнотой» и «легкостью» обновления — слишком подробные документы быстро устаревают, а слишком короткие теряют ценность.
Следуя этим рекомендациям, аналитик и команда создают документированную базу, которая упрощает разработку, внедрение и дальнейшую поддержку системы.

Глава 22. Применение искусственного интеллекта в работе системного аналитика

Современный мир IT переживает бум технологий искусственного интеллекта (AI), машинного обучения (ML) и обработки естественного языка (NLP). Системный аналитик, даже не будучи специалистом по глубоким нейронным сетям, всё чаще сталкивается с ситуациями, где применение AI-решений может упростить сбор и анализ требований, документирование, принятие решений и оптимизацию бизнес-процессов. В этой главе мы рассмотрим, как именно ИИ может помогать аналитику и какие инструменты и подходы особенно полезны.

22.1. Зачем системному аналитику знать про AI
  1. Анализ больших объёмов данных. При сборе требований в крупной организации может скапливаться множество документов, логов, переписок. AI-инструменты (NLP) помогают быстро выявлять ключевые темы, частые проблемы, «болевые точки» клиентов и стейкхолдеров.
  2. Автоматизация рутинных задач. Многие приложения AI упрощают рабочий процесс: автоматическая генерация диаграмм из текстовых описаний, распознавание шаблонов в проектных документах, «умные» помощники, предлагающие формулировки требований.
  3. Гибридные команды. Аналитик часто участвует в проектах, где требуется интегрировать модули машинного обучения. Необходимо понимать общие принципы ML, чтобы грамотно описать требования к данным, валидировать постановку задачи и коммуницировать с Data Scientist-специалистами.
  4. Инновационные решения для бизнеса. Всё больше проектов на стыке традиционной IT-автоматизации и AI — например, чат-боты, системы предиктивной аналитики, интеллектуальные рекомендательные сервисы. Аналитик, знакомый с возможностями и ограничениями AI, может предложить более эффективное решение задач.
22.2. Области применения AI в работе аналитика
1. Обработка естественного языка (NLP)
  • Анализ требований и документов. Системный аналитик может применять сервисы NLP, чтобы просматривать большие тексты (протоколы совещаний, интервью, e-mail-переписки), автоматически извлекать ключевые слова, классифицировать требования по темам или приоритетам.
  • Семантический поиск по документации. Используя AI-модели, можно искать не точные вхождения фраз, а смысловое соответствие. Это ускоряет доступ к нужной информации.
2. Генерация описаний и резюме
  • Автоматическое составление кратких сводок (summaries) из длинных текстов — это помогает аналитикам быстро извлекать главное из материала для отчетов и презентаций.
  • Генерация «черновиков» спецификаций. Некоторые модели (включая большие языковые модели, LLM) способны на основе вводных данных предложить структуру документа или первичное формулирование требований. Аналитик может затем отредактировать результат, экономя время.
3. Анализ и улучшение бизнес-процессов
  • Process Mining. AI-алгоритмы по логам систем и журналам транзакций пытаются восстановить реальную картину бизнес-процессов (часто отличающуюся от формальных схем «как задумано»). Аналитик потом сравнивает это с «AS-IS» моделями и выявляет узкие места.
  • Оптимизационные модели. Если нужно оптимизировать логистику, расписания, последовательности этапов, могут применяться алгоритмы машинного обучения и эвристики, чтобы предложить вариант с наименьшими затратами.
4. QA и тестирование
  • Умные тестовые инструменты. Некоторые AI-сервисы могут автоматически генерировать тестовые сценарии, находить потенциальные узкие места в логике.
  • Анализ дефектов. AI-модели могут группировать баги по сходным причинам, предсказывать приоритет или сложность исправления на основе исторических данных. Аналитик может использовать эти подсказки, чтобы понять, где систематическая проблема в требованиях или архитектуре.
5. Поддержка принятия решений
  • Predictive Analytics. Если у компании много данных (продажи, поведение клиентов, логи операций), AI-модели могут выдавать прогнозы и тренды. Аналитик интерпретирует эти результаты для бизнес-заказчиков, связывает с целями, формирует рекомендации о том, как улучшить систему.
  • Интеллектуальные ассистенты. В крупных экосистемах (Microsoft Power Platform, AWS, Google Cloud) есть интегрированные ИИ-инструменты, подсказывающие варианты workflows, шаблоны интеграций, best practices.
22.3. Инструменты и платформы
  1. Платформы AI/ML: TensorFlow, PyTorch, scikit-learn — обычно нужны более технарям (Data Scientist, ML Engineer). Аналитик может взаимодействовать на уровне постановки задач, интерпретации результатов, проверки валидности данных.
  2. Облачные сервисы: AWS AI Services (Comprehend, Forecast), Google Cloud AI, Azure Cognitive Services — позволяют быстро внедрять NLP, анализ изображений, прогнозную аналитику без глубоких знаний Data Science.
  3. NLP-инструменты для обработки текстов: NLTK, SpaCy (Python-библиотеки) — анализ и очистка текстов, выделение сущностей. OpenAI GPT, ChatGPT — генерация текста, резюме, ответов на вопросы. Microsoft Text Analytics — извлечение ключевых фраз, тональности, языка.
  4. Process Mining: Celonis, Disco, UiPath Process Mining — платформы, которые импортируют логи систем и строят реальные графы процессов, показывая, где есть задержки и отклонения от нормативного маршрута.
Low-code / No-code AI: для простых сценариев (например, классификация заявок) есть инструменты drag-and-drop, позволяющие настроить ML-модель из готовых блоков. Аналитик может сам экспериментировать с данными без глубокого программирования.

22.4. Ограничения и риски
  1. Качество данных: Машинное обучение требует «чистых», репрезентативных данных. Если данные неполные, несогласованные или предвзятые (biased), AI-модель выдаст некорректные результаты.
  2. Объяснимость (Explainability): Многие модели (особенно нейронные сети) — «чёрные ящики». Аналитик должен понимать, как объяснить бизнесу, почему модель приняла то или иное решение (в некоторых отраслях это критично, например, при кредитных скорингах).
  3. Неправильные ожидания: AI не заменяет полностью аналитика и инженеров требований. Если стейкхолдеры думают, что «ИИ всё сам разберёт», может случиться разочарование. AI в большинстве случаев служит вспомогательным инструментом.
  4. Этические и правовые аспекты: использование персональных данных, GDPR, соблюдение приватности. Нужно следить, чтобы не нарушать законы и не допустить утечку информации.
  5. Интеграция и поддержка: внедрённый AI-сервис — это часть системы, которую надо поддерживать, обновлять модели по мере накопления новых данных. Аналитик учитывает это как часть требований к эксплуатации.
22.5. Как начать применять AI в работе аналитика
  1. Определить задачи, где AI даст реальный эффект. Например, есть ли массив текстов, подлежащих анализу? Нужно ли быстро классифицировать обращения клиентов? Есть ли рутинные операции, которые можно ускорить?
  2. Изучить базовые инструменты. Попробовать облачные сервисы NLP (Azure Cognitive Services, Google Natural Language) на тестовых данных. Посмотреть, как работает автоматический summarization, sentiment analysis.
  3. Согласовать с командой Data/ML. Если в компании есть отдел Data Science или Data Engineers, лучше обсудить с ними возможные коллаборации. Договориться, какую часть работы делают они, а какую — аналитик.
  4. Интегрировать в процесс. Если аналитик видит, что часть требований собирается через тонны писем и чатов, можно применить AI для разбора больших объёмов корреспонденции. Результаты (ключевые темы, вопросы) проверять вручную, уточнять у стейкхолдеров.
  5. Учитывать изменения ролей. Постепенно аналитик может становиться «AI Evangelist» внутри проекта, демонстрируя, как AI помогает видеть закономерности, прогнозировать риски, улучшать процессы.
Вывод по главе 22
Применение искусственного интеллекта в работе системного аналитика — это не фантастика, а реальная возможность значительно облегчить и ускорить ряд процессов:
  • Сбор и структурирование больших массивов текстов и данных;
  • Генерация «черновиков» документов и кратких резюме;
  • Аналитика реальных бизнес-процессов (Process Mining);
  • Точечная поддержка принятия решений (predictive, рекомендационные системы).
Однако AI-инструменты не заменяют аналитика: они лишь расширяют его возможности. Важно правильно выбрать сценарии, оценить риски и ограничения, понимать, что «умные» модели требуют качественных данных и регулярного обновления. Аналитик, умеющий эффективно использовать AI, становится более востребованным, так как способен приносить дополнительную ценность бизнесу, открывая новые перспективы и оптимизируя рутинные задачи.

Глава 23. Введение в эксплуатацию и сопровождение

Когда система готова к выводу в реальную среду — будь то внутренняя инфраструктура компании или облачные платформы, — встают вопросы эксплуатации и сопровождения. Речь идёт о том, как система будет работать в «боевом» режиме, обслуживать реальных пользователей, выдерживать нагрузки и получать своевременные обновления. На данном этапе работа системного аналитика не заканчивается: он продолжает взаимодействовать с командой эксплуатации (DevOps, инженерами сопровождения, службой поддержки), а также со стейкхолдерами, чтобы система действительно решала поставленные бизнес-задачи.
23.1. Что такое эксплуатация
Эксплуатация (Operation) — это комплекс процессов и действий, направленных на поддержание системы в рабочем состоянии после её релиза, обеспечение требуемого уровня доступности, производительности, безопасности и удобства обслуживания.
  1. Внедрение (go-live): момент, когда система начинает обслуживать реальных пользователей в продакшене.
  2. Текущее обслуживание: обновления, установки патчей, резервное копирование, мониторинг производительности, реакция на инциденты.
  3. Поддержка пользователей: обработка обращений (Service Desk), ответы на вопросы, решение проблем.
  4. Управление изменениями: планирование новых релизов, согласование и внесение доработок, расширение функционала.
Эксплуатация может быть организована по-разному: в некоторых компаниях есть отдельный отдел сопровождения, в других DevOps-команда объединяет процессы разработки и поддержки в единый цикл.

23.2. Роль системного аналитика в эксплуатации
Хотя основное внимание аналитика обычно сосредоточено на разработке и постановке требований, в эксплуатационной фазе он тоже участвует:
1. Сбор обратной связи
  • Отслеживает, какие вопросы и проблемы поднимают реальные пользователи (через техническую поддержку, сервис-деск).
  • Анализирует жалобы, идеи улучшений. Помогает «перевести» их в новые требования или задачи на доработку.
2. Приоритизация улучшений
  • Визирует, какие замечания пользователей действительно критичны для бизнеса.
  • Помогает сформировать бэклог изменений и согласовать их сроки.
3. Актуализация документации
  • Если в ходе эксплуатации обнаруживаются неточности или новые нюансы, аналитик обновляет требования, рабочие инструкции, прототипы.
  • Служба поддержки и инженеры эксплуатации обращаются к аналитику за пояснениями, если в документации не всё явно описано.
4. Участие в анализе инцидентов
  • При серьёзных инцидентах (сбой функционала, нарушение бизнес-логики) аналитик помогает понять, являются ли они следствием неверной реализации требований или ошибочного сценария использования.
  • Может потребоваться корректировка документов, формулировка обходных путей (workaround).
5. Работа над релизами
  • Иногда аналитик выступает и как «промежуточное звено» при планировании релизов (Release Management), согласуя с бизнесом, какие баги или фичи войдут в очередное обновление.
  • Уточняет, не меняются ли ключевые бизнес-процессы или нефункциональные требования по ходу эксплуатации.
Таким образом, аналитик продолжает поддерживать прозрачность между эксплуатационной командой и бизнесом, убеждаясь, что система не просто «работает», а работает так, как нужно для достижения целей.

23.3. Мониторинг и SLA
Вопросы мониторинга и уровня обслуживания (SLA — Service Level Agreement) становятся центральными для эксплуатации:
1. Мониторинг
  • Настраиваются системы отслеживания метрик: доступность (uptime), время отклика, загрузка процессора и памяти, использование диска, количество ошибок.
  • Инструменты: Zabbix, Prometheus, Grafana, New Relic, Datadog и др.
  • Если метрики выходят за допустимые пределы, инженеры эксплуатации получают уведомление (alert) и принимают меры.
2. SLA
  • Договорённые показатели (например, «система доступна 99,9% времени», «время ответа не более 2 секунд при нагрузке N пользователей»).
  • Регламентирует, как быстро должны реагировать на инциденты: критические (P1) чинятся в течение X часов, менее серьёзные (P2, P3) — в течение Y.
  • Аналитик может участвовать в формулировании SLA на этапе требований, а затем контролировать, соблюдается ли он.
3. Логи и аудит
  • Лог-файлы систем, журнал действий пользователей, истории запросов.
  • Помогают разбирать инциденты и анализировать рабочую нагрузку.
  • Аналитик, при необходимости, может изучить логи для понимания реальных пользовательских сценариев и возникших ошибок.
23.4. Инцидент-менеджмент и поддержка
Инцидент-менеджмент — это процесс обнаружения, регистрации и устранения инцидентов (сбоев, неполадок). На практике он часто реализован через:
  1. Service Desk (Jira Service Management, ServiceNow, OTRS и др.), где пользователи создают заявки.
  2. Приоритизацию: поступившие инциденты классифицируются по критичности (влияет ли на ключевой бизнес-процесс, сколько пользователей затронуто).
  3. Диагностику: поддержка пытается воспроизвести проблему и локализовать причину.
  4. Устранение: если нужно менять код, создаётся задача для разработчиков (или девопсов). Аналитик помогает уточнить, связана ли ошибка с требованиями и нужна ли корректировка документации.
Системный аналитик может участвовать в разборе особенно сложных инцидентов, связанных с неправильной бизнес-логикой или неучтёнными сценариями, чтобы внести ясность в требования или предложить workaround.

23.5. Изменения и эволюция системы
Внедрённая система редко остаётся статичной: бизнес-процессы меняются, появляются новые возможности, растут объёмы данных. Так происходит эволюция:
1. Планирование новых фич
  • Бизнес видит, что можно улучшить, аналитик собирает идеи, формирует backlog.
  • Впоследствии это может вылиться в новый проект или релиз (развитие системы).
2. Управление релизами и обновлениями
  • Обсуждаются сроки релизов, тестовые среды, миграция данных, обучение пользователей.
  • Аналитик контролирует, чтобы новые изменения не противоречили существующим процессам и не ломали ранее реализованные функции.
3. Рефакторинг и оптимизация
  • Если система начала «тормозить», возможно, нужно пересмотреть архитектуру, оптимизировать запросы к БД.
  • Аналитик может помочь определить приоритеты (какие процессы самые критичные для бизнеса) и цели оптимизации.
4. Документирование новых версий
  • При каждом обновлении важно не забыть обновить инструкции, архитектурные схемы, описание интеграций.
  • Аналитик снова связан с командой сопровождения, чтобы всё было синхронизировано.
23.6. Обратная связь от пользователей и улучшение UX
Реальные пользователи зачастую дают наиболее ценную обратную связь о том, насколько система удобна, понятна и действительно решает их задачи. Методы, которые могут применяться:
1. Опросы и анкеты
  • «Насколько удобно работать в новом интерфейсе? Какие функции вам не хватает?»
  • Сбор показателей удовлетворённости (CSAT, NPS).
2. Запись сессий и аналитика интерфейса
  • Анализ того, какие страницы и кнопки наиболее востребованы, где люди чаще всего совершают ошибки или бросают процесс.
  • Инструменты вроде Hotjar, UXCam (для веб- и мобильных приложений).
3. Интервью с пользователями
  • Аналитик может встретиться (онлайн/очно) с представителями ключевых ролей и выяснить их болевые точки, идеи по улучшению.
  • Такие интервью помогают выявить «скрытые» проблемы, которые не отражаются напрямую в логах.
4. Регулярные встречи с бизнесом
  • Если система критична для нескольких отделов (продажи, финансы, склад), аналитик организует рабочие сессии, где обсуждаются результаты внедрения и дальнейший roadmap.
Вывод по главе 23
Эксплуатация и сопровождение — это не просто «завершение» проекта, а продолжение жизненного цикла системы. В этот период:
  1. От реального использования поступает масса обратной связи, обнаруживаются неточности или новые возможности для развития.
  2. Важнейшую роль играет мониторинг, инцидент-менеджмент, обновление системы, включая документацию и ролевую модель.
  3. Системный аналитик остаётся связующим звеном между бизнесом, командой сопровождения и разработчиками:
  • Помогает понять, соответствует ли система бизнес-требованиям на практике;
  • Уточняет и вносит изменения в требования;
  • Участвует в планировании новых релизов и оптимизаций.
В итоге, при грамотной организации эксплуатации и сопровождения, система не «застаивается» и не теряет актуальность, а эволюционирует вместе с потребностями бизнеса, при этом сохраняя стабильность и предсказуемость работы для пользователей.

Об авторе

■ Другие статьи по теме Архитектура

Показать еще

■ Другие статьи по теме Интеграция

■ Другие статьи на тему Базы данных

Показать еще

■ Другие статьи на тему User Stories и Use Cases

■ Другие статьи на тему Требований

Показать еще

■ Другие статьи на тему Бизнес-анализ

■ Другие статьи на тему Профессия и трудоустройство

Показать еще

■ Другие статьи на тему Проектное управление

■ Другие статьи на тему Менеджмент и архитектура предприятия

Показать еще

■ Другие статьи на тему Дизайн интерфейсов и исследования