Согласен.Цитата:
Сообщение от Михаил_Шустер
Вид для печати
Согласен.Цитата:
Сообщение от Михаил_Шустер
Потому в руководстве по качеству МАГАТЭ написана "Документация должна разрабатываться на языке пользователя". Имеется в виду не английский или русский, естественно. Хотя наши гаврики и тут доукраинизировались, зла не хватаетЦитата:
Сообщение от Andruxa
Я вот какую вещь обнаружил. Если взять любой документ толщиной страниц в 200, то окажется, что потребителем 180 из них является только создатель этого документа. А если разбить документ на "смысловые области" и "развести" их по цехам, большинству остается по 2-3 листика, а иным и вообще ничего.
Вот так бы их и писать...
Впрочем, технология уже создана и опробована :)
Ну вообщем и я в толстых регламентах не вижу смысла, скорее в одном на десять страниц и пяти одно-двух-страничных инструкциях - вот это дело, и семи-десяти одностраничных формах. Всё остальное никто не читает, а если и читает, то не запоминает, ну и т.д.
Исключение конечно же ПБУ и прочие законы. Но книжка Мишина всё равно не об этом :)
Вы спросили "прижился ли ООП в регламентации". Я, как мог, скользко ответил :)Цитата:
Сообщение от Andruxa
А книжка... Мне кажется, любая хорошая книжка - это возмущение стереотипов. Они там в голове отстраиваются в свою какую-то смесь, не образуя иерархической структуры.
Любое изложение чего-либо, это в первую очередь попытка упорядочить, структурировать, соблюсти иерархию. А мозг, похоже, устроен иначе. В этом, возможно, ключ ко всеобщему непониманию друг друга.
ага, понял. но книжка новая, может ещё приживётся.... :)Цитата:
Сообщение от Михаил_Шустер
так иерархия как раз попытка понять :/ вон биологи до сих пор на Линнея молятся, а химики - на Менделеева и Паули. Может, Мишин - Менделеев российского проектного бизнеса (нет, не устану пеарить, книга понравилась :) хорошо, понятно написана, с хорошими примерами).Цитата:
А книжка... Мне кажется, любая хорошая книжка - это возмущение стереотипов. Они там в голове отстраиваются в свою какую-то смесь, не образуя иерархической структуры.
Любое изложение чего-либо, это в первую очередь попытка упорядочить, структурировать, соблюсти иерархию. А мозг, похоже, устроен иначе. В этом, возможно, ключ ко всеобщему непониманию друг друга.
Как было бы здорово, если бы многотомные регламенты писались на принципах карт памяти...
Вы не одиноки, Михаил!Цитата:
Сообщение от Тишкин Михаил
Мне (директору по качеству с 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 под таким углом дела не рассматривает. Полистаю его, третий, отпишу ещё...
Регламенты на принципах карт памяти... интересно :) Их писать приятно, а чужие читать ничуть не проще. К тому же, стандартное оглавление любой книги и есть простейшая карта памяти, разве что не картинкой.
Это "сегодня" уже "вчера". Нынче в моде ISO 9000:2008.Цитата:
Сообщение от eliferov
С юбкой-клеш и отрезным воротом по манишке. :)
Что вы так зациклились на управлении качеством? Я же его привел как самый простой пример недотепистости PMBOK. Вот если бы я вам тут начал рассказывать о попытках построения управления бюджетом проекта на базе этого ни в чем не повинного стандарта - тогда вы бы обрыдались ... как я немного ранее.
Ну не надо, не надо :):):)Цитата:
...о попытках построения управления бюджетом проекта...
Эту задачу решили два года назад :)
Сейчас коллега на конференциях выступает.
Ну я типа тоже иногда на конференциях выступаю ... одно другому не мешает.Цитата:
Сообщение от Равиль
Александр, вживаетесь :) ?Цитата:
Сообщение от Александр Болдин
А у меня командировки в январе не будет... Только в марте
Так что давайте лучше Вы к нам :) Причем в полном составе :)
В полном составе не получится (если я подумал о том о чем вы подумали). А вот сам-то приеду - куда деваться? С заграницами не получается, а в Москве за 2 недели со скуки можно будет окочуриться.Цитата:
Сообщение от Елена И.
Болдин писал:
Отличия от 2000 - редакционные. Сути не меняют.Цитата:
Это "сегодня" уже "вчера". Нынче в моде ISO 9000:2008.
С уважением Виталий.
http://com.sibpress.ru/07.11.2008/strategies/90355/Цитата:
Сообщение от Александр Болдин
Прошу учесть, что в жизни мы лучше, чем на фотографии :)Цитата:
Сообщение от Andrey-Chechako
А зачем тогда ресертификация? Чтобы денег срубить в легкую?Цитата:
Сообщение от eliferov
Кстати, насчет чисто редакционных правок - я бы так не сказал.
Виталий, хоть мой стаж на 5 лет меньше твоего, открою секрет :)Цитата:
Сообщение от eliferov
План проекта - это и есть план качества.
Процесс - это фрагмент проекта
Сеть процессов - система качества
Управление качеством в проекте - это работа, направленная на то, чтобы четко определить кто и что должен сделать. Вопрос "когда" - это уже "чистый" вопрос планирования.
Успех проекта определяется тремя составляющими:
-качеством определения структуры работ и их детализации
-личными качествами участников
-талантом планировщика
Первая версия РМВОК "технологическая", последняя-"человеческая". Та же эволюция, что и у стандартов ИСО. Первая годится для любой организации, вторая требует определенной зрелоcти. И написаны для разного уровня пользователей, которых у последней версии практически нет.
РМВОК пошла по граблям...
этот разговор... уж сколько копий сломано...
Но мы неизбежно приблежаемся к венцу эволюции:
рюмочке коньяку с долькой лимона))
Болдин писал:
Цитата:
Кстати, насчет чисто редакционных правок - я бы так не сказал.
Замена в п. 4.1Цитата:
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
"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
Вот мне никак не понять что-то, как можно унаследовать от объекта "Внекорпоративные знания" объект "Родительская организация".
Как правило, в наследовании используется отношение "это".
То есть "Родительская организация" - это "Внекорпоративные знания" (их специализированный подвид).
Соответственно, должны наследоваться свойства и методы. Особенно, если "Внекорпоративные знания" класс абстрактный.
Хотя подход с ООП может быть полезен как декомпозиция задачи на подзадачи, объекта на подобъекты (как Михаил писал насчёт регламентов).
Хотя с этим и структурное программирование справляется.
Да и не наследование это опять же, а сцепление объектов (отношение типа "машина" - "колёса", "корпус", "мотор" и т.д.).
Другое дело, что для подкованных в ООП людей модель резко упрощается.
Но для неподкованных столь же резко усложняется.
...на время. А потом так же резко усложняется. Правда, на другом уровне :)Цитата:
Сообщение от knagaev
Скучно с тобой, Виталий, и поспорить не о чем :)Цитата:
Сообщение от eliferov
Я знал, что ты знал. Даже в книгах твоих встречаю не только понятия, но и выражения, которыми сам давно пользуюсь. Естественно, ни о каких заимствованиях не может быть речи. Путь одинаковый, хотя и разный
Так выпьем же за Дао, хотя да, разгар рабочего дня... Тогда пообедаем
Всё наследуется, я проверял глазками. Возможно, я в названиях на память накосячил, приду домой проверюЦитата:
Сообщение от knagaev
В том-то и дело, что не сцепление. А подход к регламентированию "От общего к частному" (или "От частного к общему").Цитата:
Хотя подход с ООП может быть полезен как декомпозиция задачи на подзадачи, объекта на подобъекты (как Михаил писал насчёт регламентов).
Хотя с этим и структурное программирование справляется.
Да и не наследование это опять же, а сцепление объектов (отношение типа "машина" - "колёса", "корпус", "мотор" и т.д.).
Шустер писал:
Дык, ведь. . . Спор - это не единственное лекарство от скуки. Загляни на http://quality.eup.ru/Technology/Scr...ic.php?p=58225Цитата:
Скучно с тобой, Виталий, и поспорить не о чем :)
Там мой бывший коллега развлекается (Болдин его тоже хорошо знает). Просит сформулировать определение "выхода процесса".
С уважением Виталий.
P.S. Пиво, тоже неплохое лекарство от скуки. Давно ты в Москве не был.
Работа, направленная на то, чтобы четко определить кто и что должен сделать - в PMBoK это процессы "Управления содержанием" (что для исполнителей), "Управления интеграцией" (что для руководителей) и "Управлением сроками" (кто это что делает)Цитата:
Сообщение от Михаил_Шустер
Так все-таки, что же тогда включает PMBoK в процессы "Управления качеством"? :)
Да плюньте и разотрите, какая разница? Джаст ду ит :)Цитата:
Сообщение от Тишкин Михаил
Мое подозрение такое. Разработка РМВОК шла на принципах управления проектами. Была определена СРР и распределена между участниками (гляньте список, с ума сойти). Потом объекты СРР начали конфликтовать, РП стал штопать дубли и нестыковки. Сложность задачи управления знаниями превысила реализуемость и вышло что вышло
В управление качеством искусственно вынесены некоторые детали, которые могли находиться в каком угодно разделе. Простые люди для таких вещей создают раздел "Разное", куда и прячутся все недостатки классификации (спецы по ООП меня поймут :)).
Вообще, РМВОК настолько хорошо структурировано, что аж тошно. Перестарались.
А структура ИСО чудовищна, хотя там принят совсем другой базис классификации.