Предыдущая часть статьи

4. Контроль за ходом проекта (ИСО 9001:2000 – «7.5.1 Управление деятельностью»)

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

• Вовлечение персонала. Диспетчирование осуществляет индивидуально каждым работником.
• Разбиение работ на стадии: организация работы – выполнение работы – продвижение работы[2]. Внимание направлено на помощь в организации  работ (когда исполнитель сам планирует сроки и приоритеты выполнения Заданий), а также в продвижении работы (демонстрация уровня и качества работы). Для продвижения работы действует следующий принцип:
• Работа учтена – она есть,  работа не учтена – ее нет.

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

Данная ОКП ставит следующие цели:

1. Результаты и характеристики выполняемого проекта должны постоянно сравниваться с плановыми.
2. Корректирующие действия должны выполняться тогда, когда действительные результаты значительно отклонились от плановых.
3. Изменение обязанностей должно согласовываться с задействованными группами и конкретными работниками.

Качественная характеристика уровней зрелости	в %
0. Контроля нет, есть кризисное управление внеурочными работами;	0%
1. Существует практика ежедневного обхода рабочих мест;	20%
2. Существует практика электронного журналирования выполненных работ по персональным заданиям;	40%
3. Существует практика регулярной оценки выполнения проекта для выявления отклонений от плана;	60%
4. Накапливаются формализованные знания (метрики) по трудовым процессам, что позволяет персонально оценивать свою деятельность и самостоятельно реагировать на отклонения;	80%
5. СУЗ автоматически осуществляет контроль исполнения, напоминая исполнителям об отклонениях в деятельности.	100%

В начале УИ находилось на 1-м уровне оценки зрелости данной ОКП (20%). В 1999 г. в УИ было частично внедрено диспетчирование работ персонала. Диспетчирование не стало постоянной практикой, и УИ осталось на прежнем уровне. Наблюдается тенденция к снижению уровня ОКП до 15%.

CIT в 1999 г. находилась на уровне 20%. С вводом в повседневную практику формирования заданий, а также учета с помощью Prose выполненных в рамках задания работ (индивидуальное диспетчирование), уровень зрелости данной ОКП оценивается на 40% (см. рис.5). С переходом к использованию BTS-систему teamShare в качестве системы управления инцидентами, уже здесь шло оперативное (ежедневное) диспетчирование выполнения исполнителями плановых и внеплановых заданий, а также накопление корпоративных знаний в «Базе Знаний» teamShare.

5. Управление работами с субподрядчиками (ИСО 9001:2000 – «7.3 Закупки»)

ОКП «Управление работами с субподрядчиками»  определяет процессы, связанные с оценкой, выбором и организацией работ с поставщиками (в т.ч. и поставщиками решений). В рамках данного ОКП подразумевается действие следующих принципов:

• Субподрядчик рассматривается как партнер, с которым ведутся работы на долгосрочной основе;
• Если субподрядчик тебя подвел, не выполнив взятые на себя обязательства, виноват не он, а ты, так как выбрал его в качестве партнера, не просчитав все риски.

Данная ОКП определяет следующие цели:

1. Генеральный подрядчик должен выбирать только качественных субподрядчиков.
2. Генеральный подрядчик и субподрядчик должны согласовать друг с другом свои обязательства.
3. Генеральный подрядчик и субподрядчик должны поддерживать постоянную связь.
4. Генеральный подрядчик должен постоянно отслеживать реальные результаты деятельности субподрядчика в сравнении с его обязательствами.

Качественная характеристика уровней зрелости	в %
0. Практики передачи работ субподрядчику нет;	0%
1. Существует разовая практика работы с субподрядчиками на договорной основе, партнерских отношений нет;	20%
2. Имеется практика журналирования выполненных работ субподрядчиком, дающая возможность оценивания;	40%
3. Существует систематическая практика оценки (выгодно «сделать самим или заказать субподрядчикам»), идет формирование партнерских отношений с поставщиками;	60%
4. Накапливаются формализованные знания (метрики) по качеству и срокам выполнения работ поставщиками; субподрядчики полностью интегрированы в процесс создания ПО;	80%
5. СУЗ автоматически осуществляет контроль выполнения субподрядчиками работ, напоминая им об отклонениях в их деятельности; знания становятся доступными и субподрядчикам.	100%

УИ в начале внедрения CMM находилось на 1-м уровне оценки зрелости данной ОКП (20%). В 1999 г. в УИ была внедрена система ведения заявок субподрядчикам (сначала на базе E-mail, затем на базе Интернет). Это позволило организовать коллективную работу в системе управления заявками и оценивать исполнительскую дисциплину субподрядчиков. В УИ уровень управления работами с субподрядчиками поднялся до 40%.

