?

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:


george8128 at 2010-08-24 08:40 (UTC) (Link)
Вы меня поразили в своей любви к ГОСТу. Не ожидал.

Кроме 19 и 34 я много работал с 2 (ЕСКД - с которого всё начиналось), 3 (ЕСТД), 21 (СПДС). У меня впечатления ровно противоположные.

Вы говорите об использовании ГОСТов без формализма и то, что нет руководств по использованию на практике.

Но ГОСТ - это на 99% - описание того, как ОФОРМЛЯТЬ, а не как делать (в отличие от большинства западных методик) - например, 19.201-78 первые три пункта - как оформлять. 19.101, 103, 104, 105, 106, 40Х, 50Х, 60Х - это всё - оформление. Большая часть 201 и 202 - тоже оформление.

Как делать - приходиться догадываться по намекам и полунамекам, разбросанным по всему тексту. И отсутствие руководств - это скорее всего "так и задумано". Скажу даже больше - основная практика по применению ГОСТов - это прикрыть свою задницу документами, оформленными по ГОСТ. Например, ЕСТД (3-й) вообще на реальном производстве не нужен, как показывает практика. И без ЕСКД обходятся вполне. везде используют СПДС - но эта система стандартов наиболее свободная (т.е. наименее проработанная) из всех - это спасает.

Фактически Вы описываете некую методу, которую используют некоторое число специалистов, которая не формализована, но которую эти специалисты научились транслировать в термины ГОСТа.

Вы пишете: "Это не "требования". Это - задание." Слово "задание" в русском языке давно - почему создатели ГОСТа (люди безусловно образованные и очень трепетно относящиеся к употребляемым терминам) использовали не "задание", а "требование"? Что бы всех запутать? Думаю, они имели в виду именно требования.

Вы пишете: "список стадий и этапов ... носит рекомендательный характер". Так состав разделов ТЗ по 19 - тоже только рекомендация - см. п. 1.4 последний абзац. 34 - тем более - п. 2.2 позволяет сделать любой документ под названием "ТЗ".

"ГОСТ очень легко использовать неправильно" - если даже существует правильное использование ГОСТа, то всё-равно это не достоинство ГОСТа, что его легко неправильно использовать. И т.д.

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

Всё это приводит при применении ГОСТа к ориентации именно на процесс, а не на результат.

Самый ценный документ - это ПМИ. Но тоже многие забывают, что не нужно в ПМИ выносить пункты типа "проверка работоспособности клавиатуры". Да и один документ всю систему не спасет.

Более-менее успешно применяется ГОСТ при разработке аппаратно-программных систем. Хотя тоже есть разные мнения.

Если говорить только о ИТ - дополнительная бумага по ГОСТу чаще всего сильно мешает, особенно на стадии реализации и при внесении изменений. Вы же сами об этом писали в "Пиши код" и "Читай код"! Вы передумали? Или предлагаете выкинуть 90% текста ГОСТа, а оставшиеся 10% использовать по своему? Как то я Вас не могу понять, к сожалению...
Gaperton
gaperton at 2010-08-24 17:28 (UTC) (Link)
Отвечу по существу.

Начну с того, что...
> Вы меня поразили в своей любви к ГОСТу. Не ожидал.
...у меня, в общем, нет ни малейшей цели оправдывать чьи-либо ожидания. Я пишу то, что считаю интересным, о том, что считаю нужным.

> Вы говорите об использовании ГОСТов без формализма и то, что нет руководств по использованию на практике.

Я говорю о принципе, стоящем за организацией работ по ГОСТ.

> Но ГОСТ - это на 99% - описание того, как ОФОРМЛЯТЬ, а не как делать

Если быть точным - ГОСТ - это протокол взаимодействия заказчик-исполнитель. Он определяет не "как оформлять", а порядок проведения работ, который будет наблюдаем на стыке "заказчик-исполнитель".

> Фактически Вы описываете некую методу, которую используют некоторое число специалистов, которая не формализована, но которую эти специалисты научились транслировать в термины ГОСТа.

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

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

