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

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

Инструментальный опыт отвечает на вопрос "как это сделать?". Как настроить агента, построить workflow, подключить API, организовать работу с Jira или Confluence. Это полноценный и полезный опыт. Человек вполне может владеть конкретным инструментом значительно лучше специалиста с двадцатью годами работы в профессии.

Но вот полевой опыт устроен иначе.

Я бы сформулировал свою мысль так:

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

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

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

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

Но вот знать о существовании исключения и несколько раз в него врезаться - это разные вещи.

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

Формально два специалиста могут знать одно правило: "требования необходимо валидировать". Но один смотрит на документ и думает: "Выглядит нормально". Другой: "Что мы здесь могли пропустить?"

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

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

Наверное, отсюда растет значительная часть того, что мы называем профессиональной интуицией. Постепенно накапливается библиотека "да, но…", "работает, если…", "обычно, кроме…" и "здесь лучше уточнить".

Поэтому инструментальный и полевой опыт я бы вообще рассматривал как две разные координаты. Можно великолепно владеть современными средствами автоматизации и иметь небольшой опыт деятельности, которую пытаешься автоматизировать. Можно прекрасно понимать предметную работу и плохо знать конкретный инструмент.

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

Поэтому мне нравится еще одна формулировка, к которой я пришел:

Полевой опыт - это не столько накопление правильных решений, сколько накопление границ их применимости

А если значительная часть такого опыта формируется через столкновение с исключениями, возникает следующий вопрос: что произойдет, если ИИ начнет эти столкновения сглаживать?

Но об этом, наверное, уже отдельно в другом посте.