?

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
Tags: , , , , , ,
Многим, кто работал по ГОСТ-19 или 34, или по другим ГОСТ вариациям ЕСКД, этот стиль хорошо знаком. Он значительно отличается от западной "классики", хоть и сам является не меньшей классикой.

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

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

И вот тогда, когда вы не только выставляете "внешний интерфейс" в виде ГОСТ-19, но и сами выдаете задания по его правилам - становится понятна вся его сила и весь смысл.

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

Значит, первое, и главное. Единицей планирования в ГОСТ является ТЗ. Техническое задание. Вокруг предназначения и сути этого документа много непонимания. Многие путают его с Requirements Specification.

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

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

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

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

Итак, что такое ТЗ? ТЗ, это комбинация ключевых требований, определяющих успех работ, и поэтапного плана данных работ. ТЗ - это единица планирования. Это не "требования". Это - задание.

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

Ближайшим аналогом ТЗ является Project Charter, если угодно.

А еще в ТЗ есть очень короткая секция, в самом начале, с которой у большинства есть огромные проблемы. Но - в которой состоит весь дзен ТЗ. Называется "Цели и задачи работы". :)

В чем состоят проблемы? В неумении людей отличать цели от задач. Типичное содержимое - "целью работы является разработка системы Х. Задачами работы, э-э-э... Чорт! Что здесь писать? являются проектирование, кодирование, и отладка системы Х".

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

"Задача - достать денег в партийную кассу, предотвратив тем самым закрытие типографии" - таковы цели и задачи Грина в одном из эпизодов "Статского Советника" Акунина.

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

Типографию надо оплатить в течении трех дней. Более того - ради такой цели можно рискнуть очень многим, она высокоприоритетна. И - нужна вполне конкретная сумма.

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

И в конце концов - раз у вас затруднение с формулировкой цели работ, и она дублирует задачи - может быть, работу вообще не стоит выдавать? Ну, раз выдающий задание не в состоянии внятно объяснить, зачем нужен результат работ? То, может, и работа не нужна?

Ок, переходим на конкретику. Задача работы - получить работоспособную реализацию аудиокодека Dolby Digital. А вот с какой целью? Проще выражаясь - зачем он нам нужен, ради чего вообще эта работа затеяна, для решения какой проблемы? Плевать, что вам это очевидно - это необходимо довести до исполнителей.

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

Если же с целью использования в конечном продукте - тут уже совершенно другое дело. Абсолютно другие требования к качеству, и GPL лицензия не подойдет.

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

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

Теперь два фокуса.
1) Вас могут не устраивать фиксированные даты окончания этапов. Пишете в соответствующей графе: "в соответствии с ведомостью исполнения". И все ок.
2) Вас может волновать отсутствие детально расписанных требований в документе ТЗ. Волноваться не надо - у вас есть "программа и методика испытаний".

Этот документ - именно, что программа (то есть, тест-план), и методика (общие принципы построения тест-плана и организации тестирования). Этот документ - фиксирует требования в конструктивной форме. Хреначте в него свои юз-кейсы и юзер-стори. И включайте наличие первой версии этого документа в результат первого этапа.

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

Вкратце - все. Но к самому интересному моменту мы только подошли. Вы видите - ТЗ это очень укрупненный план. Вот у вас есть ТЗ на весь проект. Что же делать дальше? Составлять WBS? Рисовать задачи?

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

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

То есть, в отличии от классики, ГОСТ:
1) Объединяет планирование и управление требованиями в единую технику.
2) Явно фокусируется на результате работ, а не на процессах и активностях.
3) Опирается на одну и ту же технику при управлении программой и проектом. Он предполагает, что вы вместо выдачи "заданий", будете дробить крупные "проекты" на "подпроекты", концентрируясь на результатах каждой задачи и этапа.
4) Не предполагает отдельной роли "менеджера". Все, кто завязан в процесс - в той или иной степени инженеры. Задание-то "техническое", как ни крути.
5) Совместим со стилем управления Auftragstaktik, про который я много писал.

