In English

Управлять проектами: планировать, но не только

15.01.2002, Соловей Илья
Издание: Директор
Все программные пакеты для управления проектами помогают составлять расписание работ. Может быть, поэтому разговор часто сразу переходит в спор о том, какой пакет «лучше». А начать следует с того, для каких, собственно, работ нужен пакет, кто его будет использовать и, наконец, как грамотно построить саму работу по проектированию?


Когда нужна автоматизация управления проектами

Управлением проектами в компаниях занимаются мно­гие, иногда даже не подозревая об этом. Точнее, они мо­гут не подозревать, что то, что они делают, это проект. В силу этого они не всегда понимают, что и как в их ра­боте можно автоматизировать, а автоматизировать можно многое.

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

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

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

Пожалуй, одним из основных препятствий на этом пути (наряду с недостаточной экономической мотиви­рованностью, описанной выше) является невысокая общая культура применения этих методов и невысо­кая способность организаций к перестроению своей деятельности. Дело в том, что наибольших результа­тов в этом направлении можно достигнуть, перестро­ив работу не только в одном проекте, но и в организа­ции в целом. На эффективное управление проектами должны быть ориентированы организационные меха­низмы (например, внутренняя отчетность и учет пока­зателей подразделений, порядок открытия и заверше­ния договоров и их этапов), система мотивации персо­нала, схема взаимодействия служб (например, службы продаж, логистики, проектных и производственных подразделений). К сожалению, такие процессы нача­лись вовсе не в большинстве организаций и служб (чаще всего в организациях, переходящих на работу в соответствии с требованиями ISO 9000-2000 или СММ), и это зачастую тормозит внедрение методов управления проектами.

Кто и для чего управляет проектами

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

Проектами в области информационных технологий (ИТ) в компаниях занимаются разные специалисты:
  • директор информационной службы (ДИС);
  • руководитель проекта со стороны заказчика;
  • руководитель проекта со стороны исполнителя.
И каждый из них по-своему заинтересован в управ­лении проектами.

Для ДИС управление проектами — не всегда его пря­мая обязанность, но всегда большая забота. Без органи­зации планирования работ, без минимизации затрат ре­сурсов такая его деятельность просто немыслима.

С точки зрения ДИС важно иметь:
  • перечень проектов и технические требования к ре­зультатам каждого из них;
  • сводный план работ с оценкой его трудоемкости, длительности и стоимости;
  • оценку состояния и развития каждого проекта во времени, пространстве и ресурсах, что позволит учи­тывать, какие из запланированных результатов дос­тижимы в плановые моменты времени, какие сдви­гаются и как это повлияет на общий ход проекта;
построить:
  • процесс надзора за ходом проектов, выполняемых подрядчиками с тем, чтобы быть уверенным в дос­тижимости результатов, - значит, иметь описанные и работающие процессы и процедуры взаимодейст­вия с заказчиками внутри компании и с подрядчи­ками, а также использовать единые требования к качеству работ и шаблоны документов, представля­емых подрядчиками; '
  • процессы освоения внедряемых ИТ, обучения им сотрудников компании — непрофессионалов в об­ласти вычислительной техники, а также обучения I персонала своей службы, которому предстоит со­провождать и обслуживать ИТ. Руководитель проекта со стороны заказчика, обычно сотрудник информационной службы, заинтере­сован в четырех основных вещах:
  • разумном и достоверном планировании работ;
  • фиксации требований к ИТ (со стороны служб компании) и отслеживании их изменений в ходе проекта;
  • учете выданных задании и контроле за их выполне­нием;
  • четких, проверяемых показателях качества выпол­нения работ.
В похожих вещах заинтересован и руководитель проекта со стороны исполнителя.

Итак, общими для всех категорий руководителей являются ключевые позиции:
  • планирование по целому ряду показателей;
  • учет хода работ, в том числе если исполнитель уда­лен от заказчика географически;
  • требования и взаимодействия по поводу их измене­ния, в том числе и с учетом возможной удаленно­сти подрядчика;
  • показатели качества.
