+380 (44) 331-2525
+380 (95) 883-3750

Невозможно автоматизировать хаос | Печать |

В результате автоматизации хаоса получишь автоматизированный хаос

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

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

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

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

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

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

Исходя из статистических исследований, в мире только 5% из всех проектов вписываются в запланированные строки и бюджет, в то время как 80% выходят за рамки сроков и/или стоимости, а оставшиеся 15% так и не доходят до завершения. Цель каждого менеджера проекта – попасть в 5%, а не использовать данные цифры для возможности оправдаться перед руководством.

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

Умелое управление проектом подразумевает рост производительности и эффективности труда обязательно с сохранением, а лучше увеличением качества производимого продукта. При этом, улучшение качества, согласно слов аналитика группы ISSIG Project Management Institute Эдварда Деминга (Edwards Deming), всегда связано с увеличением производительности.

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

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

1. постановка задач (обоснование проекта, основные этапы и цели);

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

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

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

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

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

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

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

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

6. оценка стоимости операций проекта.

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

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

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

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

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

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

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

Кроме управления рисками следует обратить внимание на проблему управления качеством проекта создания программных продуктов. Как ни странно, но этому аспекту в России уделяют очень малое значение, пытаясь снизить величину бюджета проекта, экономя на отделе качества программного обеспечения (его просто не создают). В такой ситуации, сам заказчик «играет роль» отдела качества и производит тестирование программное обеспечение на этапе опытной эксплуатации, а в немногих случаях даже на этапе промышленной эксплуатации. Думаем, не нужно объяснять к чему это приводит. На каждый проект создавать отдел качества нет необходимости, он может и должен существовать в компании в единственном экземпляре.  И что самое важное – он должен быть абсолютно независим от отдела разработки. Существует такая естественная тенденция, когда отдел разработки желает побыстрее сдать проект, чтобы приступить к новому, а процесс проверки и достижения необходимого качества является необходимой, но наиболее нелюбимой процедурой для всех разработчиков. В связи с этим очень важно, чтобы руководитель проекта не влиял на отдел качества. Такое разделение отделов разработки и качества, естественно, вызывает некие проблемы в коммуникациях между ними.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

взаимодействие элементов

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

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

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

 
Рады приветствовать вас в разделе, где консультанты КН-груп, основываясь на своих знаниях и более чем 10-летнем опыте
Менеджер проекта тратит порядка 90% своего времени на взаимодействие и коммуникации с заинтересованными сторонами
Центральной задачей менеджмента XXI в. является превращение организаций в лидеров изменений. П. Друкер Часть 1. На пути к