Вернуться в библиотеку

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

Наличие полного понимания следующих ключевых компонентов качественного управления поможет гарантировать, что эти цели будут достигнуты:

1. Управление ожиданиями
2. Проверка качества
3. Внутренняя проверка качества
4. Управление процессом
5. Определение метрик
6. Сообщение о качестве метрик
7. Постоянный процесс улучшения
8. Награды и признание
9. Качественное обучение и ориентация

Управление Ожиданиями. Оно фокусируется на двух основных компонентах: понимание ожиданий партнёра и управление ожиданиями партнёра.

Для понимания ожиданий партнера вы должны быть в состоянии собрать некоторую информацию об ожиданиях заинтересованных сторон проекта, включая сбор данных, классификацию, установления приоритетов. Ошибочно считать, что у всех партнёров одинаковые ожидания.

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

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

Для проверки качества вы должны сделать проверку, утверждение и тестирование. Обязательно включить использование методов проверки качества, таких как содержание стадии, входные и выходные критерии. Содержание стадии обращается к процессу определения границ тестирования. Входные и выходные критерии используются для определения начала и конца проверки. Когда вы идентифицируете такие процессы, рассматривают оценку вашего согласия с этимим качеством проверки процесса развития. Вы можете также сравнить эффективность с другими известными стандартами, таких как Проектный Процесс Реализации (PRP), Модель Зрелости Способности (CMM), или ISO 900X ревизии. Оценивая людей, важно измерить уровень удовлетворенности команды. Если каждый член команды раздражен дневной работой, значит что-то идёт неправильно. Вы должны решить эту проблему как можно быстрее. Никогда недооценивайте влияние морали в коллективе на проект. Старайтесь обратиться к промежуткам удовлетворения от назначения ответственности, обозначения дат завершения и сообщайте планы изменения всем.

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

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

• Подготовьте подразделение для проверки на бреши и лишние шаги, которые не эффективны.
• Оцените соответствие с процессом
• Выполните анализ причин для брешей в работе.
• Обсудите изменения или улучшения после выполнения работы.

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

1.8.3 Определить параметры деятельности

Требования должны быть разработаны для того, чтобы система обеспечила наиболее эффективный процесс работы, который соответствовал бы миссии организации. Критерии качества работы процесса должны быть разработаны для измерения его продвижения к выполнению миссии. Это есть одно из требований закона "Деятельность Правительства и ее результаты" (Government Performance and Results Act -- GPRA) от 1993 года [5]. В идеале некоторые индикаторы, которые измеряют воздействие проекта на критерии качества работы, должны быть разработаны для измерения работы системы.

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

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

Параметры деятельности, которые иногда используются фирмами частного секторы для определения ценности информационной технологии и её воздействие:

· Усовершенствование процесса/продукта/обслуживания

· Сокращение времени цикла

· Удовлетворение клиента

· Рентабельность

Некоторые параметры деятельности управления информацией включают:

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

Процентное изменение качества продукта\обслуживания (например, меньше ошибочных оценок в сделках)

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

Наконец, в течение долгого времени, некоторые ценные уроки были изучены через болезненный опыт. Эти уроки включают следующее:

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

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

В дополнении к этим метрикам часто выгодно проводить встречи постпрограммы. Они – это формальные обзоры проектного завершения, которые используются для идентификации возможностей CPI. Требуйте обратной связи от команды. Это очень важно для получения и отслеживания обратной связи во всех аспектах среды разработки. Для того, чтобы это было эффективно, нужно создать Качественные Командные Действия (QATs). Они нужны для того, чтобы действовать как единая проектная команда и создает возможность для идентификации возможных решений для любой возможности CPI. Учредите программу признания CPI, которая обеспечит стимулы и награды для поощрения более широкого участия в CPI. Наймите экспертов для обеспечения точных и объективных оценок. Это может гарантировать качество услуг. Управляйте заинтересованными сторонами, участниками команды и обзорами удовлетворения пользователей. Эти обзоры помогут SPMO определить качество общего удовлетворения от проекта в комбинации с конечной документацие.

1.8.4 Непрерывный процесс совершенствования (CPI)

Для эффективного CPI SPMO необходимо организовать политику CPI для гарантирования того, что усилия по усовершенствованию объединены в ежедневные действия. Одна техника обычно использовалась для увеличения вовлеченности участников проекта в деятельность CPI - это использование корпоративной коммуникаций. Это могут быть информационные бюллетени, обновленные проектные листы, электронная почта и так далее. Этот тип коммуникации помогает вовлечь большую корпоративную аудиторию. Это так же напоминает команду, где аудитория больше, чем в зале, где они работал над развитием и продвижением своих достижений. Это помогает участникам команды сосредоточиться на целях и чаще всего обеспечивает понимание ассоциации. Если по какой-то причине проект провалится, отрицательный эффект вероятно останется. Кто бы хотел, чтобы его или её имя ассоциировалось с провалом? Это другая форма мотивации, на которую можно положиться для обеспечения результатов. Много раз в моей карьере я слышал, что люди делают утверждения, что на их счету нет провальных проектов. Люди гордятся своей работой и хотят добиться большого успеха. CPI просто позволяет этому произойти.

1.8.5 Организация усовершенствования программного обеспечения.

В сообщении NASA Software Engineering Laboratory исследователи сообщили, что организация разработки программного обеспечения исторически показала существенные недостатки в их способности капитализировать опыт, полученный от выполненных проектов. Эти исследователи нашли, что большая полученного опыта предыдущих проектов уходила в пассив вместо того, чтобы дальше развивать через определенное планирование и использование организационной инфраструктуры. Разработчики ПО и менеджеры, хоть и действовали из лучших побуждений и заинтересованности, не имели ресурсов и времени для сосредоточения на построении корпоративного знания или улучшения организации процесса. У них есть проекты для управления и ПО для доставки. Таким образом, коллективное изучение и опыт должны стать главным беспокойством и считаться активом компании.

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

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

Хоть каждый объект и является отдельным и отличается от других, но все они тесно связаны друг с другом. У каждого компонента есть свои собственные цели, процесс, планы, но при объединении у всех 3х компонентов есть миссия обеспечения ПО для непрерывного улучшения качества и эффективности издержек. Рисунок 1.2 показывает в общих чертах ключевые различия этих трех компонентов, которые составляют организацию усовершенствования программного обеспечения. Это выдвигает на первый план действия и потоки информации для 3х компонентов разработки: разработчиков, аналитиков, шата поддержки.

Таблица 1.2 – общее понятие о ролях

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

Аналитики обрабатывают информацию, полученную от разработчиков, составляют модели продуктов и процессов, обеспечивают обратную связь для каждого проекта. Они также предоставляют базис, инструменты, полученный опыт, данные и дают параметры в форме, которая приспособлена для особенностей проекта.

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

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

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

Вернуться в библиотеку

Статистика	Реклама