Привет! Меня зовут Индира. Я системный аналитик в банке и ревьюер на курсе «Системный аналитик» в Практикуме. В IT я более 10 лет: начинала как бизнес-аналитик, затем перешла в системный анализ и была лидом группы аналитиков, а также владельцем продукта. 

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

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

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

1. Сбор информации

Владелец продукта устно рассказывает суть задачи или описывает её в формате user story: «Я как пользователь хочу узнать реквизиты счета у виртуального ассистента, чтобы переслать их».

В этом контексте я задумываюсь, какую информацию мне нужно собрать, чтобы превратить «хотелку» бизнеса в полноценное описание. Вот несколько вопросов, на которые мне нужно ответить:

• Как именно будет выглядеть запрос на получение реквизитов?

• Какие конкретные запросы пользователь может ввести?

• Как будет оформлен вывод реквизитов?

Дополнительно я ищу референсы — примеры успешно реализованных навыков виртуального ассистента. Например, хороший пример уже есть у Т-Банка.

2. Бизнес-требования

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

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

В большинстве компаний задачи бизнес-анализа и системного анализа выполняют разные специалисты, но в моей компании это делает один человек. 

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

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

Моя задача — детализировать user story до описания конкретного процесса, чтобы понять, какие действия пользователя порождают задачи у виртуального ассистента. 

Для визуализации процесса я создаю BPMN-диаграмму (Нотация BPMN (Business Process Modeling Notation), Нотация моделирования бизнес-процессов) — это метод составления блок-схем, отображающий этапы выполнения бизнес-процесса от начала до конца. BPMN-схемы наглядно и подробно демонстрируют последовательность рабочих действий и перемещение информационных потоков, необходимых для выполнения процесса. Также могу использовать диаграмму активностей (activity diagram), подробнее про то, как спроектировать диаграмму, можно почитать здесь.

3. Системные требования

На основе описанного процесса я углубляюсь на уровень системы — виртуального ассистента. Моя задача — расписать задачи каждого слоя системы: frontend, backend и СУБД, а также требования к взаимодействию между слоями. 

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

• Какие задачи виртуального ассистента выделены на BPMN-диаграмме?

• Как каждый запрос пользователя будет реализован на конкретном слое системы: frontend, backend и БД?

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

4. Пользовательский интерфейс, REST API и база данных

Прочитать, что такое REST API и методы HTTP-протокола можно здесь. 

Базы данных (БД) — это то, где хранятся данные, организованные особым образом, иногда — в зашифрованном виде. Если это реляционные базы, то данные представлены в виде таблиц, связанных друг с другом. Если объектные — в виде объектов: блоков информации с определёнными свойствами и параметрами. 

Смотря на макет (для примера возьмём за основу референсы Т-Банка), описываю требования к пользовательскому интерфейсу экран списка счетов:

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

Backend должен реализовать метод get /accounts?userId={usertId}, где 

Параметры url:

Выходные параметры:

Я также определяю, какие таблицы в базе данных требуются для реализации всех функций. 

В моем случае база данных реляционная и таблицы с пользователями (users) и их счетами (accounts) уже созданы. Один пользователь может иметь несколько счетов, при этом каждый конкретный счет принадлежит только одному пользователю, поэтому  отношение между сущностями users и accounts является отношением один-ко-многим. 

Данные из соответствующих полей таблицы accounts необходимо передавать в качестве выходных параметров метода get /accounts?userId={usertId}. 

5. Обсуждение с командой

Техническое задание готово! Но это не конец работы, теперь его нужно обсудить с командой (в основном это с разработчиками и тестировщиком). Совместно мы перепроверяем, что все аспекты учтены.

На примере своей команды расскажу, с какими специалистами взаимодействует системный аналитик: 

• Владелец продукта проекта (Product Owner) — отвечает за развитие продукта, а также планирование, координацию и контроль выполнения проекта, управляет сроками и ресурсами. Ставит задачу аналитику: доработка продукта (я совмещаю роли бизнес-аналитика и системного).

• Бизнес-аналитик (Business Analyst) — выясняет требования клиентов и анализирует бизнес-процессы для определения потребностей разработки. 

• Системный аналитик (System Analyst) — работает с техническими специалистами для проработки архитектуры системы и технических требований. Ставит задачи разработчикам.

• Frontend-разработчик — занимается разработкой пользовательского интерфейса.

• Backend-разработчик — отвечает за серверную часть и логику приложения.

• UI/UX-дизайнер (UI/UX Designer) — разрабатывает удобный и привлекательный интерфейс, отвечает за опыт пользователя.

• Тестировщик (QA Engineer) — проводит тестирование программного обеспечения для выявления ошибок и обеспечения качества продукта. Проверяет, чтобы все требования, описанные в техническом задании, были реализованы.

• DevOps-инженер — отвечает за автоматизацию процессов разработки и развёртывания, а также за инфраструктуру и системное администрирование.

• Архитектор программного обеспечения (Software Architect) — проектирует архитектуру системы, выбирает технологии и платформы, определяет стандарты разработки. 

Это основные роли для большинства IT-команд. В зависимости от проекта и компании некоторые роли могут быть совмещены или дополнены другими.

6. Постановка задачи в Jira

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

7. Проверка результата

Когда навык реализован и доступен на тестовом стенде, я проверяю критерии приёмки, чтобы убедиться, что конечный продукт полностью соответствует ожиданиям и требованиям (это необязательное действие, так как проверкой результатов у нас занимается тестировщик, но мне самой интересно посмотреть на результат моего проектирования).

Вот какие критерии приёмки будут в нашем текущем примере: 

1. Пользователь запрашивает реквизиты счёта.

2. Пользователь переходит по ссылке в раздел с реквизитами счёта.

Если я заметила несоответствие требованиям, то связываюсь с тестировщиком и сообщаю о найденном кейсе, а он уже заводит баг в Jira, если ещё не завёл.

Так мы с командой создаём полезного и удобного виртуального ассистента, который сможет эффективно выполнять задачи пользователей!

Вместо выводов

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

• описание процессов: умение проектировать BPMN-диаграмму, activity diagram и sequence diagram

• проектирование REST API

• проектирование баз данных (почитать можно здесь).

А вот как упростить работу помогут софтскилы: 

1. Поймите бизнес-цели задачи, чтобы составить осмысленные требования. 

2. Не забывайте фиксировать бизнес-потребности, чтобы помнить про источник системных требований.

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

4. Не стесняйтесь просить помощи и уточнять непонятные моменты — понимание задачи играет важную роль.

5. Обращайте внимание на возможные риски и предпринимайте меры по их предотвращению, например, проговаривая их на встречах.

6. Фиксируйте открытые вопросы, детали встреч и ответы, чтобы в любой момент вернуться к ним и дополнить информацию.

7. И помните, что важна не столько форма, сколько содержание документа и коммуникации в команде.

P.S. Я считаю, что в системном анализе ключевой навык — умение учиться, ведь всё остальное можно подтянуть с практикой и опытом.