> Вы пишете: "Это не "требования". Это - задание." Слово "задание" в русском языке давно - почему создатели ГОСТа (люди безусловно образованные и очень трепетно относящиеся к употребляемым терминам) использовали не "задание", а "требование"? Что бы всех запутать? Думаю, они имели в виду именно требования.

ТЗ означает Техническое ЗАДАНИЕ. Я пишу: ЗАДАНИЕ.

Где там создатели ГОСТ слово "требование" использовали? В одной из секций ТЗ, под названием "технические требования".

И что дальше-то? :) Вы этот абзац к чему написали вообще? Поясните, не понимаю.

> Вы пишете: "список стадий и этапов ... носит рекомендательный характер". Так состав разделов ТЗ по 19 - тоже только рекомендация - см. п. 1.4 последний абзац. 34 - тем более - п. 2.2 позволяет сделать любой документ под названием "ТЗ".

Да, я пишу. Да, состав пунктов ТЗ также носит рекомендательный характер.

Эти оговорки внизу означают не более, чем "парни, вот вам шаблон, но вы и мозг тоже включайте, смотрите по ситуации".

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

> "ГОСТ очень легко использовать неправильно" - если даже существует правильное использование ГОСТа, то всё-равно это не достоинство ГОСТа, что его легко неправильно использовать. И т.д.

Разумеется, существует его правильное использование, без каких-либо "если даже".

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

Я не понял - что означает "и т.д." в конце? :)

> Еще одно неизбежное зло - когда работаешь с клиентом, настаивающем на выполнение ГОСТа до последнего знака препинания - а текст ГОСТов составлен так, что "юридически" переубедить его невозможно.

Никаких проблем в этом не вижу, и никакого "зла". ГОСТ - УДОБЕН при заказной разработке. Гораздо лучше всевозможных велосипедов, и при этом очень гибок. Готовить его надо уметь, только и делов.

> Есть отдельная порода людей, которые заучивают ГОСТы наизусть и кроме них ничего не знают.

Trust me, мне нет никакого дела до такой породы людей.

> Всё это приводит при применении ГОСТа к ориентации именно на процесс, а не на результат.

ГОСТ
1) Не содержит никаких средств контроля активностей на этапах.
2) Не накладывает никаких ограничений на процесс разработки.

Он ортогонален применяемому процессу.

А уж то, что находятся дураки, которые относятся к нему формально - так это не его вина. Дай этим дуракам в руки RUP - будет еще хуже.

> Самый ценный документ - это ПМИ.

Угу. А еще ТЗ вы забыли.

> Но тоже многие забывают, что не нужно в ПМИ выносить пункты типа "проверка работоспособности клавиатуры". Да и один документ всю систему не спасет.

Ценный совет. :) Я не буду расширять список того, что не нужно включать в ПМИ (бестолковое это занятие - шибко много туда включать не нужно, и каждого дурака не предусмотришь), а просто добавлю, что документы вообще систему не спасают. Ни один, ни два, ни три. Хоть десять.

Gaperton
gaperton at 2010-08-24 17:31 (UTC) (Link)
> Более-менее успешно применяется ГОСТ при разработке аппаратно-программных систем. Хотя тоже есть разные мнения.

Более-менее успешно ГОСТ применяется теми, кто понимает его внутреннюю логику, и умеет его готовить. И отрасль тут абсолютно не причем - протокол отношений "заказчик-исполнитель", который только и регламентируется ГОСТ, от отрасли зависит слабо.

А теми, кто не умеет, и не понимает - ГОСТ, очевидно, успешно применен быть не может. Ничего странного в этом я не вижу.

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

> Если говорить только о ИТ - дополнительная бумага по ГОСТу чаще всего сильно мешает, особенно на стадии реализации и при внесении изменений.

Мне почему-то ТЗ, составленное по описанным принципам, не мешает, а помогает. Оно вообще-то приложением к договору является, на минуточку. Это не "дополнительная", а необходимая бумага.

> Вы же сами об этом писали в "Пиши код" и "Читай код"! Вы передумали?

Нет, я в этих статьях писал не об этом. :) Я писал о документации к КОДУ. Разницу чувствуете? Разумеется, я не передумал.

