Построили правильно - не значит построили правильное: два вопроса к любому внедрению

Проект закрыт успешно. Новый процесс согласования запущен точно по спецификации: все пункты ТЗ закрыты, роли назначены, интеграции работают. Акт подписан. А через полгода на разборе жалоб выясняется: срочные заявки согласуют в почте и мессенджерах, а в систему заносят задним числом - в процессе для срочных случаев просто нет дороги. Метрики при этом зелёные. Процесс построен правильно. Задачу он не решает.

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

Как процесс проходит верификацию и проваливает валидацию

Процессные проекты почти всегда принимают только по верификации: сверили с ТЗ, подписали акт. А валидационные вопросы остаются незаданными:

• Стало ли клиенту быстрее - или мы просто переложили ожидание в другой статус?
• Пользуются ли люди процессом? Согласования в почте и мессенджерах говорят, что нет.
• Та ли нагрузка была записана в требованиях - или спецификация писалась под демо-объёмы, которых в жизни не бывает?

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

Четыре метода проверки - и где среди них симуляция

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

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

Правило остановки: расхождение - это развилка, а не помеха

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

Валидация без операторов не считается

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

Чек-лист

1. В каждом проекте изменения пропишите два отдельных критерия приёмки: верификационный (соответствует спецификации) и валидационный (бизнес-метрика улучшилась в реальной эксплуатации).
2. Базовое значение бизнес-метрики зафиксируйте до запуска - иначе через квартал сравнивать будет не с чем. Верификацию закрывайте актом на запуске, а валидацию оформите отдельным этапом опытной эксплуатации на один-три месяца с заранее названным порогом метрики.
3. До пилота прогоните конструкцию анализом - симуляцией на пиковой нагрузке, а не на средней.
4. При плохих результатах пилота сначала задайте вопрос: сломана конструкция или сама проверка?
5. В валидации участвуют реальные исполнители, а не авторы процесса.

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