Когда вы понимаете принцип, стоящий за ГОСТ (а ГОСТ были изначально разработаны для управления большими программами, вроде разработки комплексов ПВО), все становится очень просто и симпатично.

Настолько - что вы можете даже не писать документов-ТЗ. Честно. Смотрите: Берете Redmine.
1) Иерархия ТЗ - это иерархия проектов и подпроектов.
2) Этапы - это "версии" для каждого проекта.
3) Технические требования - можете в вики писать, а можете задавать тикетами. Это уж как душе угодно.

Вот вам и все управление. Просто, симпатично, и, самое главное - отлично работает.

Я даже скажу так. Это - одна из немногих техник, которая _действительно_ работает на практике.

Comments:


Page 1 of 2
<<[1] [2] >>
Alexey Fyodorov
23derevo at 2010-08-22 14:02 (UTC) (Link)
очень интересно, спс!
Anton Kazennikov
kzn at 2010-08-22 14:56 (UTC) (Link)
Спасибо, очень интересно.

Нас в институте заставляли писать ТЗ на курсовые и диплом. Тогда было не понятно, зачем это надо, и я считал это пустой тратой времени. С таким пояснением сразу стало понятно и все стало на места.
zibsun
zibsun at 2010-08-22 15:00 (UTC) (Link)
Спасибо, очень круто разъяснил. Любой подход можно испортить неправильным исполнением.
Gaperton
gaperton at 2010-08-22 15:17 (UTC) (Link)
Беда в том, что толковых руководств по практике применения ГОСТ-ов нет. По крайней мере - мне не попадались. Это знание - как дзен, передающееся от человека к человеку.

Так что - ЕСПД очень легко использовать неправильно.

В искусстве ТЗ есть, кстати, еще одна важная тонкость. Которую вообще никто не втыкает :).

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

Надо добавить про цели и задачи. Это важно.
(Deleted comment)
(Deleted comment)
Виктор Агроскин
vvagr at 2010-08-22 17:13 (UTC) (Link)
Всё-таки классический и гостовский методы имеют свои условия применимости, без характеризации которых это всё не очень достоверно. Гостовские методы в некотором смысле перестали работать при переходе к специализированным горизонтально-интегрированным командам, когда перестало быть понятным - кто кому уполномочен ставить такие ТЗ. Коллаборация с общим репозиторием требований, общей моделью, общим issue tracker - не ложатся в эту рамку. Разработка железок в старых российских кб по госзаказу - и то переживает кризис проектного управления по этой причине.
Gaperton
gaperton at 2010-08-22 17:30 (UTC) (Link)
> Всё-таки классический и гостовский методы имеют свои условия применимости, без характеризации которых это всё не очень достоверно.

С чего вдруг? Подход можно описать достаточно достоверно. Что я и сделал. А уж выводы о применимости каждый делает сам.

> Гостовские методы в некотором смысле перестали работать при переходе к специализированным горизонтально-интегрированным командам,

Что? :) Ничего не понял.
1) "специализированным горизонтально-интегрированным командам" - уточните пожалуйста, что конкретно вы под этим имеете в виду.
2) "в некотором смысле перестали работать" - поясните, в каком именно смысле перестали работать.

> когда перестало быть понятным - кто кому уполномочен ставить такие ТЗ.

Это когда, где, и кому у нас перестало быть понятным, кто кому уполномочен задания ставить? :)

> Коллаборация с общим репозиторием требований, общей моделью, общим issue tracker - не ложатся в эту рамку.

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

> Разработка железок в старых российских кб по госзаказу - и то переживает кризис проектного управления по этой причине.

Что-то я в НТЦ "Модуль" не заметил никакого "кризиса проектного управления по этой причине" :). А там все делается по данной системе - вплоть до выдачи заданий отдельным сотрудникам.

