Файл: Стандарты управления проектами (Определение и сущность управления проектами).pdf

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

Так называемая спиральная модель управления проектом предполагает повышенное внимание к возникающим во внешней и внутренней среде рискам. Большинство рисков, на которые обращает внимание модель связаны непосредственно с командой, занятой в работе над проектом. Так, выделяется так называемый feature creep или постоянный поток изменений в перечень требований проекта, растущий перфекционизм в команде, нехватка квалифицированных специалистов, нереалистичные сроки и бюджет проекта и другие риски. Спираль состоит из четырех витков, каждый обозначает свой цикл в работе над проектом. В свою очередь каждый виток разбит на четыре секции: целеполагание, оценка текущих рисков, создание и тестирование продукта, планирование следующего цикла. [18]. Задача данной системы заключается в скорейшем создании первой версии продукта, направленной на получение дополнительных требований и корректировок со стороны заказчика. Однако, правила модели позволяют переходить на следующий этап не завершив предыдущий, а значит позволяют накапливаться текущим ошибкам и в целом лишают цикличность достаточного формализма. Другими словами, модель недостаточно жестко подходит к организации рабочего процесса.

Еще одним способом разработки проекта является V-модель. V-модель предполагает упрощение и стандартизацию задач. Суть модели заключается в том, что каждый следующий этап цикла предполагает все возрастающую детализацию.[12]. Основными положительными сторонами данного подхода является существенное снижение рисков, уменьшение стоимости проекта, так как ресурсы можно заранее рассчитать и проконтролировать, повышение качества коммуникации между участниками проекта, а также повышение качества за счет стандартизации.

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

Методология управления проектом PRINCE2 (Projects In Controlled Environments 2^[3]), разработанная в Британии не использует итеративного подхода. Для данной методики характерна концентрация на управленческих сторонах работы над проектом и классическом подходе к управлению проектами, выделяя стадии предпроекта, инициации, работы над проектом и финальной стадии проекта [22].

PRINCE2 предполагает четкую иерархическую структуру команды, так как изначально методология предполагалась для государственных проектов. Каждый член команды имеет свою роль во всех стадиях проекта. [20] С точки зрения сильных сторон, PRINCE2 легко адаптируется под нужды организации, позволяет четко определить иерархию и требования к ролям участников проекта, подразумевает уделение особого внимания управленческим решениям.

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

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

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

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

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

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

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

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

Отправной точкой в создании данной методологии можно считать 1930-е годы двадцатого века. Американский ученый-физик Уолтер Шухарт, работавший в Лаборатории Белла начал применять принцип Plan - Do - Study - Act, что переводится как «Планируй» - «Делай»- «Изучай» - «Действуй». Это стало основой формата «спринта», то есть короткого цикла разработки проекта. Шухарт передал полученные знания своему ученику - Эдвардсу Демингу, который использовал данный метод как основу при работе над восстановлением Японского производства после Второй Мировой Войны. Данную методологию можно считать прототипом одной из частей Agile - бережливого производства. Деминг, нанятый концерном Toyota, использовал ее для обучения менеджеров компании. Основа данного способа управления предприятием (или проектом) состоит в оптимизации управленческих и производственных процессов, в недопущении потерь и в использовании принципа минимакса.

В 1986 году начала зарождаться еще одна часть Agile - подхода. Такэути Хиротака опубликовал статью «The New New Product Development Game» [11] (дословно: совсем новая игра по разработке продукта). Автор выявил, что зачастую, лидерами на рынке являлись компании, которые предпочитают вести работу опираясь на небольшие, полуавтономные команды. В то время, это являлось революционным подходом к разработке продукта.

Примерами успешного применения данной методики в 1986 году являлись компании Xerox, Honda и Cannon. Их идея состояла в том, чтобы вместо традиционного, на тот момент, подхода по передаче продукта от команды к команде, фактически используя конвейерный метод, использовать команду как единое целое и позволять работать от начала и до конца над одной задачей.

С точки зрения управления командой это позволяет создать командный дух, использовать сотрудников, привыкших работать вместе как единое целое. Таким образом, у персонала появляется возможность сфокусироваться на одной задаче и принять участие в полном цикле ее выполнения. Данная методика стало прототипом появившейся позже части Agile - Scrum. [25]

Авиастроительная компания LockheedMartin Corporation использовала следующий подход к проведению научно-исследовательских и опытно-конструкторских работ: организация использовала внешнюю команду, полностью изолированную, автономную и засекреченную, которая называлась “Skunkworks”^[4]. Название было связано с тем, что офис команды располагался рядом с фабрикой по переработке пластика и в помещении всегда присутствовал специфический неприятный запах.

