Использование BSC для проектной деятельности

Цитата:

---

Значит мы про разные тусовки. Их сейчас навалом - если не хочешь работать ... можно прилично развеяться.

---

Я не про тусовку :), а про Пятую международную конференцию "Управление проектами, инновации и развитие",
которая состоялась 17-18 ноября 2008 года.
Я очень хочу работать и работаю (не только ваша компания работает, заметьте :)), но такие мероприятия считаю нужным и полезным посещать. Впрочем, если работать выше мирового уровня, то
данная тусовка явно не на пользу :)
Жду статей, материалов, новых методик, подходов,
новых прорывных подходов к управлению проектами.
Удивите нас пожалуйста, а то меня на МВА за последние
годы (Газпром, Лукойл, ЦБ РФ, РЖД, РАО ЕЭС, ОГК, ТГК и т.д, и т.д.) что-то никто новизной не порадовал. А вот напористой практикой неверного примения тех или иных международных подходов неоднократно удивлял.
Удачи!

Пару мыслей по PMBoK

PMBoK - это настольная книга не руководителя проектов, а архитектора корпоративной системы управления проектами (КСУП). Думаю, что руководитель проектов мало что может почерпнуть из данного стандарта (за исключением тех случаев, когда КСУП в компании нет).

Что касается того, что в Компании может не хватать компетенций для разработки своего корпоративного стандарта (вот для чего нужен PMBoK), то да, в этом случае, PMBoK вам не сильно поможет. Но думаю в этом случае (нехватки компетенций) и с проектами проблемы будут. Следствие нехватки компетенций - упрощение модели управления, что значит увеличение рисков.

Я в целом, очень уважаю данный стандарт. Хотя бы уже за то, что он использует процессную терминологию для описания деятельности по управлению проектами. Хотя должен признать, что не весь его я еще постиг (хоть те же процессы управления качеством для меня например непонятны).

Цитата:

---

Сообщение от Тишкин Михаил

Следствие нехватки компетенций - упрощение модели управления, что значит увеличение рисков.

---

...на которое безусловно стоит идти ради работоспособности системы

Цитата:

---

Сообщение от Равиль

Удивите нас пожалуйста, а то меня на МВА за последние
годы (Газпром, Лукойл, ЦБ РФ, РЖД, РАО ЕЭС, ОГК, ТГК и т.д, и т.д.) что-то никто новизной не порадовал. А вот напористой практикой неверного примения тех или иных международных подходов неоднократно удивлял.
Удачи!

---

Опять МВА!!! Да эти идиоты могут только учить воровать. Я бы промолчал, если бы не трогали Газпром!!!!

Мишина С.А. читаю, "Проектный бизнес". Пишет, что модели западные надо так и так адаптировать под наши нужды (напоминает про Хофстеда, и объясняет что система нац. институтов следствие нац. культуры по Хофстеду). При этом подход у Мишина своеобразный, я чего пишу - какое-то время назад шла речь на форуме об объектно-ориентированном подходе к организации, так вот Мишин его и применил, определяя проектную деятельность в организации через иерархию классов со свойствами, методами и событиями. Получается стройно и красиво, очень даже интуитивно, особенно с событиями (т.к. в жизни всё и происходит по событиям, а не столько по алгоритмам). Михаил Шустер, кажется вы упоминали об объектном подходе, можете сказать, как в жизни он прижился, или нет в регламентации? Я встречал поэтапное внедрение КСУП на основе PMI, сейчас работаю в компании с Agile-процессами, не знаю даже что лучше. По мне PMBoK 3rd очень хорош, хоть и толст (и выкинуть для небольших проектов можно много чего из каждой области знаний).

А PMBoK 4, приближаясь к Agile, может отменить четкое регламентирование (и третья волна кажется об этом?). Я прав или нет, Александр Болдин? Насколько я знаю Agile, там не принято расписывать что почем в целом, лишь "ближайшие ходы", а на всё остальное есть обратная связь.

