Команда с ИИ: что меняется в работе руководителя — Дмитрий Твердохлебов

Дмитрий начинает с ограничения, которое видит у крупных заказчиков: стремления сохранить всю информацию во внутреннем контуре и повторить там возможности облачных моделей. По его оценке, это часто тормозит внедрение сильнее технической сложности. Он сразу оговаривает смещение собственной выборки в сторону больших корпораций; у небольшого бизнеса наблюдает больше гибкости. Omnius.team выбирает задачи, в которых данные движутся снаружи внутрь: собирает и анализирует открытую информацию, затем передаёт полезный результат заказчику. Так можно показать пользу без первоначального доступа к чувствительным внутренним системам. Александр уточняет важное ограничение: отдельный успешный эксперимент ещё не означает изменения основного бизнеса. Дмитрий отвечает, что пилот должен дойти до людей, принимающих решения. Когда они видят работающий результат, появляются поддержка, ресурсы и возможность обсуждать дальнейшие согласования. Затем решение готовят к внутреннему внедрению: описывают интерфейсы, пишут документацию, сопровождают интеграцию. Агентство может оставаться в роли архитектурного надзора, а не выполнять весь проект самостоятельно.

Три примера показывают разные задачи для такого входа. Для нефтяной компании команда отслеживает изменения налогового законодательства в странах присутствия: собирает сведения из открытых источников и платных баз, выделяет важное и готовит подборки для финансовых специалистов. Второй инструмент помогает создавать рекламу в Telegram: анализирует бизнес и тексты канала, оценивает вероятность прохождения модерации и предлагает формулировки. Гость не раскрывает устойчивую численную оценку бизнес-эффекта, поэтому объявлять конкретный прирост конверсии было бы неверно. Третий проект ищет варианты замены строительных материалов. Шестнадцать агентов рассматривают инженерные, экономические, юридические и другие ограничения; дополнительные критики оспаривают промежуточные выводы. Дмитрий сопоставляет 30–40 минут работы системы с месяцем работы двух-трёх аналитиков, но это его оценка трудозатрат, не независимое измерение и не доказанная дополнительная выручка. Для руководителя эти примеры различаются не названием модели, а выбранной задачей, доступными данными и способом показать ценность заказчику.

В агентстве девять человек, и Дмитрий намеренно ограничивает рост: к концу года хочет нанять не более десяти. Первых сотрудников он выбирает как людей, определяющих будущую культуру. Общие направления распределяются между самостоятельными специалистами без подробного ежедневного контроля. Связность поддерживает внутренний помощник Omnius: ему доступны рабочие календари, почта и записи встреч с оговорёнными ограничениями для чувствительных тем. Он восстанавливает договорённости, напоминает об обещаниях и помогает понять, кто чего ждёт. Задачи в Linear появляются как отражение обсуждений; смысл системы — уменьшить зависимость от памяти основателя. При этом гость оценивает готовность собственной организации лишь на три-четыре балла из десяти относительно желаемого состояния. Польза уже есть, но завершённой модели управления он не предъявляет. Масштабирование на десятки или сотни сотрудников остаётся ожиданием: Дмитрий предполагает, что общий контекст станет ещё нужнее, когда личные связи перестанут обеспечивать согласованность.

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

В найме Дмитрий выделяет три признака. Первый — человек уже пробовал решать собственные задачи с генеративным ИИ, даже если эксперимент оказался неудачным. Гостю важнее этот опыт, чем убедительные формулировки резюме; расходы на инструменты он упоминает как личный сигнал вовлечённости, а не универсальный критерий квалификации. Второй — способность ясно выразить мысль, описать проблему, ожидаемый результат и последовательность действий. Системное и критическое мышление помогают не принимать ответ модели на веру. Третий — мотивация делать полезные вещи и совпадение с культурой команды. Дмитрий не осуждает людей, ориентированных преимущественно на деньги, но считает такую мотивацию менее подходящей для своего агентства. Технические навыки можно развить, тогда как принципиальное несовпадение в отношении к людям и работе исправить сложнее. Это критерии конкретного основателя, позволяющие осознанно выбирать коллег; они не заменяют проверку компетенций для определённой должности.

Проект talant.club предлагает отдельную модель для заказов малого и среднего бизнеса, которым дорого работать с бутиковым агентством. Площадка собирает проверенных ИИ-инженеров, помогает им обмениваться знаниями и превращает расплывчатую потребность клиента в техническую спецификацию. Несколько команд могут предложить готовые варианты решения. Первичную проверку соответствия выполняет ИИ, а окончательный выбор делает заказчик по своим критериям: скорости, точности, удобству или оформлению. По описанию Дмитрия, победившая команда получает половину бюджета, остальная сумма после удержания небольшой доли на работу площадки распределяется между участниками. На момент разговора в сообществе пять человек; это ранняя инициатива, а не доказанная массовая модель. Идея выросла из опыта сервисных площадок YouDo и Яндекс.Услуги: когда создание цифрового решения дешевеет, конкурировать можно готовым результатом вместо обещания. При этом разговор не раскрывает порядок последующей поддержки. Финальный совет руководителю тоже практический: самостоятельно решить одну небольшую задачу с ИИ и получить опыт, на котором можно строить дальнейшие изменения.