Практически все в Соединенных Штатах Америки знают о космических программах Национального управления по аэронавтике и исследованию космического пространства (НАСА). НАСА осуществляет также много других инженерных программ, в частности разработку процессов.
Инженерная поддержка инициатив НАСА — систем и программ — является основой созданных возможностей и жизненно важных технологий. Обеспечение качества, безопасности и надежности систем НАСА исключительно важно для достижения успеха миссии агентства.
Экспоненциальный рост масштаба, сложности и важности разрабатываемых систем ставит перед НАСА задачу эффективного управления ими.
Для решения этой задачи НАСА «запустило» инициативу в области программного инжиниринга и аналогичные программы для системного инжиниринга. При планировании проектов, выявлении требований и для реализации своих инициатив были применены передовые разработки, относящиеся к документированию процессов.
В табл. 1 показаны самые распространенные проблемы, связанные с документированием процессов.
| № | Проблема | Описание |
|---|---|---|
| 1 | Документов слишком много | Паскаль однажды сказал: «Это письмо получилось длиннее, чем обычно, потому что у меня не было времени сделать его короче». Эта цитата подходит к большинству процессов и процедур. Документация по процессу должна быть краткой, четкой и удобной для использования |
| 2 | Недостаточно иллюстраций | Документация по процессу должна иметь больше иллюстраций, поскольку они заменяют тысячу слов. Хорошая документация по процессу должна представлять собой объединение иллюстраций и слов. Наилучшие рисунки — это хорошо продуманные диаграммы. Наилучшие диаграммы для документирования процесса — это модели процесса. |
| 3 | Документация плохо структурирована | Нарушены такие принципы четкого построения документации на процессы и процедуры, как разделение на части и последовательность изложения; стиль письма. |
| 4 | Документы неудобны для использования, одного объема для всех пользователей | Большинство процессов и процедур создаются без участия тех, кто ими будет пользоваться. Многие документы часто создаются по единой схеме, без учета менталитета и уровня пользователей (начальный, средний, эксперт). |
| 5 | Смешение информации разных видов | Политика, стандарты, процессы, процедуры и учебные материалы — это разные виды информации, которые в большинстве документов по процессу смешиваются, как если бы они использовались одинаковым образом. А ведь каждый из этих видов используется |
| 6 | Документы не разделены на части | Документация по процессу — это не роман, она не рассчитана на восприятие только в последовательном изложении, когда ее читают от начала до конца. Документация по процессу — это ссылочный документ, который предназначен для выборочного использования. Наличие промежуточных заголовков очень важно, потому что позволяет пользователям быстро находить нужную информацию. |
| 7 | Трудно быстро найти нужную информацию | Пользователи документации обычно изучают информацию в течение нескольких минут. Но если они не смогут найти ее быстро, и это будет происходить часто, то в разочаровании прекратят поиски и просто не будут использовать процесс или процедуру. Это может привести к серьезным проблемам в организации. |
| 8 | Документы просто пылятся на полке | Документация многих процессов залеживается на полке, покрываясь пылью. Процессы с использованием электронной версии также должны быть хорошо спроектированы, а не то они аналогично будут «пылиться», но уже в электронной сети. |
Таблица 1 — Общие проблемы при документировании процессов
Как можно решить ставшие общими проблемы? Начать следует с понимания того, что не вся документация используется одинаково: «документация по процессу» может относиться и к политике, и к стандартам, и к процессам и процедурам. В табл. 2 показаны различные виды документов по процессу и описано, как каждый из них используется. В дополнение к этому на схеме документации (схема 1) показаны некоторые важнейшие их взаимосвязи.
| Виды документов | Использование |
|---|---|
| Политика | Используется высшим руководством для управления организацией. Устанавливает принципы, которым должна следовать организация. |
| Стандарт | Выделяет части документа и дает описание того, что должно входить в эти части. Обеспечивает воспроизводимость содержания документов. |
| Процесс | Говорит о том, что должно происходить в определенное время для получения желаемого результата. Должен ответить на шесть вопросов: кто? что? где? когда? почему? как? |
| Процедура | Предоставляет информацию о том, как сделать |
Таблица 2 — Виды документов по процессу
Схема 1 — Взаимосвязь документов
Документация для разных пользователей
Для пользователей разного уровня требуется различный уровень документации на процессы и процедуры:
- Пользователи, которых можно назвать экспертами, применяли процесс много раз;
- Пользователи среднего уровня хоть и применяли процесс несколько раз, но им требуются руководящие указания и практические навыки;
- Начинающие пользователи никогда ранее не применяли процесс.
Документы для экспертов. «Экспертный тип» документации — лаконичный, четкий и не содержит материалов, требуемых для обучения. Когда пилот управляет самолетом, он не берет с собой учебные пособия. Вместо этого пилоты используют краткий контрольный перечень вопросов по взлету и посадке.
Большинство людей хотело бы пользоваться экспертным типом документации, потому что она краткая. Проблема лишь в том, что не все являются экспертами. Например, не каждый сможет понять контрольный вопросник специалиста по ракетам — иногда для этого вам действительно надо быть специалистом по ракетам! Более того, подчас опасно давать экспертную документацию в руки неэкспертов.
Контрольные вопросники необходимы, так как люди могут забывать некоторые вещи. Знания экспертов должны быть закреплены документально, потому что эксперты могут покинуть организацию, забрав с собой драгоценную для вас информацию.
Пользователи среднего уровня. Документация для пользователей среднего уровня основана на документации для экспертов, но расширяет ее за счет включения руководящих указаний и практических примеров. Инструкции очень полезны для людей, которым не приходится реализовывать процесс или применять процедуру часто. Даже эксперты забывают руководящие указания и практические примеры, если процесс применяется всего несколько раз в год.
Обычно руководящие указания и примеры не являются объектом аудита. В то время как фазы процесса и отдельные шаги в процедуре обязательны для выполнения и проверяются в ходе аудита, соответствующие руководящие указания и практические примеры используются обычно только во вспомогательных целях. Хорошо, если вы будете различать этапы процесса, которые являются обязательными, и руководящие указания, которые играют лишь дополнительную роль. НАСА снабжает руководящие указания и практические примеры пометкой «руководящие указания».
Начинающие пользователи. Документация для начинающих пользователей основана на документации для пользователей среднего уровня, которая дополнена практическими заданиями для тренировки. Одни процессы простые, другие — сложные. Для освоения сложных процессов необходимо пройти официальную подготовку под руководством знающего человека.
Как же организации обеспечить предоставление трех версий одной и той же документации?
Передовой опыт
Документация по процессу хорошо «работает» только тогда, когда содержит все необходимые элементы. В табл. 3 даны описания элементов процесса (кто, что, где, когда, почему и как), необходимые для разработки «хорошего» процесса.
| Ключевой вопрос процесса | Элемент процесса |
|---|---|
| Зачем осуществляется действие? | Цель |
| Кто осуществляет действие? | Распределение ролей при осуществлении действия |
| Какие средства производства используются? | Вход |
| Какие продукты производятся? | Выход |
| Когда начинается действие? | Критерии начала |
| Когда действие заканчивается? | Критерии завершения |
| Как осуществляется действие? | Шаги, процедура, метод |
| Какое действие является следующим? | |
| Где осуществляется действие? | Окружающая среда (например, иерархия отношений) |
Таблица 3 — Ключевые вопросы процесса
«Хороший» процесс должен:
- Охватывать все шесть вопросов и содержать все ключевые элементы; содержать как текст, так и иллюстрации;
- Иметь краткое, хорошо написанное описание, удобное для использования;
- Описание процесса должно быть хорошо структурированным и иметь оглавление (для быстрого поиска нужных разделов).
Несмотря на то, что хороший процесс должен быть иллюстрирован, не все иллюстрации хороши. Некоторые иллюстрации приводят к путанице и больше вредны, чем полезны. Что же является хорошей иллюстрацией? Самое лучшее — это моделирование процесса, которое помогает строить наглядные диаграммы, охватывающие все шесть вопросов.
На схеме 2 показан пример модели процесса. Подобная модель отвечает на вопросы о фактическом состоянии процесса и обычно бывает представлена в виде диаграмм и подробных комментариев, которые устанавливают распределение ролей, осуществляемые действия, результаты работы и взаимоотношения между ними.
Лучшие процедуры состоят из пошаговой информации о том, как нужно выполнять действия, и бывают представлены в одном из трех форматов:
- Контрольные перечни вопросов;
- Формы (шаблоны);
- Таблицы этапов/действий.
Контрольные перечни вопросов — эффективный инструмент представления действий, необходимый при повторном выполнении
Формы (шаблоны), наряду с инструкциями по их выполнению, являются механизмом обеспечения повторяемости поддерживающих процессов. Формы — это очень действенный механизм для многократного повторяющегося сбора данных.
Использование таблиц этапов/ действий (табл. 4) — эффективный способ представления процедур. Они полезны, если особое значение имеет порядок действий. Например, если человек должен следить за использованием своего времени, начало наблюдения не должно быть последним этапом.
| № | Этап |
|---|---|
| 1 | Начать отсчет времени (записать время начала действий) |
| 2 | Проверить наличие дефектов в выбранном продукте с помощью применения контрольных перечней вопросов, основанных на соответствующих данных |
| 3 | Зафиксировать дефекты в соответствующей форме для фиксации дефектов. Продолжать регистрировать дефекты, используя контрольный перечень, до полного завершения контроля всей продукции |
| 4 | Закончить следить за временем (записать время окончания работы). Подсчитать, сколько времени было затрачено на поиск и регистрацию дефектов, и записать общее время в форме для фиксации дефектов |
Таблица 4 — Пример таблицы этапов/действий
Примеры успехов НАСА
Некоторые подразделения НАСА недавно успешно использовали передовой опыт документирования процессов (см. схему 2).
Схема 2 — Процесс обработки запросов потребителя
Цель: результативная и эффективная работа с запросами потребителей.
Критерии входа/начала:
- Получение запроса потребителя (телефонный звонок, голосовая почта, электронная почта, факс, внутриофисная почта
и т. д. ); - Создание официального «листа запроса».
Критерии выхода/окончания:
- Запрос потребителя выполнен;
- Запрос отозван в ходе выработки способа выполнения запроса.
Группы технической поддержки процессов (ГТП) НАСА разрабатывают, измеряют и улучшают системы. Возрастание объемов, сложность и трудности применения документации по их процессам привело к решению использовать накопленный передовой опыт описания процессов.
Первой группой, которая опробовала передовой опыт описания процессов, была ГТП исследовательского центра «Лэнгли» в Хэмптоне. Эта команда решила улучшить процесс создания программных продуктов для центра. Хотя применяемая ранее процедура превосходила средние показатели по процессам центра, в ней был ряд слабых мест:
- Смешение документов различного вида (политики, стандартов, процессов и процедур);
- Нарушение принципа разбиения на части. Большинство людей могут запомнить лишь небольшие куски информации. Именно поэтому, например, 15- и
16-значные номера кредитных карт разбиты на меньшие части по четыре и пять цифр. Исходный процесс в Лэнгли содержалблок-схему из более 30 этапов и процедуру из более 25 этапов, что создавало трудности при использовании; - Описания процессов охватывали не все ключевые вопросы. Отсутствовал ответ на вопрос «когда?», а другие ответы были неполными.
В новой процедуре с применением передовых приемов документирования исчезли все эти слабые места. Для построения хороших диаграмм и разбиения
Недавно организованный Совет НАСА по инженерным вопросам и безопасности разработал около 30 процедур. Хотя они значительно превышали по своим характеристикам средние показатели, агентство поставило задачу сделать их короче для более удобного использования. Передовой опыт помог сотрудникам Совета сократить объем процедур на 60%, при этом техническое содержание не пострадало.
Центр информационной поддержки расположен в Силиконовой долине в Калифорнии. Один из работающих в Центре опытных менеджеров получил задание создать новый отдел поддержки потребителей. Он выяснил, что хотя для решения отдельных проблем существовал ряд процедур, общий процесс выполнения запросов потребителей не был документирован.
В Центре разработали новый документ, описывающий четыре процесса всего на 19 страницах (обычно описание аналогичных процессов занимает сотни страниц). Ответы на ключевые вопросы для каждого процесса были даны в виде диаграмм объемом в одну страницу в режиме экспертного использования, а для пользователей среднего уровня прилагалась еще страница текста вместе с руководящими указаниями, комментирующая диаграмму (табл. 5 и схема 2) — примеры, взятые из документации по процессам данного Центра.
| Номер этапа | Этапы процесса |
|---|---|
| 7.1.1 |
Запрос Центру информационной поддержки Руководящие указания: потребитель может обращаться в Центр в рабочие часы, используя следующие варианты:
|
| 7.1.2 |
Первый уровень: создание «листа запроса»
|
| 7.1.3 |
Первый уровень: сортировка запроса Руководящие указания: сортировка означает использование СУУ и СОП и применение профессиональной оценки либо для выполнения запроса, либо для правильного перенаправления запроса в другое место. |
| 7.1.4 |
Первый уровень: выполнен ли запрос?
Руководящие указания:
|
| 7.1.5 |
Второй уровень: обработка запроса
|
| 7.1.6 |
Первый уровень: выполнение запроса
Руководящие указания: убедитесь, что потребитель доволен результатом выполнения запроса. |
| 7.1.7 |
Второй уровень: выполнен ли запрос?
Руководящие указания: убедитесь, что потребитель доволен результатом выполнения запроса. |
| 7.1.8 |
Третий уровень: выполнение запроса
Руководящие указания: убедитесь, что потребитель доволен результатом выполнения запроса. |
Таблица 5 — Процесс обработки запросов потребителей
Указанный менеджер недавно получил повышение. Новая документация по процессам сыграла ключевую роль в этом продвижении, потому что дала возможность новому менеджеру быстро освоить ключевой процесс отдела. Иногда опытный человек «застревает» на своей должности, потому что процесс не документирован, а он — единственный, кто хорошо его знает.
Отдел М в головном офисе НАСА. Отдел М — самый крупный в НАСА — разрабатывает и обеспечивает поддержание в рабочем состоянии космических челноков «Шаттл» и космических станций.
Главный инженер отдела М захотел провести анализ процесса и сопоставить его с другими, осуществляемыми в
Офис главного инженера. Офис главного инженера, расположенный в
Документ по новым процедурным требованиям был написан на 50 страницах и содержал около 140 требований. Это гораздо меньше, чем большинство аналогичных промышленных стандартов, которые содержат сотни страниц.
Требования содержали слово «должен» и были записаны в одно предложение. Частные рекомендации были добавлены в виде примечаний. Требования были поделены на части, относящиеся к передовым программным продуктам, каждый из которых был кратко описан.
В НАСА применялось восемь классов программного обеспечения, учитывающих тип обслуживаемой подсистемы и важность класса для успеха проекта. К каждому классу при помощи матрицы можно было предъявить до 140 требований. Для оценки программного обеспечения, играющего важную роль в реализации миссии проекта, использовались все 140 требований. Для оценки программного обеспечения более низкого класса использовалось меньше требований.
Некоторые извлеченные уроки
Вот уроки, которые извлекли в НАСА и во многих других организациях в процессе разработки процессов с использованием указанных методов:
- Не смешивайте информацию из области политики, стандартов, процессов и процедур (например, в одном параграфе). Обозначьте различную информацию соответствующими заголовками и подумайте над тем, как она используется;
- Делайте всю документацию максимально простой, но не упрощайте ее слишком, иначе она не будет работать. Следите за тем, чтобы документация оставалась краткой и точной, но будьте готовы к тому, что описание некоторых сложных процессов будет объемным; используйте хорошие иллюстрации (большинство людей предпочитают именно их), а слова применяйте для пояснения деталей;
- Для каждого процесса или подпроцесса подготовьте ответы на ключевые вопросы на одной странице, используя диаграмму, такую как на схеме 2. Хорошая диаграмма процесса может заменить 20–25 страниц текста; моделирование процесса — хороший метод, особенно удобный в случае чрезвычайно сложных систем. Используйте моделирование процесса для составления хороших иллюстраций;
- Составление схемы передачи информации — также хороший метод;
- Используйте такие процедуры, как контрольные таблицы, формы и таблицы этапов/действий;
- Разбивайте материал на секции и озаглавливайте разделы так, чтобы пользователь мог быстро найти информацию. Моделирование процессов и составление схемы передачи информации весьма помогают в выполнении этого принципа;
- Учитывайте интересы всех групп пользователей: начинающих, среднего уровня и экспертов;
- «Встройте» измерения в процесс. Не добавляйте измерения в качестве дополнительных действий уже после того, как процесс осуществлен;
- Процесс должен быть «подогнан» под потребности каждой организации, каждого подразделения и каждого проекта;
- Разработка «хороших» процессов и процедур — кратких и удобных для использования — трудная задача, являющаяся вызовом времени. Для улучшения документации по процессу могут быть использованы многие методы. Методы, рассмотренные в статье, представляют собой набор нескольких прекрасных подходов, объединенных в «процесс по разработке процессов».
Опубликовано по материалам:
Developing Best In Class Processes at NASA // Quality Progress, май 2005
Подготовил Владимир АЛЕКСЕЕВ
Октябрь 2007 г.
Поделиться: