NASA: опыт разработки «хороших» процессов

ПО СТРАНИЦАМ ЖУРНАЛА "QUALITY PROGRESS"

Тим ОЛСОН, Джон КЕЛЛИ

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

Инженерная поддержка инициатив НАСА — систем и программ — является основой созданных возможностей и жизненно важных технологий. Обеспечение качества, безопасности и надежности систем НАСА исключительно важно для достижения успеха миссии агентства.

Экспоненциальный рост масштаба, сложности и важности разрабатываемых систем ставит перед НАСА задачу эффективного управления ими.

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

В табл.1 показаны самые распространенные проблемы, связанные с документированием процессов.

Таблица1 - Общие проблемы при документировании процессов

Проблема	Описание
1. Документов слишком много	Паскаль однажды сказал: "Это письмо получилось длиннее, чем обычно, потому что у меня не было времени сделать его короче". Эта цитата подходит к большинству процессов и процедур. Документация по процессу должна быть краткой, четкой и удобной для использования
2. Недостаточно иллюстраций	Документация по процессу должна иметь больше иллюстраций, поскольку они заменяют тысячу слов. Хорошая документация по процессу должна представлять собой объединение иллюстраций и слов. Наилучшие рисунки — это хорошо продуманные диаграммы. Наилучшие диаграммы для документирования процесса — это модели процесса.
3. Документация плохо структурирована	Нарушены такие принципы четкого построения документации на процессы и процедуры, как разделение на части и последовательность изложения; стиль письма.
4. Документы неудобны для использования, одного объема для всех пользователей	Большинство процессов и процедур создаются без участия тех, кто ими будет пользоваться. Многие документы часто создаются по единой схеме, без учета менталитета и уровня пользователей (начальный, средний, эксперт).
5. Смешение информации разных видов	Политика, стандарты, процессы, процедуры и учебные материалы — это разные виды информации, которые в большинстве документов по процессу смешиваются, как если бы они использовались одинаковым образом. А ведь каждый из этих видов используется по-разному.
6. Документы не разделены на части	Документация по процессу — это не роман, она не рассчитана на восприятие только в последовательном изложении, когда ее читают от начала до конца. Документация по процессу — это ссылочный документ, который предназначен для выборочного использования. Наличие промежуточных заголовков очень важно, потому что позволяет пользователям быстро находить нужную информацию.
7. Трудно быстро найти нужную информацию	Пользователи документации обычно изучают информацию в течение нескольких минут. Но если они не смогут найти ее быстро, и это будет происходить часто, то в разочаровании прекратят поиски и просто не будут использовать процесс или процедуру. Это может привести к серьезным проблемам в организации.
8. Документы просто пылятся на полке	Документация многих процессов залеживается на полке, покрываясь пылью. Процессы с использованием электронной версии также должны быть хорошо спроектированы, а не то они аналогично будут "пылиться", но уже в электронной сети.

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

Таблица 2 - Виды документов по процессу

Виды документов	Использование
Политика	Используется высшим руководством для управления организацией. Устанавливает принципы, которым должна следовать организация.
Стандарт	Выделяет части документа и дает описание того, что должно входить в эти части. Обеспечивает воспроизводимость содержания документов.
Процесс	Говорит о том, что должно происходить в определенное время для получения желаемого результата. Должен ответить на шесть вопросов: кто? что? где? когда? почему? как?
Процедура	Предоставляет информацию о том, как сделать что-либо, и пошагово расписывает действия. Осуществляет часть процесса.

Схема 1 - Взаимосвязь документов

Документация для разных пользователей 

Для пользователей разного уровня требуется различный уровень документации на процессы и процедуры:

• пользователи, которых можно назвать экспертами, применяли процесс много раз;
• пользователи среднего уровня хоть и применяли процесс несколько раз, но им требуются руководящие указания и практические навыки;
• начинающие пользователи никогда ранее не применяли процесс.

