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

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

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

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

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

Понятно, что совмещение ролей не может быть произвольным. Одни совмещения нежелательны (в разной степени), другие нейтральны, третьи полезны для проекта. Общий регламент для совмещения определяют следующие принципы:

1. Не следует допускать совмещения ролей, которые имеют конфликтные или противоречивые интересы. Если такое совмещение все-таки используется, то необходимо предусматривать механизмы, которые будут демпфировать противоречия.
2. Представление ролей с конфликтными интересами различным людям обеспечивает равновесие противоречащих точек зрения.
3. Прибегать к совмещению ролей для участников проекта, основной ролью которых является разработка, означает заведомое увеличение сроков выполнения соответствующих работ. По этой причине для них допустимы лишь такие совмещения, которые действительно необходимы в данный момент развития проекта (например, в некоторых авральных ситуациях) и которые не требуют постоянной деятельности в течение длительного срока.
4. Если работнику поручается несколько ролей, то он всегда должен знать, какую из них он выполняет в данный момент.

В большинстве случаев заказчик и планировщик ресурсов являются действительно внешними по отношению к проекту действующими лицами, а потому совмещение этих ролей с другими — нечто экзотическое. Тем не менее роль заказчика как члена коллектива разработчиков, аккумулирующего точки зрения всех инициаторов работ, весьма полезна. В частности, подход экстремального программирования считает это обязательным, чтобы развитие проекта всегда гарантированно было направлено в сторону, нужную пользователям [3]. Поскольку в этом подходе ролевая дифференциация работников отходит на второй план, его апологеты не выделяют специально роли эксперта предметной области. Скорее всего, они считают, что его функции должны выполнять заказчик, который составляет тесты для проверки системы в целом (по крайней мере специфицирует их), и остальные разработчики группы, которые по мере уяснения актуальных пользовательских потребностей поймут, как их воплотить в коде. Но задачи эксперта предметной области иные: он должен понимать структуру пользовательской деятельности, чтобы отвечать на вопросы об узких местах этой деятельности, о критериях актуальности принимаемых решений, о содержательных формах, в которых предоставляемые средства должны преподноситься пользователям. Даже если не брать в расчет перегрузку роли заказчика экспертными функциями, понятно, что предположение о включении заказчика в команду, выполняющую проект, представляется скорее исключением, нежели правилом. Уже из этого примера видно, насколько размыты границы между функциями разных ролей, а значит, и совмещения ролей в команде. Точное определение ролей, их разграничения и совмещения — область специфики конкретных проектов. Тем не менее уместно сформулировать рекомендации, основанные на опыте успешного и неудачного менеджмента программных проектов.

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

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

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

Нежелательно совмещение ролей руководителя команды и проектировщика какой-либо подсистемы. И это обусловлено противоречивостью их ролевых интересов.

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

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

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

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

Допустимы и другие совмещения ролей. Так, довольно часто создание документации распределяется между всеми исполнителями проекта, а на руководителя команды и менеджера возлагается задача интеграции документов. Для обозримых проектов функции библиотекаря можно поручить одному из разработчиков, соответственно скорректировав его индивидуальное задание (см. принцип 3). Специалистом по пользовательскому интерфейсу вполне может быть, например, менеджер, поскольку именно он осуществляет контакты с заказчиком (в данной ситуации заказчик либо сам является пользователем, либо выступает как представитель пользователя программного изделия).