Управление качеством – ключевые термины

Управление - Управление проектом

14
Что же такое качество с точки зрения проектного управления? Вопреки бытовому представлению, это элементарное соответствие требованиям. Это уровень, на котором проект закрывает предъявленные к нему требования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

7 ключевых инструментов управления качеством

 

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

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

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

14

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. VladimirL 837 04.12.18 19:09 Сейчас в теме
Общий посыл очень сомнительный.

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


• Если бы в тот момент вместо выпуска не до конца готового продукта, Windows полировали и доводили бы до ума, то, наверное, Microsoft вообще не существовал бы
• ГОСТы для IT-проектов. Они писались, в первую очередь, для военной сферы и космоса.
• Сейчас в IT-сфере так не делают.
• В жизни проще запустить проект, который будет работать вкривь и вкось, посмотреть, что кому не нравится, и уже потом поправить.


Примеры необходимости контролировать качество приведены исключительно из медицины и космоса, тем самым максимально отдаляя слово "качество" от целевой аудитории публикации - 1С-ников. В то же время отрицательные примеры приведены из успешных ИТ компаний.

Пример с Microsoft натянут, так как есть контрпример - Apple, которые сейчас идут ноздря в ноздрю. И Майкрософт вылезли не за счет падающей Windows , а за счет комплиментарного продукта - офисных приложений, которые были значительно надежнее. Без этого качественного комплиментарного продукта успеха бы не было. Поэтому корректно рассматривать в качестве продукта именно их корпоративные приложения, а не ОС.


сделал так, что когда двигаешь мышкой, окошко поворачивается вокруг своей оси. Но зачем он это сделал? Кто его об этом просил? Никто!


В данном примере программист действительно поступил плохо. Но пример некорректен. Он искусственно гиперболизирован. Мы понимаем, что поворот окна вокруг своей оси при выгрузке/загрузке данных никто делать не будет, если это не продиктовано какой-то особой спецификой.

Думаю пример относился к разработчику, которые помимо функционала выгрузки, прописанного в ТЗ сделал еще какое-то удобство для пользователя. Поскольку это потребовало дополнительного времени это оказалось менее рентабельно для поставщика ИТ услуг, что и вызывает возмущение и отнесение работы программиста к категории некачественной.

В то же время есть типология программиста "программист - солдат". "Что прикажут то и делаю. И ничего более приказанного". Целесообразен ли такой типаж? На многих проектах да.

Но и заложенную в информационную систему бомбу этот "солдат" без приказа не уберет. И что самое страшное - даже не сообщит о ней! Потому что его об этом не явно не просили. А явно попросить об этом заказчик, меряющий качество соответствием блок схемам, даже не догадается. Не хватит у него квалификации, а главное - мотивации, опускаться до таких деталей и проговаривать это в инструкции и прописывать в блок-схемах.

Поэтому целесообразен типаж в основном при аутсорсе, со стороны поставщика ИТ услуг, а не заказчика. Взрыв бомбы в информационной системе даст дополнительную прибыль поставщику услуг.

Если конечно клиент не уйдет к другому поставщику. Чего он иногда сделать просто не может ибо уже подсажен на иглу сложно поддерживаемого, зато работающего кода ))



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

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


Возможно конечно смотрю на публикацию глазами технического специалиста, но все же кажется, что заявленная в заголовке тема также не раскрыта от слова "совсем". Если только под качеством не понимается соответствие блок-схеме и гистограмме ))

UX, UI , технологическое качество, устойчивость, маштабируемость, достаточность (то самое "не хуже, но и не лучше", упомянутое в статье). Чем в конце концов занимается QA (quality assurance)? Да и что вообще такое quality assurance в современном понимании? Да много чего даже не упомянуто. Соответствие функциональным требованиям и блок-схемам это тоже часть качества. Но разве это соответствует заголовку публикации?

https://ru.wikipedia.org/wiki/Показатель_качества
dm_romanov.idm; CSiER; GreenDragon; Makushimo; +4 Ответить
2. Makushimo 152 05.12.18 10:53 Сейчас в теме
(1) Согласен по всем пунктам. Как будто сам писал )))

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

Много публикаций "git это круто, а если еще и EDT, ваще божественно", но очень мало слов о том как правильно и быстро запустить процессы контроля качества в команде, в компании. Как запустить отдел контроля качества, как им управлять, как продать всю эту нелепую дичь разбалованному 1Снегами бизнесу.

И вот очередной "гуру" пишет правильный заголовок, но пишет опять не о том и все не то. Я тоже перелопатил много мтериала о теории QA "как должно быть". Но примеряя все это на свою ситуацию в команде, компании, понимаю, что не лезет. Никак. Нужно полностью сменить процесс, команду, компанию, или... просто отказаться от разработки на 1С.

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

Автор, надеюсь ты напишешь полезный материал для 1Снегов, а не просто своими словами перескажешь статьи или учебники.
Я понимаю, это реклама курса или даже услуг консалтинга, бла бла. Но статьи достаточно, чтобы понять - ничего полезного вы не скажете и не знаете.
VladimirL; +1 Ответить
4. acanta 45 05.12.18 14:59 Сейчас в теме
(2)
Никак. Нужно полностью сменить процесс, команду, компанию, или... просто отказаться от разработки на 1С.

Именно сейчас, вполне можно отказаться и от разработки на 1с и от MS Excel / Word.
Можно еще попросить Майкрософт подождать немного, пока 1с разработает свои нормальные электронные таблицы, а настоящих программистов станет достаточно, для того чтобы они были в каждой конторке (в linuxe ничего нельзя и на любые новые действия требуется админ) и 1/6 часть суши найдет им полноценную замену.
3. taiba 78 05.12.18 13:20 Сейчас в теме
BSOD в Windows 3.1? Вы буквы NT потеряли, а это существенно
Оставьте свое сообщение