8. Зоны ответственности ролевых групп

Каждая ролевая группа в команде имеет зону ответственности (advocacy), в которой

роль из этой группы имеет решающий голос.

• Управление программой - отвечает за управление проектом, за то, что ожидания заинтересованных сторон будут верно поняты и проведены через проект.

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

• Разработка - отвечает за проектирование и осуществление реализации.

• Тестирование - отвечает за качество решения с точки зрения заказчика и будущих пользователей.

• Управление выпуском - отвечает за гладкое внедрение решения в инфраструктуру заказчика.

• Удовлетворение потребителя - отвечает за понимание потребностей пользователей и их надлежащую реализацию в решении.

• Управление продуктом - отвечает за понимание того как, и успешное получение бизнес-отдачи от внедрения разрабатываемого решения, которое в результате сможет получить заказчик.

9. Задачи ролевых групп и взаимодействие с заинтересованными лицами

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

17. Рекомендации по возможному объединению ролей

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

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

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

Знак “-” на пересечении столбца со строкой означает, что сочетание соответствующих ролей недопустимо, за исключением случаев, когда это абсолютно необходимо, и когда связанные с этим риски могут быть уменьшены эффективными планами их предотвращения и смягчения последствий.