Управление выпуском готового продукта
Регистрационные коды продукта; процесс верификации регистрации.
Управление лицензиями.
Подготовка дистрибутивных комплектов.
Управление каналами дистрибуции продукта.
Печатные и электронные публикации.
Инфраструктура
Данная область компетенции включает в себя ряд задач, связанных с организацией инфраструктуры поддержки. Её характеристики сходны с характеристиками ролевого кластера “Инфраструктура” (infrastructure) MOF (Microsoft Operation Framework).
Сопровождение
Эта область компетенции следит за тем, чтобы создаваемое и внедряемое решение было удобным в сопровождении. Её характеристики сходны с характеристиками ролевого кластера “Сопровождение” (support) MOF.
Бизнес-процессы
Эта область компетенции связана с рядом операционных задач, которые должны выполняться при осуществлении проекта. Она ответственна за то, чтобы создаваемое и внедряемое решение было согласованным с имеющими к нему отношение бизнес‑процессами. Её характеристики сходны с характеристиками ролевого кластера “Бизнес‑процессы” (operations) MOF.
Управление выпуском конечного продукта
Эта область компетенции связана с рядом задач, относящихся к выпуску коммерческих программных продуктов. Основная ее задача – вывод продукта на действующие каналы поставки.
Масштабирование модели проектной группы
В своей книге “Rapid Development” бывший разработчик программного обеспечения Майкрософт Steve McConnell пишет:
|
|
|
“Большие проекты требуют организационных методик, которые формализуют и направляют информационный обмен. ... Все способы организации обмена информацией состоят в создании некой иерархии, то есть создании малых групп, работающих как команды, и следующего за этим назначения представителей этих групп для взаимодействия друг с другом и руководящим звеном.”
Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия.
Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т.н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.
Группы направлений
Каждый ролевой кластер проектной группы имеет одну или несколько составляющих, образующих иерархическую структуру (желательно, максимально простую). Например, тестировщики подотчетны менеджеру тестирования.
В эту структуру вплетены так называемые группы направлений (feature teams). Это компактные мини-команды, образующие матричную организационную структуру. В них входят по одному или несколько членов из разных ролевых кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от проектирования и составления календарного графика. Например, может быть сформирована специальная группа проектирования и разработки сервисов печати.
|
|
|
В “Rapid Development” Steve McConnel писал:
“Преимуществом группы направления является баланс ответственности и полномочий. Такую команду легко наделить полномочиями, поскольку она содержит представителей каждой из вовлеченных сторон. В силу этого группа будет учитывать при принятии решений все существенные точки зрения, и едва ли возникнут ситуации, требующие пересмотра её решений.
По той же причине команда становится более ответственной. В ее распоряжении есть все люди, необходимые для осуществления верных шагов. Если члены группы направления принимают плохое решение, то в этом они не могут винить никого, кроме самих себя. И эта команда хорошо сбалансирована. Вы не хотели бы, чтобы разработчики, маркетологи или тестировщики получили право решающего голоса. Но от группы направления вы сможете получить взвешенное суждение, поскольку она включает в себя представителей всех вышеназванных категорий.”
|
|
|
|
Рисунок 4. Группы направлений
Примечание: приведенный на рисунке пример не определяет требований к организации групп направления. Например, не все группы направления должны включать в себя роль “Удовлетворение потребителя”; они должны быть организованы в соответствии с той задачей, которая на них возлагается.
Функциональные группы
Функциональные группы – это группы, существующие внутри ролевых кластеров. Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. Например, в Майкрософт группа управления продуктом обычно включает специалистов по планированию продукта и специалистов по маркетингу. Как первая, так и вторая сферы деятельности относятся к управлению продуктом: одна из них сосредотачивается на выявлении качеств продукта, действительно интересующих заказчика, а вторая – на информировании потенциальных потребителей о преимуществах продукта.
Аналогично, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, бизнес-логика или объекты данных. Часто программистов разделяют на разработчиков библиотек и разработчиков решения. Программисты библиотек обычно используют низкоуровневый язык C и создают повторно используемые компоненты, которые могут пригодиться всему предприятию. Создатели же решения обычно соединяют эти компоненты и работают с языками более высокого уровня, такими как, например Microsoft® Visual Basic®.
|
|
|
Часто функциональные группы имеют внутреннюю иерархическую структуру. Например, менеджеры программы могут быть подотчетны ведущим менеджерам программы, которые в свою очередь отчитываются перед главным менеджером программы. Подобные структуры могут также появляться внутри областей компетенций. Но важно помнить, что эти иерархии не должны затенять модель команды MSF на уровне проекта в целом. Цели всех ролей остаются теми же самыми, также как и ответственность перед проектной командой за достижение этих целей.
Объединение ролей
Хотя модель проектной группы состоит из шести ролей, это не означает, что команда обязательно должна насчитывать не менее шести человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа. Во-первых, роль команды разработчиков не может быть объединена ни с какой другой ролью. Разработчики – это создатели проекта, и они не должны отвлекаться от своей главной задачи. Наделение разработчиков дополнительными обязанностями лишь делает более вероятным выход из календарного графика проекта.
Второй принцип – это избежание сочетания ролей, имеющих предопределенные конфликты интересов. Например, управление продуктом и управление программой имеют противоречащие друг другу интересы и, следовательно, не должны объединяться. Менеджмент продукта имеет цель удовлетворить заказчика, в то время как менеджмент программы обеспечивает готовность продукта в отведенное время и в рамках имеющегося бюджета. В случае сочетания этих ролей возникает риск, что затребованное заказчиком изменение либо не будет рассмотрено с должным вниманием, либо будет принято без надлежащего анализа его влияния на проект. Представление этих ролей различными людьми в проектной команде обеспечивает равновесие двух противоречащих точек зрения. То же самое относится к попытке объединения ролей разработки и тестирования.
|
Рисунок 5. Объединение ролей в малых проектах
Приведенная таблица показывает неудачные (“нельзя”) и возможные (“допустимо”) сочетания ролей. Но, как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и профессиональных навыков.
Знак “-” на пересечении столбца со строкой означает, что сочетание соответствующих ролей недопустимо, за исключением случаев, когда это абсолютно необходимо, и когда связанные с этим риски могут быть уменьшены эффективными планами их предотвращения и смягчения последствий. Ясно, что имеются различные уровни конфликтов между ролями, что делает модель проектной группы динамичной и затрудняет объединение ролей. Однако на практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.
Эскалация и подотчетность
Дата добавления: 2019-01-14; просмотров: 167; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!