Цитата:

---

Сообщение от Andruxa

Михаил Шустер, кажется вы упоминали об объектном подходе, можете сказать, как в жизни он прижился, или нет в регламентации?

---

Я не исповедую какой-то один подход. Подходом являюсь я сам, т.е. все то, что непротиворечиво сложилось у меня в голове. Набор стереотипов (по Рубцову). Что-то из него прижилось, что-то - нет. Четко описать свой подход, естественно, не могу.
Целесообразность регламентации отрицаю. Вернее, призываю не путать регламентацию с бумажкой. Плодить бумажки-грех. Договариваться о процедурах-благо. Обычное соотношение между первым и вторым - по Паретто, т.е. 99\1 :)
Что до объектно-ориентированного (а не объектного) подхода - вот Вам слоган: "Нет объекта - нет проекта" (С)

Ну да, ну да, ОО-подход, очепятка. Проект-то можно и не рассматривать как объект (при регламентации - как класс, давайте представим что мы сейчас как раз о регламенте договариваемся), продукт конкретного проекта-то понятно что объект (хотя можно и не выписывать отдельно по ООП его методы, свойства и события), более того, не строить своё понимание деятельности на основе иерархии классов.

Я сам подход оценил просто. А про набор стереотипов понятно :) особенно про "плодить бумаги - грех". По мне так не грех, смотря какие и кому...

Цитата:

---

Сообщение от Andruxa

Проект-то можно и не рассматривать как объект

---

Андрей, наверное я Вас не понял, объясню чтоб другие не путались.
Проект не может быть объектом. Объектом является то, на что нацелен проект. Объектом проекта является проблема, которую он устраняет.
Проблема-это разница между "чего хочу" и "чего имею".
Объект может существовать без проекта.
Проект без объекта - тоже бывает. Но это в стороне от здравого смысла. Отмывка, там, невежество, фигня всякая... Бурнокипящая деятельность по таким проектам и поглощает большую часть организационного КПД предприятия. Остальная растворяется в "объектах без проектов". Остается КПД паровоза: 3-7%

В том-то и прикол Мишина, что всё рассматривается как классы и их объекты, причем иерархия наследования выстроена:
"Внекорпоративные знания" -> "Родительская организация" -> "Офис УП" -> "Проект" -> ("Продукт", "Ресурсы", "Окружение"), ("Субъект", "Документы", что-то_ещё_не_помню).

И каждый класс с методами (для объектов), свойствами и событиями (например, старт согласования). И вся регламентирующая документация по Мишину так строится, в отличие от PMBoK, где процессная модель и области знаний, и от IPMA где функционально-системный подход проповедуется.

Цитата:

---

Сообщение от Andruxa

всё рассматривается как классы и их объекты, причем иерархия наследования выстроена

---

Не берите в голову. Иерархия-коварная штука. Число базисов классификации неограничено, хорошо ориентируется в классификаторе только тот, кто его придумал. Если лично Вам он кажется логичным, другие могут его совершенно не воспринимать.

Цитата:

---

Сообщение от Михаил_Шустер

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

---

Согласен.

Цитата:

---

Сообщение от Andruxa

Согласен.

---

Потому в руководстве по качеству МАГАТЭ написана "Документация должна разрабатываться на языке пользователя". Имеется в виду не английский или русский, естественно. Хотя наши гаврики и тут доукраинизировались, зла не хватает

Я вот какую вещь обнаружил. Если взять любой документ толщиной страниц в 200, то окажется, что потребителем 180 из них является только создатель этого документа. А если разбить документ на "смысловые области" и "развести" их по цехам, большинству остается по 2-3 листика, а иным и вообще ничего.
Вот так бы их и писать...
Впрочем, технология уже создана и опробована :)