Документы для экспертов. "Экспертный тип" документации — лаконичный, четкий и не содержит материалов, требуемых для обучения. Когда пилот управляет самолетом, он не берет с собой учебные пособия. Вместо этого пилоты используют краткий контрольный перечень вопросов по взлету и посадке.

Большинство людей хотело бы пользоваться экспертным типом документации, потому что она краткая. Проблема лишь в том, что не все являются экспертами. Например, не каждый сможет понять контрольный вопросник специалиста по ракетам — иногда для этого вам действительно надо быть специалистом по ракетам! Более того, подчас опасно давать экспертную документацию в руки неэкспертов.

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

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

Обычно руководящие указания и примеры не являются объектом аудита. В то время как фазы процесса и отдельные шаги в процедуре обязательны для выполнения и проверяются в ходе аудита, соответствующие руководящие указания и практические примеры используются обычно только во вспомогательных целях. Хорошо, если вы будете различать этапы процесса, которые являются обязательными, и руководящие указания, которые играют лишь дополнительную роль. НАСА снабжает руководящие указания и практические примеры пометкой "руководящие указания".

Начинающие пользователи. Документация для начинающих пользователей основана на документации для пользователей среднего уровня, которая дополнена практическими заданиями для тренировки. Одни процессы простые, другие — сложные. Для освоения сложных процессов необходимо пройти официальную подготовку под руководством знающего человека.

Как же организации обеспечить предоставление трех версий одной и той же документации?

Когда-нибудь компьютерные программы смогут включать документацию всех трех типов (эксперт/средний уровень/начинающий), что позволит пользователю видеть информацию в нужном для него виде. А пока лучший метод заключается в описании процесса в виде разделов (секций), базовый вариант которых подготовлен для пользователей среднего уровня. Тогда для начинающих пользователей стоит лишь добавить тренировочные задания, а экспертам ограничиться укороченным набором из нужных для них разделов. Другой прекрасный способ — создание специальной экспертной документации для экспертов.

Передовой опыт

Документация по процессу хорошо "работает" только тогда, когда содержит все необходимые элементы.В табл.3 даны описания элементов процесса (кто, что, где, когда, почему и как), необходимые для разработки "хорошего" процесса.

Таблица 3 - Ключевые вопросы процесса

Ключевой вопрос процесса	Элемент процесса
Зачем осуществляется действие?	Цель
Кто осуществляет действие?	Распределение ролей при осуществлении действия
Какие средства производства используются?	Вход
Какие продукты производятся?	Выход
Когда начинается действие?	Критерии начала
Когда действие заканчивается?	Критерии завершения
Как осуществляется действие?	Шаги, процедура, метод
Какое действие является следующим?	Блок-схема (например, последовательность шагов)
Где осуществляется действие?	Окружающая среда (например, иерархия отношений)

"Хороший" процесс должен:

• охватывать все шесть вопросов и содержать все ключевые элементы; содержать как текст, так и иллюстрации;
• иметь краткое, хорошо написанное описание, удобное для использования;
• описание процесса должно быть хорошо структурированным и иметь оглавление (для быстрого поиска нужных разделов).

Несмотря на то, что хороший процесс должен быть иллюстрирован, не все иллюстрации хороши. Некоторые иллюстрации приводят к путанице и больше вредны, чем полезны. Что же является хорошей иллюстрацией? Самое лучшее — это моделирование процесса, которое помогает строить наглядные диаграммы, охватывающие все шесть вопросов.

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

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

• контрольные перечни вопросов;
• формы (шаблоны);
• таблицы этапов/действий.

Контрольные перечни вопросов — эффективный инструмент представления действий, необходимый при повторном выполнении чего-либо. Порядок заполнения перечней вопросов обычно не имеет значения, что удобно для параллельного осуществления нескольких действий, в отличие от блок-схем, мало подходящих для представления параллельных действий.

