Функциональные роли в коллективе разработчиков

Определено шесть ролевых кластеров, которые соответствующим образом структурируют проектные функции разработчиков (рис. 2.1).

увеличить изображение
Рис. 2.1. Ролевые кластеры модели проектной группы MSF [44]

• Управление продуктом (product management). Ключевая цель кластера — обеспечивать удовлетворение интересов заказчика. Для ее достижения кластер должен содержать следующие области компетенции:
  • планирование продукта,
  • планирование доходов,
  • представление интересов заказчика,
  • маркетинг.
• Управление программой (program management). Задача — обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проекта и к его результату. Области компетенции кластера:
  • управление проектом;
  • выработка архитектуры решения;
  • контроль производственного процесса;
  • административные службы.
• Разработка (development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Области компетенции кластера:
  • технологическое консультирование;
  • проектирование и осуществление реализации;
  • разработка приложений;
  • разработка инфраструктуры.
• Тестирование (test). Задача кластера — одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Области компетенции кластера:
  • разработка тестов;
  • отчетность о тестах;
  • планирование тестов.
• Удовлетворение потребителя (user experience). Цель кластера — повышение эффективности использования продукта. Области компетенции кластера: — общедоступность (возможности работы для людей с недостатками зрения, слуха и др.);
  • интернационализация (эксплуатация в иноязычных средах);
  • обеспечение технической поддержки;
  • обучение пользователей;
  • удобство эксплуатации (эргономика);
  • графический дизайн.
• Управление выпуском (release management). Задача кластера — беспрепятственное внедрение и сопровождение продукта. Области компетенции кластера:
  • инфраструктура (infrastructure);
  • сопровождение (support);
  • бизнес-процессы (operations);
  • управление выпуском готового продукта (commercial release management).

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

Если обратиться к менеджерским задачам руководства коллективом в проекте, то оказывается, что схема MSF мало что регламентирует. Говорится лишь о том, какие должны быть группы, но вопросы их формирования оставлены без ответа. Этого и следовало ожидать, имея в виду постулат невозможности формализовать руководство. В то же время, сама схема ограничивает действия менеджера. В подтверждение этому приведем один пример из опыта автора этих строк. При работе с очень квалифицированной программистской группой был замечен явный рост продуктивности ее членов, когда на собраниях присутствовала весьма привлекательная лаборантка, о профессионализме и компетентности которой не могло быть и речи. Единственное объяснение тому — повышение духа состязательности в коллективе. Вместе с тем по логике MSF для такой работницы просто нет места в проектной группе. Как учитывать и использовать подобные ситуации? Единственный совет, который можно здесь дать, — не очень полагаться на формализованные схемы организации и быть как можно более наблюдательным.

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

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

• Заказчик (Customer) — реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как текущие, так и окончательные) разработки.
• Планировщик ресурсов (Planner) — выдвигает и координирует требования к проектам в организации, осуществляющей данную разработку, а также развивает и направляет план выполнения проекта с точки зрения организации.
• Менеджер проекта (Project Manager) — отвечает за развитие проекта в целом, гарантирует, что распределение заданий и ресурсов позволяет выполнить проект, что работы и предъявление результатов идут по графику, что результаты соответствуют требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов .
• Руководитель команды (Team Leader) — производит техническое руководство командой в процессе выполнения проекта. Для больших проектов возможно привлечение нескольких руководителей подкоманд, отвечающих за решение частных задач.
• Архитектор (Architect) — отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом.
• Проектировщик подсистемы (Designer) — отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами.
• Эксперт предметной области (Domain Expert) — отвечает за изучение сферы приложения, поддерживает направленность проекта на решение задач данной области.
• Разработчик (Developer) — реализует проектируемые компоненты, владеет и создает специфичные классы и методы, осуществляет кодирование и автономное тестирование, строит продукт. Это широкое понятие, которое может подразделяться на специальные роли (например, разработчик классов). В зависимости от сложности проекта команда может включать различное число разработчиков .
• Разработчик информационной поддержки (Information Developer) — создает документацию, сопровождающую продукт, когда выпускается версия. Включаемые в нее инсталляционные материалы, равно как ссылочные и учебные, а также материалы помощи предоставляются на бумажных и машинных носителях. Для сложных проектов возможно распределение этих задач между несколькими разработчиками информационной поддержки .
• Специалист по пользовательскому интерфейсу (Human Factors Engineer) — отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям.
• Тестировщик (Tester) — проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта.
• Библиотекарь (Librarian) — отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты, а также за соответствие рабочих продуктов стандартам.

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

Мы будем иметь возможность убедиться в том, что заказчик как реальная персона не является единственным лицом, заинтересованным в получении результатов. На задачи проекта влияют персоналии из сфер производства и потребления программных продуктов, расширяя или сужая возможности будущего программного изделия, — так называемые инициаторы работ (stakeholders)^{1Термин "инициаторы работ" — перевод английского слова "stakeholders". В литературе можно встретить и другие его переводы: организаторы работ, заинтересованные лица и даже акционеры (последнее уводит далеко в сторону). Некоторые прибегают к транслитерации и говорят о стейкхолдерах проекта. Мы предпочитаем назыать всех тех, чьи интересы в той или иной мере затрагивают проект и его результаты, инициаторами работ. Наряду с этим мы употребляем термин "заинтересованные лица", обозначая им всех тех, кто проявляет интерес к проекту и от действия которых может зависеть его развитие, пусть даже косвенно. Таким образом, инициаторы работ включают в себя заинтересованных лиц (в частности, разработчиков проекта), но обратное неверно. К примеру, акционер проекта является инициатором работ, так как его интересы судьба проекта, безусловно, затрагивает. Но полагаясь на своего брокера, он может позволить себе даже не думать о проекте, т.е. не быть его заинтересованным лицом (в нашей терминалогии).}. О них говорить необходимо, когда обсуждение менеджмента касается влияния на проект внешних требований. И в этом плане полезно воспринимать заказчика в качестве равнодействующей всех инициаторов работ, которая выставляет согласованные требования и задачи. Иными словами, там, где удобно не различать внешние влияния на проект, мы определяем абстрактного заказчика.