На сегодняшний день в России наиболее приоритетными направлениями деятельности для организаций ИТ — сферы является повышение качества услуг. Как показывают социологические исследования, проведенные Институтом экономики переходного периода в 2004-2005 г.:
- 83 % руководителей российских предприятий признают существование проблемы несовершенства системы управления и организационной структуры и называют ее основной проблемой бизнеса;
- 66 % компаний нуждаются во внедрении системы показателей эффективности деятельности;
- 72 % руководителей высказали намерение совершенствовать систему управления теми или иными средствами (внедрить систему оценки эффективности подразделений и сотрудников, а также информационную систему, упорядочить бизнес-процессы).
Таким образом, вопрос оптимизации управления компанией, позиционирующейся на рынке информационных услуг и продуктов, является сегодня ключевым.
От качества напрямую зависит успех любого бизнеса. Управляя качеством, мы управляем ресурсами, персоналом и, конечно, качеством проектов.
Проектно ориентированная деятельность имеет узкую специфику, поэтому и архитектура системы менеджмента качества (СМК), и конкретные способы реализации её элементов в каждой проектной компании очень сильно могут отличаться друг от друга и зависят от её масштаба, профиля, структуры, целей, стиля управления и культуры.
Одна из основных идей всеобщего управления качеством (Total Quality Management — TQM) заключается в управлении качеством разрабатываемого продукта в процессе его изготовления, посредствам чего достигается на каждой стадии этого процесса.
Процесс разработки должен быть построен таким образом, чтобы обеспечить возможность измерения качества продукта на каждой стадии.
Это достигается специальной организацией процесса разработки информационного продукта (услуги), предусматривающего создание на основе требований плана тестирования. Причем, снижение качества происходит при рассогласовании всех этих документов в сложных проектах. Обеспечение стабильности процесса возлагается на контроль качества, который должен выявлять несоответствия и информировать о них разработчиков и руководителей проекта.
Для управления качеством необходимо иметь возможность его измерения на всех этапах жизненного цикла на основе отраслевых стандартов.
Приоритетом при выборе показателей качества в большинстве случаев являются назначение, функции и функциональная пригодность соответствующего программного средства. Полное и корректное описание этих свойств должно служить базой для определения значений большинства остальных характеристик качества.
Выбор характеристик и оценка качества программных средств — лишь одна из задач обеспечения качества продукции, выпускаемой компаниями — разработчиками программного обеспечения.
Проектно-ориентированная компания — это компания, осуществляющая свою деятельность преимущественно в проектной форме.
Выбор такой формы существования предполагает получение доходов только за счет создания для клиентов уникальных продуктов, например, специализированного программного обеспечения, информационных систем различной сложности. Уникальность накладывает особый отпечаток и на все стороны деятельности предприятия — от стратегии на рынке до операционного уровня ее бизнес-процессов.
Как показывает практика, модель описания бизнес-процессов, в рамках которой компания описывается в терминах функциональной деятельности (по предмету деятельности), для проектной деятельности неудобна, так как при декомпозиции таких моделей на уровень подразделений бизнес — процессы на нижнем уровне охватывают деятельность, распределенную по различным функциональным подразделениям и специалистам, что нарушает главный принцип реинжиниринга — «один процесс — одно подразделение — один бюджет — один владелец процесса».
В этом случае более целесообразно и удобно (и с целью формирования ключевых показателей деятельности тоже) использовать подход, основанный на цепочке создания ценности, в которой выделяются основные БП, обеспечивающие операционный цикл выполнения проекта и выполняющиеся последовательно, и поддерживающие БП, обеспечивающие функционирование бизнес — системы и сопровождающие создание проектного продукта на всем его протяжении.
Бизнес — процессы в проектно-ориентированной компании осуществляются в соответствии с принятыми в этой компании стандартами управления проектами. Напомним, что по общепризнанной методологии PMI (Project Management Institute) — РМВоК 2000 [6] процессная модель проекта включает несколько стандартных стадий (инициализация, планирование, выполнение, контроль, завершение), каждая из которых предполагает выполнение определенных функций, связанных с управлением временными и стоимостными параметрами проекта, с управлением рисками, проблемами, контрактами, качеством и т. д. [4, 6].
Главной особенностью бизнес — процессов проектно-ориентированной компании являются стандартная структура процессов выполнения проекта (этапы проекта) и стандартные ограничения (срок, себестоимость, персонал). Именно эти стандартные ограничения по времени и стоимости реализации проектов и по качеству результатов и могут быть использованы для построения интегрального (обобщенного) показателя, характеризующего бизнес — процессов проектно-ориентированной компании .
Рассмотрим еще одну важную особенность проектного бизнеса.
Для проектно-ориентированной компании важным условием успешной деятельности является наличие достаточного числа специалистов, отвечающих определенному набору требований к компетенции. Поэтому обязательным показателем служит уровень квалификации различных категорий персонала компании (администраторы, руководители проектов, консультанты, аналитики, программисты и т. д.).
Однако успех проекта в целом определяется не только их квалификацией, но и степенью их заинтересованности, что особенно важно в командной работе в процессе выполнения проекта. Для того чтобы регулировать мотивацию персонала, должен рассматриваться такой вопрос, как доля премии в общем доходе сотрудников.
В компаниях с многолетним опытом работы, особенно в ИТ, просто опасно выстраивать долгосрочную личную эффективность людей на монопольном решении их прямых руководителей.
В таких организациях особенно необходимо создание прозрачной системы мотивации, ориентированной на ценности компании, на коллективные решения по оценке вклада каждого сотрудника. Иначе неизбежны интриги, в результате с уходом из компании одного топ-менеджера уйдет и его команда, то есть получится, что это были люди не компании, а конкретного руководителя.
Это требует построение политики оплаты труда, основанной на реальном весе должности, результате, оценке индивидуального вклада каждого сотрудника.
Основная идея лежит в ведении показателя «Личный рейтинг сотрудника».
Личный рейтинг сотрудника должен зависеть по крайней мере от двух основных показателей:
- от его реальной утилизации (например, за год);
- от его потенциала: знаний и опыта их реализации.
СМК может быть очень эффективной (высокая степень вероятности достижения всех запланированных результатов проекта) для конкретной ИТ-компании, но при этом иметь много отклонений именно от модели ISO 9000.
Поэтому для проектных компаний сертификация по ISO 9000 — мера вынужденная, так как заказчики о других стандартах на проекты разработки ПО и внедрения информационных систем (ИС) просто ничего не знают.
Качество для проектной деятельности —это удовлетворение требований потребителя к поддержке его бизнеса, подтвержденное объективными данными тестирования, а также получение этого результата при заданных ограничениях на сроки, бюджет и персонал.
Качество выполнения для ИТ-проектов складывается:
- из определения требований потребителей к ИС или ПО;
- отображения требований на функциональность ИС или ПО;
- разработки и внедрения ИС или ПО с характеристиками, обеспечивающими соответствие установленным к ним требований потребителя;
- поддержания характеристик, заложенных при разработке ИС или ПО при их внедрении в компании потребителя;
- технической поддержки внедренной ИС или ПО в течение их срока жизни с целью сохранения заложенных в них характеристик.
Для проектных компаний, как правило, характерна не функциональная — где действия персонала могут быть четко регламентированы, а матричная структура — это когда один и тот же сотрудник может в разных проектах играть разные роли. И более того — в разных проектах могут требоваться от сотрудников и разные профессиональные навыки.
Процессу постоянного обучения и повышения квалификации в ИТ-компаниях в этих обстоятельствах надо уделять гораздо больше внимания, чем это требует ISO 9000: для ИТ-услуг это просто жизненно необходимая задача — ведь сами ИТ развиваются катастрофически быстро.
Поэтому процесс обучения просто необходимо сделать одним из основных производственных бизнес — процессов для проектной компании.
Теперь рассмотрим реализацию процесса управления качеством проекта.
Ключевой особенностью всех сложных проектов является то, что качество на каждой стадии не контактирует с остальными. На предконтрактной стадии невозможно заранее описать в полном объеме требования к создаваемой системе или работе.
Это обстоятельство определяет другую характерстику практически любого проекта: большое количество рисков и высокая степень неопределенности. Внедрение информационных технологий, как правило, связано также со значительным изменением роли специалистов в затрагиваемых бизнес-процессах, неизбежно приводит к изменению точки зрения экспертов предметной области, что, в свою очередь, меняет требования к процессам.
Это означает, что полностью определить все требования к проекту в начале его практически невозможно. Кроме того, необходимо учитывать, что в большинстве случаев цели носят качественный характер и сами по себе не могут служить основой для определения объема работ.
Кроме того, проектный бизнес имеет еще следующие общепризнанные особенности:
- интеллектуалоемкий характер предметной области большинства проектов;
- сильная зависимость успеха проектов от поведения заказчика;
- повышенные риски нарушения сроков и бюджета, прекращения либо приостановки проекта;
- повышенные требования к качеству, имеющие конструктивный, то есть объективно проверяемый, характер;
- высокая степень индивидуализации под клиента и важное значение организации «плотной» работы с ним;
- быстрая потеря актуальности их результатов;
- высокая вероятность появления новых, ранее не выполнявшихся работ, для которых методология, технология и сиcтема управления создаются «на лету»;
- высокие требования к квалификации менеджеров и исполнителей, их высокая стоимость;
- критическая важность корпоративной офисной системы, поддерживающей и бизнес, и коммуникации, и базу знаний.
Высокая степень индивидуализации необходима просто потому, что невозможно загнать всех заказчиков под один уровень готовых решений. Это время проходит, сейчас заказчик не хочет ломать свои бизнес-процессы и подстраивать их под готовые рецепты. Ему нужны решения, которые учитывают его специфику, помогают создавать оригинальную продукцию и поддерживают удобный ему стиль управления. Только такой подход позволяет быстро находить гибкие и высокоэффективные решения.
В рамках проектного подхода качество проекта можно определить очень коротко и емко: это получение требуемого результата при заданных ограничениях на ресурсы и сроки.
Для каждого конкретного проекта в соответствии с ISO 9000 [4,6] сравнительно нетрудно разработать логичный комплекс мер по обеспечению качества. Этот комплекс может быть оформлен как план обеспечения качества (Quality Assurance — QA). QA-план, как правило, является составной частью плана-графика всего проекта, но может выделяться и для больших проектов, и как самостоятельный план (подпроект).
Выполнение QA-плана и процедур управления качеством обычно приводит к удорожанию проекта на 10-15 %.И для больших и серьезных проектов это абсолютно оправданно — это как раз пример необходимого предупреждающего действия для снижения риска высокой неопределенности при старте проекта.
В то же время отказ от управления качеством вообще может привести к очень опасным рискам и даже к провалу всего проекта.
В заключительной части хотелось бы рассмотреть аспекты улучшения качества проекта.
Все требования современных стандартов к обеспечению качества проекта в рамках СМК, включающие несколько видов внутреннего контроля, характеризуются большинством реальных разработчиков, который, может быть, чисто теоретически и хорош, но в реальной жизни, по их мнению, не только существенно не влияет на результаты, но и всегда ведет только к уменьшению скорости создания ИТ — продукта.
Более того, внутренние проверки (контроль), которые предусмотрены требованиями, скажем, модели обеспечения качества по стандарту ISO 9001, на практике рассматривались всегда как «вмешательство во внутреннюю кухню» и всегда однозначно не приветствовались разработчиками.
Тем не менее сформулируем ряд параметров, которые смогут повысить качество проекта (табл.1).
Таблица 1.
Цель | Действие | Этап проекта |
Более достоверный анализ хода реализации проекта | Как можно более мелкая детализация работ или предельно возможное снижение сложности отдельных задач | Планирование |
Создание мотивации персонала на повышение качества проекта | Связать размер бонуса с показателем качества выполненного проекта | Внепроектная организационная задача |
Полнота анализа необходимости конкретных требований к системе | Инициация изменений в функциональности системы для предвосхищения последующих дополнительных требований потребителя | Диагностика |
Обеспечение качества проектной документации | Организация независимого рецензирования всех описывающих систему проектных документов | Проектирование |
Организация независимого рецензирования программного кода бизнес-приложений | Разработка | |
Обеспечение возможности адаптации ИС к изменениям в БП уже в процессе эксплуатации ИС | Подробное документирование программного кода бизнес- приложении | Разработка |
Уменьшение вероятности возникновения дефектов при эксплуатации ИС | Увеличение степени покрытия тестовыми сценариями функциональности ИС | Тестирование |
Уменьшение вероятности возникновения проблем и ошибок при эксплуатации ИС | Обучение конечных пользователей ИС по всем возможным сценариям ввода данных и настройкам пользовательского интерфейса | Внедрение |
Анализ и экспертная оценка действительной необходимости и реальной степени сложности требований к функциональности ИС | Диагностика | |
Создание методологии выполнения проектов | Организация ЦУП, в задачи которого входят создание методологии УП и контроль за ее выполнением | Внепроектная организационная задача |
Интерес к управлению проектами — признак развития, появления инвестиций, оздоровления экономики. В России у управления проектами большое будущее, нам предстоит выстроить современную экономику, и желательно рационально использовать имеющиеся ограниченные ресурсы.
Именно поэтому управление проектами вызывает огромный интерес, и уже сотни российских предприятий и организаций внедряют его.
Литература:
- Джодж С., Ваймерских А. Всеобщее управление качеством: стратегии и технологии, применяемые сегодня в самых успешных компаниях. (TQM).- СПб., «Виктория плюс», 2002 г. — 256 с.
- Лапидус В.А. Всеобщее качество (TQM) в российских компаниях. — Типография «Новости», 2003 г. — 436 с.
- Руководство качеством проектов. Практический опыт/ Владислав Ильин. — М.: Вершина, 2006. — 176 с.
- Либерзон В. И. Основы управления проектами. — М., 1997.
- ISO 9000:2000: Система менеджмента качества. Требования.
- Открытые системы // Стандарты в проектах современных информационных систем. — ВИНИТИ, 2001.
- Дастин Э., Рэшка Дж., Пол Дж. Автоматизированное тестирование программного обеспечения: Внедрение, управление и эксплуатация. — М.: Лори, 2003.
- http://www.cnews.ru/newsline/index.shtml72005/06/01/178760.
- Богданов В. Управление проектами в MS Project 2002. — СПб.: Питер, 2003.
- http://www.microsoft.com/msf.
Автор: Сахаров И. С.