ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2015 / Выпуск №7 (50) / Не меняйте проекты как перчатки. Часть 5. Жизненный цикл проектов ИТ

Рубрика: Управление проектами

 Марина Аншина, председатель Комитета по стандартам, Российский Союз ИТ-директоров

Не меняйте проекты как перчатки.
Часть 5. Жизненный цикл проектов ИТ

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

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

А также рисунок, показывающий жизненный цикл проекта разработки ПО из PRINCE2.

Оба эти рисунка схожи в своем подходе к модели жизненного цикла проекта:

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

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

Таким образом все модели жизненного цикла проектов ИТ можно разделить на два типа:

• Жесткий, последовательный.
• Гибкий, циклический.

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

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

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

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

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

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

Давайте обсудим каждый этап.

1. Предварительный этап

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

1.1. Начальная стадия, инициация проекта. На этой стадии определяются цель проекта, его окружение и ограничения. Если обратиться к шести сакраментальным вопросам модели Захмана*, то на этой стадии необходимо ответить на два из них: что и зачем. То есть что мы делаем, какой результат хотим получить и зачем нам это надо. А также проверить, что именно этот результат позволит достичь того, что нам нужно. Потому что очень часто проекты начинаются из неясных и не вполне оформленных желаний. И разрыв между полученным результатом и тем, что на самом деле было нужно, бывает разителен.

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

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

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

Рисунок 1. Жизненный цикл проекта в РМВоК

1.3. Стадия планирования и установки. На этой стадии поставленные ранее вопросы должны найти свои вполне однозначные ответы. Именно здесь, если необходимо, происходят исследования, оценки и пробы, в частности, аналитическая работа и пилотные проекты. На этой стадии проводится декомпозиция проекта на отдельные, поддающиеся обзору, управлению и контролю единицы – формируется иерархическая структура работ WBS (Work Breakdown Structure). Тут конкретизируется, из каких фаз и задач состоит проект, определяются его ключевые события, формируется план выполнения проекта.

Здесь каждая роль находит своего «актера»: назначаются руководитель проекта и ответственные за каждую область и процесс (например, 47 процессов РМВоК или 43 процесса ИСО/МЭК 12207), формируется состав проектной команды, определяются внешние исполнители проекта. Это время тендеров, конкурсов и торгов. Уточняются права и обязанности участников проекта, формируется система управления проектом, проверяются и настраиваются средства коммуникаций. В частности, настраивается страница проекта на корпоративном портале, формируется группа в корпоративной социальной сети, или хотя бы создаются общая папка на файл-сервере и общий адрес электронной почты проекта.

2. Этап выполнения

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

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

Эта стадия в некоторых проектах разработки ТО может включать создание того, что в ГОСТ 34 называлось Технический проект – т.е. документа, содержащего технические решения проекта. Хороший технический проект – это тот, по которому средняя по квалификации команда проекта может успешно его выполнить, достигнув нужных результатов и соблюдая требуемые ограничения.

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

2.2. Снабжение, поставка. Здесь осуществляется поставка выявленных на предыдущей стадии компонент проекта: оборудования, вспомогательных компонентов, различного ПО. Эта стадия весьма важна для своевременного выполнения планов и качества результата. К сожалению, во многих проектах ИТ именно эта стадия вынесена вовне: осуществляется отделом снабжения, сотрудники которого не входят в команду проекта, слабо мотивированы, и потребности проекта воспринимают как не самые главные для предприятия. Однако именно для этой стадии необходима грамотная оркестровка усилий. Представьте себе, что при внедрении ERP-системы оборудование закуплено с опозданием. Все другие стадии и задачи проекта будут заморожены, если только команда проекта не предпримет усилий, усложняющих и удорожающих проект (например, по временной аренде оборудования).

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

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

Рисунок 2. Жизненный цикл проекта разработки ПО в PRINCE2

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

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

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

2.5. Проверка, тестирование. Созданный в ходе проекта продукт необходимо проверить. Если речь идет о создании программных систем в соответствии с ГОСТ-Р ИСО/МЭК12207-2010, то такая проверка предполагает как верификацию**, которая позволяет удостовериться в том, что мы выполнили все требования к результату, зафиксированные в проекте, то есть сделали то, что хотели, так и валидацию***, заключающуюся в том, чтобы удостовериться, что мы сделали то, что было нужно. То есть, если результат прошел верификацию, но не прошел валидацию, мы ошиблись на начальной стадии проекта, а такие ошибки далеко не самые редкие, но зато самые опасные.

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

3. Этап завершения

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

Стадия завершения проекта представляет собой комплекс мероприятий.

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

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

3.4. Подведение итогов и анализ результатов проекта. Не только на ошибках надо учиться, но и на достижениях. Как я уже писала, даже самая простейшая оценка проекта ИТ – успешный или неудачный – нередко бывает весьма неоднозначной. Довольно часто результаты проектов ИТ можно оценивать только через несколько лет после их завершения. Большинство пользователей в силу здорового консерватизма не любят новые ПС и с удовольствием находят в них недостатки, не замечая достоинств. Удовлетворенность такими проектами становится понятна только после того, как к использованию их результатов привыкли. И, конечно, не стоит обманывать ни самих себя, ни окружающих, случайно или намеренно искажая проект.

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

Рисунок 3. Последовательная модель жизненного цикла проекта

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

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

 * Модель Захмана – модель описания архитектуры предприятия, разработанная Джоном Захманом в 1987 году.

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

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

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи