Один отрицательный график — три разные причины
Предположим, экономический симулятор показывает недостаток средств для выполнения обязательств. Что именно обнаружено?
Возможны как минимум три объяснения. Алгоритм неверно считает. Алгоритм считает правильно, но исходные бизнес-правила несовместимы. Или правила непротиворечивы, однако расчёт опирается на нереалистичные предположения о пользователях и доходах.
Внешне результат может выглядеть одинаково. Способ исправления — принципиально разный.
Причина №1. Дефект реализации
Признаки: неверное списание или начисление, повторный учёт одной операции, нарушение порядка событий, ошибки округления, некорректные ограничения, зависимость результата от непредусмотренного состояния.
Для диагностики подходят модульные тесты, контрольные примеры с ручным расчётом, проверка инвариантов и независимая сверка отдельных операций.
Например, если в замкнутом контуре ресурс может только переходить между участниками, его суммарное количество не должно самопроизвольно увеличиваться. Нарушение такого инварианта указывает на ошибку вычислений или неполноту описания источников эмиссии.
Исправление здесь техническое: устранить дефект, зафиксировать регрессионный тест и повторить затронутые расчёты.
Причина №2. Противоречие бизнес-правил
Вторая ситуация сложнее: каждый алгоритм работает правильно, но совместное действие правил не позволяет достичь финансовых целей.
Например, система обязана производить выплаты при условиях, в которых ожидаемые поступления их не покрывают. Никакая корректировка программного цикла не устранит такой разрыв без изменения предположений, источников финансирования или самих обязательств.
Здесь необходимо построить трассировку от результата к конкретным требованиям, показать воспроизводимый конфликт и предложить варианты изменения конструкции.
Критически важно не объявлять такое изменение «исправлением бага». Это новое бизнес-решение.
Причина №3. Неподтверждённые предположения
Третья ситуация: модель корректно реализует непротиворечивые правила, но параметры выбраны без достаточных оснований.
Например, прогноз доходов основан на ожидаемой конверсии, которая ещё не подтверждена фактической статистикой. Или отток пользователей задан постоянным, хотя в реальном продукте он может существенно зависеть от времени и поведения отдельных групп.
Такие проблемы нельзя устранить одним тестом. Нужны данные, интервалы неопределённости, альтернативные сценарии и анализ чувствительности.
Если фактических данных пока нет, правильный вывод — «результат условен», а не «модель доказала прибыльность».
Диагностическая последовательность
Практически я начинаю с проверки происхождения результата: какая версия движка использовалась, какая конфигурация загружена, какие входные данные применялись и можно ли повторить запуск.
Затем проверяю контрольные операции и инварианты. Если здесь есть дефекты, экономические выводы откладываются до их исправления.
После этого сопоставляю реализованные правила с актуальной спецификацией. Расхождения относятся к реализации; противоречия внутри спецификации — к требованиям.
Только затем анализирую реалистичность предположений и устойчивость выводов при изменении параметров.
Эта последовательность помогает не тратить время на обсуждение бизнес-модели, пока сам вычислительный инструмент не прошёл необходимые проверки.
Зачем нужна независимая проверка
Автор симулятора хорошо знает его внутреннюю логику, но может не заметить собственное допущение. Независимая проверка полезна тем, что рассматривает результат как утверждение, требующее доказательств.
Проверяются не только итоговые числа, но и входные данные, версии, критерии, тестовые артефакты и ограничения методики.
Однако и независимый технический PASS нельзя интерпретировать шире, чем позволяет его предмет. Он подтверждает определённые свойства расчётов и процесса, а не будущую коммерческую успешность продукта.
Пример из исследования FIGHTEX
В серии A6.3-R на движке 0.8.1 проведено 72 повторных запуска. Технический статус исследования — PASS WITH ACCEPTED LIMITATIONS. Экономический статус — NO QUALIFIED CANDIDATES.
Эти результаты не противоречат друг другу. Первый характеризует техническую проверку исследуемых расчётов с оговорёнными ограничениями. Второй сообщает, что проверенные варианты не удовлетворили установленным экономическим критериям.
Из этого нельзя автоматически заключить, что все возможные варианты экономики непригодны. Но и нельзя объявить экономическую задачу решённой только потому, что симулятор работает корректно.
Как оформлять итоговый вывод
Полезный отчёт должен разделять четыре элемента: что проверялось, что установлено, что осталось неизвестным и какое решение предлагается.
Например: «Для зафиксированных параметров и исследованных механизмов подходящие варианты не найдены; технические проверки пройдены с принятыми ограничениями; влияние альтернативной экономической конструкции ещё не оценено».
Такая формулировка менее эффектна, чем «модель работает» или «проект убыточен», зато существенно точнее.
Вывод
Экономический симулятор — измерительный инструмент. Чтобы доверять его выводам, необходимо проверить и сам инструмент, и правила, которые он воспроизводит, и предположения, на которых основаны расчёты.
Только разделение ошибок кода, требований и исходных гипотез позволяет выбрать правильное следующее действие — исправление, пересмотр правил или сбор дополнительных данных.
Связанные материалы: Кейс FIGHTEX · Услуга аудита токеномики
Частые вопросы
Как понять, ошибается симулятор или бизнес-модель?
Сначала проверить воспроизводимость, контрольные операции и инварианты. Затем сверить правила со спецификацией и оценить исходные предположения и чувствительность результата.
Доказывает ли технический PASS прибыльность продукта?
Нет. Он подтверждает только проверенные технические свойства с указанными ограничениями. Экономические критерии и бизнес-гипотезы оцениваются отдельно.
Что делать, если нет фактических данных о пользователях?
Указать неопределённость, использовать альтернативные сценарии и анализ чувствительности. Полученный финансовый результат остаётся условным.