Программисты делают бизнес

Где AI приносит пользу бизнесу быстрее всего?

Именно в повторяющихся сценариях с понятной логикой внедрение AI даёт измеримый результат за короткое время. 

В новой статье разбираем примеры решений, которые помогли сократить затраты, ускорить работу и разгрузить сотрудников:

🌟AI-база знаний для Альфа-Банка ускорила поиск данных в 20 раз
🌟Чат-бот для банка обрабатывает 97% запросов за 3 секунды
🌟Ассистент для строительной компании помог увеличить конверсию в лид с 38% до 55%

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

Как меняется работа аналитика в AI SDLC

В прошлом посте про AI SDLC я писал, что основной прирост эффективности даст не автоматизация отдельных задач, а перестройка всего конвейера разработки.

Продолжу эту мысль на примере работы аналитика.

Недостаточно сохранить прежний процесс и просто ускорить его с помощью Cursor, Claude или другого инструмента. Так делают все.

Преимущество появится там, где AI меняет не скорость отдельных действий, а сам порядок работы.

Нужно смотреть на каждый этап и спрашивать: а должен ли я вообще здесь включаться?

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

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

То есть не читать ничего сырого, а работать уже с готовой версией.

Этот эффект будет усиливаться с каждой новой моделью: они становятся умнее и получают больше контекста.

Возьмём спецификацию. Здесь есть два сценария.

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

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

Раньше первый сценарий считался правильным, потому что переделывать было дорого. Сейчас стоимость итерации снижается.

Если человек продолжает тратить силы там, где можно сначала получить черновик от модели, он просто теряет время.

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

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

#максим_павлов 😀 #менеджментkts

❗️Осторожно: мошенники подделывают вакансии KTS

Они предлагают работу, а затем просят установить программу, которая крадёт данные.

К KTS эти предложения отношения не имеют. Установка подозрительных программ в тестовое задание не входит. Мы не просим кандидатов передавать пароли, коды из СМС, данные банковских карт или доступ к устройству.

А вот настоящие вакансии у нас действительно есть: смотрите их на hh.ru.
Если вы не нашли подходящую, не грустите и расскажите о своих талантах напрямую нашему HR-отделу: @kts_hr_talent_bot.

Берегите данные, откликайтесь или перешлите этот пост тем, кто сейчас ищет работу.

От выполнения задач к инжинирингу конвейера разработки

Есть стандартный подход к автоматизации: сначала ты делал что-то руками, теперь используешь инструмент.

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

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

Большая аналитическая часть при этом остаётся за человеком. Нейросеть не может самостоятельно обсудить задачу с заказчиком, собрать требования и проверить все детали. Для анализа и коммуникации по-прежнему нужны люди.

Но после этого должны включаться правила, контрольные точки и автоматические проверки.

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

Разберём это на примере идеализированной технической поддержки.

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

При этом клиент уже в негативе: у него что-то не работает.

Скорость обработки обращений сильно влияет на впечатление от подрядчика. Для команды это может быть небольшой баг. Для клиента он критичен: останавливает работу или не даёт выполнить нужное действие.

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

Затем система исследует код, анализирует проблему, формирует баг-репорт и предлагает план исправления.

На следующем этапе AI-агент вносит изменения в отдельной ветке, чтобы не затронуть основной код, и запускает автоматические тесты. Например, с помощью Playwright открывает браузер и проходит нужный путь.

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

Если через час или несколько часов заказчик получает протестированный фикс, готовый к выпуску, это впечатляет. К такому уровню сервиса быстро привыкают.

Это и есть идеализированный AI SDLC: не отдельный инструмент, а полноценный конвейер разработки.

#максим_павлов 😀 #менеджментkts

ИИ вне разработки

В прошлых постах много писал про разработку. А что поменялось в процессах других отделов?

Сегодня поговорим про эволюцию отдела продаж. За последние несколько месяцев было попробовано много инструментов.
Начиналось все, как, думаю, и у всех, с того, что сейлзы начали использовать нейро-инструменты. Например, начали обсуждать с ChatGPT свои сделки.

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

Когда сейлзы начали использовать ИИ-инструменты, это, как и в случае с разработкой, начало ускорять работу и делать ее местами более качественной за единицу времени. Но это все еще не кратное ускорение / улучшение.

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

Соответственно, чтобы выходить на новый уровень качества/скорости, нужно усиливать эту капитализацию с ИИ.
Все перечисленные пункты на самом деле раскладываются на 2 задачи:
— Накопление знаний (четкая структура, быстрый и простой доступ)
— Типовые кросс-командные решения

Поэтому первое, что мы сделали, — ИИ-агента с поиском по нашим решениям. Позволяет быстрее ориентироваться в продуктах и кейсах (которых, на минуточку, больше нескольких сотен, и никто не знает про все). А второе — агент, который позволяет оценивать уровень качества КП по оформлению и принятым практикам. Таким образом, регламенты и подходы становятся не просто рекомендациями (которые на практике быстро деградируют), а правилами, заложенными в систему.

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

И тут становится понятно, что эти проблемы давно решены в разработке:
— Экспертиза, знания и правила — это скиллы для ИИ-агентов
— Общее хранилище данных — репозитории, где работают все инженеры (вместе с им-агентами) в одном контексте
— Генерация артефактов с кодинговыми агентами работает лучше всяких чатов с gpt.

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

Мы сделали один общий git-репозиторий для продаж. Он содержит:
— Схему данных о клиентах и их заявках для накопления всех артефактов о заявках
— MCP CRMки
— Набор скиллов для работы с кодинговыми агентами

Процесс выглядит так:
При поступлении новой заявки и начале работы над ней сейлз получает данные о заявке из CRM с помощью скилла. Другой скилл делает предварительный анализ клиента и заявки. Сейлз может поразгонять его в глубину вместе с агентом. Дальше может быть первичный созвон с клиентом. Запись попадает в папку лида в репозитории и агент может использовать ее для помощи в генерации первичного решения. Аналогично с записью брейншторма команды по генерации решения. На основе собранных артефактов сейлз может составить план КП. А партнер или архитектор решения сразу получает весь набор артефактов, просто спуллив апдейт репозитория.

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

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

#сергей_чернобровкин 👨

Стримы, как зона ответственности

Глядя на предыдущий пост, становится понятно, что зона ответственности должна быть в размере объекта поставки специалиста — что «под ключ» может сделать специалист.

Если атомарной задачей может стать фича целиком, то это и есть новый объект поставки.

И специалист тем ценнее, чем больший объем этого объекта он может сделать «под ключ»: условно маленькую фичу или большую, комплексную или простую, с простым пайплайном или сложным.

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

В мире, где опытный специалист может с клодом сделать фичу так, как он хочет, быстро и почти автономно (реальный кейс нашего архитектора — 39-часовой околоавтономный рефакторинг проекта  с fable 5), этому специалисту просто не хочется дробить задачу и объяснять детали младшим специалистам, а потом за ними проверять, и все это с большой задержкой (часы / дни) вместо минут у клода.

Но у этого специалиста все еще остается ограничение — контекстная вместимость и приоритеты. Он не может удерживать в голове 10 разнородных треков. Даже 3 уже сложно. А значит ценно для такого старшего специалиста полностью передать один из этих контекстов на младших специалистов. То есть, чтобы они взяли «под ключ» какой-то из стримов. Сложность этого стрима очевидно должна быть соразмерна грейду специалиста. Как и размер объектов поставки в рамках этого стрима.

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

Эти мета-скиллы всегда были важны, но часто по моим наблюдениям (не только нашей компании) им придавали меньшее значение, чем технике.

Сейчас значение этих скиллов будет расти вместе с упрощением / ускорением разработки.

Поэтому мы плавно меняем матрицу и фокусируемся на них уже сейчас в развитии и обучении.

#сергей_чернобровкин 👨

Монорепы на пути к AI SDLC

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

Следующий шаг «сближения» данных и сбора общего контекста для разработчиков и агентов — создание монорепы / общего воркспейса с несколькими репозиториями у проекта.

Классическая картинка выглядит так: есть репа с бекендом, есть с фронтендом, и еще несколько вспомогательных реп на какие-то смежные сервисы.

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

Это очевидная точка оптимизации на пути к AI SDLC. Если я могу (утрированно) сгенерить код фронта за час, но мне нужно ждать целый день, чтобы его передать следующему спецу, который сделает бек, а потом это все сливать в стейдж, чтобы отдельно интеграционно потестит, то я теряю уйму времени на передаче контекста и отслеживание статусов атомарных задачек и контроля их синхронизации. Никаким кратным ускорением не пахнет.

Соответственно, возможность, которую хочется использовать в AI SDLC — атомарной задачей должна стать сама фича, а не ее кусочки. А для этого мне нужно в одном месте собирать все артефакты: от бизнес-требований (см предыдущий пост) до автотестов. Это место — в идеале монорепа. Тогда я смогу одним коммитом вмержить целый блок функционала: и актуальные бизнес-требования, и техническую спецификацию, и реализацию, и автотесты.

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

Идеальный процесс тогда может выглядеть так:

– Аналитик собирает требования, кладет расшифровки звонков в репу, любые другие артефакты в процессе анализа, и генерит документацию по бизнес требованиям. Все это в ветке монорепы.

– Опционально аналитик может даже сгенерировать прототип в реальном коде на основе своих же бизнес-требований и показать клиенту (автоматический деплой из фича-ветки, такая вот нативная интеграция наших услуг)

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

– Разработчик вместе с агентом реализует фичу в этой же ветке, глядя на согласованные бизнес-требования и прототип (который он потом просто выкинет) прямо в этой же ветке. Обновляет автоматически документацию, если есть изменения в процессе.

– Ветка проходит ревью у тимлида целиком.

– Тестировщик тестит эту же ветку (снова нативная интеграция фича-стендов) в изолированном окружении и дописывает автотесты.

Фича стала набором связанных артефактов и они все одной транзакцией попали в основную ветку при мерже.

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

#сергей_чернобровкин 👨

Спецификации на пути к автономной разработке

В прошлых постах рассуждал про инженеров будущего и про автономный цикл создания ПО.

Мы работаем над инструментами для такого AI SDLC (как сейчас модно говорить) и масштаб компании дает как преимущества, так и создает проблемы.

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

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

Теперь вернемся к AI SDLC. По моему мнению, сейчас не столь важны инструменты, сколько создание общей среды для агентов и людей. Накопление знаний и создание общего контекста. LLM меняются, инструменты меняются, данные и знания остаются.

Это значит, что первая задача, которую надо решить на пути к автономному созданию ПО — максимально «сблизить» данные, которыми оперируют разные специалисты и агенты.

И первая задача, которую все решают при создании ПО — сбор бизнес-требований. Spec driven development уже давно звучит из каждого утюга. Но проблема в том, что конечный стейкхолдер выдает требования обычно обрывочно и не структурировано. Их нужно собирать с заказчика, анализировать и на основе них синтезировать спецификацию. А потом согласовывать. И обычно этот процесс ведется в удобных инструментах типа Гугл-доков или конфлюенсов, где можно оставить комментарии, предложить изменения и тд.

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

В целом, работать через mcp с теми же гугл доками можно. И мы так и делали в первых итерациях. Проблема в том, что «мостиком» между агентом и документацией тогда является человек, который работает с агентом. Он должен указать документ, с которым работает, изменить его (например, автоматически обработать комментарии заказчика) через mcp часто бывает неудобно (перетирается весь док, нельзя включить режим предложений). А обновить документацию уже потом в процессе разработки — отдельный шаг, который точно кто-нибудь забудет. Мы даже разработали плагин к гугл докам, который умеет обработать комментарии, внести правки в режиме предложений. Но этого все еще недостаточно, потому что кодинговый агент, живущий в репозитории, лучше всего работает с артефактами из этого репозитория.

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

Поэтому нам пришлось разработать сервис для просмотра и согласования документации, которая лежит в репозитории. Сервис позволяет комментировать (через комменты к мерж-реквестам) и редактировать (через коммиты) документы прямо онлайн, полностью имитируя процесс гугл-доков. Теперь большинство аналитиков согласуют с заказчиками документацию в нашем сервисе, и она автоматически попадает в репозиторий, где ее же и использует агент. А комменты от заказчиков можно обрабатывать автоматически. Затем разработчики используют документацию уже для программирования и в процессе разработки могут автоматически (агентом) проапдейтить документацию, если было изменение в процессе реализации.

Но мало сделать, надо еще и внедрить. Для внедрения мы сделали простой yaml-конфиг, описывающий структуру документации в репозитории. Разработчикам / аналитикам нужно добавить только этот конфиг и репозиторий автоматически покажется в интерфейсе сервиса для просмотра и согласования документов.

Вуаля, и вот мы сделали маленький, но важный шажок на пути к автономному AI SDLC.

