Александр Крючков — Как поднять мотивацию команды и вывести проект из проблемной зоны

Как поднять мотивацию команды и вывести проект из

проблемной зоны

Александр Крючков

Senior Project Manager

Ciklum

Обо мне

• Senior Project Manager, Ciklum

• 13 лет опыта в ИТ

• 10 лет управляю командами и проектами

• Начинал как разработчик

• В докладе показан опыт конкретного менеджера на

конкретном проекте

• Примененные приемы не универсальны

• Другой менеджер решал бы проблемы другим

способом и, возможно, с лучшим результатом

Проект, команда и проблемы

Проект и команда

BE/TL BE BE BEBEBEBE

FE FE FE FE FE

QA QA QA QA

BA

PO/PM PM

Компания-клиент

Компания-разработчик

Проект и команда

BE/TL BE BE BEBEBEBE

FE FE FE FE FE

QA QA QA QA

BA

PO/PM PM

Компания-клиент

Компания-разработчик

Склонен к микроменеджменту

Держит технические решения «в голове»

Недовольны командой

«Не любят» клиента

Проект и команда - география

BE/TL BE BE BEBEBEBE

FE FE FE FE FE

QA QA QA QA

BA

PO/PM PM

Компания-клиент

Компания-разработчик

Что еще:

• Технически сложный проект

• Много интеграций с незнакомыми системами

• Распределенная команда

• Клиент участвует в разработке

• Scrum

• Задержка по срокам, риск срыва релиза

• Команда дает неточные оценки

• Команда демотивирована

Что огорчало команду

• Задержки сроков

• Микроменеджмент

• Долгие неэффективные митинги с клиентом

• Сравнение команды с разработчиками клиента

• Постоянные просьбы переоценить скоуп

• Давление при спринт-планнингах

• Претензии со стороны клиента “почему они не ...”

Решение

Шаг 1 - Разговор с командой

• Для чего мы ходим на работу?

• За что мы её любим?

• Почему сложилась такая ситуация?

• Что сделать чтобы стало лучше?

• «Я займусь клиентом, но без вас успеха не будет»

• Как должен работать ответственный инженер

Шаг 2 - Перераспределение ролей

PO/PM PM

• Цели• Требования• Приоритеты• Внутренние

стейкхолдеры клиента

• Процесс разработки

• Структура команды и роли в ней

PO/PM BE/TL PO/PM PM

• Цели• Требования• Приоритеты• Внутренние

стейкхолдеры клиента

• Процесс разработки

• Структура команды и роли в ней

Шаг 3 - Процесс

Было

Scrum

Спринты по 2 недели

Смена приоритетов на планировании спринта

Стало

Kanban

Релизы с фиксированным скоупом и гибкой датой

Смена приоритетов возможна всёвремя:- Управление приоритетами в Jira- Метки (labels) для разных групп

задач

Шаг 4 - Оценки и статус

Было

Оценки в стори-поинтах«Торговля» с клиентом за оценки

Велосити считалась по стори-поинтам, но не была стабильной

Еженедельные отчеты клиенту

Стало

Задачи не оцениваются

Велосити = количество закрытых задач в неделю

Частые (вплоть до ежедневных) статус-отчеты от ПМа

Шаг 5 - Меньше неэффективной коммуникации

Было

Ретроспективы с клиентом, каждый спринт

Дейли с клиентом

Планинги всей командой

Все общаются со всеми

Стало

Ретроспективы только внутри команды, не чаще 1 раза в месяц

Дейли без клиента. Если нужен митинг с клиентом – он назначается отдельно

Планинги релизов только с ключевыми людьми

За каждую часть скоупа отвечает Epic Lead

Пример отчета клиенту

Шаг 6 - Коммуникация с командой

• Команда всегда знает текущий статус – получает те же отчеты, что и клиент

• Любой хороший фидбек сразу доносится до всей команды

• Регулярные письма команде с последними новостями

Что получилось

• Мотивация и скорость команды выросла

• Продукт вышел в live и реально используется

• Клиент продолжает работать с той же компанией

Счастливая команда – не только средство, но и цель

Спасибо