Управление качеством – ключевые термины. Курс по управлению проектами, часть 10

Продолжение моего учебного курса по проектному управлению. Предыдущие материалы: 

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

2. Три фундаментальных принципа проектного управления

3. Роли в проектном управлении

4. Управление заинтересованными сторонами 

5. Устав проекта — это скорлупа яйца

6. Алгоритм управления содержанием проекта

7. Сбор требований

8. Создание концепции проекта (project scope statement)

9. Иерархическая структура работ (ИСР)

Управление качеством представляет собой три процесса:

• планирование;
• выполнение;
• мониторинг.

Важно пояснить качество через другой термин – «нанесение позолоты» (gold plating), который можно описать, как предоставление заказчику чего-то сверх его ожиданий.  То есть заказчик этого не просил, и он был готов принять проект в том виде, в каком он у вас был готов. Но вы сделали для заказчика что-то дополнительное. С точки зрения проектного управления это неправильно. Потому что вы использовали ресурсы спонсора не согласованным с ним образом: лучше было бы не проявлять излишнюю инициативу, а оставить ресурсы в запасе, пусть спонсор сам их использует там, где решит самостоятельно. То есть вы полезли туда, куда вас не просили.
 
Пример «нанесения позолоты». У разработчика стоит задача – сделать выгрузку данных из лабораторных промышленных систем. Это рутинная монотонная задача, которую надо выполнить за неделю. Когда сроки подходят, оказывается, что свою задачу он не выполнил, зато сделал так, что когда двигаешь мышкой, окошко поворачивается вокруг своей оси. Но зачем он это сделал? Кто его об этом просил? Никто! Это его собственная инициатива. И вполне можно было бы обойтись без подобного «улучшения».
 
Поэтому качественный продуктс точки зрения проектного управления – это когда продукт сделан не хуже, чем просили, но и не лучше, чем просили.
 
Еще один термин, который надо знать, – цена качества. Как вы считаете, можно ли сделать мобильное приложение, игру или какую-то программу без единого дефекта, без бага? Наверное, сделать идеальную программу нельзя. Хотя если потратить много сил, применить множество тестов, можно создать софт, который при штатном режиме использования никогда не будет выдавать критические ошибки. Но это долго, дорого, и настолько высокий уровень надежности на самом деле никому не нужен. Пусть лучше будут дефекты, главное, чтобы они не были критичными.
 
Вы помните, как Microsoft выпустил Windows 3.1? Это был ужас ужасный. Именно тогда пользователи выучили термин «голубой экран смерти», потому что они его видели регулярно. Но если бы в тот момент вместо выпуска не до конца готового продукта,  Windows полировали и доводили бы до ума, то, наверное, Microsoft вообще не существовал бы. Потому что не стоит стремиться к полному отсутствию ошибок, важно выпустить какой-нибудь приличный продукт, а дефекты можно устранить потом.
 
Но в некоторых ситуациях требования к качеству будут гораздо выше. Представьте себе ситуацию, когда нужно разработать программное обеспечение для спутника. Если этот софт будет сырым и постоянно сбоить, то цена ошибки окажется высока: перепрограммировать его, а затем перезагрузить будет очень трудно. Или возьмем в качестве примера томограф. Это устройство, которое при неправильном использовании может легко убить человека, у него все для этого есть. Поэтому сертификация томографа – дело очень сложное: проводится множество проверок и тестов, чтобы убедиться, что ваш томограф не убивает людей.
 
Если на вашем проекте цена ошибки оказывается высокой, вам надо сто раз перестраховаться и убедиться, что в вашем продукте нет дефектов. Это и есть цена качества. Иными словами, какую цену вы готовы заплатить, чтобы у вас не было ошибок. Готовы ли вы проверять все множество раз или в вашем случае проще и быстрее запустить проект, а наличие в нем критических ошибок можно пережить. Это то, что вы варьируете в зависимости от обстоятельств.
 
В этой связи надо вспомнить советские ГОСТы для IT-проектов. Они писались, в первую очередь, для военной сферы и космоса. Поэтому там заложен принцип – семь раз отмерь, один отрежь. Сейчас в IT-сфере так не делают. Поскольку мы чаще всего работаем в условиях высокой конкуренции, скорость выполнения часто имеет большее значение, чем качество. В жизни проще запустить проект, который будет работать вкривь и вкось, посмотреть, что кому не нравится, и уже потом поправить.
 
Тем не менее, в больших корпорациях бывают совсем другие правила. Там очень часто нужно пройти множество согласований между департаментами, много всего запланировать и распланировать, и только потом можно будет запустить проект. 
В этой статье я в общих чертах рассказал, что такое качество с точки зрения проектного управления.  А в следующих статьях я подробно разберу 7 ключевых инструментов управления качеством.

К ним относятся:

• причинно-следственная диаграмма (диаграмма Ишикавы);
• блок-схема;
• контрольный листок (чек-лист);
• контрольная карта;
• гистограмма;
• диаграмма Парето;
• диаграмма разбрасывания.

 
Это основные инструменты, но пользоваться можно только теми, которые понравятся. Гистограммы и блок-схемы разработаны не только для контроля качества, ими пользуются и в других сферах. Контрольная карта и контрольный лист – неплохие штуки, но в проектах они редко помогают. 

Следите за обновлениями!

Статья написана на основании видео учебного курса по управлению проектами.

Предыдущая часть курса: Иерархическая структура работ (ИСР). Курс по управлению проектами, часть 9 

Следующая часть курса: Управление качеством – диаграмма Ишикавы (Ishikawa diagram). Курс по управлению проектами, часть 11

Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1