Нельзя автоматизировать хаос

Прежде чем говорить о том, как управлять проектами, определимся сначала, что собственно подразумевается под термином “проект”. Авторитетная в области управления проектами, признанной специальной дисциплиной управления, организация Project Management Institute определяет проект как “совокупность действий (процессов), приносящих результат, во время которых людские, финансовые и материальные ресурсы определенным образом организуются с тем, чтобы результат соответствовал утвержденным спецификациям, стоимостным и временным затратам как по качественным, так и по количественным показателям”.

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

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

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

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

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

Для справки отметим, что по статистике в мире всего 5% из всех проектов завершаются вовремя и не выходят за рамки бюджета, в то время как 80% - опаздывают или выполняются благодаря дополнительным инвестициям, а оставшиеся 15% - так и остаются незаконченными. Но также надо отметить, что надо стремится попасть в заветные пять процентов, а не использовать эту справку для оправдания перед руководством.

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

Грамотное управление подразумевает увеличение производительности труда, но с обязательным сохранением, а в идеале и улучшением качества выпускаемых систем. В свою очередь, улучшение качества, согласно аналитику из специальной группы ISSIG Project Management Institute Эдварду Демингу (Edwards Deming), всегда связано с соответствующим увеличением производительности.

Основная сложность разработки инфосистем состоит в том, что создаются уникальные интеллектуальные решения. Консультант ISSIG Луис Зеллс (Lois Zells) считает, что “в 9 случаях из 10 специалисты в области информационных систем работают над задачами, которые до этого ни они сами, ни кто-либо другой не выполняли. В отличие от каменщиков, десятилетиями кладущих одни и те же кирпичи одним и тем же способом, программисты не пишут одинакового кода”. Хотя концептуально это правильно, необходимо рассмотреть факторы, которые могут помочь, грубо говоря, привести работу программиста к работе каменщика.

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

1. разработка постановки задачи (проектное обоснование, основные этапы и цели проекта);
2. разбиение этапов проекта на более мелкие компоненты для обеспечения точной оценки трудоемкости выполнения компонентов и последующего действенного контроля.

   Эта операция является наиболее важной в управлении проектом создания информационной системы, так как именно на этом этапе происходит снижение (именно снижение, а не устранение) той самой неопределенности, которая в конце концов оказывает прямое воздействие на сроки и стоимость проекта. В то же время степень детализации проекта должна зависеть от самого проекта и его сложности. Глупо требовать разбиения проекта вплоть до компонентов, которые содержат только одну строчку кода, но до функций или функциональных блоков, почему бы нет. Кроме того, необходимо требовать, чтобы разработке компонентов предшествовало ее проектирование с созданием проектного документа и обсуждением и принятием этого документа в команде проекта. Это только кажется, что конкретный исполнитель до конца понимает ту задачу, которую ему поручили, иногда даже руководитель проекта этого не понимает. Предварительное обсуждение перед непосредственным кодированием помогает снизить неопределенность и повысить вероятность исполнения задания по кодированию компонентов в предварительно объявленные сроки.

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

   4.1. Детализация проекта и достижение полной ясности для ВСЕХ участников проекта по каждому компоненту проекта. Нельзя оценивать то, что никто не знает, ни как делать, ни что именно.

   4.2. Постоянное измерение производительности КАЖДОГО из участников проекта с целью выяснения их сильных и слабых сторон, а самое главное - сбор статистики о том, насколько при условии выполнения пункта 4.1 его оценка сроков выполнения этапа соответствует реальной действительности. Что бы ни говорили руководители проектов, оценку исполнения этапа им дает сотрудник, который будет исполнять данный этап. И если сотрудник ошибается, то “поползет” весь проект, так как решения, заметьте - все последующие, будут приниматься руководителем проекта исходя из неверных оценок. Опыт проведения многих проектов показывает, что это возможно, и вполне вероятно достичь средней ошибки в оценках, которая не превысит 20%, что является довольно неплохой точностью в разработке программного обеспечения.

   4.3. Соответственно, измерение производительности разработчиков приводит к селекции участников проекта, с целью создания команды из сотрудников, которые дают наиболее точные и соответствующие реальности оценки трудоемкости этапов;

5. определение ресурсов (людей, оборудования, материалов) и их характеристик для проекта и отдельно по каждой операции;
6. оценка стоимостей каждой операции проекта.

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

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

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

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

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

На этом этапе определяют необходимые для успешной реализации проекта управляющие воздействия и применяют их. Управление рисками - это реагирование на события и изменение рисков в процессе реализации проекта.

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

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

Решение коммуникационных проблем лежит в области налаживания стандартных процедур работы над качеством продукта. В отличие от создания самого продукта, процесс исправления ошибок в программе более формализуем, и оценки трудоемкости исправления могут быть очень точны (если уж здесь, на этом этапе, есть ошибки более 100%, то вам нужно менять отдел разработки). Стандартная процедура контроля качества может выглядеть, например, так:

1. отдел разработки должен собирать “билды” проекта каждый рабочий день;
2. в конце каждого рабочего дня отдел разработки передает в отдел качества построенный “билд” и сопроводительную документацию к нему. Сопроводительная документация должна включать в себя информацию о новой функциональности, реализованной в проекте, а также об исправленных ошибках, включая просьбы протестировать вновь ту или иную ненайденную ошибку;
3. в вечернюю смену отдел качества должен проверить новый “билд” по тому сопроводительному отчету, который прислал отдел разработки и составить отчет о тестировании;
4. на следующее утро отдел разработки видит результаты своей вчерашней работы, а руководитель обладает всей информацией по текущему состоянию проекта для принятия управляющих воздействий.

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

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

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

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

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

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

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

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

Для идентификации риска используются методы качественной оценки случайных событий; количественный анализ риска может быть выполнен с помощью различных инструментов: моделей риска, а также по метам Монте-Карло или PERT.

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

Важность управления риском подкрепляется доказанными западными специалистами данными о том, что увеличение затрат на его анализ всего на 20% приводит к повышению вероятности успеха на 80%.

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

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

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

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

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

В частности, компании Time Line, Computer Associates и другие выпускают упрощенные модули для рядовых пользователей, которые служат для ввода данных в более сложные системы, применяемые менеджерами проектов. Project Updater (Time Line) - это своеобразный агент для рассылки запросов менеджеров исполнителям. Последним, в свою очередь, достаточно ввести в формы данные об отработанных часах и процентах выполненных заданий.

TimeSlip (Computer Associates) первоначально был разработан с целью помочь юристам отслеживать затрачиваемое на клиентов время, которое, собственно, последние и оплачивают. Программа интегрирована с Super Project.

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

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

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

Электронная почта используется повсеместно для обмена данными.

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

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

В заключение хотелось бы отметить, что важно не только какой продукт использовать, но и как. Никогда нельзя упускать из глаз общую картину проекта. По мнению директора компании Time Line Дэвида Блэра (David Blair), 15% неудачных внедрений систем автоматизированного управления проектами в области разработки инфосистем связано с непониманием того, что собой представляет проект в целом. “Без этого нельзя сказать, как применять тот или иной инструмент”.

Версия для печати