Ну вообщем и я в толстых регламентах не вижу смысла, скорее в одном на десять страниц и пяти одно-двух-страничных инструкциях - вот это дело, и семи-десяти одностраничных формах. Всё остальное никто не читает, а если и читает, то не запоминает, ну и т.д.

Исключение конечно же ПБУ и прочие законы. Но книжка Мишина всё равно не об этом :)

Цитата:

---

Сообщение от Andruxa

Но книжка Мишина всё равно не об этом :)

---

Вы спросили "прижился ли ООП в регламентации". Я, как мог, скользко ответил :)
А книжка... Мне кажется, любая хорошая книжка - это возмущение стереотипов. Они там в голове отстраиваются в свою какую-то смесь, не образуя иерархической структуры.
Любое изложение чего-либо, это в первую очередь попытка упорядочить, структурировать, соблюсти иерархию. А мозг, похоже, устроен иначе. В этом, возможно, ключ ко всеобщему непониманию друг друга.

Цитата:

---

Сообщение от Михаил_Шустер

Вы спросили "прижился ли ООП в регламентации". Я, как мог, скользко ответил :)

---

ага, понял. но книжка новая, может ещё приживётся.... :)

Цитата:

---

А книжка... Мне кажется, любая хорошая книжка - это возмущение стереотипов. Они там в голове отстраиваются в свою какую-то смесь, не образуя иерархической структуры.
Любое изложение чего-либо, это в первую очередь попытка упорядочить, структурировать, соблюсти иерархию. А мозг, похоже, устроен иначе. В этом, возможно, ключ ко всеобщему непониманию друг друга.

---

так иерархия как раз попытка понять :/ вон биологи до сих пор на Линнея молятся, а химики - на Менделеева и Паули. Может, Мишин - Менделеев российского проектного бизнеса (нет, не устану пеарить, книга понравилась :) хорошо, понятно написана, с хорошими примерами).

Как было бы здорово, если бы многотомные регламенты писались на принципах карт памяти...

Цитата:

---

Сообщение от Тишкин Михаил

Пару мыслей по PMBoK
.........
(хоть те же процессы управления качеством для меня например непонятны).

---

Вы не одиноки, Михаил!
Мне (директору по качеству с 20-летним стажем) тоже непонятно: Зачем и как управлять качеством в проектах?http://www.forum.cfin.ru/images/icons/icon7.gif
Поразмыслив впомнил историю и решил сделать такой вывод:
1. РМВоК отстал от жизни и ИСО 9001:2000! Потому, что в новом стандарте термин "качество продукции (проекта)" ПРАКТИЧЕСКИ НЕ ИСПОЛЬЗУЕТСЯ.
2. Из ИСО 9000:2000 "Качество - степень выполнения установленных требований, совокупностью собственных характеристик". Представьте себе, что Вы делаете проект и его результат не соответствует требованиям ТЗ. У Вас его примут?
3. В старых стандартах ИСО 9001:94 ( и 9001:88) действительно делалось различие в ответственности за "качество" и за "количество". То есть отдельно управляли выполнением требований к результатам проекта; отдельно "качеством проекта" (см. п. 2).
Бред???
Да! Бред!!!
4. По старым стандартам, система (гарантии) качества (quality assurance) существовала отдельно от системы менеджмента и других требований.

Цитата:

---

Следует подчеркнуть, что требования к системе качества, установленные в настоящем стандарте, ГОСТ Р ИСО 9002-96 и ГОСТ Р ИСО 9003-96, являются дополнительными (не альтернативными) по отношению к техническим требованиям на продукцию. [ГОСТ Р ИСО 9001-1996]

---

Сегодня: "Система менеджмента качества - это система менеджмента применительно к качеству" (ИСО 9000:2000), то есть часть всей системы менеджмента, а не отдельная программа.
С уважением Виталий.

