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

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

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

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

Как бы, например, выглядело идеальное техническое задание. Это документ, в котором учтены все возможные случаи в работе пользователей и действия алгоритма в ответ на них. Указано абсолютно всё что делать и можно и чего нельзя. Да, с таким ТЗ можно сделать идеальный продукт. Вот только проблема в том, что таких ТЗ не существует, это "сферический конь в вакууме".

В реальности же, проектирование и далее разработка, идут итерационным путём до достижения некоего приемлемого состояния. Представим, к примеру, процесс обработки обращений. Человек описывает цель: быстро восстановить работу клиента. Модель предлагает классифицировать обращения по последствиям и сразу показывать обходной путь для критичных случаев. Специалист добавляет то, чего не видно из формального описания: некоторые заявки нельзя закрывать без подтверждения клиента, а часть проблем требует участия другой службы. Руководитель определяет, какие сроки и риски приемлемы.

Так появляется не «автоматизация отдела», а новый способ совместно проектировать работу:

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

Зрелое использование LLM начинается там, где заканчивается вопрос «что ещё можно автоматизировать?». На его месте появляется другой: «как должен быть устроен процесс, если мы проектируем его сегодня - с учётом человеческого опыта, ограничений и возможностей модели?»

Поэтому ТЗ (как документ) будущего должно описывать не только последовательность действий. В нём нужны цель операции, критичные ограничения, признаки ошибки, правила ручной проверки и условия пересмотра. Иначе новый инструмент, разрабатываемый по "чётко сформулированному, но по старым принципам ТЗ" снова со временем превратится в набор привычных шагов, смысл которых никто не проверяет.

А что изменится в вашей работе, если LLM станет не только исполнителем задач, но и постоянным собеседником при проектировании процессов?