CIT в 1999 г. находилась на уровне 20% зрелости ОКП. С вводом в повседневную практику формирования заявок к субподрядчикам, а также учета выполненных работ на базе E-mail, уровень зрелости данной ОКП оценивается в 30% (см. рис.6).  В настоящее время учет заданий субподрядчикам ведется в BTS-системе teamShare, в которой автоматически генерируются письма для рассылки субподрядчикам и автоматически закачивается электронная почта от субподрядчиков, пришедшая на определенный корпоративный Email и оформленные по заданному шаблону. Планируется организовать прямой доступ субподрядчикам к web-серверу фирмы, где развернута BTS-система teamShare.

6. Обеспечение качества ПО  (ИСО 9001:2000  «7.5.2 Идентификация и прослеживаемость»)

Рекомендуется использовать данную ОКП наряду с методологией PSP [2], где львиная доля работ по контролю качества ПО возлагается на разработчика. По данным SEI [10], разработчик находит ошибки в десять раз быстрее и в десять раз больше, чем тестировщик. Работы по отдельному тестированию считаются экономически невыгодными и приносящими добавочной стоимости, если выполнены условия четкого определения требований к ПО и оценки критериев качества ПО. Тестировщики осуществляют тестирование системы по принципу «черного ящика», т.е. осуществляют общесистемное тестирование.

Данная ОКП определяет следующие цели:

1. Деятельность по обеспечению качества ПО должна планироваться.
2. Должен обеспечиваться объективный контроль за строгим соответствием ПО и процессов принятым стандартам, процедурам и требованиям.
3. Задействованные группы и конкретные работники должны информироваться о действиях по обеспечению качества и об их результатах.
4. Вопросы несоответствия требованиям, которые невозможно разрешить в рамках проекта, должны решаться на высшем уровне компании.

Качественная характеристика уровней зрелости	в %
0. Контроля качества ПО нет, есть повседневная практика - «лучшим контролером ПО является пользователь»;	0%
1. Существует практика «полицейского контроля», с определением виновного и его «материальным наказанием»;	20%
2.Существует практика тотального учета дефектов в разрезе выполненных работ и исполнителей; за выявленный дефект исполнитель не наказывается, идет стимулирование раннего обнаружения дефектов;	40%
3. Существует практика регулярного измерения уровня качества ПО и планирование повышения качества;	60%
4.Накапливаются формализованные знания (метрики) по причинам, вызывающим дефекты, что позволяет исполнителям самостоятельно и своевременно выявлять и исправлять дефекты;	80%
5. СУЗ позволяет планировать предупреждающие действия  по исключению дефектов.	100%

УИ в начале внедрения CMM находилось выше 0-го уровня оценки зрелости данной ОКП (10%). В 1999 г. в УИ попытались внедрить учет дефектов с назначением ответственных за дефект.  В реальной работе учет дефектов не использовался. Сейчас уровень обеспечения качества ПО снизился до 5%.

CIT в 1999 г. находилась на уровне 10% зрелости по данной ОКП. С вводом в повседневную практику  учета дефектов с помощью Prose уровень оценивается в 30%. Наблюдается тенденция к его повышению (см. рис.7).  В 2000 г. начали использовать для управления дефектами систему TestTrack Pro. В начале 2001 г. перешли на BTS-систему teamShare, где дефекты трактовались как инциденты, которые могли прогнозироваться и жизненный цикл которых мониторился с помощью мощной системы отчетов (т.н. «Живые отчеты»).

7. Управление конфигурацией (ИСО 9001:2000 – «7.5.4 Консервация продукции»)

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

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

В ОКП «Управление конфигурацией» входят процессы, связанные с подготовкой и отсылкой версий конечным пользователям. Если рассматривать конечных пользователей как партнеров, участвующих в разработке ПО и вносящих свои замечания, то обновления версий могут быть достаточно частыми. В данном случае система «Управление конфигурациями» должна стоять у конечного пользователя и быть связана с системой учета требований. Работает четкая связка, представленная на рисунке 8.

Рисунок 8

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

Данная ОКП ставит следующие цели:

1. Деятельность по управлению конфигурациями должна планироваться.
2. Находящиеся в работе ПО должны быть идентифицируемы, управляемы и доступны.
3. Изменения в находящихся работе ПО должны контролироваться.
4. Задействованные группы и конкретные работники должны информироваться о статусе и содержании основных направлений разработки ПО.

