Как мы исправляли не то или как бизнес порой ошибается в понимании проблем

Есть поведение системы, которое не совпадает с ожиданиями, и почти сразу возникает решение, как это исправить. В моменте это кажется достаточным: видно, где "не так", значит достаточно внести правку.

Сейчас я стараюсь в таких ситуациях не спешить с выводами, а для начала погрузиться в "почему это случилось".

Один простой кейс стал показательным.

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

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

Когда система оказалась в реальной среде, поведение изменилось.

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

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

Со временем взгляд на такие вещи меняется. Речь уже не о том, чтобы быстрее устранить конкретное поведение. Гораздо важнее понять, за счёт чего оно вообще возникло.

Потому что именно здесь чаще всего и появляется системная ошибка: решение принимается на неверной картине происходящего.

И в этот момент возникает риск, который почти не виден.

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

В итоге можно долго «чинить» отдельные проявления и не замечать, что сами принципы работы остаются непроверенными.

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