Роль системного аналитика

В разных командах слово «аналитик» означает разное: где-то это человек, который пишет документы, где-то тот, кто решает, что делать дальше, а где-то тот, кто выбирает технологии. Границы между ролями размыты, поэтому по названию должности понять, чья это задача, нельзя. Зато по самой задаче понять можно: у каждой роли свой вопрос, на который она отвечает. Разберём это на одной фразе владельца «Узелка» и найдём тот вопрос, который принадлежит системному аналитику.

Кейс: «Хотим принимать оплату картой»

Владелец «Узелка» на встрече говорит: «Хотим, чтобы покупатели могли оплачивать заказ картой на сайте». Все кивают, а потом у каждого за столом возникает свой вопрос. Сам владелец думает, нужно ли это прямо сейчас или сначала доставка. Старший разработчик думает, через какой платёжный сервис подключаться и где хранить статусы платежей. А разработчик страницы не знает, что показывать покупателю, если банк отклонил карту. Три вопроса родились из одной фразы, и отвечают на них разные роли, о которых рассказывала статья 01-03.

Рисунок 1. Фраза владельца и три вопроса разных ролей

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

Что системный аналитик делает на практике

Работа складывается из трёх шагов, которые повторяются для каждой задачи. Сначала он выясняет, что нужно на самом деле: разговаривает с владельцем продукта, пользователями и командой. Потом описывает решение так, чтобы по нему можно было работать: действия пользователя, данные, правила, связи с другими системами. И наконец отвечает на вопросы команды по ходу работы и проверяет, что сделанное совпадает с описанным.

Рисунок 2. Три шага работы системного аналитика над задачей

Для оплаты картой фрагмент такого описания выглядит так. Сценарий (последовательность действий пользователя и ответов системы) «Банк отклонил карту»: покупатель нажимает «Оплатить», банк не принимает платёж. Заказ остаётся в статусе «Ожидает оплаты». Покупатель видит сообщение «Банк не принял платёж» и кнопку «Попробовать снова». Дальше возникает вопрос, на который аналитик сам не ответит: сколько времени заказ ждёт оплаты, прежде чем отменяется. Это решение про деньги и остатки товара, поэтому аналитик задаёт его владельцу продукта и записывает ответ, а не пишет на один день «на всякий случай».

Рисунок 3. Сценарий отказа банка и открытый вопрос к владельцу продукта

Какие документы остаются после такой работы: требования, схемы процессов и данных, описания обмена с другими системами, разбирает раздел 8, начиная со статьи 08-01.

Чем он отличается от соседних ролей

Рядом работают ещё три роли, и границы с ними размыты. Бизнес-аналитик изучает потребности и процессы бизнеса и предлагает, что в них менять: бизнес-анализ описывают как практику, которая помогает организации меняться, определяя потребности и предлагая решения. Product owner решает, что делать и в каком порядке. Архитектор решает, из чего построить систему и как связать её части. Системный аналитик стоит между ними: он получает цель от бизнеса и превращает её в описание, которое можно передать в разработку.

Рисунок 4. Роли product owner, бизнес-аналитика, системного аналитика и архитектора на оси от бизнеса к технике

Роль	Главный вопрос	Пример в «Узелке»
Product owner	Что и зачем делать в первую очередь	Оплата картой раньше доставки или позже
Бизнес-аналитик	Как работает бизнес и что в нём менять	Как сейчас берут оплату при получении и где теряются заказы
Системный аналитик	Что должна делать система	Что видит покупатель, если банк отклонил карту
Архитектор	Из чего построить и как связать части	Через какой платёжный сервис подключаться

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

Как понять, чья это задача

Разбираться стоит по вопросу, который стоит за задачей. Если вопрос о том, нужно ли это и что важнее, он у product owner. Если о том, как работает бизнес сейчас, у бизнес-аналитика. Если о том, что должна делать система в конкретной ситуации и какие данные для этого нужны, у системного аналитика. Если о том, из чего это построить и как связать, у архитектора.

Часто в одной задаче сразу несколько вопросов. Возьмём просьбу «добавьте на страницу заказа поле для промокода». Нужен ли промокод и подождёт ли он доставки, решает владелец продукта. Как скидка ведёт себя, если покупатель вернул один товар из трёх, описывает системный аналитик. Где хранить промокоды и как не перегрузить сайт в день рассылки, решает архитектор. Ошибка, которая встречается часто: ответить на чужой вопрос. Если не дождаться решения владельца и записать «промокод не сочетается с акциями» самим, получится правило работы магазина, которого никто не утвердил. Правильный ход: принести владельцу варианты и последствия каждого.

Рисунок 5. Путь вопроса о промокоде от вопроса до записи решения

Где это встречается в работе

Вопрос разработчика по ходу работы. «Что показывать, если банк не ответил?»: это вопрос о поведении системы, и с ним идут к автору требований.
Планирование работ. Владелец продукта выбирает между оплатой картой и доставкой и хочет знать, сколько труда и рисков за каждым вариантом, прежде чем решить.
Выбор технического решения. Архитектор предлагает вынести оплату в отдельный сервис, и нужно успеть выяснить, как изменятся сценарии покупателя.
Спор о расхождении. Тестировщик нашёл, что экран не совпадает с требованием, и по тексту требования решают, что исправлять: экран или требование.
Новая должность в команде. Одна и та же должность описывает разные задачи, поэтому смотрят на список обязанностей, а не на название.

Итог

Системный аналитик отвечает на вопрос «что должна делать система», и поэтому его результат нужен всем, кто будет работать дальше: разработчик берёт из него сценарии и правила, тестировщик проверяет по ним. Границы с владельцем продукта, архитектором и бизнес-аналитиком размыты, поэтому надёжнее смотреть не на название роли, а на вопрос, на который отвечает человек.

Что дальше

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

01-05. Из чего состоит приложение: интерфейс, бэкенд, база данных.
01-06. От идеи до релиза: жизненный цикл разработки и путь задачи.
02-04. Уточняющие вопросы: как выяснять, что нужно на самом деле.