Команда была полностью изолирована и не имела внешнего управления. Подобный подход позволил совершить несколько критических открытий в отрасли. Один из основателей Agile Джефф Сазерленд столкнулся с необходимостью срочно создать замену основному продукту компании Easel Corporation, в которой он работал. Он изучал имеющиеся на тот момент подходы к управлению проектами и пришел к выводу, что для решения поставленной задачи идеально подходит команда, по типу команду Skunkworks, с одним различием: сформировать подобную группу нужно было внутри организации, используя ее сильные стороны в виде автономности, свободы действий и интеграции в производственный процесс.

Сазерленд решил заимствовать опыт команды Borland Quattro Pro^[5]. Члены команды ежедневно встречались и обменивались мнениями о том, что было сделано за день, с какими трудностями они столкнулись и что планируется сделать завтра. Подобные встречи повышали эффективность, слаженность и синхронизацию в команде. Совместив опыт “Skunkworks”, Borland Quattro Pro и Такэути Хиротаки Сазерленд придумал собственный подход к управлению проектами - Scrum^[6]. [12]

В итоге, поставленная перед Сазерлендом задача была выполнена крайне успешно. Используя человеческую психологию, разумную автономность команды и краткосрочное планирование удалось сохранить бюджет, сделать в срок и достичь хорошего качества продукта. Формализация подхода была закончена в 1995 году совместными усилиями Джеффа Сазерленда и усилиями его коллеги Кена Швабера [24].

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

В 2001 году состоялась первая встреча клуба «Организационных анархистов», на горнолыжном курорте Сноуберд, в штате Юта для того, чтобы поделиться мнениями и опытом в использовании различных методик управления проектами: Scrum, Crystal, подход к разработке, ориентированный на функциональность. Подобные методологии называются облегченными фреймворками, так как легки в применении и изменяются с учетом динамической внешней и внутренней среды. Несмотря на то, что участники форума придерживались различных позиций по управлению проектами и разработке программного обеспечения было решено найти унифицированное название к нескольким обобщенным подходам менеджмента. Так появилось название Agile.

Несмотря на то, что некоторые менеджеры отмечают, что Agile является в первую очередь набором методов по разработке программного обеспечения, на практике, зачастую, подобная методология применяется и в других отраслях коммерческой деятельности. [24] Например, в книге «Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer» (1994 г.) Стивена Голдмана предлагаются примеры использования данной методики компаниями Harley Davidson и Boeing.

В итоге, требуется отметить, что Agile имеет достаточно разветвленную «родословную», начав свое существование как набор принципов в 1930-х годах в Лаборатории Белла, данная методология продолжила свое развитие в послевоенной Японии и была использована при разработке программного обеспечения Джеффом Сазерлендом в США в 1980-х годах. Используя управленческий опыт, применяя на практике некоторые из принципов методологии менеджеры достигали более высоких результатов, чем их коллеги. Оформление принципов Agile в единый манифест позволяет внедрить данную методику в практически любую компанию [25].

Манифест Agile является комплексным документом, описывающим основные принципы и ценности данного подхода к управлению проектами. Манифест переведен на 50 языков, поддерживается и дополняется с течением времени. Для того, чтобы в полной мере понимать теоретическую часть гибкого управления проектами требуется провести анализ принципов и ценностей методики. Все они были подписаны на первой встрече разработчиков методологий управления проектами в Юте, в 2001 году. Так как Agile предполагает гибкий подход к управлению, то его принципы и ценности также позволяют интерпретировать их с учетом отрасли или текущих особенностей проекта.

Перейдем к анализу содержания манифеста. [25] Первой ценностью данного подхода является: «люди и взаимодействие важнее процессов и инструментов» - эта идея подчеркивает то, что на практике, зачастую успешность выполнения технического задания или проекта зависит непосредственно от исполнителей, их мотивированности и слаженности. Следующей ценностью является: «работающий продукт важнее исчерпывающей документации», другими словами, подписавшие манифест Agile говорят о том, что бюрократическая сторона проекта не является приоритетом и иногда ей можно пожертвовать для достижения главной цели. «Сотрудничество с заказчиком важнее согласования условий контракта» - по мнению подписавших манифест, исполнитель должен взаимодействовать с заказчиком минуя бюрократические процедуры для улучшения общего взаимодействия, напротив, требуется более тесное взаимодействие сторон. Четвертая, и завершающая ценность, описанная в манифесте, фактически является кратким описанием всей методологии: «Готовность к изменениям важнее следования первоначальному плану».