Насколько я помню, PMBoK третий неплохо говорит о качестве, причем понимает его как атрибут производственных процессов (диаграмма Ишикавы в нём точно есть). Единственно, что ISO понимает управление проектами как часть СМК, тогда как PMBoK под таким углом дела не рассматривает. Полистаю его, третий, отпишу ещё...

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

Цитата:

---

Сообщение от eliferov

Сегодня: "Система менеджмента качества - это система менеджмента применительно к качеству" (ИСО 9000:2000), то есть часть всей системы менеджмента, а не отдельная программа.

---

Это "сегодня" уже "вчера". Нынче в моде ISO 9000:2008.
С юбкой-клеш и отрезным воротом по манишке. :)

Что вы так зациклились на управлении качеством? Я же его привел как самый простой пример недотепистости PMBOK. Вот если бы я вам тут начал рассказывать о попытках построения управления бюджетом проекта на базе этого ни в чем не повинного стандарта - тогда вы бы обрыдались ... как я немного ранее.

Цитата:

---

...о попытках построения управления бюджетом проекта...

---

Ну не надо, не надо :):):)
Эту задачу решили два года назад :)
Сейчас коллега на конференциях выступает.

Цитата:

---

Сообщение от Равиль

Ну не надо, не надо
Эту задачу решили два года назад
Сейчас коллега на конференциях выступает.

---

Ну я типа тоже иногда на конференциях выступаю ... одно другому не мешает.

Цитата:

---

Сообщение от Александр Болдин

Нынче в моде.....С юбкой-клеш и отрезным воротом по манишке. :)

---

Александр, вживаетесь :) ?

А у меня командировки в январе не будет... Только в марте
Так что давайте лучше Вы к нам :) Причем в полном составе :)

Цитата:

---

Сообщение от Елена И.

Александр, вживаетесь :) ?

А у меня командировки в январе не будет... Только в марте
Так что давайте лучше Вы к нам :) Причем в полном составе :)

---

В полном составе не получится (если я подумал о том о чем вы подумали). А вот сам-то приеду - куда деваться? С заграницами не получается, а в Москве за 2 недели со скуки можно будет окочуриться.

Болдин писал:

Цитата:

---

Это "сегодня" уже "вчера". Нынче в моде ISO 9000:2008.

---

Отличия от 2000 - редакционные. Сути не меняют.
С уважением Виталий.

Цитата:

---

Сообщение от Александр Болдин

Ну я типа тоже иногда на конференциях выступаю ... одно другому не мешает.

---

http://com.sibpress.ru/07.11.2008/strategies/90355/

Цитата:

---

Сообщение от Andrey-Chechako

http://com.sibpress.ru/07.11.2008/strategies/90355/

---

Прошу учесть, что в жизни мы лучше, чем на фотографии :)

Цитата:

---

Сообщение от eliferov

Отличия от 2000 - редакционные. Сути не меняют.
С уважением Виталий.

---

А зачем тогда ресертификация? Чтобы денег срубить в легкую?

Кстати, насчет чисто редакционных правок - я бы так не сказал.

Цитата:

---

Сообщение от eliferov

Мне (директору по качеству с 20-летним стажем) тоже непонятно: Зачем и как управлять качеством в проектах?http://www.forum.cfin.ru/images/icons/icon7.gif

---

Виталий, хоть мой стаж на 5 лет меньше твоего, открою секрет :)
План проекта - это и есть план качества.
Процесс - это фрагмент проекта
Сеть процессов - система качества
Управление качеством в проекте - это работа, направленная на то, чтобы четко определить кто и что должен сделать. Вопрос "когда" - это уже "чистый" вопрос планирования.
Успех проекта определяется тремя составляющими:
-качеством определения структуры работ и их детализации
-личными качествами участников
-талантом планировщика
Первая версия РМВОК "технологическая", последняя-"человеческая". Та же эволюция, что и у стандартов ИСО. Первая годится для любой организации, вторая требует определенной зрелоcти. И написаны для разного уровня пользователей, которых у последней версии практически нет.
РМВОК пошла по граблям...