Не будем сегодня рассматривать воп­росы требований и показателей качест­ва. Не будем также говорить и о выдаче и контроле исполне­ния заданий (для разрабатывающей и сопровождающей организации, так называемый Change Request Management). Но зато остальные воп­росы как раз и являются традиционной сферой прило­жения автоматизированных методов управления про­ектами.

Инструменты автоматизации управления проектами

Управлять сложными проектами без использования инструментальных средств перестали пару десятков лет назад: это нерентабельно и практически нереаль­но. В настоящее время широко известны продукты Primavera, Artemis, Open Plan — прежде всего для управления проектами в строительстве и крупном сборочном производстве. Известен и положитель­ный опыт их использования в России для проектов этого типа.

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

ДИС — директор информационной службы - это не строитель, который заказывает проекты проектным институтам. Его дело - формирование информацион­ной инфраструктуры компании. Однако и у него есть проекты комплексные, связанные с поставками обору­дования, производством проектных, монтажных и пуско-наладочных работ, с взаимодействием большого количества организаций. В большинстве случаев это проекты среднего размера (несколько сотен или тысяч работ). Однако для больших компаний (Газпром, ЛУ­КОЙЛ, ЮКОС, крупный металлургический комби­нат) проекты могут быть и очень большими - тогда могут потребоваться мощные инструментальные сред­ства (например, Primavera).

Общими отличительными особенностями подходов, заложенных в инструменты управления крупными проектами, является то, что инструменты сами по себе не внедряются. При их внедрении необходимо пони­мать следующее :
  • процессы управления проектами в организации должны быть поставлены, то есть должны быть приняты и введены в действие организационно-экономические решения, устанавливающие поря­док управления проектами, который, собственно, и автоматизируется;
  • необходимо обучение персонала, использующего средства автоматизации;
  • работы надо планировать комплексно по целому ряду временных и ресурсных показателей;
  • необходимо формировать и вести репозиторий (хранилище данных о проектах);
  • требуется использовать архитектурные решения, позволяющие заказчику и подрядчику одновремен­но видеть состояние проекта и отслеживать его из­менения, особенно в технологии intranet. Нетрудно также видеть, что основной областью применения лидирующих на рынке инструментальных средств является все-таки строительство, а применение их в области ИТ-проектов пока имеет характер, види­мо, опытного внедрения.
В программистских ор­ганизациях широко извес­тен MS Project, который стал стандартом де-факто в ИТ-индустрии: большин­ство инструментов плани­рования и даже проектиро­вания имеют интерфейс к нему. Многие используют MS Project для отметки о выполнении работ в ходе проекта, для учета хода проекта и визуализации планов-графиков работ. Особенно перспективным стало такое направление его использования после выхода версии с репозито-рием Central, в котором могут накапливаться данные по средним и большим проектам (тысячи и десятки тысяч работ). Некоторые компании — разработчики ПО для управления средними по размеру проектами используют пакеты Sure Track, Time Line и АВТ Workbench.

С этой точки зрения было бы интересно в последу­ющих выпусках журнала увидеть публикации об опыте применения таких инструментов, как MS Project Cen­tral, в проектах по разработке, внедрению и сопровож­дению программных систем и внедрению готовых ре­шений, например, ERP-систем. (Такой опыт накапли­вается в ряде организаций, в том числе и в нашей.)

Отметим, что в последние годы на рынок (прежде всего отечественный и Восточной Европы) выходят и российские продукты — Project Expert, Spider Project.

Как планировать программные проекты

Для многих проектов характерно, что в их состав входит программная составляющая: разработка ПО (например, Web-сайта или В2В-системы), или его привязка к условиям компании (как по-русски те­перь говорят, кастомизация), или развитие сущест­вующей системы, ее сопровождение и модифика­ция. И в этом случае главная трудность - как плани­ровать работы. Ведь у программистов нет таких нор­мативов, как, например, СНиП у строителей. А преж­де чем планировать проекты, хотелось бы иметь нор­мативы или хотя бы достоверную оценку трудоемко­сти и длительности проекта. Вышеперечисленные инструменты, к сожалению, таких возможностей не предоставляют.

