развивающимся проектом можно считать

Развивающимся проектом можно считать

3.3. развивающиеся проекты

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

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

Иерархический характер модификации версий структуры содержания проекта и структуры продукции проекта можно продемонстрировать на конкретном примере. Вслед за созданием первой версии программы появляется подверсия с номером 1.1 или подверсия еще более низкого уровня — 1.1.1. В зависимости от потребностей могут создаваться подвер-сии 1.2, 1.3 и т.д. или же подверсии более низкого уровня — 1.1.2, 1.1.3. 1.1.10, 1.2.1, 1.2.2. 1.2.5 и т.д. После того как потенциал решений первой версии будет исчерпан, начинается развитие новой, второй версии программного продукта с последующим развитием ее подверсии (2.1, 2.2 и т.д.). Таким образом, по ходу развивающегося проекта складывается слож­ная иерархическая система последовательного (а иногда и параллельного) управления структурой продукции. Цифровой код той или иной версии определяется самым нижним уровнем структуры продукции, который не подвергался изменениям. Иными словами, версии 1.3.4 и 1.3.7 созданы на базе версии 1.3, т.е. на основе модификации третьего уровня; в данном случае второй уровень является нижним уровнем структуры продукции, который не подвергается изменениям при разработке этих версий. Этот нижний, не подвергаемый изменениям уровень является базовым для со­здания всех производных от него версий. Такая иерархическая модель наглядно демонстрирует особенности развивающегося проекта (конечно, реальная нумерация и кодификация различных версий продукции опреде­ляется не только логикой внесения изменений в конфигурацию продук­ции, но и содержанием проекта и его продукции).

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

4 Управление проектом

ствах), то развивающийся проект построен на постоянном изменении, совершенствовании и управлении конфигурацией продукции проекта.

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

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

Проект создания программного обеспечения — яркий пример развиваю­щегося проекта. Однако развивающийся проект характерен и для других отраслей экономики. Именно развивающийся проект является наиболее распространенным в современной хозяйственной действительности. Со­временная продукция отличается чрезвычайной диверсификацией товар­ного пространства и сокращением периода морального устаревания. Ус­пех продукции определяется широтой ассортимента и интенсивностью его обновления. Динамизм развития продукции не просто оптимальная, а един­ственно возможная стратегия выживания в современном быстроразвива-ющемся мире. Показательность проекта создания программного обеспе­чения обусловлена тем, что в данном случае нет необходимости в налажи­вании серийного производства, а современные средства разработки про­граммного обеспечения’позволяют соединить проектирование программы и ее создание путем генерации программного кода. Например, при ис­пользовании так называемых САБЕ-сре&ств проектирование программы осуществляется путем создания графической модели, описывающей логи­ку информационных потоков и преобразований, затем без вмешательства специалиста преобразуется в программный код. Иными словами, програм­мный проект является развитием продукции в чистом виде. В проектах же разработки и производства материальной продукции процессы разви­тия могут в большей или меньшей степени скрываться за теми видами деятельности, которые сами по себе принципиальной новизной не облада­ют (серийное производство), но при этом вовлекают огромное количество ресурсов и весьма продолжительны по времени, поэтому не позволяют увидеть особые черты развивающегося проекта. Но тем не менее, даже не углубляясь в подробное описание примеров развивающихся проектов в области материального производства, анализ структуры модельного ряда, скажем фото- и видеотехники фирмы «Sony» или же автомобилей «ВМТУ», даст необходимую информацию для вывода о широкой распространенно­сти развивающихся проектов.

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

Содержание