этот разговор... уж сколько копий сломано...
Но мы неизбежно приблежаемся к венцу эволюции:
рюмочке коньяку с долькой лимона))

Болдин писал:

Цитата:

---

Кстати, насчет чисто редакционных правок - я бы так не сказал.

---

Цитата:

---

ISO 9001:2008 contains no new requirements compared to the 2000 edition, which it replaces. It provides clarifications to the existing requirements of ISO 9001:2000 based on eight years’ experience of implementing the standard worldwide ...
источник: http://www.iso.org/iso/pressrelease?refid=Ref1180

---

Замена в п. 4.1
"a) identify the process ..." на "a) determine the process ..."
и так далее по тексту, - иначе как редакционными правками я назвать не могу.
С уважением Виталий.

Шустер писал:

Цитата:

---

План проекта - это и есть план качества.
Процесс - это фрагмент проекта
Сеть процессов - система качества
Управление качеством в проекте - это работа, направленная на то, чтобы четко определить кто и что должен сделать. Вопрос "когда" - это уже "чистый" вопрос планирования.
Успех проекта определяется тремя составляющими:
-качеством определения структуры работ и их детализации
-личными качествами участников
-талантом планировщика

---

Михаил!
Это же секрет Полишинеля! http://www.forum.cfin.ru/images/icons/icon7.gif
Давай заменим "управление качеством проекта" на "управление проектом". А то, в таком контексте, Руководитель проекта считает, что он может сделать проект кое-как:"У меня же не было менеджера по качеству в проекте!".
Вообще, в последние годы я стал очень плохо реагировать на термин "качество" (иногда даже рычать и кусаться. . .http://www.forum.cfin.ru/images/icons/icon7.gif).
С уважением Виталий.

Цитата:

---

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

---

И у меня такое же ощущение, хотя не рычу и не кусаюсь... :)

Цитата:

---

Сообщение от Andruxa

В том-то и прикол Мишина, что всё рассматривается как классы и их объекты, причем иерархия наследования выстроена:
"Внекорпоративные знания" -> "Родительская организация" -> "Офис УП" -> "Проект" -> ("Продукт", "Ресурсы", "Окружение"), ("Субъект", "Документы", что-то_ещё_не_помню).

И каждый класс с методами (для объектов), свойствами и событиями (например, старт согласования). И вся регламентирующая документация по Мишину так строится, в отличие от PMBoK, где процессная модель и области знаний, и от IPMA где функционально-системный подход проповедуется.

---

Я когда-то был программистом, причём ООП знаю не хорошо, а очень хорошо.
Вот мне никак не понять что-то, как можно унаследовать от объекта "Внекорпоративные знания" объект "Родительская организация".
Как правило, в наследовании используется отношение "это".
То есть "Родительская организация" - это "Внекорпоративные знания" (их специализированный подвид).
Соответственно, должны наследоваться свойства и методы. Особенно, если "Внекорпоративные знания" класс абстрактный.

Хотя подход с ООП может быть полезен как декомпозиция задачи на подзадачи, объекта на подобъекты (как Михаил писал насчёт регламентов).
Хотя с этим и структурное программирование справляется.
Да и не наследование это опять же, а сцепление объектов (отношение типа "машина" - "колёса", "корпус", "мотор" и т.д.).

Другое дело, что для подкованных в ООП людей модель резко упрощается.
Но для неподкованных столь же резко усложняется.

Цитата:

---

Сообщение от knagaev

для подкованных в ООП людей модель резко упрощается

---

...на время. А потом так же резко усложняется. Правда, на другом уровне :)

Цитата:

---

Сообщение от eliferov

...

---

