Стороны и Подотчётные

Роли в Проектах (здесь и далее по тексту -- Лектио) -- это часть урока Суть Проектов. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.

Материалы

Предшественник этого Лектио -- Стадии Проектов.

Текст

Роли в Проектах

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

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

Два ответственных

Владелец проекта несет ответственность за управление проектом. Чтобы направлять, контролировать и/или поддерживать персонал проекта, владелец может создать офис управления проектом, часто сокращенно ОУП.

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

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

Если персонал проекта составляет менее 5-9 человек и график не сжат, менеджер редко выполняет выделенную роль. Один из разработчиков или кто-то другой может выступать в качестве менеджера проекта в дополнение к другим обязанностям.

В Жестком Подходе функции управления распределены между несколькими ролями. Например, разработчики определяют работу на основе требований решения, таких как пользовательские истории. На этапе Планирования некий координатор, например, менеджер по работе с клиентами, работающий в ОУП, нанимает членов группы планирования в дополнение к владельцу продукта. Эта команда проводит Нулевой Спринт или аналогичные действия, предпринимаемые для создания Бэклога Продукта.

На исполнительный этап нанимается команда разработчиков. Помимо product owner-а(Владелец Продукта), в эту команду входят разработчики и, возможно, такие официальные лица, как Scrum Master. Разработчики обычно работают в итерациях и, как только разрабатываются новые инкременты и обнаруживаются новые данные, обсуждают будущий продукт и его доставку с Владельцем Продукта. Скрам-Мастера не занимаются рабочими продуктами и поставками; Вместо этого Скрам-Мастера следят за тем, чтобы разработка шла в соответствии с согласованными правилами. В отличие от Управления проектами, администрирование разработки часто распределяется между двумя организациями, если две организации участвуют в одном проекте.

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

В проектах Гибкой Методологии -- эта административная роль называется Спонсором Проекта. Базовые показатели не являются особенностью проектов с Жесткким Подходом, поэтому администрация концентрируется только на требованиях к продукту.

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

А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, :

Варианты

Следующее лектио -- Окончание Проектов

Термины

Владелец Продукта, Скрам-Мастер, Спонсор Проекта, Администрация Развития, ОУП, Заказчик Проекта