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

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

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

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

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

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

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

Проектами в области информационных технологий (ИТ) в компаниях занимаются разные специалисты:

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

И каждый из них по-своему заинтересован в управлении проектами.

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

С точки зрения ДИС важно
иметь:

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

построить:

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

Руководитель проекта со стороны заказчика, обычно сотрудник информационной службы, заинтересован в четырех основных вещах:

• разумном и достоверном планировании работ;
• фиксации требований к ИТ (со стороны служб компании) и отслеживании их изменений в ходе проекта;
• учете выданных заданий и контроле за их выполнением;
• четких, проверяемых показателях качества выполнения работ.

В похожих вещах заинтересован и руководитель проекта со стороны исполнителя.

Итак, общими для всех категорий руководителей являются ключевые позиции:

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

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

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

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

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

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

• процессы управления проектами в организации должны быть поставлены, то есть должны быть приняты и введены в действие организационно-экономические решения, устанавливающие порядок управления проектами, который, собственно, и автоматизируется;
• необходимо обучение персонала, использующего средства автоматизации;
• работы надо планировать комплексно по целому ряду временных и ресурсных показателей;
• необходимо формировать и вести репозиторий (хранилище данных о проектах);
• требуется использовать архитектурные решения, позволяющие заказчику и подрядчику одновременно видеть состояние проекта и отслеживать его изменения, особенно в технологии intranet.

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

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

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

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

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

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

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

Существует ряд методик, позволяющих оценить сложность программного проекта, а по ней спрогнозировать трудоемкость и длительность проекта. Наиболее известны методики СОСОМО [1] и метод функциональных точек [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 Software Productivity Research.
4. Capers Jones Assessment and Control of Software Risks (Yourdon Press Computing) // Hardcover/Published 1994.

Статья опубликована в журнале "Директор ИС", № 10, 2001 год