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

Процесс согласования описан в регламенте версии 3.2. Но юристы работают по версии 2.8, потому что так привыкли. В отделе закупок живёт распечатка с рукописными пометками предыдущего руководителя. В почте ходит вордовский файл «Регламент_финал_правки_Иванова_новый(2).docx». Какая версия настоящая? Никакая. Инженеры зовут это потерей контроля конфигурации: никто больше не знает, какая версия действует и совпадает ли она с тем, как реально работают люди. Просто пока никто не заплатил за это заметную цену.

NASA платила. Комиссия по гибели шаттла «Колумбия», разбирая программу, наткнулась на чертежи, годами не совпадавшие с реальной конструкцией: к причинам катастрофы она это не отнесла, но вынесла в отчёт отдельным списком серьёзных проблем. А спутник NOAA N-Prime упал с поворотной тележки прямо в цехе - ремонт обошёлся в 135 миллионов долларов. Команда работала по процедуре, исчерканной правками так, что та требовала прыжков от шага к шагу, и в таком виде никогда прежде не выполнялась - при этом все положенные согласования она прошла. Поэтому в хендбуке NASA управление конфигурацией - отдельная дисциплина с жёсткими правилами. Это пятая статья серии «Процессы по-инженерному».

Три опоры контроля конфигурации

Функций контроля конфигурации у хендбука пять; для регламентов критичны три.

Базовая версия (baseline). В каждый момент существует ровно одна утверждённая версия - и она доступна всем, кого касается. Не «где-то в папке у методолога», а в известном всем месте. Если исполнитель не может за минуту открыть действующую версию своего процесса - базовой версии у вас нет.

Контроль изменений. Любое изменение базовой версии проходит через формальный запрос с оценкой влияния и утверждением теми, кого оно касается. Звучит бюрократично - но альтернатива ещё хуже: процесс, который меняется письмом «коллеги, с понедельника делаем так», через полгода не описан нигде. Важная деталь из хендбука: комитету по изменениям нужно реальное время на оценку; если сроки сжаты до невозможных - получаются либо штампованные согласования, либо скрытые изменения в обход. И ещё одна: если руководство объявляет, что особых мнений в протоколе не будет, - контроль уже сломан. От себя добавим бытовой родственник этого флага: протоколы, где из раза в раз «возражений не зафиксировано», обычно означают, что никто не читал.

Соответствие факта документу (аудит). Периодически сверяется, что реальная работа соответствует утверждённой версии. Расхождение - не повод для наказания, а сигнал: либо документ устарел и его надо обновить через нормальный цикл, либо практика уехала куда-то, куда не следовало. И оговорка про масштаб: в команде на десять человек «комитет» - это владелец регламента и пятнадцать минут; суть не в заседаниях, а в том, что изменение оставляет след и о нём узнают все, кого оно касается.

Рукописные правки: временная мера, а не способ жизни

У NASA есть понятие redline - правка поверх утверждённого документа. Редлайны разрешены для случаев, когда формальный цикл остановил бы работу, но живут по своей контролируемой дисциплине: как минимум с утверждением ответственным за железо и службой качества. Комиссия по NOAA N-Prime назвала правки одной из главных причин аварии: процедура была исчеркана настолько, что по ней в таком виде никто никогда не работал, - и команда пропустила проверку болтов крепления, которые раньше снял другой экипаж. Отсюда два урока для регламентов: правка ограничена по объёму, а внесение в базовую версию - не «когда-нибудь», а по заранее оговорённому порядку. Процессный эквивалент - регламент, обросший устными исключениями: «вообще-то так, но для клиентов А и Б иначе, а по пятницам спроси у Маши». Каждое устное исключение - невнесённый redline. Новый сотрудник работает по написанному - и ошибается, потому что написанное давно разошлось с практикой.

Красные флаги потери контроля - версия для процессов

• На вопрос «где актуальная версия процесса» разные люди называют разные места.
• Схема процесса и текстовый регламент противоречат друг другу, и оба считаются действующими.
• Изменения вносятся письмами и устными договорённостями, без следа в документе.
• Боты и интеграции работают по какой-то из прошлых версий - по какой именно, никто не помнит.
• Обучение новичков идёт «от наставника», потому что документам никто не верит.

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

Как это устроено в Stormbpmn

Именно эту дисциплину мы строили в продукте: схема процесса живёт в одном месте с историей версий, каждая версия проходит через согласование с фиксацией, кто и когда утвердил, а в карточке процесса видно владельца и статус. Распечатка с рукописными пометками в этой конструкции перестаёт быть версией: актуальная всегда одна и всегда по известному адресу. А почему процессной модели при этом нужна ещё и оргструктура - есть отдельный разбор про связку процессов и ролей.

Чек-лист

1. Проведите опрос по трём ключевым процессам: пусть пять человек из разных отделов пришлют ссылку на действующую версию. Сколько разных ссылок пришло - таков масштаб проблемы.
2. Заведите единое место правды и правило: всё, чего там нет, - не действует. Для срочных правок - короткий отдельный порядок с обязательным внесением в базовую версию.
3. Устные исключения инвентаризируйте раз в квартал: либо вносите в базовую версию, либо отменяйте.
4. Изменения - только через согласование с теми, кого касается, и с реальным сроком на оценку.
5. Раз в полгода - аудит соответствия: работают ли люди так, как написано. Каждое расхождение разбирайте по развилке «обновить документ или вернуть практику».

Серия «Процессы по-инженерному» основана на NASA Systems Engineering Handbook (SP-2016-6105) и начинается со статьи о том, почему ошибка в проекте в сто раз дешевле ошибки после запуска и расширенном руководстве к нему. Предыдущая статья - про схемы счастливого пути. Следующая - про то, почему процессы ломаются на стыках отделов, даже когда каждый отдел работает идеально.