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

04.12.18

Управление проектом - Компетенции и навыки РП

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

Управление качеством в 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 ключевых инструментов управления качеством

 

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

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

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

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

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

 

Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"

См. также

Как быть эффективным руководителем проекта, а не экскурсоводом для команды стейкхолдеров

Компетенции и навыки РП Бесплатно (free)

Статья о том, как быть эффективным руководителем проектов. Кто такой руководитель проектов, что подразумевает эта роль в проекте, и зачем она нужна?

22.03.2024    426    0    PChizhov    0    

5

Управление проектом Руководителем проекта со стороны Заказчика

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

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

26.02.2024    778    0    user1270271    0    

11

Нужно ли аналитику 1С знать конфигурирование?

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

Аналитики 1С не всегда хорошо представляют себе, в каких таблицах системы хранятся данные, и из каких объектов состоит конфигурация. Как следствие – технические задания часто получаются непонятными для разработчиков. Расскажем о том, зачем аналитику разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными.

02.02.2024    1187    0    otkalo    1    

6

5 основных внутренних ограничений руководителя

Компетенции и навыки РП Бесплатно (free)

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

22.01.2024    966    0    andmakarov    2    

13

Риски, роли, книги и светлое будущее для ПМов: проектный дайджест #35

Компетенции и навыки РП Обучение и наставничество Инструменты управления проектом Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации vc, Хабра, Инфостарта (и не только) и выбрали самые крутые и полезные.

09.10.2023    804    0    Birby    0    

1

Методика оценки задач или Как «не угореть» по срокам

Компетенции и навыки РП Бесплатно (free)

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

31.08.2023    2250    0    Midzgun    4    

12

Практика построения проектного офиса в ИТ-компании

Компетенции и навыки РП Бесплатно (free)

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

18.08.2023    2234    0    Pryamonosov    2    

6

Национальные особенности управления

Компетенции и навыки РП Бесплатно (free)

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

17.08.2023    1425    0    paalferov    2    

18
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Vladimir Litvinenko 2869 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 160 05.12.18 10:53 Сейчас в теме
(1) Согласен по всем пунктам. Как будто сам писал )))

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

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

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

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

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

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