Привет! Меня зовут Индира. Я системный аналитик в банке и ревьюер на курсе «Системный аналитик» в Практикуме. В 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-протокола можно здесь

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

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

Элемент

Тип элемента

Счет

button

Иконка валюты счета

icon

Название счета

label

Тип счета

label

Баланс

label

Код валюты

label

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

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

Параметры url:

Параметр

Тип

Обязательность

Описание

userId

String

Обязательный

Идентификатор пользователя

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

Параметр

Тип

Обязательность

Описание

accountId

String

Обязательный

Уникальный идентификатор счета

accountName

String(20) 

Обязательный

Название счета

accountType

String(50)  

Обязательный

Тип счета (например, «текущий», «сберегательный» и т.д.)

balance

Float

Обязательный

Текущий баланс на счете

currency

String(3) 

Обязательный

Валюта счета (например, USD, EUR, RUB)

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

В моем случае база данных реляционная и таблицы с пользователями (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. Фиксируйте открытые вопросы, детали встреч и ответы, чтобы в любой момент вернуться к ним и дополнить информацию.

Дата

Тема встречи и участники

Содержание

20.08.2024

Формат заметки Участники: Индира, системные аналитики

Открытые вопросы (какие вопросы с кем надо обсудить): 

формат ведения заметок — системные аналитики

Результат (какие решения приняты): фиксировать открытые вопросы и решения этих вопросов, чтобы снижать неопределённость в задаче

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

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

Комментарии (7)


  1. iEstale
    06.09.2024 14:33
    +3

    Вроде написано разбираем системного аналитика и опять все в кучу... Вода по другим ролям, BPMN-схемы, которые должен составлять БА, Активити, примера которой нет (как и упоминания про UML) и в скиллах "проектирование БД", которого тут на самом деле тоже нет (вы просто описали класс счета, причем в контексте ответа API, бд проектируется не так).

    "В большинстве компаний задачи бизнес-анализа и системного анализа выполняют разные специалисты, но в моей компании это делает один человек." - вы за границей где-то работали, раз для вас в большинстве компаний это разные люди? Для российского ИТ очень характерно непонимание разделения БА и СА, поэтому это в 90% случаев совмещаемые роли.

    Однажды, я встречу хорошую статью про SA.

    I want to believe.


  1. Vitalis83
    06.09.2024 14:33
    +1

    Только меня смутило 12 мест работы за 10 лет? Это нормально?


    1. Batorskylab
      06.09.2024 14:33

      эйчары поговаривают, что это не нормально


  1. Demox410
    06.09.2024 14:33
    +2

    Выглядит немного не раскрыто. Сам я работаю так же системным аналитиком и хотел бы подсветить пару моментов:
    1. Например проектирование БД включает в себя не только проектирование схемы, а так же продумывание необходимых индексов, прикидывания какие данные будут лежать и сколько, иногда вплоть до продумывания оптимального SQL запроса для каких-либо операций.
    2. Проектирование API почему-то сразу рассматривается REST, а не рассматриваются разные варианты в рамках задачи. Почему REST для чата с ботом, а как подгружать новые сообщения от бота? Еще кажется плохое решение передавать userId в квери параметре, который никак маскироваться не будет)
    3. Ну и еще куча есть стадий, например какие инструменты использовать, нужен ли КЭШ и где, в каком виде хранить, как инвалидировать, какие узкие места, как от них защищаться, например если пользователь начнет кликать 100500 раз, какие ошибки запрос должен возвращать.


    1. Batorskylab
      06.09.2024 14:33

      Индексы, оптимизация SQL запросов - все это ложится на СА в силу каких обстоятельств?
      Предположу, что команда небольшая и в ней нет отдельного архитектора или DBA?

      "Еще кажется плохое решение передавать userId в квери параметре, который никак маскироваться не будет)" - соглашусь, тоже показалось странным...

      Как вариант:
      GET /users/{id}
      Если очень хочется ходить в accounts, то GET /accounts/{id-account}
      Просто странно, что в сущности account идентификатор записи user_id


  1. Batorskylab
    06.09.2024 14:33

    В системном анализе ключевой навык - умение логически мыслить и лаконично излагать свои мысли.


    1. iEstale
      06.09.2024 14:33

      А еще быстро разбираться в непонятных вещах, находя и усваивая большие объемы информации за короткое время.

      Можно научиться рисовать схемки в разных нотациях, научиться классы какие-то составлять, можно даже спеки на oa3.1, gRPS и graphQL делать... И при этом быть так себе аналитиком, потому что вот не дается человеку быстро думать и понимать, когда и как все эти навыки применять правильно. Вот в этом кстати кроется сложность обучения новых кадров. Я всегда говорю ребятам, что я могу им что-то объяснить, но я не могу за них это понять.