> Или предлагаете выкинуть 90% текста ГОСТа, а оставшиеся 10% использовать по своему?

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

Но вы ведь видете в тексте не то, что написано, а то, что вам хочется видеть, правда? :) То же самое произошло со статьей "Читай код". 90% вообще не смогло прочитать, что в ней написано. :) Что смешно и символично.

> Как то я Вас не могу понять, к сожалению...

Это бывает, ничего страшного в этом нет. Вы - не можете, другие могут. Велика ли беда?
george8128 at 2010-08-25 08:46 (UTC) (Link)
Спасибо за ответ по существу. Сори за излишнюю эмоциональность.

Согласен, прочитал немного невнимательно - вариант с Redmine сразу не заценил. Просто "ГОСТ" у меня ассоциируется только с толстой пачкой бумаги. И это не исключение, это правило - всё ВПК, весь космос.

Просто мне кажется, нужно предупреждать - если в требованию к сотрудничеству (например, в условиях тендера) стоит "оформление документации по ГОСТу" - это чаще всего означает ориентацию на бумагомарательство, а не на результат. Это бросается в глаза всякому, кто долго работал с ГОСТом.

По мелочи:
> Он определяет не "как оформлять", а порядок проведения работ, который будет наблюдаем на стыке "заказчик-исполнитель".

ГОСТ 19.001-77
"1.1. Единая система программной документации - комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления (!!!) и обращения программ и программной документации."
Оформление на 2-м месте, но, как я написал выше, обычно его ставят на 1-е. В западных стандартах оформление обычно вообще не фиксируется - только общие принципы. Это еще один минус ГОСТу - что вообще оформление упоминается.

Вообще с ТЗ как инструментом взаимодействия тоже постоянно траблы возникают - в силу обычной программисткой проблемы "последние 10% занимают 90% времени" важно даже не определить требования (тоже важно, но), а постоянно контролировать результат - привет скраму.

Если говорить о 34-м ГОСТе и его применение в чисто программных (корпоративных) системах - то он вообще не нужен - в абсолютном большинстве случаев в начале проекта ничего кроме целей, задач и бюджета не известно. А документ состояций только из целей и задач - это скорее концепция по PMI, а не ТЗ.

> ТЗ означает Техническое ЗАДАНИЕ. Я пишу: ЗАДАНИЕ.
> Где там создатели ГОСТ слово "требование" использовали? В одной из секций ТЗ, под названием "технические требования".
> И что дальше-то? :)

В 19-м и особенно в 34-м ГОСТе это самая деталлизированный раздел. Поэтому традиционно считается основным. Хотя в статье Вы эту тему раскрыли. Часто как элемент давления на исполнителя заказчик требует описание ВСЕХ подразделов в разделе требования, даже таких специфичных как "требования к патентной чистоте", например.

> Оно вообще-то приложением к договору является, на минуточку. Это не "дополнительная", а необходимая бумага.

Можно написать бумагу на 2 страницы (ели + задачи) на назвать ТЗ. Зачем ГОСТ нужно упоминать? У нас сейчас, например, сама собой выработалась практика с определенными заказчиками не использовать названия документов по ГОСТу - что бы разные "контролирующие" товарищи со стороны клиента не могли прикопаться.

> Нет, я в этих статьях писал не об этом. :) Я писал о документации к КОДУ. Разницу чувствуете?