Специалисты, имеющие опыт работ в области соз­дания и внедрения ИТ, знают, что для успеха такого проекта важен целый ряд факторов:
  • класс решаемых задач, тиражность готового про­дукта, вид работ (разработка, развитие, сопровож­дение);
  • выбор схемы ведения работ (модели жизненного цикла) с учетом сложности проекта и возможно­стей коллектива разработчиков;
  • опыт работы в предметной области и на средствах автоматизации разработки;
  • оснащенность разработчиков средствами автомати­зации и аппаратно-программной базой;
  • уровень требований заказчика к срокам и качеству работ.
Существует ряд методик, позволяющих оценить сложность программного проекта, а по ней спрогнозировать трудоемкость и длительность проекта. Наибо­лее известны методики СОСОМО [Т] и метод функ­циональных точек [2|. С их помощью в ряде организа­ций, в том числе и в СНГ, проводится оценка сложно­сти проектов.

Пожалуй, наиболее известным и эффективным инструментальным средством для оценки трудоемко­сти, длительности проектов и числа дефектов, ожида­емых в ходе проекта, в настоящее время является Knowledge Plan [3], пакет, основанный на методиках, разработанных Capers Jones [4] в ходе его почти 15-летней практики по оценке и экономическому сопро­вождению программных проектов. Этот пакет нозволяет «измерять» процессы разработки и сопровожде­ния программного обеспечения независимо от техно­логии, используемой для его создания; при этом оценке подлежат только те функции, которые «вид­ны» заказчику/пользователю.

Knowledge Plan содержит базу знаний, в которой хранятся в параметризованном виде характеристики около 15 000 завершенных проектов. Основываясь на этих знаниях и на имеющихся в арсенале Knowledge Plan моделях жизненного цикла, можно:
  • сгенерировать типовые планы работ но проектам разработки, развития и сопровождения ПО;
  • уточнить их параметрами опыта конкретной орга­низации;
  • сформировать оцененный план работ но проекту;
  • определить трудоемкость планируемых проектов, включающих в себя разработку и сопровождение программного обеспечения;
  • оценить состав ресурсов, необходимых для выпол­нения указанных выше проектов;
  • определить размеры и «функциональную напол­ненность» приобретаемых прикладных пакетов пу­тем подсчета количества функциональных точек по всем функциям, выполняемым в них;
  • провести сравнительный анализ качества и произ­водительности разработки разнотипных проектов или однотипных проектов, при выполнении которых ис­пользовались различные тех­нологии;
  • провести анализ плановой и реальной оценки сложности и величины разработанного программного обеспечения и трудоемкость выполнения проекта;
  • получить стандартные мет­рики сравнения программ­ных продуктов. Можно также накапливать метрики проектов организации и формировать базу метрик и ти­повых планов работ.
Пожалуй, наиболее важной при автоматизированном плани­ровании работ является возмож­ность пересчитать план при раз­личных показателях, чтобы по­нять, что будет, если изменить ситуацию: обучить людей, авто­матизировать их труд, добавить ресурсы и т. п. (то есть выпол­нить анализ «что - если»). Принципиально важно, что результаты оценки могут быть экспортированы в MS Project и использованы совместно с ним.

Заключение

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

Литература

1. Боэм Б. У. Инженерное проектирование программного обеспечения// Радио и связь. М., 1985.

2. Garmus D., Herron D. Function Point Analysis Measurement Practices for Successful Software Projects // Addison-Wesley.

3. SPR Knowledge Plan Version 3.0. User's Guide Copyright (c) 1998 Soft­ware Productivity Research.

4. Capers Jones Assessment and Control of Software Risks (Yourdon Press Computing) // Hardcover/Published 1994.

Центральный федеральный округ