Статьи

Многим, кто работал по ГОСТ-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) Технические требования - можете в вики писать, а можете задавать тикетами. Это уж как душе угодно.

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

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