ГОСТ 19.401 и 402 регламентирует правила оформления кода, а ГОСТы 404, 503 и 504 - требования к документации :(

Но всё это - мелочи. Главное - еще раз повторю - соглашаясь на "работу по ГОСТу", велик риск влипнуть в бумагомарательство. Это не 100% риск, о очень большой. Как не влипнуть - техника не менее сложная, чем правильное применение ГОСТа.
Gaperton
gaperton at 2010-08-25 11:58 (UTC) (Link)
> Вообще с ТЗ как инструментом взаимодействия тоже постоянно траблы возникают - в силу обычной программисткой проблемы "последние 10% занимают 90% времени" важно даже не определить требования (тоже важно, но), а постоянно контролировать результат - привет скраму.

Описанные проблемы возникают не с ТЗ, а с отсутствием управления приоритетами.

И ГОСТ никак не противоречит скраму. Итерация = этап, и все. ГОСТ вообще не накладывает ограничений на процесс разработки внутри.

> Если говорить о 34-м ГОСТе и его применение в чисто программных (корпоративных) системах - то он вообще не нужен - в абсолютном большинстве случаев в начале проекта ничего кроме целей, задач и бюджета не известно.

Принципы, о которых я рассказываю - соблюдаются и в 34-м. Они вообще едины для всех ГОСТ.

Принципы - интересны. Конкретные ГОСТ - нет.

Из конкретных, я, кстати, предпочитаю 19-й. За простоту и чистоту.

> А документ состояций только из целей и задач - это скорее концепция по PMI, а не ТЗ.

А ТЗ состоит не только из целей и задач. :) Еще - там поэтапный план работ, и (ключевые) технические требования. Все это важно. И еще кое-что.

>>> Где там создатели ГОСТ слово "требование" использовали? В одной из секций ТЗ, под названием "технические требования".
>> И что дальше-то? :)

> В 19-м и особенно в 34-м ГОСТе это самая деталлизированный раздел. Поэтому традиционно считается основным. Хотя в статье Вы эту тему раскрыли.

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

Я же вам говорю, что так неправильно, что ТЗ не эквивалент requirement spec. На практике разумные люди предпочитают не делать это сильно детализированным разделом, фиксируя только ключевые требования. Хотя бы потому, что ТЗ приложение к договору, и выпуск допсоглашения к ТЗ - гемор. А выписывать при таком подходе придется, ибо детальные требования на момент подписания договора неизвестны почти всегда, и представление о них будет меняться.

> Можно написать бумагу на 2 страницы (ели + задачи) на назвать ТЗ. Зачем ГОСТ нужно упоминать?

Я в своей работе и не упоминаю, если этого специально не требуется. Но и от упоминания проблем никаких нет.

Перечитайте статью еще раз. Я пишу в ней не о том, какую бумагу можно назвать ТЗ, и не о том, из каких бумажек состоит ГОСТ, а о принципе организации и планирования работ, стоящим за ГОСТ.

>> Нет, я в этих статьях писал не об этом. :) Я писал о документации к КОДУ. Разницу чувствуете?

> ГОСТ 19.401 и 402 регламентирует правила оформления кода, а ГОСТы 404, 503 и 504 - требования к документации :(

Ага. А я, еще раз, рассказываю не про оформление документации, а про принцип планирования и организации работ, стоящий за ГОСТ. :) Хороший принцип, просто замечательный. Разница - понятна?

> Но всё это - мелочи. Главное - еще раз повторю - соглашаясь на "работу по ГОСТу", велик риск влипнуть в бумагомарательство. Это не 100% риск, о очень большой. Как не влипнуть - техника не менее сложная, чем правильное применение ГОСТа.

А вот здесь соглашусь. Чистая правда.

Как не влипнуть - это часть техники правильного применения ГОСТ-а, приходит с опытом :). Там большинство страшных документов опционально (посмотрите матрицу). А код - передается на электронных носителях, это допускается.

И тем не менее, от работы по ГОСТ есть и плюсы как заказчику, так и исполнителю. При правильном применении он защищает интересы обоих. Если его взять за основу, и кастомизировать.
george8128 at 2010-08-25 13:04 (UTC) (Link)
>Описанные проблемы возникают не с ТЗ, а с отсутствием управления приоритетами.

Согласен. Но:

> И ГОСТ никак не противоречит скраму. Итерация = этап, и все. ГОСТ вообще не накладывает ограничений на процесс разработки внутри.

ГОСТ 19.102 накладывает достаточно жесткие ограничения: как минимум, даже с учетом 1-го примечания, сначала разработка (рабочий проект) всего-всего, и только потом - внедрение у клиента. Явно противоречит agile-методикам. итеративности выше стадий не предусмотрено.