#сергей_чернобровкин 👨

Заказчики больше не хотят платить за прокси-менеджеров

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

Мы видим эту тенденцию и на своих проектах. К нам приходят либо с технически сложными задачами, либо с высоким уровнем неопределённости. Где нужен опыт, чтобы дойти до результата за один-два эксперимента, а не за пять.

В такой ситуации трансформируется и роль менеджера. Заказчикам больше не нужен координатор, который просто передаёт информацию туда-сюда.

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

Мы два года не меняли профиль менеджеров-сеньоров, которых хотим видеть в команде, и получали хороший результат. У нас изначально была высокая планка по технической осведомлённости, но мы не выделяли это как отдельный критерий. Больше смотрели на погружение в задачи, которые ставятся разработчикам.

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

#максим_павлов 😀 #менеджментkts

Корпоративное ПО в эпоху AI

8 месяцев назад мы с коллегами обсуждали выбор ПО для автоматизации части внутренних процессов. Мы были в классической ситуации, которую сами помогаем решать нашим клиентам: каждый отдел использует свои инструменты разного уровня автоматизации — от экселек с аппскриптами до специализированного ПО под конкретные задачи. Типичная «лоскутная автоматизация». Мастер-данные при этом не хранятся в единой системе: сотрудники в 1С, клиенты в CRM, финансы в агрегаторе, отчетность в таблицах, ДО и КЭДО в отдельных сервисах, управление проектами в трекере. Все это помазано сверху самописными сервисами, которые перекладывают данные между системами.

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

Тем временем вышел Opus 4.5, я смог достаточно качественно «кодить» в перерывах между звонками по 5–10 минут, моя самописная система разрасталась и уже покрывала несколько важных процессов. Затем прошел этап внедрения. Часть администраторов проектов стали работать в моей системе. Постепенно к созданию системы подключились и другие разработчики. За несколько месяцев довели продукт до продакшн-уровня, заместили часть текущих систем, выработали подходы к работе и документации для еще более быстрой разработки и даже дали менеджерам делать простые инструменты (не затрагивающие кор-функционал) под себя самостоятельно через согласование спецификаций.

Это дало кратный буст и уже значительно сказалось на бизнесе: от прямой экономии ФОТ (проще всего посчитать в экономике) до онлайн-мониторинга показателей и сокращения времени принятия управленческих решений. Всего за несколько месяцев я увидел, как капитализировалась большая часть нашего опыта, данных, процессов, живущих до этого в головах, документах и разрозненных системах.

Более того, благодаря подключению «нетехнарей» получилось сократить цикл создания ценности в продукте: бизнес-пользователи лучше всего знают свои процессы, и теперь они могут не рассказывать аналитикам, что же нужно сделать, чтобы аналитики написали ТЗ, передали его в разработку и т. д. Теперь они сами часто пишут ТЗ, согласуют его и реализуют нужный им функционал. (Для скептиков: не пугайтесь, есть гардрейлы и централизованная архитектура, а эффект от распараллеливания кратно превосходит риски.)

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

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

#сергей_чернобровкин 😊

Как AI превращает проджекта в «десятикратного» менеджера

Раньше наш стандартный трек внутренней автоматизации выглядел так: анализируем процесс, описываем его, аналитики структурируют, составляем ТЗ. Потом разрабатываем, тестируем, делаем приёмку. А после — внедрение, и… новый цикл доработок.

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

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

Опытный менеджер уже умеет формулировать требования, понимает, что поедет, и как это внедрять. Раньше процесс упирался в зависимость от разработчика. А теперь менеджер сам ставит задачу, сразу валидирует, поедет ли решение в таком виде, и тут же фиксит.

Это работает особенно мощно, если команда выстроила предсказуемый пайплайн: доработки не ломают всё, их можно изолированно тестировать и быстро катить.

В результате мы получаем «десятикратных» менеджеров — с помощью AI они дают в 10 раз больше результата. По аналогии с «десятикратными» программистам из книги «Мифический человеко-месяц» Фредерика Брукса.

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

Чтобы получить такой результат, важны две вещи:
— понять, что мир изменился, и сломать внутренний блокер «я должен делегировать это разработчикам»
— выстроить предсказуемую работу с ИИ и обеспечить среду, в которой можно итеративно пробовать, не боясь всё сломать.

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

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

#максим_павлов 😀 #менеджментkts