Кто? Что? Когда? При решении IT-задач

Привет, меня зовут Шашкова Екатерина - я главный системный аналитик в финтехе и один из авторов развивающего tg-канала для аналитиков - Sprint Аналитика.

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

ЖЦ задачи наследует ЖЦ системы и содержит аналогичные этапы. Классификаций цикла разработки достаточно много, но все они отражают общую структуру. Для наглядности и более глубокого понимания процесса реализации задач в статье выделены следующие этапы:

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

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

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

Эта статья будет полезна тем, кто хочет определиться с направлением развития в IT или только начинает свой путь. Опытным специалистам предлагаю проверить, все ли роли есть в вашей команде, чтобы составить полную картину происходящего. Может у вас на проекте есть компетенции, которые мне не встречались? Предлагаю собрать полный список в комментариях.

Итак, поехали. Как и в любом деле, все начинается с планирования.

Участники: заказчик, владелец продукта (product owner, PO), менеджер проекта (project manager, PM), бизнес-аналитик (БА, BA)

Суть:

На этом этапе осуществляется выявление и приоритезация потребностей заказчика, формирование требований к продукту, оценка рисков и составление плана работ.

Менеджер проекта отвечает за планирование, контроль бюджета, распределение ресурсов. Владелец продукта определяет общую стратегию и видение продукта. Если на проекте нет PM, то его функции выполняет PO. Совместно менеджеры формируют бэклог проекта, за исполнением которого будут следить на следующих этапах.

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

Результат: Сформирован бэклог

Итоговые артефакты: Бэклог

Участники: заказчик, БА, системный аналитик (СА, SA), опционально дизайнер UI/UX

Суть:

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

Основные задачи на данном этапе выполняет бизнес-аналитик. Он погружается в потребности бизнеса и проводит несколько встреч со стейкхолдерами. БА выявляет, формулирует и группирует по типам все виды требований, анализирует текущий (as is) и будущий (to be) бизнес-процессы. Все требования бизнес-аналитик фиксирует в BRD (Business Requirements Document - документ, содержащий верхнеуровневые требования к изменению) и согласует с заказчиком.

Также на данном этапе БА определяет пользовательские сценарии и формирует прототипы экранных форм, чтобы передать их дизайнеру UI/UX для создания макетов. На эти макеты будут ориентироваться все стейкхолдеры, в том числе команда разработки.

Далее БА передает BRD системному аналитику, чтобы он мог дополнить их техническими артефактами, а также проверить реализуемость.

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

Результат: Согласованы требования с заказчиком

Итоговые артефакты: BRD

Участники: БА, СА, архитектор, технический лидер (техлид) или senior любой роли, опционально владелец продукта и заказчик

Суть:

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

Начинает этап БА, который формирует несколько вариантов решений бизнес-процесса to be с учетом всех требований и анализа процесса as is, которые подготовлены на предыдущем этапе.

Далее БА совместно с СА и техническим лидером (или senior) выбирают оптимальное решение с учетом потребностей заказчика и технических ограничений.

Если оптимальными считаются несколько вариантов реализации, то к выбору привлекается владелец продукта и заказчик, которые принимают управленческие решения с учетом всех рисков. Итоговый бизнес-процесс to be БА согласует с заказчиком.

Совместно с техлидом или senior специалистом команды выбирают технологию реализации данного решения. Далее СА описывает спроектированное решение в техническом задании (ТЗ) или спецификации изменения, обогащая его описанием интеграций, схемами технических алгоритмов, атрибутами, маппингом данных и т.д.

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

Результат: Спроектирован итоговый бизнес-процесс и техническая реализация, опционально создана архитектура

Итоговые артефакты: Техническое задание, архитектурный документ

Участники: разработчики (фулстек, бэкенд, фронтенд), техлид

Суть:

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

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

Если в команде есть бэкенд (backend) и фронтенд (frontend) разработчики, то они пишут свои части кода параллельно. Каждый специалист реализует конкретную часть ТЗ. Если задачу реализует фулстек-разработчик (fullstack), то он пишет код и для внутренней и для внешней части функционала.

Завершением данного этапа является скомпилированный проект, для поставки доработки пользователям

Результат: Написан код

Итоговые артефакты: Код проекта (Скомпилированный проект)

Участники: тестировщики (QA функциональный/ручной тестировщик), автотестировщики (AQA), нагрузочные тестировщики (НТ)

Суть:

На данном этапе проводится всестороннее тестирование изменения. Задача тестировщиков всех направлений проверить соответствует ли описание доработки в ТЗ тому, что реализовано разработчиками на предыдущем шаге.

Для этого в некоторых командах проводится встреча между СА, разработчиком и тестировщиком для передачи задачи в тестирование. Аналогично этапу разработки, тестировщики консультируются с СА по ТЗ, а также могут дополнить или скорректировать описание.QA создает чек-листы с набором необходимых проверок по задаче, который затем согласует с разработчиком и системным аналитиком. На основе чек-листов по необходимости тестировщик описывает тест-кейсы, которые также согласует с участниками команды.

При проведении тестирования QA фиксирует найденные баги и анализирует результаты тестирования. Если ошибка в формулировке ТЗ, то ее исправляет аналитик, а если в коде, то разработчики.

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

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

Результат: Протестировано изменение

Итоговые артефакты: Тест-кейсы, чек-листы

Участники: Инженеры по внедрению

Суть:

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

Результат: Внедрено изменение

Итоговые артефакты: Релизный документ, задача на deploy и план поставки

Участники: специалисты поддержки и сопровождения, бизнес-поддержка

Суть:

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

Бизнес-поддержка создает инструкции и проводит обучение пользователей. Также занимается подсчетом и анализом метрик, которые отражают эффективность доработки в соответствии с выделенными критериями качества на этапе анализа.

Результат: Обеспечено сопровождение системы, проведено обучение пользователей и определена эффективность изменения

Итоговые артефакты: Метрики и отчеты

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

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

А еще больше полезного вы можете найти на нашем tg-канале - Sprint Аналитика.