Файл: Метод указания магистерская диссертация магистратура ПИ.docx

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

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

Прежде всего, это основная группа специалистов, выделенных для выполнения проекта, т.е. команда проекта, осуществляющая работы по проекту на протяжении всего жизненного цикла. В эту группу могут входить еще и профессионалы, которые будут выполнять конкретные работы по проекту в какое-то определенное время, т.е. приглашенные специалисты [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

Функции ролевых кластеров

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

При этом должны соблюдаться два принципа [1, С. 35-36]. Во-первых, роль команды разработчиков не может быть объединена ни с какой другой ролью. Второй принцип – это избежание сочетания ролей, имеющих предопределенные конфликты интересов. Стандарт MSF рекомендует следующие сочетания ролей (рис. 3).

Рисунок 3. Объединение ролей в проектных командах.

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

Рекомендуемая литература по данному разделу:

1. Microsoft Solutions Framework, Модель процессов MSF, вер.3.1 (Отдел MSF, Microsoft ) - White Paper.- 2002.

2. Р. Денис Гиббс. Управление проектами с помощью IBM Rational Unified Process. Практические уроки. Пер.с англ. – М.: КУДИЦ-ПРЕСС. – 2007. – 304 с

3. Алексеева Т.В. Организация взаимоотношений участников ИТ - проекта. // «Бизнес команда и ее лидер», № 6.- М.: ООО «Интерсоциоинформ».- 2008.- 8 стр.

3. Средства коллективной работы над проектом автоматизации

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

Для выбора СКР предлагается Вам использовать обзор, представленный в таблице 1 и 2. Вышеприведенный обзор включает всего три средства коллективной разработки, хотя всего таких программ, конечно, гораздо больше. В таблице 1 приведена таблица возможностей некоторых коммерческих СКР, а в таблице 2 - некоммерческих. К сожалению, все имеющиеся средства перечислить невозможно. Достаточно полный список ссылок на сайты производителей СКР можно найти по адресу http://www.cs.colorado.edu/users/andre/configuration_management.html

Таблица 1 Коммерческие средства разработки

Таблица 2 Некоммерческие средства разработки

Условные обозначения

VC – поддержка контроля версий;

Cnf – автоматизация разрешения конфликтов;

Brn – поддержка ветвления версий;

Shr – возможность использования одного файла в нескольких проектах;

Net – доступ к БД проекта по сети (TCP/IP);

FS - доступ к БД проекта с использованием файловой системы;

Srv – серверный ли тип этой СКР (S - серверный, W - бессерверный, B - работа в обоих режимах);

Cmd – наличие интерфейса командной строки;

GUI – наличие графического интерфейса;

jc - автоматизация управления распределением обязанностей;

bc - контроль и ускорение сборки проекта;

bt - встроенная система поиска ошибок;

Lic – условия распространения (для некоммерческих средств).

+ имеется

- отсутствует

= имеется в большинстве поставок

* поддерживается внешними средствами

~ не удалось получить точных сведений

p находится в зачаточном состоянии

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

Следующим вопросом является выбор между работой в командной строке и графическим интерфейсом. Любое пожелание на этот счет можно оспорить. Если большая часть разработчиков в вашем коллективе может быстро набирать команды СКР на клавиатуре, то системы вроде Perforce или CVS - это для вас. Большинству все же удобнее работать с графическим интерфейсом. Тут, правда, есть одна тонкость: большая часть средств коллективной разработки имеет графический интерфейс только в версиях для операционной системы Windows. Практически все коммерческие СКР обладают этой особенностью.

Некоммерческие СКР, разработка которых годами велась под UNIX'ом, не имеют графического интерфейса. Тем не менее, благодарные пользователи понаписали множество внешних утилит, предоставляющих возможность производить часть операций все же не в командной строке, а с использованием графического интерфейса. Чемпионом по количеству таких утилит - около 5 - является CVS (что свидетельствует о популярности). Стоит отметить WinCVS (Win32, MacOS) и JCVS (Java).