С остальным не могу не согласиться. Да, ПГР нужен. Ключевые ТТ - тоже. Порядок (общий) сдачи-приемки нужен.
Gaperton
gaperton at 2010-08-25 13:41 (UTC) (Link)
> ГОСТ 19.102 накладывает достаточно жесткие ограничения: как минимум, даже с учетом 1-го примечания, сначала разработка (рабочий проект) всего-всего, и только потом - внедрение у клиента. Явно противоречит agile-методикам. итеративности выше стадий не предусмотрено.

Да, формально это так. Так написано в стандарте.

На практике же все гибче. То есть:

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

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

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

При этом - обратите внимание, - "эскизный проект" и прочие - это _стадия_, внутри которой могут быть _этапы_. А что у нас ГОСТ говорит об этапах?

2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

Бинго. Обитерируйся. :) С учетом первого пункта - вообще красота. Короче, ГОСТ очень гибок. :)

Вот и все. Все что делает ГОСТ - устанавливает общую терминологию в названиях стадий. Это удобно.

На практике, если того требует ситуация, и никто не фанатично не следит за буквой, допустимо вообще класть на названия стадий, и делать так, как надо. Я специально консультировался у "гуру" на эту тему - это нормальная практика, если заказчик не государственный. Проходит вполне нормально.
Евгений
sandu at 2012-03-05 10:23 (UTC) (Link)
Вы несколько раз упомянули, что на каждый этап можно делать отдельное ТЗ. А помимо этого, видимо, и остальные сопутствующие документы? Какое итоговое количество документов вы можете получить (реально получали на практике) и кто в них будет разбираться? Что важнее — кто их будет использовать? Раз ТЗ — это документ, регламентирующий отношения, то, значит, к нему надо аппеллировать разным людям — а для этого надо знать его. И что если вследствие десятка этапов получился десяток ТЗ?

Подозреваю, что пример с Redmine был неспроста. Думаю, ГОСТ-методику работы можно использовать в случае внедрения системы управления требованиями, формируя ТЗ по мере необходимости. Вы, видимо, именно таким вариантом предпочитаете пользоваться?
Gaperton
gaperton at 2012-03-12 14:24 (UTC) (Link)
Необходимым минимумом является наличие двух документов - ТЗ и "Программы и методики испытаний". Они предствляют собой формальный или неформальный "контракт" между заказчиком и исполнителем, и являются руководящими документами при выполнении работ. Их составляют и читают технические специалисты. Для мелких проектов - это обычные программисты, для крупных - руководители. В советской конструкторской школе руководитель является в первую очередь инженером ("архитектором"), это надо учитывать.

ТЗ касается границ проекта (технические требования) и промежуточных контрольных точек (этапы). ТЗ - это короткий документ, несколько страниц.

"Методика испытаний" - описывает подход к приемочному тестированию. Также короткий документ - несколько страниц.

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

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

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

Совсем не обязательно ЧТЗ должны впрямую соответствовать этапам - так на практике бывает редко, хотя и возможно.

Ничего страшного в том, что получится 10 ЧТЗ, нет. Особенно, если ЧТЗ будет представлять собой задачу в трекере.

В случае ЧТЗ "заказчиком" является руководитель (который также инженер), ответственный за подразбиение работ на определенном уровне.

В сумме, это совсем не много "документов". И, возможно, полное их отсутствие, при грамотном использовании трекера задач + вики.
Евгений
sandu at 2012-04-16 07:17 (UTC) (Link)
Ухх! Гениально! Жаль только, крайне трудно этот подход пробовать, находясь в госконторе :) Увы, в моем случае это обязательно будут документы, и десятки документов. Но основную идею я понял и попробую применить! Афтар пешы ищо! ©
Gaperton
gaperton at 2010-08-25 13:44 (UTC) (Link)
Короче, все дело в отношении к ГОСТ.

Если относиться к нему как к инструменту - он становится гибок, и полезен. Ибо он таки, не смотря на страшный вид, аккумулирует большой опыт отношений заказчик-исполнитель.

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

А вот если относится к нему как к ограничениям - то он будет тупо путаться под ногами и мешать.
george8128 at 2010-08-25 15:20 (UTC) (Link)
С этом полностью согласен.

Спасибо за пояснения к статье. Подход действительно интересный.
Previous Entry  Next Entry