Формирование команды проекта автоматизации

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

Прежде всего, это основная группа специалистов, выделенных для выполнения проекта, т.е. команда проекта, осуществляющая работы по проекту на протяжении всего жизненного цикла. В эту группу могут входить еще и профессионалы, которые будут выполнять конкретные работы по проекту в какое-то определенное время, т.е. приглашенные специалисты [3, С.27-35 ].

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

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

Учитывая сложность современных ИТ-проектов, можно сказать, что условием успеха проекта является тесное сотрудничество между заказчиком и разработчиком. Сотрудничество должно происходить на всех фазах жизненного цикла проекта.

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

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

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

Ведущий представитель пользователей со стороны заказчика выступает в роли посредника между сообществом пользователей организации и аналитиками организации разработчика. Задача этого человека - донести нужды пользователей до аналитиков. Он работает в тесном взаимодействии с аналитиком организации разработчика [3, С.27-35 ].

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

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

Рисунок 2. Проектные команды [2, С. 60].

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

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

Технический лидер – это самый опытный разработчик в команде. Он направляет деятельность разработчиков, тестировщиков и аналитиков. Технический лидер – это правая рука руководителя проекта.

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

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

Специалист по заключению контрактов работает со всеми контрактами по проекту, в его компетенцию входит управление проектом с точки зрения бизнеса.

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

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

Различные методологии, используемые в сфере ИТ, предлагают свои принципы формирования команды ИТ проекта и распределения ролей между членами команды. Например, методология Microsoft Solutions Framework (MSF) предлагает модель проектной группы, состоящую из шести ролевых кластеров [1, С. 13-15]:

1. Управление продуктом (product management),

2. Управление программой (program management),

3. Разработка (development),

4. Тестирование (test),

5. Удовлетворение потребителя (user experience)

6. Управление выпуском (release management).

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

Таблица 1