Формы (шаблоны), наряду с инструкциями по их выполнению, являются механизмом обеспечения повторяемости поддерживающих процессов. Формы — это очень действенный механизм для многократного повторяющегося сбора данных.

Использование таблиц этапов/ действий (табл. 4) — эффективный способ представления процедур. Они полезны, если особое значение имеет порядок действий. Например, если человек должен следить за использованием своего времени, начало наблюдения не должно быть последним этапом.

Таблица 4 - Пример таблицы этапов/действий

Номер	Этап
1	Начать отсчет времени (записать время начала действий)
2	Проверить наличие дефектов в выбранном продукте с помощью применения контрольных перечней вопросов, основанных на соответствующих данных
3	Зафиксировать дефекты в соответствующей форме для фиксации дефектов. Продолжать регистрировать дефекты, используя контрольный перечень, до полного завершения контроля всей продукции
4	Закончить следить за временем (записать время окончания работы). Подсчитать, сколько времени было затрачено на поиск и регистрацию дефектов, и записать общее время в форме для фиксации дефектов

Примеры успехов НАСА

Некоторые подразделения НАСА недавно успешно использовали передовой опыт документирования процессов (см. схему 2).

Схема 2 - Процесс обработки запросов потребителя

Цель: результативная и эффективная работа с запросами потребителей.
Критерии входа/начала:

• Получение запроса потребителя (телефонный звонок, голосовая почта, электронная почта, факс, внутриофисная почта и т.д.);
• Создание официального «листа запроса».

Критерии выхода/окончания:

• Запрос потребителя выполнен;
• Запрос отозван в ходе выработки способа выполнения запроса.

Группы технической поддержки процессов (ГТП) НАСА разрабатывают, измеряют и улучшают системы. Возрастание объемов, сложность и трудности применения документации по их процессам привело к решению использовать накопленный передовой опыт описания процессов.

Первой группой, которая опробовала передовой опыт описания процессов, была ГТП исследовательского центра "Лэнгли" в Хэмптоне. Эта команда решила улучшить процесс создания программных продуктов для центра. Хотя применяемая ранее процедура превосходила средние показатели по процессам центра, в ней был ряд слабых мест:

• смешение документов различного вида (политики, стандартов, процессов и процедур);
• нарушение принципа разбиения на части. Большинство людей могут запомнить лишь небольшие куски информации. Именно поэтому, например, 15- и 16-значные номера кредитных карт разбиты на меньшие части по четыре и пять цифр. Исходный процесс в Лэнгли содержал блок-схему из более 30 этапов и процедуру из более 25 этапов, что создавало трудности при использовании;
• описания процессов охватывали не все ключевые вопросы. Отсутствовал ответ на вопрос "когда?", а другие ответы были неполными.

В новой процедуре с применением передовых приемов документирования исчезли все эти слабые места. Для построения хороших диаграмм и разбиения блок-схемы на более мелкие части было применено моделирование процессов. Новые процессы ответили на все ключевые вопросы, а ответы на вопросы "как?" и "где?" были представлены всего на одной странице в виде документов для эксперта. На основе передового опыта в Лэнгли было разработано шесть новых и улучшенных процедур.

Недавно организованный Совет НАСА по инженерным вопросам и безопасности разработал около 30 процедур. Хотя они значительно превышали по своим характеристикам средние показатели, агентство поставило задачу сделать их короче для более удобного использования. Передовой опыт помог сотрудникам Совета сократить объем процедур на 60%, при этом техническое содержание не пострадало.

Центр информационной поддержки расположен в Силиконовой долине в Калифорнии. Один из работающих в Центре опытных менеджеров получил задание создать новый отдел поддержки потребителей. Он выяснил, что хотя для решения отдельных проблем существовал ряд процедур, общий процесс выполнения запросов потребителей не был документирован.