Скучно с тобой, Виталий, и поспорить не о чем :)
Я знал, что ты знал. Даже в книгах твоих встречаю не только понятия, но и выражения, которыми сам давно пользуюсь. Естественно, ни о каких заимствованиях не может быть речи. Путь одинаковый, хотя и разный
Так выпьем же за Дао, хотя да, разгар рабочего дня... Тогда пообедаем

Цитата:

---

Сообщение от knagaev

Вот мне никак не понять что-то, как можно унаследовать от объекта "Внекорпоративные знания" объект "Родительская организация".
Как правило, в наследовании используется отношение "это".
То есть "Родительская организация" - это "Внекорпоративные знания" (их специализированный подвид).
Соответственно, должны наследоваться свойства и методы. Особенно, если "Внекорпоративные знания" класс абстрактный.

---

Всё наследуется, я проверял глазками. Возможно, я в названиях на память накосячил, приду домой проверю

Цитата:

---

Хотя подход с ООП может быть полезен как декомпозиция задачи на подзадачи, объекта на подобъекты (как Михаил писал насчёт регламентов).
Хотя с этим и структурное программирование справляется.
Да и не наследование это опять же, а сцепление объектов (отношение типа "машина" - "колёса", "корпус", "мотор" и т.д.).

---

В том-то и дело, что не сцепление. А подход к регламентированию "От общего к частному" (или "От частного к общему").

Шустер писал:

Цитата:

---

Скучно с тобой, Виталий, и поспорить не о чем :)

---

Дык, ведь. . . Спор - это не единственное лекарство от скуки. Загляни на http://quality.eup.ru/Technology/Scr...ic.php?p=58225
Там мой бывший коллега развлекается (Болдин его тоже хорошо знает). Просит сформулировать определение "выхода процесса".
С уважением Виталий.
P.S. Пиво, тоже неплохое лекарство от скуки. Давно ты в Москве не был.

Цитата:

---

Сообщение от Михаил_Шустер

План проекта - это и есть план качества.
Процесс - это фрагмент проекта
Сеть процессов - система качества
Управление качеством в проекте - это работа, направленная на то, чтобы четко определить кто и что должен сделать. Вопрос "когда" - это уже "чистый" вопрос планирования.

---

Работа, направленная на то, чтобы четко определить кто и что должен сделать - в PMBoK это процессы "Управления содержанием" (что для исполнителей), "Управления интеграцией" (что для руководителей) и "Управлением сроками" (кто это что делает)

Так все-таки, что же тогда включает PMBoK в процессы "Управления качеством"? :)

Цитата:

---

Сообщение от Тишкин Михаил

Так все-таки, что же тогда включает PMBoK в процессы "Управления качеством"? :)

---

Да плюньте и разотрите, какая разница? Джаст ду ит :)
Мое подозрение такое. Разработка РМВОК шла на принципах управления проектами. Была определена СРР и распределена между участниками (гляньте список, с ума сойти). Потом объекты СРР начали конфликтовать, РП стал штопать дубли и нестыковки. Сложность задачи управления знаниями превысила реализуемость и вышло что вышло
В управление качеством искусственно вынесены некоторые детали, которые могли находиться в каком угодно разделе. Простые люди для таких вещей создают раздел "Разное", куда и прячутся все недостатки классификации (спецы по ООП меня поймут :)).
Вообще, РМВОК настолько хорошо структурировано, что аж тошно. Перестарались.
А структура ИСО чудовищна, хотя там принят совсем другой базис классификации.

Цитата:

---

Сообщение от Михаил_Шустер

В управление качеством искусственно вынесены некоторые детали, которые могли находиться в каком угодно разделе. Простые люди для таких вещей создают раздел "Разное", куда и прячутся все недостатки классификации (спецы по ООП меня поймут ).

---

А простой парень Билл Гейтс для этого даже придумал специальный программный объект - "Корзина".

