?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

ГОСТ-овский стиль управления

Posted on 2010.08.22 at 17:32

Comments:


Кром
krom at 2011-03-22 11:41 (UTC) (Link)
Значит, первое, и главное. Единицей планирования в ГОСТ является ТЗ. Техническое задание. Вокруг предназначения и сути этого документа много непонимания. Многие путают его с Requirements Specification.

Так вот, это НЕ Requirement Specification. Начать можно с того, что правильно составленное ТЗ обычно гораздо короче, и в секции "технические требования" содержит в основном ключевые требования, определяющие успех всей рабоы. Почему? Потому, что эта секция - только одна из секций документа, который суть "Задание", а не требования.

Вторая главная секция - поэтапный план работ. Это простая таблица - последовательность этапов выполнения работы. В ГОСТ есть список стадий и этапов, но этот список носит рекомендательный характер. На практике - у вас есть полная свобода в определении количества этапов, их названий, и состава работ.


Ставить ГОСТ в заслугу наличие документа, смешивающего требования и план, мне кажется неоправданным. То, что ГОСТ предлагает для ТЗ, в любом случае, должно быть определено для управляемого проекта (ISO 9001, п. 7.3.1, 7.3.2).
На практике требования и планы (не календарные даже, а те, что в 7.3.1 описаны) живут отдельной жизнью, поэтому и управлять ими лучше по отдельности. Таким образом, ТЗ содержит только требования и вырождаются в RS, причем содержащие не только "технические" требования. Глубина же раскрытия таких требования в любом случая одинаковая: достаточная для начала проектирования системы целиком.
Gaperton
gaperton at 2011-03-22 14:33 (UTC) (Link)
> На практике требования и планы (не календарные даже, а те, что в 7.3.1 описаны) живут отдельной жизнью, поэтому и управлять ими лучше по отдельности.

Это не так. План по созданию чего-либо неразрывно связан с определением этого чего-либо. Связан по логике вещей, совершенно независимо от того, что написано в ISOXXXX. Поэтому, и управлять ими лучше вместе.

А вот когда эта связь "на практике" теряется, то становится уже совершенно неважно, называется это "управляемым проектом" по какому-то определению, или нет.

ГОСТ представляет собой отдельный подход, непохожий на "классику". У него свои свойства.

И вопрос очень простой - либо вы тратите усилия на то, чтобы разобраться, либо нет. Если нет - то всего доброго. Дискутировать мне не интересно, равно как и кого-то в чем-то убеждать.
Кром
krom at 2011-03-22 14:42 (UTC) (Link)
В том-то и суть, что ГОСТ "особым" подходом не является, он (как и многие другие подходы) прекрасно ложится на обобщенные подходы вроде ISO 9001 (который только логику вещей-то и описывает), но если уже кроме своего мнения ничего не интересует, конечно же, увидеть это вряд ли получится.
Всего доброго.
Gaperton
gaperton at 2011-03-22 21:28 (UTC) (Link)
Я в данной статье не "мнение" излагаю, а некоторую методику, построенную на ГОСТ. Которая вам, очевидно, не знакома.

А вот как раз _мнения_ людей, которые не поняли статью, и начинают мне по пересказывать то, что они где-то прочитали, или где-то учили - меня действительно не интересуют, Вы правы.

А с чего они меня интересовать-то должны? Вы время на понимание того, что я хотел сказать - потратили? С чего вы решили, что я должен тратить на вас свое? Все эти ISO и прочий балшыт я и так знаю.
Кром
krom at 2011-03-23 10:32 (UTC) (Link)
я вас отлично понимаю: пришел какой-то хрен и выражает несогласие. но не надо сразу ярлыки вешать. мне знакомы принципы управления, основанные на ГОСТ по практической деятельности (применяемые, например, в одной крупной организации-разработчике и -производителе медицинских аппаратно-программных комплексов, правда в отношении ПО мы руководствуемся больше IEC 62304). и, в том числе поэтому, я, в целом согласен с описаной методикой, но вижу и спорные тезисы.

например, предложение указывать в ТЗ только ключевые требования. загляните, к примеру в ОСТ 45.186-2001. там предлагается достаточно детально и всесторонне описывать требования, причем такие требования в частные ТЗ не попадут, потому что это требования к изделию в целом, а не на отдельные его узлы.

далее, программа и методика. вы пишете, что она "фиксирует требования в конструктивной форме". идея, в общем-то правильная: действительно для проверки требований в ПМ указываются, по сути, юзкейсы, но только требования ПМ устанавливать не должна. это противоречит определению из ГОСТ 16504 и требованиям ГОСТ Р 51672 (в котором, как раз ПМ очищена от того, что не работает на основную ее задачу - оценку соответствия).

ну а 9001 вы охаяли совсем зря. отличный документ, дающий "вид сверху" и способствующий пониманию практически любой методики, в т.ч. по ГОСТ (тот же ГОСТ Р 15.201 и вовсе напрямую на него ссылается). я пока знаю только одну причину критики этого стандарта: непонимание его сути.

p.s. что вы подразумеваете под "классикой"? я, например, как раз модель, описанную в ISO 9001 как наиболее общую.
Gaperton
gaperton at 2011-03-24 11:02 (UTC) (Link)
> я вас отлично понимаю: пришел какой-то хрен и выражает несогласие.

Нет, вы не понимаете. Возражайте на здоровье - но мне спорить на эту тему не интересно. Мне в ней все понятно, и поэтому тратить силы на спор я не хочу.

> например, предложение указывать в ТЗ только ключевые требования. загляните, к примеру в ОСТ 45.186-2001. там предлагается достаточно детально и всесторонне описывать требования, причем такие требования в частные ТЗ не попадут, потому что это требования к изделию в целом, а не на отдельные его узлы.

Во-первых, "всесторонне" это совсем не то же самое, что "детально". Уровень детальности стандартами не регулируется.

Во-вторых, есть стандарты, а есть практика их применения. Если заглянуть в форму ТЗ по ГОСТ-34, там тоже предлагается писать в ТЗ кучу мусора. Это вовсе не означает, что все перечисленное нужно там писать. И - что все перечисленное пишут в ТЗ на практике. Не пишут.

Любой человек, который проходил по ГОСТ несколько проектов, понимает, какой это геморрой - выпускать изменения к ТЗ, и быстро приучается не писать туда непринципиальных и излишне детальных вещей, закрывая детали в ПМИ.

И так как мне это совершенно ясно, я не имею никакого намерения обсуждать это в режиме спора. Оставайтесь при своем мнение на здоровье.

То же самое касается остальных замечаний.

> ну а 9001 вы охаяли совсем зря.

Я учавствовал в подготовке к сертификации к ISO 9001, и прекрасно знаю, что это такое. Оно имеет весьма опосредованное отношение к проектной деятельности. Проще сказать - никакого.

> p.s. что вы подразумеваете под "классикой"? я, например, как раз модель, описанную в ISO 9001 как наиболее общую.

PMI и хренову тучу совместимые с ним подходов, разделяющих те же принципы. Что должно быть очевидно, ибо разговор о проектном управлении. Не имею никакого желания всерьез обсуждать в этом контексте ISO 9001.
Gaperton
gaperton at 2011-03-24 11:04 (UTC) (Link)
> PMI

Ну, то есть творчество PMI, конечно же. PMBoK.
Previous Entry  Next Entry