Вопрос не праздный, поскольку в Scrum никакого менеджера проекта нет. Вместо этого есть три роли: Product Owner, Scrum Master и команда.
Давайте посмотрим, что стало с менеджером проекта.
Я честно выписал все активности менеджера проекта из PMBOK. Получилось довольно много:
- Управление интеграцией проекта
Разработка Устава проекта
Разработка предварительного описания содержания проекта
Разработка плана управления проектом
Руководство и управление исполнением проекта
Мониторинг и управление работами проекта
Общее управление изменениями
Закрытие проекта - Управление содержанием проекта
Планирование содержания
Определение содержания
Создание иерархической структуры работ (ИСР)
Подтверждение содержания
Управление содержанием - Управление сроками проекта
Определение состава операций
Определение взаимосвязей операций
Оценка ресурсов операций
Оценка длительности операций
Разработка расписания
Управление расписанием - Управление стоимостью проекта
Стоимостная оценка
Разработка бюджета расходов
Управление стоимостью - Управление качеством проекта
Планирование качества
Процесс обеспечения качества
Процесс контроля качества - Управление человеческими ресурсами проекта
Планирование человеческих ресурсов
Набор команды проекта
Развитие команды проекта
Управление командой проекта - Управление коммуникациями проекта
Планирование коммуникаций
Распространение информации
Отчетность по исполнению
Управление участниками проекта - Управление рисками проекта
Планирование управления рисками
Идентификация рисков
Качественный анализ рисков
Количественный анализ рисков
Планирование реагирования на риски
Мониторинг и управление рисками - Управление поставками проекта
Планирование покупок и приобретений
Планирование контрактов
Запрос информации у продавцов
Выбор продавцов
Администрирование контрактов
Закрытие контракта
Понятно, что в Scrum некоторые вещи называются по другому. Что поделаешь, каждая методология вносит свои термины (лично я это ненавижу - зачем понадобилось итерацию называть спринтом? Зачем standup называется daily scrum?).
Кое-что остается за бортом методологии. Например, управление поставками никак не описывается в Scrum. Делать, понятно, это все равно иногда приходится.
Давайте раскидаем все эти активности по ролям Scrum. Для понятности я буду все именовать так, как это делается в Agile, а описание из PMBoK буду использоваться в качестве справочника, просто чтобы ничего не забыть. У меня получается следующая картина:
Получается, что обязанности классического менеджера более или менее равномерно распределились по всем ролям в Scrum. Менеджер проекта при переходе в Scrum чаще всего достаточно органично трансформируется в Product Owner'a.
За кадром на самом деле осталось ровно две вещи, которые надо таки делать, хотя Scrum ни сном ни духом об этом не говорит.
Первая группа относится, как правило, к ответственности вышестоящего менеджера. Речь идет об управлении бюджетом:
Спонсор. Управление бюджетом
- Старт и закрытие проекта
- Управление поставками проекта (на уровне принятия решений по бюджету)
- Ввод и вывод людей из команды
- Бюджетирование проекта
Вторая группа - это HR практически в чистом виде:
HR. Управление людьми
- Найм и увольнение сотрудников
- Управление ресурсами: зарплаты, бонусы, повышения
Вопрос в том, кто это должен делать в Scrum-команде? Достаточно часто это какие-то отдельные люди. Спонсором проекта является вышестоящий менеджер (генеральный директор либо начальник отдела). HR-активности логичным образом падают на HR-менеджера. Впрочем, в Luxoft, например, есть специальная роль - people manager, который чаще всего является менеджером подразделения.
Относительно неплохо все эти вещи может делать Product Owner, если вы конечно не боитесь его перегрузить :-)
Только не надо совмещать роли HR и Scrum Master в одном человеке! Скрам-мастер все таки член команды, эдакий добрый малый, свой в доску. Представьте себе, утром он помогает команде, а ночью увольняет несправившихся. Это какой-то оборотень получается!
8 коммент.:
А менеджер по своей сути и есть оборотень, мечущийся между светлой (разработка) и тёмной (бизнес) сторонами Силы. :)
Вообще, по сравнению с традиционными корпорациями, agile по отношению к людям - более жёсткий подход. Не случайно все гуру аджайла (или не все?) твердят: если человек не вписывается в команду, расстаньтесь с ним.
"Люди и их взаимодействие важнее, чем процессы и средства", но это должны быть самые лучшие люди. Слабаки не нужны, они развалят команду.
В общем, чтобы скрам-мастер мог оставаться добрым малым, ему в дополнение нужен Evil director of HR. :)
Ты слушаешь неправильных гуру.
Насколько я понимаю, гуру не особо любят распространятся на эту тему - слишком велик риск быть неправильно понятым. Ну что-то типа "Швабер сказал, нужно тебя уволить".
У нас при внедрении Scrum от менеджера - PM остался. При этом он выполняет большую часть функциой PO, но и следит за бюджетом спринтов, контролирует выполнение формальностей перед заказчиком.
Кто управляет рисками, тот и управляет бюджетом. Если вы взваливаете ответственность за риски на плечи Product Owner'a, то и бюджетирование должно быть в его компетенции.
> Кто управляет рисками, тот и управляет бюджетом
По идее, так и должно быть. Но PO и команды существуют не в вакууме, а в организации. Подбор людей в команду не всегда ведется с рынка. Часто речь идет о переходе людей из одной команды в другую. Такую ответственность взять на себя PO одного конкретного продукта не может.
Бюджетирование также не существует в вакууме. Бюджет продукта, который сам денег пока не зарабатывает, берется из бюджета организации и, как правило, формируется снаружи тем или иным способом - либо просто в виде некоторого количества денег, либо (для чисто софтверной разработки) определяется размером команды.
Ситуации бывают разные, согласен. Поэтому всегда надо смотреть на контекст. Но тем не менее есть концептуальные вещи - нельзя нести ответственность за то, чем ты не можешь управлять. Кто несет ответственность за конечный результат - PO или команда? Если PO, то у него должны быть соответствующие полномочия
Касательно бюджета. Да, обычно он формируется снаружи, но как распоряжаться этими деньгами, а значит и рисками - это должно быть в компетенции PO. Но опять-таки, надо рассматривать конкретные ситуации: офшорная разработка, внутренний проект, коробочный продукт, стартап в гараже... Везде есть место Agile, но везде своя специфика, свои ньюансы. Хотя можно выработать различные паттерны для роли PO в зависимости от типа проекта.
Асхат, добрый день.
Изображение с распределением задач по ролям отдает 403 ошибку.
Отправить комментарий