Как закрыть ИТ-проект

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

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

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

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

2. Итеративно-каскадный подход, представляющий собой ограниченный набор перекрывающихся по времени фаз проекта и повторяющихся от фазы к фазе процессов ( 2). Такой подход часто используется при внедрении бизнес-приложений, например, в методологии Oracle AIM (Application Implementation Method).

3. Спиралевидный подход - проект состоит из неограниченного набора итераций с повторением определенной цепочки фаз ( 3). Так ведутся современные проекты разработки заказного ПО в соответствии с методологиями IBM Rational Unified Process и Microsoft Solutions Framework.

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

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

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

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

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

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

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

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

Наличие техзадания не является ни необходимым, как в приведенном примере с AIM, ни достаточным основанием для полноценного закрытия работ. Если исполнитель придерживается ГОСТов, к приемочным испытаниям на основании техзадания должен быть разработан и согласован с заказчиком дополнительный документ "Программа и методика испытаний". В нем должны быть прописаны принципы оценки реализации требований техзадания. Другие стандарты и методологии содержат ряд документов-аналогов "Программы и методики испытаний".

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

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

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