Надо же как вы тут спелись с Виталием. :-)
А я однако несогласный - не тождественно управление проектом управлению качеством в проекте. И менеджер по качеству нужен. И задач у него всего 2: предотвращение и разгребание - предотвращение инцидентов и разгребание последствий оных (ибо не всегда есть возможность все предусмотреть). Остальные задачи из этих 2х получаются наследованием.

И еще вдогонку: в проекте качество - совсем не обязательно соответствие ожиданиям клиента. Просто в силу самого понятия проекта:
а) результат уникален (не с чем сравнивать, ожидания эфемерны);
б) неопределенность (другими словами клиент точно не знает, чего и когда хочет).
Отсюда прямо следует, что для проектного бизнеса ISO 9000 работает с оговорками.
...
Ну надо же, куда может завести, казалось бы обычная логическая цепочка. :)

*Подумалось* Менеджер по управлению качеством качества...

Однако, вызывает определённые ассоциации с определённым сатирическим номером прошлого.

Цитата:

---

Сообщение от Александр Болдин

Ну надо же, куда может завести, казалось бы обычная логическая цепочка. :)

---

Как выразился Ерофеев в незабвенном: "И тут моя глухонемая мама сказала: "Далеко же ты зашла, Лиза, в своих поисках любви" :)

Цитата:

---

Сообщение от Александр Болдин

в проекте качество - совсем не обязательно соответствие ожиданиям клиента

---

Позвольте, товарисчь, Вас поправить.
Отец направления Деминг возопил (плял?): "Одержимость клиентом"
Типа, выпрыгивая из штанов, ПОНЯТЬ чего хочет клиент и дать ему это.
Потому что он никогда не знает наверняка, чего хочет; в проектах, там, или еще где либо. Кстати, есть ли такое "что-либо", чего нельзя было бы назвать "проектом"? Кому и закупка скрепок на базаре - проект.

Менеджер по качеству в проекте... Если он хороший менеджер-то нужен, чтоб разгрузить РП и самому вырасти в РП. Если плохой-то чтоб заносить хвосты или не нужен вообще. Такое постоянное мнение мое.

Цитата:

---

Сообщение от Михаил_Шустер

Отец направления Деминг возопил (плял?): "Одержимость клиентом"
Типа, выпрыгивая из штанов, ПОНЯТЬ чего хочет клиент и дать ему это.
Потому что он никогда не знает наверняка, чего хочет; в проектах, там, или еще где либо.

---

Отец направления недаром был понят только в хентайной Японии. Есть в этом некий скрытый смысл, вероятно. :)
Что касается "выпрыгивания из штанов", могу привести другую цитату (не помню из кого) - "Не стоит стараться быть бОльшим католиком, чем Папа римский".
Не надо ни из чего выпрыгивать - зима на дворе. Тем более, что в проектах чаще всего: задание ставит один, принимает результат другой, а платит вообще третий ... тут никаких штанов не хватит.

Цитата:

---

Сообщение от Михаил_Шустер

Менеджер по качеству в проекте... Если он хороший менеджер-то нужен, чтоб разгрузить РП и самому вырасти в РП. Если плохой-то чтоб заносить хвосты или не нужен вообще. Такое постоянное мнение мое.

---

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

Цитата:

---

Кстати, есть ли такое "что-либо", чего нельзя было бы назвать "проектом"? Кому и закупка скрепок на базаре - проект.

---

Одна знакомая дама специализирующаяся на консалтинге по управлению проектами утверждала, что в мире ничего нет, кроме проектов. Как в фильме "Москва слезам не верит" - будет только одно телевидение. Спорить было абсолютно бесполезно. Если ты был несогласен на тебя смотрели как на сумасшедшего дебила. Вот так :)

Болдин писал:

Цитата:

---

И еще вдогонку: в проекте качество - совсем не обязательно соответствие ожиданиям клиента. Просто в силу самого понятия проекта:
а) результат уникален (не с чем сравнивать, ожидания эфемерны);
б) неопределенность (другими словами клиент точно не знает, чего и когда хочет).
Отсюда прямо следует, что для проектного бизнеса ISO 9000 работает с оговорками.