Да я, признаться, вообще с трудом представляю себе "кризис проектного управления". Это что такое? :)
DVoRNick
dvornickus at 2010-08-22 18:12 (UTC) (Link)
Спасибо, все стало гораздо понятнее.
Всем бы студентом вместо/перед чтения ГОСТ-19 давать читать эту статью :)
NaN
guamoka at 2010-08-22 20:28 (UTC) (Link)
GTD-GTD-GTD. Первые главы. Ничего нового или прорывного. Просто сам-ап уже давно известного. Дзен how tackle a problem.
Gaperton
gaperton at 2010-08-22 21:45 (UTC) (Link)
В GTD-то? Ну да. Ни нового, ни прорывного. Пустышка.

Вы ведь не про ЕСПД, который введен постановлением комитета стандартов совета министров СССР от 20 мая 1977 года, правда? :)
artsg
artsg at 2010-08-23 09:44 (UTC) (Link)
> Вот у вас есть ТЗ на весь проект. Что же делать дальше? Составлять WBS? Рисовать задачи? Черта с два. Единственная "задача" - это ТЗ. Правильный ответ - выделять частные, более мелкие ТЗ, на более мелкие работы. И так - до самого мелкого уровня.ыделять частные, более мелкие ТЗ, на более мелкие работы. И так - до самого мелкого уровня.

Получается структура плана, похожая на карту работы у Голдратта (strategy and tactic tree), http://praxos.ru/index.php/Карта_действий_и_результатов
Gaperton
gaperton at 2010-08-23 11:58 (UTC) (Link)
Действительно похоже.

Голдрадт, однако, на мой взгляд, чуть более академичен, чем следует.

Прога интересна по ссылке, надо глянуть.
http://flyinglogic.com/
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 - будет еще хуже.

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

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

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

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

ndochp at 2010-08-25 20:44 (UTC) (Link)
В чем состоят проблемы? В неумении людей отличать цели от задач. Типичное содержимое - "целью работы является разработка системы Х. Задачами работы, э-э-э... Чорт! Что здесь писать? являются проектирование, кодирование, и отладка системы Х".
Этот абзац меня сначала сбил с толку, потом вроде стало понятнее, но на всякий случай уточню, если написать:
1. Целью работы является ускорение формирования ОТЧЕТА... с недели до одного дня.
2. Задачей является разработка системы Х, автоматизирующей обработку входных данных.

То будет правильно? То есть система Х у нас присутствует, но в качестве задачи, а не цели.
Gaperton
gaperton at 2010-08-25 21:39 (UTC) (Link)
Да, на мой взгляд, это хорошая, годная формулировка. Скажем так - мне она кажется куда более осмысленной, чем та хрень, что в этой секции обычно пишут.

Хотя секция "цели и задачи" настолько загадочна, что медитируя над ней можно словить просветление, но так нихера ее по человечески и не написать :).
Alexander  Mikhalev
alexander_mikh at 2010-09-02 08:50 (UTC) (Link)
спасибо.
прочитал с большим интересом - появилась связка между тем чему учили в вузе и современным redmine.
li_538 at 2010-09-11 15:32 (UTC) (Link)
Добавлю свой отзыв.

С удовольствием отмечаю, что наконец наши русские разработчики стали возвращаться к отработанным годами конструкторским советским документам. Результат их _вдумчивого_ применения - рабочее изделие, а не процесс и ворохи проектно-сметной документации с заложенными золотыми унитазами. Очень верно вынесена мысль, что заказчику (не формальному - контрактодержателю), а заказывающему подразделению в общем-то пофиг на все эти красивые процессные подходы и шильдики. Ему нужно полностью соответствующе затребованным ТТХ изделие. А тут как раз замок технического _замысла_, оформленного в виде ТЗ как изделия в целом (не тождественно продукту в зарубежных подходах, т.к. ТЗ также фиксирует подготовку объектов к пусконаладке и ввводу изделия в действие) закрывается ПМИ - то, что реально будет принимать заказчик. И кроме ПМИ вывешивать кучу названий использованных при разработке новомодных подходов - бессмысленно, ибо заказчику пофигу - главное чтобы комплекс работал.

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