В Центре разработали новый документ, описывающий четыре процесса всего на 19 страницах (обычно описание аналогичных процессов занимает сотни страниц). Ответы на ключевые вопросы для каждого процесса были даны в виде диаграмм объемом в одну страницу в режиме экспертного использования, а для пользователей среднего уровня прилагалась еще страница текста вместе с руководящими указаниями, комментирующая диаграмму (табл. 5 и схема 2) — примеры, взятые из документации по процессам данного Центра.

Таблица 5 - Процесс обработки запросов потребителей

Номер этапа	Этапы процесса
7.1.1	Запрос Центру информационной поддержки Потребитель запрашивает услугу или сообщает о проблеме по телефону, по почте: голосовой, электронной, внутриофисной, по факсу или лично. Руководящие указания: потребитель может обращаться в Центр в рабочие часы, используя следующие варианты: - позвонить по телефону х4-2000 или по факсу х4-0063 - отправить электронное письмо по адресу: help@mail.arc.nasa.gov - прийти по адресу: здание 233, комната 195 - послать внутриофисное письмо по адресу: 233-17
7.1.2	Первый уровень: создание "листа запроса" - Персонал Центра использует сборник типовых "листов запросов", помогающий оформить официальный "лист запроса". - Персонал должен включить в "лист запроса" ясную, точную и полную информацию в соответствии с требованиями, установленными Соглашением об уровне услуг (СУУ)
7.1.3	Первый уровень: сортировка запроса Персонал Центра должен следовать СУУ и стандартной операционной процедуре (СОП) для корректного определения, куда следует направить "лист запроса". Руководящие указания: сортировка означает использование СУУ и СОП и применение профессиональной оценки либо для выполнения запроса, либо для правильного перенаправления запроса в другое место
7.1.4	Первый уровень: выполнен ли запрос? - Если да (вы можете выполнить запрос), переходите к этапу 7.1.6. - Если нет, то передайте запрос на второй уровень. Руководящие указания: - когда запрос направляется на второй уровень, ответственность за его рассмотрение сохраняется за Центром информационной поддержки; - руководитель Центра должен ежедневно проверять, какие "листы запроса", направленные на второй и третий уровни, исполняются более 8 ч, и доводить эту информацию до менеджеров второго и третьего уровней
7.1.5	Второй уровень: обработка запроса - Использование СУУ для выполнения запроса. - Обновление записей о ходе выполнения работы с добавлением ясной, точной и полной информации. - Изменение статуса выполнения запроса на "находится в стадии выполнения" или "пауза"
7.1.6	Первый уровень: выполнение запроса - Использование СУУ и СОП для выполнения запроса. - Обновление записей о ходе выполнения работы с добавлением ясной, точной и полной информации. - Изменение статуса выполнения запроса на "выполнено" Руководящие указания: убедитесь, что потребитель доволен результатом выполнения запроса
7.1.7	Второй уровень: выполнен ли запрос? - Если да (вы выполнили запрос), измените статус выполнения запроса на "выполнено". - Если нет, передайте запрос на третий уровень. Руководящие указания: убедитесь, что потребитель доволен результатом выполнения запроса
7.1.8	Третий уровень: выполнение запроса - Использование СУУ и СОП для выполнения запроса. - Обновление записей о ходе выполнения работы с добавлением ясной, корректной и полной информации. - Изменение статуса выполнения запроса на "выполнено" Руководящие указания: убедитесь, что потребитель доволен результатом выполнения запроса

Указанный менеджер недавно получил повышение. Новая документация по процессам сыграла ключевую роль в этом продвижении, потому что дала возможность новому менеджеру быстро освоить ключевой процесс отдела. Иногда опытный человек "застревает" на своей должности, потому что процесс не документирован, а он — единственный, кто хорошо его знает.

Отдел М в головном офисе НАСА. Отдел М — самый крупный в НАСА — разрабатывает и обеспечивает поддержание в рабочем состоянии космических челноков "Шаттл" и космических станций.

