іни, бюджет і персонал.
Якість виконання для ІТ-проектів складається:
1. з визначення вимог споживачів до ІВ або ПЗ;
2. відображення вимог на функціональність ІС або ПЗ;
. розробки та впровадження ІС або ПЗ з характеристиками, що забезпечують відповідність встановленим до них вимог споживача;
. підтримання характеристик, закладених при розробці ІВ або ПО при їх впровадженні в компанії споживача;
. технічної підтримки впровадженої ІВ або ПО протягом їх терміну життя з метою збереження закладених в них характеристик [21].
Для проектних компаній, як правило, характерна не функціональна - де дії персоналу можуть бути чітко регламентовані, а матрична структура - це коли один і той же працівник може в різних проектах грати різні ролі. І більше того - у різних проектах можуть вимагатися від співробітників і різні професійні навички.
Процесу постійного навчання та підвищення кваліфікації в ІТ-компаніях в цих обставинах треба приділяти набагато більше уваги, ніж це вимагає ISO 9000: для ІТ-послуг це просто життєво необхідне завдання - адже самі ІТ розвиваються катастрофічно швидко.
Тому процес навчання просто необхідно зробити одним з основних виробничих бізнес - процесів для проектної компанії.
Тепер розглянемо реалізацію процесу управління якістю проекту.
Ключовою особливістю всіх складних проектів є те, що якість на кожній стадії не контактує з іншими. На предконтрактной стадії неможливо заздалегідь описати в повному обсязі вимоги до створюваної системи або роботі. Ця обставина визначає іншу характеристику практично будь-якого проекту: велика кількість ризиків і високий ступінь невизначеності.
Впровадження інформаційних технологій, як правило, пов'язано також зі значним зміною ролі фахівців в уражених бізнес-процесах, неминуче призводить до зміни точки зору експертів предметної області, що, у свою чергу, змінює вимоги до процесів. Це означає, що повністю визначити всі вимоги до проекту на початку його практично неможливо. Крім того, необхідно враховувати, що в більшості випадків цілі носять якісний характер і самі по собі не можуть служити основою для визначення обсягу робіт.
Крім того, проектний бізнес має ще наступні загальновизнані особливості:
1. интеллектуалоемкой характер предметної області більшості проектів;
2. сильна залежність успіху проектів від поведінки замовника;
. підвищені ризики порушення термінів і бюджету, припинення чи призупинення проекту;
. підвищені вимоги до якості, що мають конструктивний, тобто об'єктивно перевірявся, характер;
. високий ступінь індивідуалізації під клієнта і важливе значення організації щільною роботи з ним;
. швидка втрата актуальності їх результатів;
. висока ймовірність появи нових, раніше не виконували робіт, для яких методологія, технологія і сиcтема управління створюються на льоту raquo ;;
. високі вимоги до кваліфікації менеджерів і виконавців, їх висока вартість;
. критична важливість корпоративної офісної системи, що підтримує і бізнес, і комунікації, і базу знань [20].
Високий ступінь індивідуалізації необхідна просто тому, що неможливо загнати всіх замовників під один рівень готових рішень. Це час проходить, зараз замовник не хоче ламати свої бізнес-процеси і підлаштовувати їх під готові рецепти. Йому потрібні рішення, які враховують його специфіку, допомагають створювати оригінальну продукцію і підтримують зручний йому стиль управління. Тільки такий підхід дозволяє швидко знаходити гнучкі і високоефективні рішення.
У рамках проектного підходу якість проекту можна визначити дуже коротко і ємко: це отримання необхідного результату при заданих обмеженнях на ресурси і терміни.
Для кожного конкретного проекту відповідно до ISO 9000 порівняно неважко розробити логічний комплекс заходів щодо забезпечення якості. Цей комплекс може бути оформлений як план забезпечення якості (Quality Assurance - QA). QA-план, як правило, є складовою частиною плану-графіка всього проекту, але може виділятися і для великих проектів, і як самостійний план (підпроект).
Виконання QA-плану і процедур управління якістю зазвичай призводить до подорожчання проекту на 10-15%. І для великих і серйозних проектів це абсолютно виправдано - це якраз приклад необхідного застережливого дії для зниження ризику високої невизначеності при старті проекту. У той же час відмова від управління якістю взагалі ...
