Регламент, который нельзя проверить, — не регламент: пять фильтров NASA для требований

Откройте любой корпоративный регламент и найдите фразы вроде: «заявки рассматриваются оперативно», «обеспечить качественную проверку», «минимизировать сроки согласования». Звучит солидно. Проверить невозможно: ни один аудитор не скажет, выполняется пункт или нет. А значит, пункт не управляет ничем: каждый читает его по-своему, а в споре побеждает не регламент, а тот, кто громче.

В NASA такой текст завернули бы на первой же вычитке. Требования - центральный жанр системной инженерии: хендбук проверяет каждое по целым чек-листам качества, прежде чем оно попадёт в утверждённую версию требований - baseline. Мы свели эти проверки к пяти фильтрам. Регламент процесса - это те же требования, только к людям и срокам, а не к железу, и фильтры переносятся почти дословно. Это третья статья серии «Процессы по-инженерному» - после разбора о том, почему ошибка в проекте дешевле в сто раз.

Пять фильтров: от формулировки до способа проверки

1. Форма. Требование - это одно утверждение с явным субъектом: кто и что должен. Не «обеспечивается своевременное рассмотрение» (кем? чего? когда?), а «юрист берёт заявку в работу в течение одного рабочего дня».
2. Прослеживаемость. У каждого пункта есть родитель - цель или риск, ради которого он существует. Хендбук предлагает жёсткую развилку: пункт без родителя - это либо дыра в самой трассировке, либо gold-plating, золочение, и тогда пункт убирают. В переводе на жизнь регламентов золочение - это «кто-то когда-то вписал, все боятся убрать». В живых регламентах таких пунктов на удивление много: согласования, которые никто не читает, отчёты, которые никто не открывает, - и каждый ежедневно съедает чьё-то время.
3. Согласие заинтересованных. Те, кого пункт касается, подтвердили, что он решает их задачу, - это та самая валидация из прошлой статьи серии, применённая к каждому пункту, а не к продукту целиком. Регламент, написанный процессным офисом без исполнителей, проваливает этот фильтр целиком.
4. Выполнимость. Требование достижимо при текущих ресурсах. «Каждая заявка проверяется в течение часа» при двух юристах и сорока заявках в день - не требование, а пожелание: даже по полчаса чистой работы на заявку выходит двадцать человеко-часов при шестнадцати доступных, арифметика не сходится. Выполнимость нормативов проверяют расчётом до подписания. Именно для этого есть симуляция: она показывает, какая доля заявок впишется в норматив при заданном штате.
5. Верифицируемость. Существует способ проверить выполнение: по логам системы, по выборочной проверке, по метрике. Если способа нет - пункт переписывается или удаляется. «Минимизировать сроки» непроверяемо. «95% согласований укладываются в пять рабочих дней» - проверяемо одним запросом к данным.

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

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

Размытость - первая ошибка требований. Вторая - противоположная: требование жёстче, чем нужно делу. В расширенном руководстве к хендбуку есть пример: если зарядка батареи за 12 часов устраивает миссию, требование «за 3 часа» вырезает целые варианты конструкции без пользы для дела. Лекарство - задавать два значения: порог (минимум, без которого процесс не имеет смысла) и цель (желаемый уровень). Между ними - пространство для торга и проектирования. Для SLA это звучит так: порог - 95% согласований за пять дней (иначе теряем клиентов), цель - за три дня (конкурентное преимущество). Сколько стоит путь от порога к цели - считают сценариями в симуляторе.

Метаданные: паспорт каждого пункта

Хендбук настаивает: метаданные требования записываются в момент написания, а не задним числом - обоснование (зачем оно), способ проверки, владелец. Для регламентов это означает: у каждого пункта есть ответ на вопросы «зачем он», «как проверим» и «кто отвечает». Пункт, у которого нет ответа на «зачем», через год невозможно ни обновить, ни удалить: никто не помнит, что сломается. Так регламенты и превращаются в археологические слои, где ничего нельзя тронуть. В Stormbpmn эта дисциплина частично встроена: у схемы процесса виден владелец, через согласование процессов фиксируется, кто и когда подтвердил версию - то самое «согласие заинтересованных» из третьего фильтра, - а автоматическая проверка правил оформления при каждом сохранении держит в тонусе форму, первый фильтр.

Чек-лист

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

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