И выходит, что ГОСТ по сути нужен исключительно системному разработчику, причем высокопрофессинальному, т.е. не тому, который спосбен формировать тонны отчетных материалов, а тому, который ведет свои проектные команды к рабочему изделию - а не во имя процесса и для разработки _макета_, который попытаться выдать на испытаниях за целевой разрабатываемый комплекс.

Вот как-то так.

Причем если сравнивать подходы к разработке действительно _высокосложных_ изделий, в т.ч. включающих в качестве составной части программные средства - подход наших более "жестоких" ГОСТ РВ за исключением одного принципиального различия - точь-в-точь совпадает с американскими DoD MIL STD - XXXX. Отличие простое - у нас предложен фиксированный перечень этапов работ (и неспроста - по ним финансовые акты закрываются), у друзей - итеративная модель разработки, по мере прохода итераций закрываются пункты ТТЗ. Причем у них заказчик на формализованной основе ведет мониторинг хода закрытия пунктов ТТЗ по окончанию каждой итерации. У нас - ПМИ и различные виды испытаний, что дает несколько больше свободы разработчику изделия. И опять-таки, несмотря на наш жестко зафиксированный перечень этапов разработки изделий по ГОСТ РВ в реальной работе разработчиков ПО никто не мешает использовать и XP и SCRUM и прочее. Главное, что все инженерные коллективы при этом работают не на процесс, а на закрытие пунктов ТТЗ. В т.ч., например, подготовка полигона к проведению испатаний, завоз комплектующих испытательного стенда, его сборка и т.д. - все подчинено только созданию изделия. Лишние активности как правило при этом только отъедают драгоценнное время. Как минус - системный разработчик должен очень аккуратно отнестись к процессу документирования конструкторских решений (читай - архитектуры, в случае ПО).

Вот :)
Gaperton
gaperton at 2010-09-12 20:44 (UTC) (Link)
Класс! Спасибо за столь развернутый и глубокий комментарий.

Вопрос - не могли бы Вы раскрыть тему итеративности DoD MIL STD ХХХХ, и дать точные ссылки/номера? И Заодно - расшифровать "ТТЗ".

Что до ЧТЗ или СЧ ТЗ - это и так понятно. :) СЧ - есть Составная Часть ОКР, если кто из читателей не понял. :) То самое "частное" ТЗ, на которые дробится крупное общее ТЗ.
ljournalist_bot
ljournalist_bot at 2011-02-06 11:24 (UTC) (Link)
Поздравляем! Ваш пост был отобран нашими корреспондентами и опубликован в сегодняшнем выпуске ljournalist'а.
(Deleted comment)
Gaperton
gaperton at 2011-02-06 21:54 (UTC) (Link)
ГОСТ иррелевантен к методологии разработки - это протокол отношений заказчик-исполнитель. Его нельзя получить ни из Скрама, ни Рупа, хотя работу и по тому, и по другому (как вообще любую работу) несложно завернуть в ГОСТ.

Чтобы это осознать, знаний одного скрама, очевидно, недостаточно - надо иметь более широкий кругозор.
(Deleted comment)
Кром
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. Поэтому, и управлять ими лучше вместе.

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

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

И вопрос очень простой - либо вы тратите усилия на то, чтобы разобраться, либо нет. Если нет - то всего доброго. Дискутировать мне не интересно, равно как и кого-то в чем-то убеждать.
Евгений
sandu at 2012-03-05 12:38 (UTC) (Link)
Вот я в итоге как-то слабо понимаю, что представляет собой комплект документации, который вы получите в конце проекта. Может, вы могли бы дать пример? :)
Gaperton
gaperton at 2012-03-12 14:28 (UTC) (Link)
В итоге получается продукт, а не комплект документации :).

Некоторые примеры ТЗ по второстепенным проектам, вероятно, могу выслать почтой. Программы и методики - вряд ли. То что есть в наличии, оформленное в пригодном для пересылке виде - строго конфиденциально, не имею права разглашать.
Previous Entry  Next Entry