Эволюция стандарта
Стандарт прошел эволюцию: от короткого документа примерно на 25 страниц до объемного текста, который используется сейчас. По всей видимости, изменения продолжатся. Кроме основного стандарта появляются сопутствующие стандарты, например посвященные менеджменту модели жизненного цикла. Их много; новые появляются, старые заменяются. Это динамичная и быстро меняющаяся среда.
ГОСТ 34: документ или процесс
В первоначальном виде ГОСТ 34 не предполагал управленческой квалификации у тех, кто его применяет. Причина в том, что основной артефакт стандартизации в нем — не процесс, а документ. Проверить соответствие документа формату ГОСТ 34 может каждый: не обязательно понимать содержательную сторону или разбираться в терминологии. Достаточно посмотреть на структуру, названия разделов и, возможно, ключевые слова.
Для адаптации стандарта этого недостаточно. Нужно хорошо понимать задачу, ограничения, свои возможности и назначение процессов. Это требует высокой управленческой квалификации, причем не айтишной, а именно управленческой.
Владельцы процессов и верификация
Все бизнес-процессы имеют владельцев и администраторов, или менеджеров. Это справедливо и для стандарта 12207. Даже на примере четырех рассмотренных процессов видно, что вопрос о владельце процесса верификации нетривиален. В каждом проекте за конкретный план верификации и конкретный процесс верификации отвечает проектный менеджер. Но кто отвечает за сам состав работ по верификации — за верификацию кода, документации, сборки, а возможно, и других объектов, например тестов или персонала, — неясно. Непонятно, какой это должен быть человек и в какой должностной роли он должен находиться.
В стандарте 12207 такие вопросы видны особенно ярко. Они непростые и плохо стандартизируются.
Комплексные референтные модели
В начале стандарта показана картина процессов: большая таблица с множеством прямоугольников, разбитых на группы и категории. Там есть, например, процессы управления проектами. Возникает вопрос: зачем они нужны, если существуют специализированные референтные модели по управлению проектами?
Это указывает на тенденцию строить комплексные референтные модели — многоаспектные, покрывающие много процессов. Такие процессы часто работают вместе. Есть отдельные области знаний по управлению проектами и управлению требованиями, есть специальная методика Business Analysis Body of Knowledge (BABOK). Но все это собирается в компактную картину, где процессы объединены, чтобы решать задачу разработки ПО.
Отсюда следует вывод о комплексном реинжиниринге процессов: внедрение законченных моделей, направленных на решение конкретной задачи, может быть правильнее и разумнее, чем внедрение референтных моделей бизнес-процессов из разных областей деятельности.
Краткие итоги
Стандартизация в области разработки программного обеспечения развивается неравномерно: от компактных документов к объемным системам требований и сопутствующим стандартам. Основной водораздел проходит между стандартизацией документа и стандартизацией процесса. Когда стандарт ориентирован на документ, проверка соответствия сводится к формальным признакам: структуре, названиям разделов, ключевым словам. Это делает такую проверку доступной широкому кругу исполнителей, но не гарантирует содержательной корректности и применимости. Для адаптации стандарта требуется иной уровень компетенций: понимание задачи, ограничений, возможностей организации и назначения процессов. Здесь ключевой становится управленческая квалификация, а не только техническая или айтишная. Это объясняет, почему формальное соблюдение формата не равно эффективному внедрению.
Далее логика переходит к процессному управлению. Бизнес-процессы не существуют сами по себе: у них есть владельцы и администраторы или менеджеры. Однако распределение ответственности оказывается сложным. На примере верификации видно, что проектный менеджер отвечает за конкретный план и процесс в проекте, но вопрос о владельце самого состава работ по верификации остается открытым. Неясно, кто должен определять, что именно верифицировать — код, документацию, сборку, тесты, персонал или иные объекты. Такая неопределенность показывает, что многие управленческие вопросы плохо поддаются стандартизации, хотя стандарт 12207 делает их особенно заметными.
Наконец, наблюдается тенденция к комплексным референтным моделям. Отдельные области знаний — управление проектами, управление требованиями, BABOK — существуют самостоятельно, но на практике процессы работают вместе. Поэтому их объединяют в многоаспектные модели, ориентированные на конкретную задачу, например разработку ПО. Это подводит к идее комплексного реинжиниринга процессов: внедрять законченную модель под задачу может быть разумнее, чем собирать референтные модели из разных областей.
Следующий шаг — модели зрелости, которые продолжают эту логику оценки и развития процессов.
Стандарт в области разработки ПО прошел эволюцию: от короткого документа примерно на 25 страниц до объемного текста, который используется сейчас. Изменения, вероятно, продолжатся. Появляются сопутствующие стандарты, например по менеджменту модели жизненного цикла. Их много, новые возникают, старые заменяются; среда динамична.
ГОСТ 34 в первоначальном виде не предполагал управленческой квалификации у применяющих. Его основной объект стандартизации — не процесс, а документ. Проверить соответствие документа формату может каждый: не обязательно понимать содержание или терминологию. Достаточно структуры, названий разделов и ключевых слов. Но для адаптации стандарта этого мало. Нужно понимать задачу, ограничения, свои возможности и назначение процессов. Требуется высокая управленческая квалификация — не айтишная, а именно управленческая.
Бизнес-процессы имеют владельцев и администраторов, или менеджеров. Это справедливо и для стандарта 12207. На примере верификации видно, что вопрос о владельце процесса нетривиален. В каждом проекте за конкретный план и процесс верификации отвечает проектный менеджер. Но кто отвечает за сам состав работ по верификации — за верификацию кода, документации, сборки, а возможно, и других объектов, например тестов или персонала, — неясно. Непонятно, какая это должностная роль. В стандарте 12207 такие вопросы видны особенно ярко. Они непростые и плохо стандартизируются.
В начале стандарта показана картина процессов: большая таблица с множеством прямоугольников, разбитых на группы и категории. Там есть, например, процессы управления проектами. Возникает вопрос: зачем они нужны, если есть специализированные референтные модели по управлению проектами? Это указывает на тенденцию строить комплексные референтные модели — многоаспектные, покрывающие много процессов, потому что процессы часто работают вместе. Есть отдельные области знаний по управлению проектами и управлению требованиями, есть методика Business Analysis Body of Knowledge (BABOK). Но все это собирается в компактную картину, где процессы объединены для решения задачи разработки ПО. Отсюда вывод: комплексный реинжиниринг процессов, то есть внедрение законченных моделей под конкретную задачу, может быть разумнее, чем внедрение референтных моделей из разных областей. Далее рассматриваются модели зрелости.
1. Стандарт эволюционирует от короткого документа к объемному тексту; появляются сопутствующие стандарты.
2. Среда стандартизации динамична: новые стандарты появляются, старые заменяются.
3. ГОСТ 34 изначально стандартизирует документ, а не процесс.
4. Формальная проверка документа по ГОСТ 34 возможна без понимания содержания и терминологии.
5. Адаптация стандарта требует понимания задачи, ограничений, возможностей и назначения процессов.
6. Для адаптации нужна управленческая, а не только айтишная квалификация.
7. Бизнес-процессы имеют владельцев и администраторов или менеджеров.
8. Вопрос о владельце процесса верификации нетривиален и плохо стандартизируется.
9. За конкретный план и процесс верификации в проекте отвечает проектный менеджер.
10. Состав работ по верификации может включать код, документацию, сборку и другие объекты.
11. Комплексные референтные модели объединяют процессы, которые работают вместе.
12. Комплексный реинжиниринг процессов может быть разумнее внедрения разрозненных референтных моделей.
1. Почему ГОСТ 34 в первоначальном виде не требовал управленческой квалификации?
2. Какой основной артефакт стандартизируется в ГОСТ 34?
3. Что достаточно проверить для соответствия документа формату ГОСТ 34?
4. Что необходимо понимать для адаптации стандарта?
5. Какая квалификация особенно важна для адаптации стандарта?
6. Почему у бизнес-процессов есть владельцы и администраторы?
7. В чем нетривиальность вопроса о владельце процесса верификации?
8. Кто отвечает за конкретный план и процесс верификации в проекте?
9. Какие работы могут входить в состав верификации?
10. Почему вопросы ответственности в стандарте 12207 плохо стандартизируются?
11. Зачем в комплексную модель включены процессы управления проектами?
12. Почему комплексный реинжиниринг процессов может быть разумнее внедрения разрозненных референтных моделей?
