Модель измерения качества проекта

В традиционных областях индустрии следование четко опре­деленной методике и стандартам построения СМ К действитель­но приносит успех.

Однако такие области, как программирование и внедрение ин­формационных технологий в форме ИТ-проектов, остаются су­губо творческим процессом со значительным элементом неопре­деленности, и прямое следование отработанным методикам и стандартам (СММ или ISO 9000) все-таки не дает уверенности в качестве конечных результатов ИТ-проекта.

Привлекательность модной СММ стоит на трех китах процве­тания ИТ-компании: понимании процесса разработки и проек­тирования (или программирования), оценке его зрелости и пла­нировании совершенствования этого процесса. Именно такая модель теперь используется и в ISO 9000:2000.

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

Само по себе, конечно, усовершенствование процесса разра­ботки, так же как и оценка (Assessment) ИТ-компаний по уров­ню профессионализма по ставшей сейчас модной методике типа СММ, безусловно, правильно и похвально. Однако реальная практика именно формального подхода к оценке по уровням СММ и сертификации по ISO 9000 убедительно доказывает, что предположение об однозначной связи между «официально» за­свидетельствованными уровнями СММ и качеством ИТ-услуг в целом все-таки ошибочно. Но, к сожалению, в ИТ-индустрии этот миф получил чрезвычайно широкое распространение.

Поэтому предметом рассмотрения данной главы будет анализ именно сути вопросов обеспечения и повышения качества имен­но ИТ-проектов без прямого привлечения содержания упомяну­тых выше моделей построения СМК.

Начнем с общих понятий проектного управления.

Как известно, краеугольным камнем в управлении проектами (УП) является управление сроками и ресурсами [6, 9].

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

Но руководители проектов — не бизнесмены, они у нас — «ка­питаны кораблей».

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

Вот как определяет основные функции РП по обеспечению ка­чества проекта РМВоК 2000 [6]: «Менеджер проекта — это лицо, ответственное за достижение целей проекта. В управление про­ектом входят определение требований, установка четких и до­стижимых целей, уравновешивание противоречащих требований по качеству, содержанию, времени и стоимости, коррекция ха­рактеристик, планов и подхода в соответствии с мнением и ожи­даниями различных участников проекта. В области УП часто говорят о "тройном ограничении" — содержании проекта, време­ни и стоимости, которое приходится учитывать при согласова­нии разнообразных требований проекта» [9]. В связи с этим умест­но привести матрицу компромиссов в соответствии с трактовкой методологии Microsoft Solutions Framework (MSF) [5] (рис. 2.1).

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

Здесь же рассмотрим предлагаемую мной возможную модель формирования измеримого понятия качества проекта, напри­мер внедрения информационной системы (ИС) в форме ИТ-про-екта.

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

Поэтому следить за расходом бюджета проекта, конечно, нуж­но. Хотя бы потому, что увеличение себестоимости и длительно­сти проекта от запланированных означает безусловные потери его качества (рис. 2.2).

В соответствии с логикой рис. 2.2 введем показатель качества выполненного ИТ-проекта — К, который будем рассчитывать по следующей формуле:

К = (1 + t/Ф/Ф) х (1 - dS/S) х (1 - dT/T) (18),

где: й?Ф/Ф — степень изменения функциональности ИС («плюс» стоит потому, что функциональность, как правило, только рас­тет; если же она сокращена, то нужно ставить «минус»); dS/S— степень изменения себестоимости проекта; dT/T— степень изменения длительности проекта.

Матрица

компромиссов

при выполнении

проекта

noMSF

Трансформируем

матрицу

компромиссов

в модель

формирования

качества

проекта

Под результатами подразумевается

объем

функциональности

в соответствии с

требованиями

Модель формирования понятия качества проекта

Рис. 2.1. Модель формирования измеримого понятия качества проекта внедрения информационной

системы (ИС) — ИТ-лроекта

Таблица 2.1 (продолжение)

Цель	Действие	Этап проекта
Уменьшение вероят­ности возникновения дефектов при эксплуа­тации ИС	Увеличение степени покрытия тестовыми сценариями функцио­нальности ИС	Тестирование
Уменьшение вероятно­сти возникновения про­блем и ошибок при эксплуатации ИС	Обучение конечных пользовате­лей ИС по всем возможным сце­нариям ввода данных и настрой­кам пользовательского интер­фейса	Внедрение
Анализ и экспертная оценка действительной необходимости и реальной степени сложности требований к функционально­сти ИС	Диагностика
Создание методологии выполнения проектов	Организация ЦУП, в задачи которого входят создание методо­логии УП и контроль за ее выпол­нением	Внепроектная организационная задача

Рассмотрим теперь перечисленные процедуры и действия бо­лее подробно.