Качественная характеристика уровней зрелости	в %
0. Нет практики ведения конфигураций, каждый исполнитель на своем компьютере имеет версии исходных файлов, и он же обновляет их у конечных пользователей;	0%
1. Существует практика эталонной версии, с ответственным за сборку исходных файлов от всех исполнителей;	20%
2.Существует технология ведения репозитария ПО, куда разработчики помещают последние версии исходных файлов;	40%
3. Существует практика использование технологий коллективной среды разработки, где автоматически подготавливаются версии конфигураций ПО;	60%
4.Накапливаются формализованные знания (метрики) по стилю и методам разработки, формируются шаблоны и сценарии тестирования, проводится регрессивное тестирование;	80%
5. СУЗ  автоматически оценивает программный модуль и формирует шаблоны и сценарии тестирования, автоматически синхронизирует версии на разных площадках разработки.	100%

УИ находилось на уровне 10%. В начале 1999 г. в УИ было  внедрено поддержание эталонной версии, в конце 1999 г. – среда коллективной разработки «Roundtable». Но данная система не охватывает ведения автономных задач, т.е. часть исполнителей в УИ находятся на уровне зрелости ОКП, равном 60%, а другая – 0%. Интегральный показатель уровня зрелости ОКП - 30% (см.рис.9).

CIT в 1999 г. находилась на уровне 20%. С вводом в повседневную практику среды коллективной разработки «Roundtable» и интеграции её с Prose (а затем и с teamShare) уровень зрелости оценивается в 70%. Фирменный документооборот и хранилище документов (не связанных с разрабатываемым ПО) осуществляется в рамках BTS-системы teamShare.

Основные выводы

Зрелость процессов работы над ПО в УИ соответствует 1-му (начальному) уровню CMM (рис.12). Есть выбросы в сторону 2-го уровня CMM только по двум ОКП: «Управление работ с субподрядчиками» и «Управление конфигурациями». Практика в данных ОКП неустойчива, и УИ может в ближайшие полгода откатиться и по ним. Виден явный провал в ОКП «Обеспечение качества ПО». То состояние, в котором находится сейчас УИ, означает, что внедрение CMM не состоялось (хотя Задача минимум в УИ была решена). Выделяются три основные причины, способствующие этому:

I. Руководство предприятия декларативно поддерживало внедрение CMM в УИ; в своей повседневной практике не использовало методы CMM. Сработало правило: Реальная реорганизация может проводиться только сверху.

II. При внедрении CMM в УИ была выбрана сертификационная схема, т.е. последовательность: «разработка комплекта документации» -> «нормирование» -> «внедрение информационных технологий» -> «начало работы персонала по CMM». Комплект документации был принят в УИ в качестве стандарта «де-юре», «де-факто» – работа велась по старому. Таким образом проявился принцип «двойных стандартов» [1]. Результатом стало то, что в процессе всех аудиторских проверок (которых было очень много в рамках решения проблемы 2000 г.), руководство УИ показывало проверяющим данные документы, – информационный аудит проходил «на ура». С практической точки зрения данные документы стоят меньше, чем бумага, на которой они напечатаны.

III. Так как средний возраст персонала УИ был больше 40 лет, обучение сотрудников шло медленно. При внедрении модели CMM применялись жесткие методы мотивации персонала [4]. Пока высшее руководство поддерживало внедрение, темпы были приемлемы, но затем произошел откат. Причем по некоторым ОКП откатились даже ниже уровня, с которого начиналось внедрение CMM.

Исходя из оценки зрелости ОКП по итогам внедрения CMM, CIT (рисунок 10) ближе ко 2-му уровню CMM. Наблюдается отставание только по двум ОКП: «Управление работами с субподрядчиками» (связано с тем, что привлечение субподрядчиков было эпизодическим) и «Обеспечение качества ПО» (связано с тем, что технологию «Учета и контроля дефектов» начали внедрять в последнюю очередь, и результаты еще не сказались). Внедрению CMM в CIT способствовали следующие факторы:

Руководство CIT на всех уровнях способствовало внедрению методов CMM; первым начинало использовать методы CMM в своей повседневной практике;

Из-за опасения действия принципа двойных стандартов была выбрана следующая схема: «начало работы персонала по CMM» -> «ввод информационных технологий»а«нормирование процессов» -> «разработка комплекта документации». Таким образом, производственная культура в CIT выращивалась, а не навязывалась сверху, как в УИ;

