Подходы к формированию команды ИT-проекта: подход Центра объектно-ориентированной технологии компании IBM. 
Команда ХР проекта. 
Проектная группа: подход MSF

управление человеческий планирование организационный По результатам множества опросов менеджеров проектов в России и за рубежом, до 80% успеха при реализации проектов обусловлено слаженной работой проектной команды, которая, в свою очередь, обеспечивается верным распределением ролей среди участников.

Поэтому многие руководители IT-проектов стремятся максимально ограничить число людей, работающих над системой, тем более что при таком подходе проще обеспечить концептуальное единство проекта и выработать согласованную позицию участников относительно стратегии его реализации. С другой стороны, концепция маленькой энергичной группы имеет один существенный недостаток — это слишком медленно для действительно больших систем (есть риск, что растянув процесс разработки программной системы на годы, вы создадите продукт, потребность в котором давно уже отпала).

В ходе развития проекта командой выполняются те или иные функции. Распределение функций между исполнителями является ничем иным как распределением ролей в команде, выполняющей проект. Значимость ролей различается в зависимости от того, какой проект выполняет IT-команда.

1. Подход Центра объектно-ориентированной технологии компании IBM (Функциональные роли в коллективе разработчиков) В качестве достаточно полного перечня ролей можно указать на список, предлагаемый в рамках подхода Центра объектно-ориентированной технологии фирмы IBM:

• 1. Заказчик — реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как текущие, так и окончательные) разработки;
• 2. Планировщик ресурсов — выдвигает и координирует требования к проектам в организации, осуществляющей данную разработку, а также развивает и направляет план выполнения проекта с точки зрения организации;
• 3. Менеджер проекта — отвечает за развитие проекта в целом, несет ответственность за распределение заданий и ресурсов, за соответствие результатов установленным требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов;
• 4. Руководитель команды — производит техническое руководство командой в процессе выполнения проекта. Для больших проектов возможно привлечение нескольких руководителей подкоманд, отвечающих за решение частных задач;
• 5. Архитектор — отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом;
• 6. Проектировщик подсистемы — отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами;
• 7. Эксперт предметной области — изучает сферу приложения, поддерживает направленность проекта на решение задач данной области;
• 8. Разработчик — реализует проектируемые компоненты, владеет и создает специфичные классы и методы, осуществляет кодирование и автономное тестирование, строит продукт. Это широкий термин, который может подразделяться на более узкие роли (например, разработчик классов). В зависимости от сложности проекта команда может включать различное число разработчиков;
• 9. Разработчик информационной поддержки — создает документацию, сопровождающую продукт, когда выпускается версия. Включаемые в нее инсталляционные материалы, равно как ссылочные и учебные, а также материалы помощи предоставляются на бумажных и машинных носителях. Для сложных проектов возможно распределение этих задач между несколькими разработчиками информационной поддержки;
• 10. Специалист по пользовательскому интерфейсу — отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям;
• 11. Тестировщик — проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта;
• 12. Библиотекарь — отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты. Он также отвечает за соответствие рабочих продуктов стандартам.

Отдельные роли в проекте могут совмещаться и, наоборот, одна и та же роль может быть разделена между несколькими исполнителями.

Желательное или часто встречающееся совмещение ролей:

• 1. менеджер проекта + архитектор
• 2. руководитель команды + архитектор
• 3. руководитель команды + менеджер
• 4. разработчик + разработчик (с различными функциональными направлениями)
• 5. библиотекарь + разработчик
• 6. специалист по пользовательскому интерфейсу + менеджер
• 7. разработчик + тестировщик (при условии «перекрестного» совмещения ролей, когда разработчики независимых компонентов проекта тестируют функциональность друг друга)

Нежелательное или невозможное совмещение ролей:

• 1. заказчик + планировщик
• 2. руководитель команды + проектировщик
• 3. менеджер проекта + разработчик
• 4. разработчик + тестировщик
• 2. Команда ХР проекта — роли для людей

В экстремальном программировании чётко описаны все роли. Каждая роль предусматривает характерный набор прав и обязанностей. Здесь существуют две ключевые роли: заказчик и разработчик.

Заказчик — человек или группа людей, заинтересованных в создании конкретного программного продукта.

Разработчик — один или группа от 2 до 10 человек, занимающихся непосредственно программированием и сопутствующими инженерными вопросами. Разработчик наделён следующими правами и обязанностями:

Каждая из базовых ролей экстремального программирования может быть уточнена более мелкими ролями. В ХР разрешено совмещение ролей в рамках одного человека.

Сторона заказчика.

• 1. Составитель историй — специалист предметной области, обладающий способностями доступно изложить и описать требования к разрабатываемой системе. Этот человек или группа людей ответственны за написание историй пользователя и прояснения недопонимания со стороны программистов.
• 2. Приёмщик — человек, контролирующий правильность функционирования системы. Хорошо владеет предметной областью. В обязанности входит написание приёмочных тестов.
• 3. Большой босс — следит за работой всех звеньев, от разработчиков до конечных пользователей. Он контролирует внедрение системы и сопутствующие организационные моменты. Может быть также инвестором проекта.

