Когда ошибка находится в техническом задании, а не в коде

Система работает правильно. Почему результат неправильный?

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

Это не обязательно ошибка разработчика. Возможно, программа точно исполняет противоречивые требования.

В финтехе и проектах с внутренней экономикой такое различие принципиально. Аудит реализации отвечает на вопрос «правильно ли работает система?». Аудит требований — на другой: «может ли система с такими правилами достичь заявленной цели?».

Как возникают противоречия

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

Например, бизнес хочет одновременно обеспечить минимальные выплаты, сохранить широкие бесплатные возможности и достичь самоокупаемости при ограниченной доле платящих пользователей. Реализовать эти правила технически возможно. Обеспечить их финансовую совместимость — отдельная задача.

Ещё одна распространённая проблема — скрытые допущения. В ТЗ указана выручка, но не объяснено, на каких данных основана конверсия. Предусмотрены регулярные расходы, но неясно, какие из них действительно операционные, а какие относятся к разработке. Заданы ограничения, но не описано, что делать при их конфликте.

Три уровня проверки

В своей работе я разделяю три независимых уровня.

Положительный результат на одном уровне не закрывает остальные.

Почему нельзя «починить» экономику незаметной правкой параметров

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

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

Если изменение нарушает принципиальное условие заказчика, его нельзя выдавать за оптимизацию в рамках прежнего ТЗ.

Как документировать обнаруженное противоречие

Практически полезная запись содержит исходные требования и их версии, наблюдаемый конфликт, воспроизводимый пример, используемые предположения, последствия и варианты решения. Отдельно фиксируется, что подтверждено вычислениями, а что остаётся гипотезой.

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

Когда следует остановить оптимизацию

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

В такой точке разумнее зафиксировать отрицательный результат, пределы исследования и предложить пересмотр конструкции. Это не отказ от задачи, а смена уровня принятия решения: от настройки механизма к пересмотру требований.

Что получает заказчик

Полезный результат аудита — не список замечаний ради списка. Это карта решений: какие требования совместимы, какие конфликтуют, какие показатели зависят от неподтверждённых предположений и какие изменения требуют согласования.

В работе над экономическими моделями особенно важно не смешивать технический успех с бизнес-успехом. Исправный симулятор может добросовестно показывать, что предложенная конструкция не проходит заданные критерии.

Связанные материалы: Услуга аудита токеномики · Кейс экономического симулятора FIGHTEX

Частые вопросы

Чем аудит требований отличается от проверки кода?

Проверка кода определяет, верно ли реализованы правила. Аудит требований выясняет, полны ли сами правила и совместимы ли они с целями продукта.

Можно ли изменить коэффициенты ради положительного результата?

Можно исследовать новые параметры, но затронутые требования, допущения и критерии приёмки необходимо явно зафиксировать и согласовать.

Что делать, если требования противоречат друг другу?

Зафиксировать конфликт и воспроизводимый пример, описать последствия и варианты решения, затем передать изменение на согласование владельцу продукта.