Итак, возьмем несколько стандартных описаний Системного аналитика:
- IT профессия с широким спектром действий
- анализирует, оптимизирует и автоматизирует работу компании и ее подразделений
- преобразует требования в технические спецификации.
Написано красиво, но понятно ли из этих определений, что необходимо делать такому сотруднику? Мне нет...
Попробуем разобрать по пунктам. Сначала посмотрит стандартный состав IT команд:
- Product/Project менеджер
Руководитель вашего проекта, или продукта в целом (один продукт может содержать несколько проектов) - курирует проект в целом, отвечает за бюджет, общую концепцию, постановку задач и их контроль. Обязанности могут несколько отличаться в зависимости от проекта.
- Аналитики (Бизнес и системные)
В зависимости от проекта могут присутствовать как аналитики 2-х видов, так и кто-то один. Часто их путают и объединяют, иногда убирают бизнес аналитиков и за все отвечают системные. Что же они делают - получают задачу на внесение каких-то изменений или добавление чего-то нового в продукт (сайт, приложение на мобильном, программу и т.п.). Проверяют что необходимо сделать, что нужно изменить в текущем продукте, согласовывают макеты, анализируют ограничения, проводят встречи с заказчиком. И в итоге - перекладывают все неоформленные "хотелки" по новому функционалу в четкие и понятные требования (ТЗ) для разработчиков.
- Разработчики
Разрабатывают и реализовывают функционал, описанный аналитиками.
- Тестировщики
На основании написанного технического задания - тестируют разработанный функционал - проверяют работоспособность, соответствие требованиям, пытаются протестировать поведение системы (сайта, приложения и т.п.) в нестандартных условиях.
Так же команда может включать в себя дизайнера и архитектора. В зависимости от нагрузки дизайнер и архитектор могу работать как на одном проекте, так и сразу на нескольких.
Теперь, когда мы представляем примерный состав команды и зону ответственности каждого участника, поговорим подробнее о системных аналитиках.
Иногда их соединяют с бизнес аналитиками, и в этих случаях Системный аналитик выполняет сразу 2 функции.
Предположим, что у нас есть интернет магазин, и добавить товар в корзину можно только из карточки товара. Заказчик хочет добавить новую кнопку. Функционал кнопки: добавить товар в корзину из списка товаров (без открытия каждой карточки товара)
Задача аналитика - проанализировать задачу, задать вопросы заказчику и написать ТЗ На кнопку.
Опишем некоторые шаги по этой задаче (внимание, список не является конечным - это только пример)
1. Выясним как должна выглядеть кнопка: цвет, размер, расположение, меняется ли кнопка после того как на нее нажали. Готовим дизайн проект( или используем дизайн предоставленный заказчиком), анализируем дизайн - не диссонирует ли он с общим дизайном сайта, насколько приятен и понятен и т.п.
2. Параллельно с внешним видом начинаем анализировать технические требования к кнопке:
- Будет ли функционал кнопки одинаковый для авторизованных и неавторизованных пользователей?
- Что происходит после нажатия на кнопку (Пользователь остается на той же странице, а товар добавляется в корзину? Добавляется ли ссылка для перехода в корзину сразу после добавления товара? Меняется ли внешний вид кнопки после добавления товара в корзину? Где и как отображается и регулируется количество добавляемого товара в корзину? При повторном нажатии на кнопку в корзину добавится еще одна единица товара или товар будет удален из корзины? и пр.)
- Если выбранный товар уже не доступен к заказу - кнопка будет неактивной? Как будет выглядеть дизайн для неактивно кнопки? Будет ли отображаться подсказка/ошибка, что товара уже нет в наличии?
3. Далее смотрим есть у нас какие-то ограничения? Например, обязательный договор Оферта, есть ли на него ссылка на страницах где мы располагаем кнопку? Есть ли ограничения по возрасту на приобретение нашего товара? Есть ли какие-то ограничения по регионам и прочие возможные нюансы касающиеся законодательства, возможностей доставки.
Когда все моменты уточнены и выяснены, макеты утверждены - пишем техническое задание.
Четко расписываем поведение и внешний вид кнопки в разных статусах, прописываем сценарии использования. При необходимости прорисовываем модели процесса, пишем какие изменения при нажатии кнопки произойдут в базе данных. Это уже будет наше техническое задания для разработки.
В процессе разработки аналитик участвует как консультант для разработчика: если что-то не описано, это надо описать, если что-то не понятно - объяснить как должно работать и возможно подкорректировать требования.
После того как разработка закончена, бывает что аналитик занимается приемочным тестирование, или помогает тестировщикам писать тесты с использованием различных инструментов. Но это уже совсем другая история, а в конце проводит демонстрацию разработанного функционала заказчику. Но в зависимости от устоявшегося порядка в команде обязанности могут незначительно отличаться. =)
