?

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 2 of 2
<<[1] [2] >>
0x7be
0x7be at 2013-01-29 01:48 (UTC) (Link)
Запозадло откомментирую.
Забавно, что выделенные Вами пункты: цель, задача, ПМИ весьма хорошо "ложатся" на структуру User Story: цель, описание фитчи, критерии приемки.

Или я переупрощаю? :)
Gaperton
gaperton at 2013-05-08 10:12 (UTC) (Link)
Вы попросту не читаете.

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

О мотивах такого поведения можно только догадываться. Впрочем, они нехитры.

Или я переупрощаю?
0x7be
0x7be at 2013-05-08 11:31 (UTC) (Link)
Я рассчитывал обсудить тему Вашей заметки, а не свою скромную персону :)
Gaperton
gaperton at 2013-05-17 11:18 (UTC) (Link)
Да? Тогда это я не читаю.

Юзер-стори, или фича из FDD являются отличными способами постановки задач.

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

ТЗ - это проект. Который должен состоять из одной или нескольких итераций (этапов).
Previous Entry  Next Entry