Как NASA выбирает из трёх вариантов: трейд-стади для процессных решений

Компания выбирает, как перестроить процесс обработки заявок. Варианта три: нанять людей, автоматизировать маршрутизацию, отдать часть на аутсорс. Как принимается решение обычно: час спора на совещании, у каждого варианта свой лоббист, побеждает тот, кто убедительнее говорит или выше сидит. Через год никто не может восстановить, почему выбрали именно это, - и на ошибке никто не учится.

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

Критерии - до вариантов, а не после

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

Оценки: числа вместо прилагательных

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

Проверка робастности: держится ли победитель

Перед тем как объявить победителя, хендбук отводит отдельный шаг под анализ чувствительности: держится ли ранжирование, если входные оценки пошевелить в разумных пределах. Если от небольшого сдвига одной оценки победитель меняется - выбор неустойчив. Честных выхода два. Либо уточнить именно ту оценку, от которой всё зависит. Либо признать варианты равными и выбирать по соображениям вне матрицы - срок, команда, аппетит к риску, - открыто, а не прятать выбор за перевесом в сотые доли балла. Это та же логика чувствительности, про которую мы писали в NIST-серии про замеры: уточняйте только то, что меняет решение.

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

Итоги серии

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

Чек-лист

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

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