96
автономия и самоорганизация на уровне команды проекта, лучшие
технические требования, дизайн и архитектура получаются у самоорганизованной
команды;
постоянная адаптация к изменяющимся обстоятельствам.
Общей схемой гибкого проектного управления может быть признана
циклическая модель жизненного цикла проекта (рисунок 2), разбивающая проект
на большое количество итераций. «Каждая итерация сама по себе выглядит как
программный проект в миниатюре, и включает все задачи, необходимые для
выдачи мини-прироста по функциональности: планирование, анализ требований,
проектирование, кодирование, тестирование и документирование. Хотя отдельная
итерация, как правило, недостаточна для выпуска новой версии продукта,
подразумевается, что гибкий программный проект готов к выпуску в конце каждой
итерации. По окончании каждой итерации, команда выполняет переоценку
приоритетов разработки» [14].
Модель на рисунке 2 предполагает, что проект разворачивается как
неопределенное количество циклов (итераций), каждый из которых проходит
через четыре фазы - выявление требований, проектирование, создание и оценка.
Каждый последующий цикл приводит к уточнению требований, пересмотру
содержания, улучшению продукта и процессов реализации проекта. В реальности
итерационная природа гибкого проекта более сложна и предполагает возможность
любого перехода между этапами, что иногда отображается в виде так называемой
хаотической модели жизненного цикла проекта (рисунок 3).
Такие представления о жизненном цикле проекта предполагают
нетрадиционный взгляд на содержание проекта. Действительно, в отличие от
традиционного проектного управления с его жестким закреплением требований к
результату и границ содержания, гибкое управление рассматривает требования и
содержание как динамически изменяемые [10]. Во многом представления о
гибком управлении проектом соответствуют концепциям развивающихся и
открытых проектов [7;6]. Если традиционные терминальные проекты
предполагают четкое определение границ жизненного цикла и содержания
проекта, достижение которых автоматически означает завершение проекта, то
97
развивающиеся проекты оставляют содержание всегда открытым для дальнейших
изменений и развития. Открытые проекты вообще определяют содержание только
лишь в виде общих ориентиров и индексов, постоянно изменяя его в ходе
выполнения.
Оценка
Выявление
требований
Проектирование
Создание
Последняя версия
Вторая версия
Первая версия
Завершающее
проектирование
Физическое
проектирование
Логическое
проектирование
Концептуальное
проектирование
Одобрение
концепции
Анализ риска
Экспертиза
Экспертиза
Тестирование
Требования бизнеса
Системные
требования
Требования единиц
техники
Выпуск в
производство
Производство и
поддержка
Требования
подсистем
Рисунок 2.1 – Циклическая модель жизненного цикла гибкого проекта
«Гибкость» содержания проекта связана также с ориентацией проектов на
ценность для клиента (и команды), а не на формальные результаты. Гибкое
управление отходит от традиционного «железного» треугольника «качество-
время-затраты» и от представлений о проекте, как о механизме выполнения работ,
и предлагает новый «подвижный» треугольник «ценность-ограничения-качество»
[16]. Данные взгляды полностью совпадают с идеями М.Винтера [14] и другими
участниками инициативы по «Переосмыслению проектного управления» [1].
Также они практически совпадают с общими взглядами представителей
ситуационного подхода к управлению проектами Д.Двира и А.Шенхара,
изложенными в их концепции «переизобретения проектного управления» [14].
98
Определение требований
Проектирование архитектуры
Детальное проектирование
Создание и тестирование
модулей
Интеграция
Тестирование системы
Поддержка
Рисунок 2.2 – Хаотическая модель жизненного цикла проекта
Итерационная природа гибкого проекта предполагает совмещение и
соединение многих этапов разработки новой продукции и даже работ по
проектированию, планированию и созданию продукции, что во многом сходно с
параллельным проектированием [4]. Гибкое управление проектом базируется на
многократном циклическом параллельном проектировании, что предполагает
использование межфункциональных команд и эффективные коммуникации между
всеми участниками проекта. В этом аспекте «подвижное» проектное управление
вобрало в себя многие подходы, предлагаемые методикой интегрированной
разработки продукции (IPD - Integrated product development) [12].
Гибкость и открытость в составе и структуре работ предполагает высокий
уровень свободы от формальных процедур и процессов. Гибкое проектное
управление всячески подчеркивает необходимость минимизации документальной
работы, формальных процессов и процедур, заведомо определенных методов и
подходов к решению задач и управлению. Формальные стандарты и процедуры
рассматриваются как серьезные ограничители «подвижности» в управлении
проектами. Акцент в управлении делается на неформальных методах и связях,
личностных способностях, высокой мотивации, лидерстве, интенсивном личном
общении всех участников проекта. Как гласит китайская поговорка, «в руках
99
хорошего человека даже плохой метод становится хорошим, а в руках плохого
человека хороший метод становится плохим».
Разработка видения проекта предполагает разработку видения продукции
проекта, а также выработку и согласование устава проекта, представлений о
содержании проекта и его ограничениях, процедурах оценки и контроля,
архитектуре продукции, целях и ценностях команды. Данный этап должен
определить общие контуры и параметры создаваемой продукции, цели и
ограничения проекта, участников проектной экосистемы, правила, приоритеты и
ценности, определяющие стиль и порядок работы команды проекта. Видение
продукции и проекта выступает не как популистско-рекламное заявление, но как
реальный инструмент управления, причем более важный, нежели более детальные
планы. По большому счету, видение определяет весь проект, все его составные
элементы и связи на высоком концептуальном уровне и мотивирует деятельность
команды проекта.
Вслед за разработкой видения выполняется концептуальное
проектирование, направленное на определение способностей и ресурсов для
воплощения видения. Концептуальный проект в себя включает также описание
характеристик создаваемой продукции и общих направлений деятельности по их
созданию. Концептуальное проектирование определяет приблизительное
количество версий (или модулей) продукции, последовательность их создания, их
параметры и связи друг с другом.
Планирование цикла создания версии (или модуля) направлено на
разработку более детального плана создания очередной версии (или модуля)
продукта, или же его прототипа. В рамках этого этапа осуществляется переход из
цикла концептуальной разработки в цикл выполнения работ в режиме
итерационного создания и адаптации. Но при необходимости цикл
концептуальной разработки может осуществляться несколько раз, таким образом,
меняя и видение, и концептуальный проект, и планы создания версий.
В рамках цикла создания и адаптации выполняются работы по разработке
технического проекта и плана работ для программистов и инженеров,
программирование, тестирование, исправление ошибок, уточнение требований,
100
интеграция, оценка результатов пользователями, внесение изменений в
требования, изменение проектов и планов (при необходимости изменение
видения), повторение цикла до тех пор, пока не будет создан ценный и
качественный продукт для клиента. После чего происходит передача продукта
заказчику и завершение проекта. Все изменения в концептуальном проекте
должны агрегироваться для накопления опыта и обучения, необходимого для
последующих проектов.
Дж.Хайсмит предлагает свои восемь принципов гибкого управления
проектами:
поддержка видения и адаптивной организационной культуры со
стороны руководства и спонсоров;
создание, развитие и поддержка самоорганизуемых и автономных
проектных команд;
стимулирование достижения надежности и последовательности, на
уровнях возможных при данной в проекте неопределенности;
способность к адаптации и постоянным изменениям;
визуализация и обеспечение прозрачности процессов;
институциализация организационного обучения;
развитие практик, поддерживающих каждую выделенную стадию
(специализация способностей и практик);
установление необходимого (но не избыточного) числа контрольных
точек по проекту.
Именно эти принципы можно рассматривать в качестве основополагающих
принципов управления гибкого управления проектами.
Проектный отдел компании, как правило, включает в себя начальника
отдела, менеджеров проекта, технических специалистов по областям
проектирования. Организационно-штатная структура отдела представлена на
рисунке 2.3.
101
Менеджеры
проектов
Менеджеры
проектов
Начальник проектного
отдела
Специалисты (по
направлениям)
3
Менеджеры
проектов
Рисунок 2.3 – Организационно-штатная структура типового проектного
отдела
Отдел выполняет работу на всех стадиях проектирования от предпроектных
разработок до выпуска рабочей документации и осуществления авторского
надзора объектов различного назначения и сложности.
Специалисты разрабатывают комплексную проектно-сметную
документацию на стадиях Проект, Рабочий проект и Рабочая документация.
Специалисты отдела объединяются в рабочие группы во главе с
менеджером отдела. В зависимости от объёма и характера проекта в такую группу
может входить различное количество специалистов каждого профиля.
При выполнении любого этапа разработки проектной документации
главная роль принадлежит менеджеру проекта. В процессе разработки менеджер
проекта отвечает за такие функции, как: отслеживание соответствия объема и
сроков реализованных работ допустимому минимуму, прописанному в контракте,
внедрение в проект ведущих специалистов по инженерным дисциплинам,
координация их работы: нахождение наиболее оптимальных сроков начала работ
для избегания их выполнения преждевременно; выявление числа занятых
работников; отслеживание всех занесенных в проект изменений; рассмотрение
факторов, условий и документов, помогающих оптимизировать цену работ;
контроль выполнения последовательностей и приоритетов, указанных в процессе
распределения работы; поддержание наилучшего выбора стандартных
102
материалов и оборудования в доступном количестве ситуаций, поддержка
минимальной номенклатуры используемых изделий; составление и
использование соглашения с лицензиаром; контроль соблюдения плана
проектных работ, скорректированного с общим планом; подготовка совместно с
заказчиком проектного задания.
Исходя из объема и сложности проекта, деятельность менеджера в момент
проектирования возлагается как на менеджера всего проекта, так и на изначально
указанного проект-менеджера, который находится в команде под руководством
основного менеджера.
2.2.3 Средства коллективной работы над проектом автоматизации
Система управления проектами - это набор организационных и
технологических методов и инструментов, которые поддерживают управление
проектами в организации и помогают повысить эффективность их реализации.
Часто термин система управления проектами трактуют более узко как
автоматизированную или информационную систему управления проектами, т.е.
программу. Организационную и методическую составляющие при этом
вкладывают в термин корпоративная система управления проектами.
qTrack - Система управления проектами с уникальными возможностями
коммуникаций - сервис полностью интегрирован с электронной почтой:
обсуждать задачи так же легко, как по e-mail, а управлять и следить за их
выполнением так же удобно, как в трекере. Базовые возможности
предоставляются бесплатно.
Мегапла
н (продукт) — это отечественная система управления бизнесом,
которая позволяет устанавливать задачи и поручения, следить за их выполнением,
хранить базу данных сотрудников компании, вести историю клиентов и т.д.[1].
Разработчики - одноименная компания Мегаплан.
Является полноценным Groupware продуктом. Само ПО может быть
установлено как на личный сервер компании в интранет, так и арендовано на
серверах поставщика решения «Мегаплан» (SaaS). На сегодняшний день это один
103
из немногих российских программных продуктов, успешно распространяющихся
как SaaS сервис. [2]
Ключевая особенность «Мегаплана» в его SaaS-редакции заключается в
интерфейсе программы, который создан с учетом высоких требований [источник
не указан 154 дня] к удобству пользования и эргономике рабочего пространства.
Для этого архитекторы использовали современные веб-технологии AJAX – все
функциональные блоки на страницах могут обновляться целиком без
перезагрузки, снижая нагрузку на сервер [источник не указан 154 дня] и уровень
потребляемого трафика [источник не указан 154 дня]. Интерфейс сервиса
совместим со всеми современными веб-браузерами, что означает, что компания
не будет зависеть от какой-либо специфичной и устаревшей версии ПО. [2]
Дизайн интерфейса и основной набор модулей были разработаны в Студии
Артемия Лебедева.
Worksection - русскоязычная онлайн-система для управления проектами.
Содержит dashboard, задачи с комментариями, календарь, хранилище файлов,
систему учета времени, тэги. Поддержка SSL, FTP пользователя, субдоменов
пользователя. Отличается простотой и доступностью.
teamtools - система управления бизнесом, которая позволяет вести дела и
задачи, планировать и контролировать проекты, вести базу клиентов, обсуждать
любые объекты, организовать документооборот, настроить оргструктуру и
многое другое
Сравнение разработок по основным параметрам представлено в таблице 2.3.
104
Таблица 2.3
Сравнение систем управления проектами
Параметры
qTrack
Мегаплан
Worksection
Claris
teamtools
ПланФикс
Объединение
сотрудников в
группы
+
-
+
-
+
-
Подключение
клиентов в
систему
+
+
-
+
-
+
Система
оповещений
по e-mail
+
+
+
-
+
-
Система
оповещений
по jabber
+
-
+
-
+
-
Внутренняя
система
оповещений
+
-
+
-
+
-
SSL-
шифрование
+
+
-
+
-
+
Общее
количество
баллов
3.5
5
3.5
3.5
3
6
Наличие
сущности
"Проект"
+
-
+
-
+
-
Разграничение
доступа к
проектам
+
+
-
+
-
+
Диаграмма
Ганта
+
+
+
-
+
-
Наличие
сущности
"Задача"
+
-
+
-
+
-
Вложенность
задач
+
-
+
-
+
-
Разграничение
доступа к
задачам
+
+
-
+
-
+
Возможность
указать
точную дату
выполнения
+
+
+
-
+
-
105
Возможность
указать
точное время
выполнения
+
-
+
-
+
-
Статусы
состояния
задач
+
-
+
-
+
-
Повторяющиеся
задачи
+
+
-
+
-
+
Шаблоны задач
+
+
+
-
+
-
Оповещение о
назначенной
задаче
+
-
+
-
+
-
Оповещение о
просроченной
задаче
+
-
+
-
+
-
Уведомление в
настраиваемое
пользователем
время
+
+
-
+
-
+
Учет рабочего
времени (Тайм-
трекинг)
+
+
+
-
+
-
На основании рассмотренных решений выбрано Мегаплан.
2.3 Информационное обеспечение задачи
2.3.1 Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов.
Информационная модель представлена на рис. 2.1.