Читать: Аннотация
Читать: Введение
Читать: Управляющая система
Читать: Основы управления проектом
Читать: 1.1. современная концепция управления проектом
Читать: 1.2. окружающая среда и участники проекта
Читать: 1.3. жизненный цикл проекта
Читать: 1.4. базовые элементы управления проектом
Читать: 1.5. характеристика видов деятельности по управлению проектом
Читать: 1.6. подсистемы управления проектом
Читать: Управление проектом. история и современность
Читать: 2.1. управление проектом на фоне развития теории и практики управления
Читать: 2.2. краткая история проектного управления за рубежом (30-е годы xx века — настоящее врем2.3. краткая история проектного управления в россии
Читать: 2.4. проблемы вхождения россии в мировое сообщество управления проектом
Читать: Классификация проектов и разновидности проектного управления
Читать: 3.1. проблемы классификации проектов
Читать: 3.2. терминальные проекты
Читать: 3.3. развивающиеся проекты
Читать: 3.4. открытые проекты
Читать: 3.5. мультипроекты
Читать: 3.6. классификация проектного управления
Читать: Организационная структура управления проектом
Читать: 4.1. понятие организационной структуры управления проектом
Читать: 4.2. организационная структура управления и система взаимоотношений участников проекта
Читать: 4.3. организационная структура управления и содержание проекта
Читать: Сетевые модели
Читать: 5.1. основные понятия и элементы сетевых моделей
Читать: 5.2. правила построения сетевых моделей
Читать: 5.3. упорядочение сетевых моделей
Читать: 5.4. укрупнение работ
Читать: 5.5. «сшивание» сетевых моделей
Читать: 5.6. аналитические параметры сетевых графиков
Читать: 5.7. определение ранних начал и ранних окончаний работ сетевой модели
Читать: 5.8. определение поздних начал и поздних окончаний работ сетевой модели
Читать: 5.9. определение работ, составляющих критический путь
Читать: 5.10. определение резервов времени
Читать: 5.11. определение коэффициента напряженности работы
Читать: 5.12. табличный метод расчета аналитических параметров сетевой модели
Читать: Сетевые модели (дополнительные методы)
Читать: 6.1. расчет сетевой модели методом диагональной таблицы
Читать: 6.2. секторный метод расчета сетевой модели
Читать: 6.3. другие методы расчета сетевой модели
Читать: 6.4. независимый резерв времени
Читать: 6.5. подкритические работы
Читать: 6.6. расчет многоцелевых сетевых моделей
Читать: 6.7. сетевые модели с вероятностной оценкой продолжительности работ
Читать: 6.8. проблемы использования сетевых моделей с вероятностной продолжительностью работ
Читать: 6.9. привязка сетевого графика к календарю и построение масштабных сетевых графиков
Читать: Оптимизация сетевых моделей
Читать: 7.1. оптимизация сетевых моделей по времени
Читать: 7.2. оптимизация сетевых моделей по ресурсам
Читать: 7.3. оптимизация сетевых моделей по времени и стоимости
Читать: Сетевые матрицы
Читать: Матрицы разделения административных задач управления (матрицы разу)
Читать: Информационно-технологические модели
Читать: Структура разбиения работ
Читать: Управление стоимостью и продолжительностью проекта
Читать: Управление качеством проекта
Читать: Управление рисками

Источник

Развивающимся проектом можно считать

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

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

Но если рассмотреть реальную практику строительной деятельности, то оказывается, что даже в такой классической проектной сфере традиционные подходы подвергаются значительно корректировке. Создание строительного объекта никогда не является окончательным результатом, после которого никаких следов от проекта не остается. Можно указать момент, когда проекта еще не было, например, продемонстрировать фотографию, изображающую свалку мусора на том месте, где впоследствии появился мусоросжигательный комбинат. Но вот четко указать момент, когда проекта уже нет, значительно сложнее. Так как чаще всего традиционные терминальные проекты и строительные в частности создают некую продукцию, которая в дальнейшем эксплуатируется, потребляется в течение неопределенно длительного времени без существенного изменения физической формы и используется как средство для достижения каких-либо иных целей субъектов, осуществляющих эксплуатацию. Но ввиду того, что традиционное управление проектами чаще всего не рассматривает стадии эксплуатации, и сам проект приходится искусственно «обрубать». В теории такое возможно (но допустимо ли?), но практику, к счастью, в такое прокрустово ложе традиционного понимания не уложить. Это вовсе не означает, что терминальные проекты никоим образом не соответствуют действительности и являются надуманным продуктом интеллектуальной деятельности, оторвавшейся от реальной жизни. Совсем нет, классические терминальные проекты имеют место быть, например, в том же строительстве: возведение здания или сооружения на условиях «под ключ» генподрядной организацией обобщенно может рассматривать как именно такой конечный проект. «Обобщенно» означает, что все-таки активность генподрядной организации выйдет за пределы стадии реализации в период эксплуатации в виде гарантийного обслуживания, технической поддержки и иных других, на сегодняшний день широко распространенных и продолжающихся развиваться форм участия производителя в процессе эксплуатации его продукции. И при этом свести такую постреализационную деятельность к единовременному завершению проекта невозможно. Но все же с точки зрения генподрядной фирмы постреализационная деятельность вовлекает незначительный ресурс и занимает малую долю внимания менеджмента по сравнению с предыдущими стадиями проектирования (разработки проекта здания или сооружения) и непосредственного строительства (реализации проекта) [2]. И поэтому эту деятельность можно условно выносить за рамки основного проекта без особого ущерба для эффективности деятельности.

Но такой пример реализации терминального проекта необходимо рассматривать как один и, пожалуй, не самый распространенный, частный случай управления проектом. Сводить все проектное управления исключительно к терминальным проектам представляется нецелесообразным. А именно этим занимается сложившаяся на сегодня в России и ставшая уже по умолчанию традиционной методология управления проектами. Этому есть и объективное оправдание. У нас в России эта управленческая методология изначально рождалась и развивалась именно в строительной сфере. Но на сегодняшний день актуальность проектного управления вышла за рамки инвестиционно-строительного комплекса и ныне осознается в наиболее динамично развивающихся сферах хозяйственной деятельности, таких как информационные технологии, консалтинг, деловые услуги [6]. Да и в инвестиционно-строительной сфере экономики появляются новые формы, которые не укладываются в традиционные концепции. Так, например, появившийся недавно в России девелопмент подразумевает значительное расширение рамок применения проектного управления, так как не сводится только лишь к созданию объекта недвижимости будь то с позиций генподрядчика, заказчика-застройщика или инвестора [3]. Наиболее явно отличие девелопмента от других форм организации строительной деятельности заключается в расширении рамок активного участия до включения всего периода эксплуатации. Для девелопера важно, чтобы здание было спроектировано исходя из выявленных им потребностей потенциальных клиентов и с учетом всех архитектурных и строительных норм и правил. Не менее важно, чтобы здание было построено в соответствии с проектом, в установленные сроки и в рамках утвержденного бюджета. Но, пожалуй, самым важным для девелопера является эффективное использование полученной продукции, так как именно на этом этапе осуществляется поступление всех доходов. При этом девелопер может решать задачи не только продажи недвижимости и промышленных объектов физическим или юридическим лицам, осуществляющим непосредственную эксплуатацию, но и передачи в аренду объекта целиком или по частям. Девелопер активно заинтересован в том, чтобы созданный объект приносил как можно дольше и больше прибыли, и поэтому он активно развивает этот объект исходя из собственного знания рынка и необходимости соответствия его требованиям уже в период эксплуатации. Таким образом, девелопмент как новая форма инвестиционно-строительной деятельности не укладывается в традиционное понимание терминального проекта. Но как ни странно, популяризаторы концепции девелопмента в справочной и публицистической литературе являются самыми консервативными сторонниками традиционного управления проектами. Такая, мягко говоря, невнимательность свидетельствует об интеллектуальной оторванности от реальной практики как проектного управления, так и девелопмента. Это довольно характерный пример того, что многие специалисты по теории проектного управления, да пожалуй и по теории менеджмента основной свой интеллектуальный ресурс направляют не в сторону того, что происходит в жизни, а в сторону того, что когда-то было написано на этот счет кем-то еще.

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

Следует повторить, что строительство в этом смысле не является показательным примером, хотя, как видно, и здесь происходят определенные изменения в общем русле развития постреализационной активности. Более целесообразно рассмотреть в этой связи проекты создания новой продукции, и как частный случай проект разработки нового программного обеспечения. Первоначально этот проект проходит стадии проектирования и разработки (реализации), так же, как и обычный терминальный проект. И чаще всего после создания первой полноценной версии такое терминальное понимание проектного управления исчезает. Вслед за выпуском первой версии и ее дальнейшей эксплуатацией проводится работа по сбору и анализу всех замечаний и рекламаций. Помимо того, что в текущем режиме осуществляется техническое сопровождение и устранение выявленных недостатков путем выпуска дополнительных приложений (так называемые «пачи», «сервис-паки»), что, как правило, делается специалистами команды проекта, т.е. в рамках самого проекта, также создается база для пересмотра созданного программного продукта и разработки новой, улучшенной его версии. Такая новая версия не создается на пустом месте, а является органичным продолжением предшествующей версии, и поэтому в организационном плане эта работа проводится специалистами и руководителями, участвующими в разработке первой версии. Таким образом, очередная версия является продолжением, развитием изначального проекта, хотя сама по себе также имеет самостоятельное проектное значение, т.е. рассматривается как подпроект создания новой версии в рамках единого проекта разработки программного продукта. Уже при рассмотрении создания двух версий программного обеспечения видно, что перед нами не простой терминальный проект. Еще более наглядно иная природа проектного управления в подобного рода проектах выступает, если мы рассмотрим более продолжительную временную перспективу, охватывающую не две, а значительно большее количество версий. Такой проект предстанет как постоянно развивающаяся коммерческая инициатива, с одной стороны, проектно-ориентированного характера, а с другой стороны, не имеющая четких общих характеристик всего проекта [1]. Исходя из этого, можно заключить, что это иной вид проектов.

Развивающиеся проекты – это проекты, на момент их инициации не имеющие однозначных целей, достижение которых означало бы завершение проекта. Такие «терминальные» цели в развивающихся проектах обязательно появляются, но момент их появления зависит от многих факторов и в первую очередь от эффективности ранее осуществленной деятельности [5]. Иными словами, хоть развивающийся проект, в отличие от терминального проекта, не имеет известной на начало точки завершения, но эта точка существует, и развивающийся проект рано или поздно завершается, так как рано или поздно исчерпывается набор гипотез и концептуальных решений, заложенных в проект при его инициации. Хоть программные продукты имеют неограниченное количество версий, но в конце концов наступает момент, когда разработчики понимают, что необходимо создавать совершенно иное решение, никоим образом не соотносимое с предыдущим проектом. В логико-временном плане развивающийся проект складывается из отдельных инициатив по дальнейшему совершенствованию, развитию ранее разработанной продукции. При этом такие инициативы также носят проектно-ориентированный характер и по сути могут рассматриваться как самостоятельные последовательные подпроекты. Последовательная природа подпроектов дальнейшего развития имеет помимо всего прочего в плане управления содержанием иерархическую структуру. Каждый из подпроектов развития продукции (создания очередной версии продукции) не начинается с чистого листа, ему всегда предшествует то или иное решение по содержанию продукции, заложенное в самую первоначальную модель содержания проекта, дерево продукции проекта. Накопленные на момент инициации очередного подпроекта данные заставляют усомниться в эффективности отдельных решений, и происходит возврат, «откат» на определенные узлы дерева продукции более высокого уровня. А затем происходит перепроектирование продукции от этих узлов (к которым произошел возврат) дерева продукции вниз, на нижние уровни иерархии, но уже на основе новых данных по параметрам функционирования и эксплуатации продукции. Таким образом, по ходу всего развивающегося проекта происходит появление иерархической совокупности решений по продукции. Такой иерархический характер версионной модификации структуры содержания проекта и структуры продукции проекта можно продемонстрировать на том же примере разработки и развития программного обеспечения. Вслед за созданием первой версии программы появляются подверсии с номерами «1.1» или еще более нижнего уровня «1.1.1». В зависимости от потребностей подверсии первой версии программы могут увеличиваться в количестве («1.2», «1.3» и так далее), или же происходит разработка подверсий более нижнего уровня, таких как «1.1.2», «1.1.10», «1.2.5» и так далее. После того как потенциал решений первой версии будет исчерпан, происходит развитие новой, второй версии программного продукта с последующим развитием ее подверсий. Таким образом по ходу развивающегося проекта складывается сложная иерархическая система последовательного (а иногда и параллельного) управления структурой продукции. Количественный код той или иной версии определяется самым нижним уровнем структуры продукции, который не подвергается изменениям. Иными словами, версии «1.3.4» и «1.3.7» созданы на базе версии «1.3» на основе модификаций третьего уровня, а второй уровень явился нижним уровнем структуры продукции, который не подвергается изменениям при разработке этих версий. Этот нижний, не подвергаемый изменениям уровень является базовым для создания всех производных от него версий. Такая иерархическая модель наглядно демонстрирует существенные особенности развивающегося проекта.

Яркая иллюстрация развивающегося проекта на базе проекта создания программного обеспечения не означает того, что такой этот вид проектов не распространен в других отраслях экономики. Следует сказать, что именно развивающийся проект является наиболее распространенным в современной хозяйственной действительности. Современная продукция отличается чрезвычайной диверсификацией товарного пространства и сокращением периода морального устаревания. Успех определяется широтой продуктовой «линейки» и интенсивностью ее обновления. Динамизм развития продукции сегодня не просто оптимальная стратегия, а единственно возможная для выживания в современном сложном быстроразвивающемся мире. Показательность проекта создания программного обеспечения обусловлена тем, что необходимости в налаживании серийного производства здесь нет, а современные средства разработки программного обеспечения позволяют практически соединить проектирование программы и ее создание путем генерации программного кода. Иными словами программный проект является развитием продукции, так сказать, в чистом виде. В проектах же разработки и производства материальной продукции процессы развития могут в большей или меньшей степени затеняться видами деятельности, которые сами по себе принципиальной новизной не обладают и поэтому не позволяют увидеть особые черты развивающегося проекта. Но тем не менее, даже не углубляясь в подробное описание примеров развивающихся проектов в области материального производства, внимательный анализ структуры модельного ряда, скажем, фото- и видеотехники фирмы «Сони» или же автомобилей «БМВ» даст необходимую информацию для вывода о широкой распространенности развивающихся проектов.

Выводы

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

Рецензенты:

Кещян В.Г., д.э.н., профессор, ФГБОУ ВПО «Российский экономический университет имени Г.В. Плеханова», г. Москва;

Емельянов С.В., д.э.н., ведущий научный сотрудник ИСКРАН, г. Москва.

Источник