---

Нет таких слов в стандарте "ожидания потребителей". В разделе 1.1 ИСО 9001:2000 прямо написано для каких предприятий предназначен стандарт:

Цитата:

---

предоставлять продукцию, которая соответствует требованиям потребителя и соответствующих нормативных документов...

---

А требования вносятся в ТЗ на проект, меняются, согласовываются и . . . выполняются руководителем проекта. А если мне (руководителю проекта) будет мешать "менеджер по качеству", или пытаться управлять проектом через мою голову, - выгоню такого. Отвечать за результат может только один.
Мои выводы:
а) ИСО 9001:2000 для проектов применим,
б) менеджер по качеству - "дармоед", который не нужен.

Шустер писал:

Цитата:

---

А структура ИСО чудовищна, хотя там принят совсем другой базис классификации.

---

Структура ИСО 9001 - примитивна и содрана у Деминга. Давно известный цикл P-D-C-A (Plan-Do-Check-Act). Кстати, в версии ISO/DIS была ссылка на Деминга, а в утвержденном стандарте убрали. ???

Цитата:

---

Сообщение от Равиль

утверждала, что в мире ничего нет, кроме проектов.

---

Можно и так сказать, но любые крайности вредны
Зачем делать сложно то, что можно сделать просто?
В русле сегодняшнего обсуждения, лишнее качество-вредно :)

Цитата:

---

Сообщение от Александр Болдин

Не получаются из менеджеров по качеству РП

---

Значит меня и Елиферова не существует :)

Цитата:

---

Сообщение от eliferov

а) ИСО 9001:2000 для проектов применим,
б) менеджер по качеству - "дармоед", который не нужен.

---

а) проект проекту рознь. Из проекта на ИСО нужно смотреть на предмет не пропущено ли чего в плане проекта. Иным проектам (закупка скрепок) и план не нужен, иным (строительство коммунизма в отдельно взятой стране) и руководство по качеству с наворотами мало.
У нас на АЭС сначала гребли все под одну гребенку, под каждый чих писали программу качества. Профанация чистейшей воды. Я воевал тем, что, дескать, нигде не написано, что ПК должна быть больше 2-х листов и закрывался таблицами. Тем самым планом проекта.

б) Абижаеш. В 93-97 году был менеджером по качеству в проекте строительства хранилища отработавшего ядерного топлива по американской технологии. Свой хлеб отработал полностью. Американы пришли к нам, как к дикарям и первый год вели себя соответственно. Каково же было их удивление...

в) менеджер по качеству для каждого проекта не нужен, разве что проект гигантский. А аудитом обходить все проекты на предмет все ли там согласно как положено, очень даже стоит. Иначе зачем писать устав, структуру работ и т.п.? Лучшая совесть-контролер. В роли РП я всегда стараюсь найти, кто будет контролировать всякую фигню за меня.

Цитата:

---

Сообщение от Михаил_Шустер

Значит меня и Елиферова не существует

---

А ведь я мог бы закосить под Рубцова и в 5 минут доказать публике, что вас таки не существует. :)
Но не стану. Устал немного после 3х совещаний подряд. И вообще я уже дома, как ни странно.

Елиферову должно быть стыдно в меня номерами разделов ИСО кидаться, я их и в Ростелекоме выучить не мог для поддержания беседы на ихнем птичьем языке, а теперь-то уж ...
Отличие "ожиданий потребителя" от "требований потребителя" чисто философское. Что характерно, в наших проектах мы скорее сталкиваемся с "ожиданиями". Причем клиент оставляет за сбой право просто передумать ... Вам бы такого клиента - вы бы его полюбили до одержимости.

И посмотрел бы я на вас без специалиста по качеству на строительной площадке высокотехнологического объекта типа АЭС. Ну-ну.