Сторона разработчика.

• 1. Программист — человек, занимающийся кодированием и проектированием на низком уровне. Он достаточно компетентен для решения текущих задач разработки и предоставления правдивых оценок запланированных задач. Но при этом он должен обладать умением работать в паре, привычкой к простоте, умением и желанием постоянно переделывать код и рассматривать систему как общую собственность, которая принадлежит всей команде.
• 2. Тестер — помогает заказчику в подборе и написании функциональных тестов, отвечает за регулярный их запуск и оповещает команду о результатах тестирования. Кроме того, он следит за правильностью работы тестирующих инструментов.
• 3. Инструктор — отвечает за весь процесс разработки. Это опытный разработчик, хорошо владеющий всем процессом разработки и его методиками. Несёт ответственность за обучение команды аспектам процесса разработки. Внедряет и контролирует правильность выполнения методик используемого процесса. Обращает внимание команды на важные, но по каким-то причинам упущенные моменты разработки. Вмешательство инструктора в процесс разработки должно быть по-возможности минимальным.
• 4. Наблюдатель (ревизор) — член команды разработчиков, пользующийся доверием всей группы (совесть команды), который следит за прогрессом разработки. Он сравнивает предварительные оценки трудозатрат и реально затраченные усилия, выводя количественные показатели работы команды, такие как средняя скорость и процентное соотношение выполненных и запланированных задач. Данная информация предоставляется заказчику для своевременного контроля над ситуацией.
• 5. Дипломат — коммуникабельная личность, инициирующая общение между членами команды. Так как документооборот минимизирован, важно постоянное общение и передача опыта внутри команды, лучшее понимание требований к системе. Дипломат регулирует и упрощает общение между заказчиками и разработчиками. Является важным звеном на собраниях. Он препятствует недомолвкам, разгару страстей и ненужным ссорам. Дипломат не может навязывать своего мнения дискутирующим сторонам.
• 3. Проектная группа: подход MSF

При использовании подхода MSF все задачи, выполняемые в рамках проекта, распределяются по 6 ролям:

1. Менеджер продукта.

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

2. Менеджер программы Задача менеджера программы — вести процесс разработки с учетом всех ограничений. Главная обязанность менеджера программы — выполнить все стадии разработки так, чтобы нужный продукт был выпущен в нужное время. Кроме того, менеджер программы дает заказчику рекомендации, касающиеся дальнейшего развития продукта. Отдел программного менеджмента отвечает за функциональные возможности, изложенные в спецификациях (в котором описано, что будет создано) и в главном плане проекта (который определяет, как это будет сделано). Он также координирует работу над этими документами. Тем не менее каждый участник проекта вносит свой вклад в функциональные спецификации и в план проекта.

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

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

Как правило, группа менеджмента программы управляет ресурсами, используемыми другими ролями, а также составляет и координирует расписания совещаний. Менеджер программы отвечает и за бюджет проекта, объединяя требования к ресурсам всех членов группы в единый план расходов. Важно, чтобы еще до начала проекта менеджер программы имел непререкаемый авторитет у всех его участников, включая бизнес-отделы и руководство организации.

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

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

Нельзя совмещать должности тестера и разработчика. Разделение этих обязанностей:

• — гарантирует независимую проверку того, что продукт действительно выполняет все требования;
• — повышает качество продукта за счет конкуренции между группами.
• 5. Инструктор

Цель группы обучения — повысить эффективность труда пользователей. Группа обучения отвечает за выпуск удобного, полезного продукта, которому практически не нужна поддержка.

6. Логистик Логистик представляет интересы служб поддержки и сопровождения, справочных служб и других служб канала доставки. Он занимается развертыванием продукта и его сопровождением и контролирует продукт с этой точки зрения в процессе проектирования. Логистик руководит всеми сотрудниками, устанавливающими и настраивающими пользовательские системы. Кроме того, он должен уметь координировать установку программного обеспечения и оценивать ее результаты.

После развертывания логистики в течение некоторого времени консультируют группу сопровождения. Конечно, сложно предсказать все трудности, которые могут возникнуть в процессе эксплуатации приложения, поэтому во всех планах следует предусматривать и порядок действий в экстренном случае.

6 ролей модели проектной группы связаны с 6 целями проектной группы (табл. 2). Все цели важны для успеха проекта в целом, и поэтому все роли равноправны. В этой модели нет руководителя всего проекта — есть группа людей, знающих, что нужно делать, и делающих это.

Табл. 2. Цели и роли.

Цель.	Роль.
Удовлетворение требований заказчика.	Менеджер продукта.
Соблюдение ограничений проекта.	Менеджер программы.
Соответствие спецификациям.	Разработчик.
Выпуск только после выявления и устранения проблем.	Тестер
Повышение эффективности труда пользователя.	Инструктор
Простота развертывания и постоянное сопровождение.	Логистик.

Обычно каждую роль исполняют несколько человек, один из которых считается руководителем.