Главный инженер отдела М захотел провести анализ процесса и сопоставить его с другими, осуществляемыми в штаб-квартире НАСА. В ходе анализа было обнаружено, что этот процесс не документирован. Тогда главный инженер составил описание процесса на 19 страницах. Процесс был описан для пользователей среднего уровня в виде блок-схем, похожих на ту, что приведена на схеме 2, с использованием моделирования процесса. Ответы на ключевые вопросы были представлены диаграммой на одной странице в виде, предназначенном для использования экспертами, а для пользователей среднего уровня прилагалась страница текста с руководящими указаниями, комментирующими диаграмму.

Офис главного инженера. Офис главного инженера, расположенный в штаб-квартире НАСА, периодически получает задание написать и обновить документы и требования для всего НАСА. Один из исполнителей, занимающийся технической поддержкой программного обеспечения, получил задание создать на уровне агентства поли- тику и процедурные требования для программного обеспечения, разрабатываемого, поддерживаемого и покупаемого для НАСА.

Документ по новым процедурным требованиям был написан на 50 страницах и содержал около 140 требований. Это гораздо меньше, чем большинство аналогичных промышленных стандартов, которые содержат сотни страниц.

Требования содержали слово "должен" и были записаны в одно предложение. Частные рекомендации были добавлены в виде примечаний. Требования были поделены на части, относящиеся к передовым программным продуктам, каждый из которых был кратко описан.

В НАСА применялось восемь классов программного обеспечения, учитывающих тип обслуживаемой подсистемы и важность класса для успеха проекта. К каждому классу при помощи матрицы можно было предъявить до 140 требований. Для оценки программного обеспечения, играющего важную роль в реализации миссии проекта, использовались все 140 требований. Для оценки программного обеспечения более низкого класса использовалось меньше требований.

Некоторые извлеченные уроки

Вот уроки, которые извлекли в НАСА и во многих других организациях в процессе разработки процессов с использованием указанных методов:

• не смешивайте информацию из области политики, стандартов, процессов и процедур (например, в одном параграфе). Обозначьте различную информацию соответствующими заголовками и подумайте над тем, как она используется;
• делайте всю документацию максимально простой, но не упрощайте ее слишком, иначе она не будет работать. Следите за тем, чтобы документация оставалась краткой и точной, но будьте готовы к тому, что описание некоторых сложных процессов будет объемным; используйте хорошие иллюстрации (большинство людей предпочитают именно их), а слова применяйте для пояснения деталей;
• для каждого процесса или подпроцесса подготовьте ответы на ключевые вопросы на одной странице, используя диаграмму, такую как на схеме 2. Хорошая диаграмма процесса может заменить 20—25 страниц текста; моделирование процесса — хороший метод, особенно удобный в случае чрезвычайно сложных систем. Используйте моделирование процесса для составления хороших иллюстраций;
• составление схемы передачи информации — также хороший метод;
• используйте такие процедуры, как контрольные таблицы, формы и таблицы этапов/действий;
• разбивайте материал на секции и озаглавливайте разделы так, чтобы пользователь мог быстро найти информацию. Моделирование процессов и составление схемы передачи информации весьма помогают в выполнении этого принципа;
• учитывайте интересы всех групп пользователей: начинающих, среднего уровня и экспертов;
• "встройте" измерения в процесс. Не добавляйте измерения в качестве дополнительных действий уже после того, как процесс осуществлен;
• процесс должен быть "подогнан" под потребности каждой организации, каждого подразделения и каждого проекта.
• Разработка "хороших" процессов и процедур — кратких и удобных для использования — трудная задача, являющаяся вызовом времени. Для улучшения документации по процессу могут быть использованы многие методы. Методы, рассмотренные в статье, представляют собой набор нескольких прекрасных подходов, объединенных в "процесс по разработке процессов".

По материалам статьи Tim Olson and John C. Kelly,
Developing Best In Class Processes at NASA // Quality Progress, май 2005.

Подготовил Владимир АЛЕКСЕЕВ