Для кластера

Организация процесса внутри кластера

В данной статье описывается процесс взаимодействия между владельцем продукта (Product Owner, PO) и IT-лидером (Tech Lead, TL) внутри команды. Каждая команда работает над своим направлением (МЛМ, БНПЛ, МФО), но процессы организации работы стремятся быть унифицированными.

Структура кластера

Применимо к каждой команде кластера:

• Каждая команда имеет владельца продукта (PO) и IT-лидера (TL)
• Внутри команды работают системные аналитики, тестировщики, разработчики
• Архитектор и DevOps находятся вне команд, предоставляя услуги всему кластеру

Роли и ответственность

Владелец продукта (PO)

• Отвечает за бизнес-цели и приоритеты продукта
• Формирует бэклог задач
• Взаимодействует с заинтересованными сторонами
• Принимает решения о том, что будет реализовано в следующем спринте/релизе
• Контролирует соответствие продукта ожиданиям пользователей

IT-лидер (TL)

• Отвечает за техническую реализацию продукта
• Координирует работу внутри команды (разработчики, тестировщики, аналитики)
• Разрабатывает технические решения совместно с архитектором
• Гарантирует качество кода и соблюдение стандартов разработки
• Решает технические конфликты и балансирует нагрузку между участниками команды

Границы ответственности

Распределение ответственности

Вопрос	Ответственный
Определение бизнес-целей	Владелец продукта (PO)
Техническая реализация	IT-лидер (TL)
Приоритизация задач	Владелец продукта (PO) + IT-лидер (TL)
Качество продукта	IT-лидер (TL) + тестировщики
Инфраструктура	DevOps (по запросу)
Архитектурные решения	Архитектор + IT-лидер (TL)

Процесс взаимодействия

1. Сбор требований

• Владелец продукта собирает требования от заинтересованных сторон
• Владелец продукта формирует эпики (epic) и user stories
• Владелец продукта передает требования IT-лидеру для оценки их технической реализуемости

2. Оценка задач

• IT-лидер проводит технический анализ требований вместе с системными аналитиками и архитектором
• Команда оценивает трудозатраты (story points) на выполнение задач
• Владелец продукта и IT-лидер согласовывают приоритеты и сроки реализации

3. Планирование

• Владелец продукта составляет backlog для спринта
• IT-лидер распределяет задачи внутри команды
• Архитектор и DevOps предоставляют необходимые ресурсы и инфраструктуру

4. Разработка

• Разработчики пишут код под руководством IT-лидера
• Тестировщики проверяют качество продукта
• Владелец продукта получает демо-версии и дает фидбек

5. Релиз

• IT-лидер координирует выпуск продукта
• DevOps настраивает CI/CD и деплоит изменения
• Владелец продукта информирует заинтересованных сторон о релизе(выпуск realise notes)

6. Обратная связь

• Владелец продукта собирает отзывы пользователей, корректирует метрики
• IT-лидер анализирует технические проблемы и предлагает улучшения

Управление приоритетами

• Если решение принимает PO:
  • PO определяет бизнес-приоритеты на основе целей компании и обратной связи от заинтересованных сторон
  • TL предоставляет информацию о технических ограничениях и рисках
• Если решение принимает TL:
  • TL может пересмотреть приоритеты в случае технических сложностей или рисков для стабильности продукта
  • Важно, чтобы TL обосновывал свои решения перед PO

Роль архитектора

• Архитектор работает на уровне кластера, но временно выделен на одно направление
• Для других направлений архитектор должен быть доступен для консультаций
• Рекомендуется:
  • Проводить регулярные встречи между архитектором, PO и TL для согласования решений
  • Документировать архитектурные решения, чтобы они были доступны всем командам

Роль DevOps

• DevOps предоставляют услуги по запросу, но важно:
  • Создать четкие SLA для реакции на запросы
  • Автоматизировать процессы CI/CD, чтобы минимизировать зависимость от DevOps

Инструменты управления проектами

• Бэклог: Ведется в облачной таблице
• Задачи на спринт: Заводятся в "Сфере.Задачи"

Метрики успеха

Базовые показатели:

• Для PO: скорость выпуска функционала, удовлетворенность пользователей
• Для TL: качество кода, количество багов, время на исправление ошибок
• Для команды: скорость выполнения задач (velocity), процент выполненных задач в спринте

Дополнительные мероприятия

• Еженедельные встречи PO и TL для согласования приоритетов и обсуждения текущих проблем
• Общие ретроспективы на уровне кластера для выявления узких мест во взаимодействии между командами
• Создание матрицы RACI для четкого распределения ролей между PO, TL и другими участниками

Матрица RACI(DRAFT)

Определение ролей

Роль	Описание
Владелец Бэклога(PO)	Формирует и приоритизирует задачи разработки
Ответственный за развитие ИС	Обеспечивает развитие информационных систем
Корпоративный технолог	Разрабатывает технологические стандарты
Технолог Решения	Формирует требования к решениям
Системный аналитик	Разрабатывает функциональные требования
Архитектор Решения	Проектирует архитектуру системы
Разработчик	Реализует функциональность
Тестировщик	Обеспечивает контроль качества
DevOps	Разрабатывает CI/CD процессы

Полная матрица RACI

Процесс	Владелец Бэклога(PO)	Ответств. за ИС	Корп. технолог	Технолог решения	Систем. аналитик	Архитектор	Разработчик	Тестировщик	DevOps
Формирование бэклога	R	I	C	A	C	C	I	I	I
Приоритизация бэклога	R	I	C	A	C	C	I	I	I
Разработка требований	A	C	C	R	R	C	I	C	I
Проектирование архитектуры	I	C	C	C	C	R	C	I	C
Разработка компонентов	I	I	I	I	C	C	R	I	I
Создание тест-кейсов	I	I	I	I	C	I	C	R	I
Проведение тестирования	I	I	I	I	C	I	C	R	I
Автоматизация тестирования	I	I	I	I	I	I	C	R	C
Разработка CI/CD	I	I	I	I	I	C	C	I	R
Управление техдолгом	A	C	C	C	C	R	C	I	C
Приемка результатов	R	I	I	A	C	C	I	A	I
Разработка стандартов	I	I	R	C	C	C	I	I	R

Условные обозначения

• R (Responsible) - непосредственно выполняет работу
• A (Accountable) - утверждает и несет окончательную ответственность
• C (Consulted) - должен быть проконсультирован
• I (Informed) - должен быть информирован о результате

Ключевые взаимодействия

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

См. также

• Управление IT-проектами
• Agile-методологии
• Процесс разработки ПО