Подходы к формированию команды ИT-проекта
По результатам множества опросов менеджеров проектов в России и за рубежом, до 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 ролям:
Менеджер продукта.
Цель этой роли — удовлетворение требований заказчика. Его главная задача — сформировать общее представление о поставленной задаче и о том, как ее решать. Как представитель заказчика, менеджер продукта отвечает за создание бизнес-сценариев, он помогает заказчику определить функциональные требования к программной системе и расставить приоритеты их реализации, проверяет, удовлетворяют ли решения группы потребностям заказчика.
Менеджер программы
Задача менеджера программы — вести процесс разработки с учетом всех ограничений. Главная обязанность менеджера программы — выполнить все стадии разработки так, чтобы нужный продукт был выпущен в нужное время. Кроме того, менеджер программы дает заказчику рекомендации, касающиеся дальнейшего развития продукта. Отдел программного менеджмента отвечает за функциональные возможности, изложенные в спецификациях (в котором описано, что будет создано) и в главном плане проекта (который определяет, как это будет сделано). Он также координирует работу над этими документами. Тем не менее каждый участник проекта вносит свой вклад в функциональные спецификации и в план проекта.
Внимание! Важно, чтобы менеджер программы понимал, что каждый член группы разбирается в своих обязанностях намного лучше его. Менеджер программы должен полностью положиться на опыт остальных сотрудников и только следить за соблюдением всех условий и ограничений.
В ходе реализации проекта менеджер программы контролирует реальные затраты, сравнивая их с запланированными. Он регулярно сообщает о состоянии работы всем основным участникам проекта.
Как правило, группа менеджмента программы управляет ресурсами, используемыми другими ролями, а также составляет и координирует расписания совещаний. Менеджер программы отвечает и за бюджет проекта, объединяя требования к ресурсам всех членов группы в единый план расходов. Важно, чтобы еще до начала проекта менеджер программы имел непререкаемый авторитет у всех его участников, включая бизнес-отделы и руководство организации.
Разработчик
Разработчики знакомят остальных членов группы с применяемыми технологиями и собственно создают продукт. В качестве консультантов они предоставляют исходные данные для проектирования, проводят оценку технологий, а также разрабатывают прототипы и тестовые системы, необходимые для проверки решений и сокращения рисков на ранних стадиях процесса разработки. Руководителю группы разработки не рекомендуется совмещать несколько ролей.
Тестер
Задача тестеров — испытание продукта в реальных условиях, дабы определить, что в продукте работает и что не работает. Тестеры разрабатывают стратегию, планы, графики и сценарии тестирования, которые позволяют убедиться, что все ошибки выявлены и исправлены до выпуска приложения. Ошибкой называют любую проблему, из-за которой продукт не выполняет свои функции.
Нельзя совмещать должности тестера и разработчика. Разделение этих обязанностей:
- гарантирует независимую проверку того, что продукт действительно выполняет все требования;
- повышает качество продукта за счет конкуренции между группами.
Инструктор
Цель группы обучения — повысить эффективность труда пользователей. Группа обучения отвечает за выпуск удобного, полезного продукта, которому практически не нужна поддержка.
Логистик
Логистик представляет интересы служб поддержки и сопровождения, справочных служб и других служб канала доставки. Он занимается развертыванием продукта и его сопровождением и контролирует продукт с этой точки зрения в процессе проектирования. Логистик руководит всеми сотрудниками, устанавливающими и настраивающими пользовательские системы. Кроме того, он должен уметь координировать установку программного обеспечения и оценивать ее результаты.
После развертывания логистики в течение некоторого времени консультируют группу сопровождения. Конечно, сложно предсказать все трудности, которые могут возникнуть в процессе эксплуатации приложения, поэтому во всех планах следует предусматривать и порядок действий в экстренном случае.
6 ролей модели проектной группы связаны с 6 целями проектной группы (табл. 2). Все цели важны для успеха проекта в целом, и поэтому все роли равноправны. В этой модели нет руководителя всего проекта — есть группа людей, знающих, что нужно делать, и делающих это.
Таблица 2. Цели и роли
| Цель | Роль |
| Удовлетворение требований заказчика | Менеджер продукта |
| Соблюдение ограничений проекта | Менеджер программы |
| Соответствие спецификациям | Разработчик |
| Выпуск только после выявления и устранения проблем | Тестер |
| Повышение эффективности труда пользователя | Инструктор |
| Простота развертывания и постоянное сопровождение | Логистик |
Обычно каждую роль исполняют несколько человек, один из которых считается руководителем.