Были исключены все жестские методы; для мотивации персонала использовались только «мягкие методы». Средний возраст персонала в CIT соответствовал 26 годам.

Использование в УИ той же схемы внедрения CMM и методов мотивации еще не гарантировало бы Успеха. Проблема глубже – подходы к реализации принципов «Лидерство» и «Вовлечение работников» определяются типом организационной структуры. Предприятие, в УИ которого осуществлялось внедрение CMM, характеризуется Иерархической организационной структурой («Эйфелева башня»), где из-за жесткой структуры процесс «выращивания лидеров» невозможен, поэтому необходимо принять на работу (или выбрать из существующего персонала) лидера, признать его как лидера, дать соответствующие полномочия, которые должны его приравнять в той или иной мере к первым лицам – руководству предприятия. Только в этом случае на предприятии будет внутренний рычаг непрерывного улучшения, который сделает возможным использование принципов «Лидерство» и «Вовлечение работников».CIT характеризуется организационной структурой, по своему содержанию близкой к «Эткохратии», где можно наладить «систему инкубаторов», воспроизводящих и воспитывающих лидеров, которые смогут вовлечь весь персонал в непрерывное улучшение, тем самым обеспечивая действие принципов «Лидерство» и «Вовлечение работников». («Качество» организации оценивается  по критериям представленным в таблице 9).

Оценка	Средний возраст персонала	Организационная структура	Приверженность стандартам	Видение перспектив	Цели в коллективе
1	от 50 лет	Клановая	тройной стандарт	в прошлом	личные
2	от 40 лет	Иерархическая	двойной стандарт	в настоящем	узкие коллективные
3	от 30 лет	Предпринимат. Ракета	единый стандарт	в ближ. будущем	на потенциал организации
4	от 20 лет	Эткохратия	непрер.улучшение	в перспективе	на развитие общества

УИ представляет собой достаточно консервативную организацию. Любые организационные изменения здесь имеют тенденцию к затуханию и откату. В CIT наблюдаются противоположные тенденции. Во главе угла поставлен принцип «Лидерство», а «Вовлечение работников» идет на основе «Воспитания лидеров».  Таким образом, здесь на деле работает парадигма от «качества предприятия» к «качеству человека»(в профессиональном плане).  Из сравнительного анализа УИ и CIT (рисунок 11) делаем вывод, что для налаживания процесса улучшения необходим определенный уровень корпоративной культуры в организации, иначе все улучшения временны и скоротечны.

Модель CMM по заложенным в ней принципам близка к стандарту ИСО 9001:2000. Но и CMM и ИСО 9001:2000 являются всего лишь инструментами для непрерывного улучшения деятельности предприятия. Сертификация по стандарту ИСО 9001:2000 и подтверждение сертификата должны способствовать росту качества процессов организации, где критерий оценки роста качества процессов – выход предприятия на новый уровень BPI [5].

Список используемой литературы:

1. Лапидус В.А. КонфликтTQMс постсовестким менеджментом на типичном российском предприятии. «Болезни» российского менеджмента // Методы менеджмента качества – 2000. – № 2, 4, С.3.
2. Бобровский С.А. Ошибкам – бой.Personal Software Process (PSP) // PC Week – 2000. - № 8,С.5.
3. Васкевич Д. Стратегии клиент/сервер. Руководство по выживанию для специалистов по реорганизации бизнеса, Перевод с англ. – К.: “Диалектика”, 1996. – 384 с.
4. Головко М.В. Проекты ИС для крупных предприятий: от бессистемного управления к системам управления знаниями // Директору информационной службы – 2000. - № 4, С.2
5. Кутыркин С.Б., Волчков С.А., Балахонова И.В. Повышение качества предприятия с помощью информационных систем классаERP// Методы менеджмента качества – 2000. - № 4, С.8
6. Лузин А.Е., Ляпунов С.И. Новый подход к реструктурированию российских предприятий //PCWeek– 1998. - № 12, С.10.
7. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: Реинжиниринг организаций и информационные технологии. – М.: Финансы и статистика, 1997. – 336 с.
8. Проект Международного Стандарта ИСО/DIS9001:2000 «Системы менеджмента качества. Требования». Перевод с англ. – Н.Новгород: СМЦ «Приоритет», 2000. – 33 с.
9. Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model  for Software, version 1.1. // CMU/SEI-93-TR-024, – Februaru, 1993.
10. Personal Software Process (PSP). Managing Defects // Carnegie Mellon University / SEI, - April, 1999

Отправить ссылку на страницу по e-mail
Обсудить на форуме