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

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

前往频道在 Telegram

Блог основателей и сотрудников компании KTS. Не душно о бизнесе, проджект менеджменте и разработке. https://kts.tech Также мы: @inside_ai_tech, @metaclass, @kts_specials, @kod_v_kaske Welcome!

显示更多
4 043
订阅者
+224 小时
+47 天
+430 天
吸引订阅者
九月 '26
九月 '26
+16
在0个频道中
八月 '26
+73
在0个频道中
Get PRO
七月 '26
+113
在1个频道中
Get PRO
六月 '26
+83
在3个频道中
Get PRO
五月 '26
+63
在2个频道中
Get PRO
四月 '26
+61
在2个频道中
Get PRO
三月 '26
+110
在2个频道中
Get PRO
二月 '26
+95
在0个频道中
Get PRO
一月 '26
+155
在1个频道中
Get PRO
十二月 '25
+104
在0个频道中
Get PRO
十一月 '25
+116
在3个频道中
Get PRO
十月 '25
+189
在2个频道中
Get PRO
九月 '25
+140
在4个频道中
Get PRO
八月 '25
+259
在5个频道中
Get PRO
七月 '25
+140
在0个频道中
Get PRO
六月 '25
+202
在3个频道中
Get PRO
五月 '25
+225
在4个频道中
Get PRO
四月 '25
+222
在2个频道中
Get PRO
三月 '25
+105
在2个频道中
Get PRO
二月 '25
+92
在2个频道中
Get PRO
一月 '25
+73
在1个频道中
Get PRO
十二月 '24
+80
在2个频道中
Get PRO
十一月 '24
+91
在5个频道中
Get PRO
十月 '24
+92
在1个频道中
Get PRO
九月 '24
+68
在0个频道中
Get PRO
八月 '24
+66
在2个频道中
Get PRO
七月 '24
+87
在0个频道中
Get PRO
六月 '24
+99
在0个频道中
Get PRO
五月 '24
+65
在0个频道中
Get PRO
四月 '24
+83
在0个频道中
Get PRO
三月 '24
+67
在4个频道中
Get PRO
二月 '24
+72
在3个频道中
Get PRO
一月 '24
+54
在0个频道中
Get PRO
十二月 '23
+65
在0个频道中
Get PRO
十一月 '23
+64
在0个频道中
Get PRO
十月 '23
+88
在2个频道中
Get PRO
九月 '23
+86
在0个频道中
Get PRO
八月 '23
+97
在0个频道中
Get PRO
七月 '23
+64
在0个频道中
Get PRO
六月 '23
+85
在0个频道中
Get PRO
五月 '23
+205
在0个频道中
Get PRO
四月 '23
+62
在0个频道中
Get PRO
三月 '23
+51
在0个频道中
Get PRO
二月 '23
+68
在0个频道中
Get PRO
一月 '23
+110
在0个频道中
Get PRO
十二月 '22
+184
在0个频道中
Get PRO
十一月 '22
+139
在0个频道中
Get PRO
十月 '22
+104
在0个频道中
Get PRO
九月 '22
+104
在0个频道中
Get PRO
八月 '22
+178
在0个频道中
Get PRO
七月 '22
+49
在0个频道中
Get PRO
六月 '22
+268
在0个频道中
Get PRO
五月 '22
+30
在0个频道中
Get PRO
四月 '22
+57
在0个频道中
Get PRO
三月 '22
+136
在0个频道中
Get PRO
二月 '22
+155
在0个频道中
Get PRO
一月 '22
+193
在0个频道中
Get PRO
十二月 '21
+55
在0个频道中
Get PRO
十一月 '21
+15
在0个频道中
Get PRO
十月 '21
+92
在0个频道中
Get PRO
九月 '21
+30
在0个频道中
Get PRO
八月 '21
+154
在0个频道中
Get PRO
七月 '21
+28
在0个频道中
Get PRO
六月 '21
+210
在0个频道中
Get PRO
五月 '21
+491
在0个频道中
Get PRO
四月 '21
+431
在0个频道中
日期
订阅者增长
提及
频道
04 九月+5
03 九月+4
02 九月+4
01 九月+3
频道帖子
⚡️ KTS — в топе по отраслям Рейтинг Рунета опубликовал срезы за 2025 год. Мы попали в топ-5 во всех ключевых индустриях:  ⭐️ HRTech — 1-е место в разработке веб-сервисов. ⭐️ PropTech— 1-е место в мобильной разработке. ⭐️ Retail— на 2 месте по услугам: мобильная разработка, AI-интеграции и геймификация. ⭐️ FinTech— 4-е место среди AI-интеграторов.  Радуемся результатам вместе с вами 💚 Продолжаем накапливать опыт в этих и других отраслях и применять его в проектах — от веб- и мобильных продуктов до AI и геймификации.

2
От первого пилота Stackland — к техническому гайду Мы уже рассказывали, что начали работать с Yandex Cloud Stackland. Фишка платформы: инфраструктура остаётся на собственном железе внутри закрытого контура, а управляется как в облаке. KTS разворачивает платформу на bare metal, готовит инфраструктуру и конфигурации, запускает встроенный мониторинг и управляемые сервисы, а также сопровождает внедрение в enterprise-среде.  Практический опыт собрали в подробной статье с пошаговой установкой, примерами конфигураций и разбором ошибок, которые могут остановить развёртывание кластера. Материал пригодится DevOps- и инфраструктурным командам, которые планируют тестировать или внедрять Stackland: по нему можно проверить требования к инфраструктуре и заранее изучить проблемные места. Проджектам и техническим руководителям статья поможет оценить реальный объём подготовки, учесть риски в плане проекта и предметно обсудить с инженерами сценарий запуска. Приятного чтения и предсказуемых внедрений.
564
3
Metaclass в первый класс! 💐 В честь 1 сентября покопались в архивах и нашли детские фото тех, кто сегодня менторит и развива
Metaclass в первый класс! 💐 В честь 1 сентября покопались в архивах и нашли детские фото тех, кто сегодня менторит и развивает Metaclass 👀 Эти малыши ещё не знают, что однажды будут учить и растить крутых специалистов! А пока у них впереди первый звонок, уроки и домашка. Вспоминаем в комментах свое первое сентября — посмотрим, какими первоклашками были будущие айтишники!
564
4
视频消息
780
5
Ваш KTS и тут и там показывают Рассказали в программе Наука и Техника на @rentv_channel про нашу разработку — мобильное приложение Локки, которое помогает контролировать время в соцсетях. Ограничить соцсети очень просто: открываете Локки, выбираете, какие приложения заблокировать и задаете период доступа. А ограничения снимаются по физическому ключу-карте. Смотрите сюжет, скачивайте на Google play и тестируйте. P.S. Концепт приложения собрали всего за пару часов.
686
6
Играем на retention вместе с Авито Что общего у квартиры, велосипеда, и коллекции винила? Всё это можно найти на Авито. А теп+1
Играем на retention вместе с Авито Что общего у квартиры, велосипеда, и коллекции винила? Всё это можно найти на Авито. А теперь — ещё и встретить в игре. С командой сервиса мы придумали «Раскладушку» — геймификацию внутри приложения, построенную вокруг ассортимента Авито.  Проект решает ключевые продуктовые задачи Авито: · вовлечь больше пользователей в Портал призов, · дать дополнительный повод регулярно возвращаться в сервис, · показать, сколько всего можно найти в разных вертикалях Авито. Мы начали с аналитики и нашли механику, которая будет понятна широкой аудитории, не станет копией уже популярных геймификаций и будет дружить с брендом Авито. Так появились ассоциации: пользователь объединяет карточки с товарами в тематические категории, нарабатывает скилл и проходит уровни, а за прогресс получает монетки. Их можно обменять на шансы в розыгрышах на Портале призов или потратить на бустеры, если уровень оказался сложным. Продумали retention и мотивировали пользователей возвращаться: 🌟 игровой цикл с прогрессом: чем больше играешь, повышаешь уровень, забираешь больше монет, тем выше шансы на призы, 🌟 апдейты: новые уровни открываются каждый день Посмотрите, что у нас получилось:  откройте «Раскладушку» в Портале призов → avito.ru/apps
873
7
MCP для Яндекс Трекера пробил 100 звёзд на GitHub⭐️ Когда-то давно мы сделали сервер для собственных процессов: с ним AI-асси
MCP для Яндекс Трекера пробил 100 звёзд на GitHub⭐️ Когда-то давно мы сделали сервер для собственных процессов: с ним AI-ассистенты создают и обновляют задачи, дополняют описания, оставляют комментарии и фиксируют затраты времени прямо в Трекере. Потом открыли код на GitHub. И теперь видим больше 100 звёзд и радуемся, что инструмент пригодился и другим командам. К первой сотне выпустили обновление 0.8.0. Главное изменение: MCP научился работать с проектами, портфелями и целями. Добавили 39 инструментов для поиска, создания, обновления и удаления этих сущностей, а также работы с комментариями. Теперь агенту можно поручить создать проект, обновить статус цели или собрать информацию по портфелю. Меньше данных придётся переносить вручную между AI-ассистентом и Трекером. В релизе есть и другие изменения. Полный список собрали в changelog. Спасибо всем, кто пользуется сервером, ставит звёзды и помогает его развивать! 💚
995
8
Покупатели часто выбирают квартиры вечером, ночью или в выходные, когда отдел продаж не на связи. Если в этот момент клиент н
Покупатели часто выбирают квартиры вечером, ночью или в выходные, когда отдел продаж не на связи. Если в этот момент клиент не получает быстрый ответ на вопрос, его интерес остывает. Мы запустили ИИ-ассистента для девелоперов, который помогает сохранить конверсию воронки продаж и разгрузить менеджеров. 🟢 Ассистент круглосуточно консультирует пользователей, подбирает подходящие лоты по свободному запросу и переводит диалог в запись на просмотр, когда клиент готов. 🟢 Покупатели, которые еще не готовы к разговору с отделом продаж, могут задать вопросы о проекте, ценах и условиях, не опасаясь навязчивых звонков. 🟢 Первичные справочные диалоги ассистент берет на себя, поэтому менеджер подключается сразу к разговору с теплым клиентом. 😎 Подключим ассистента за 2 дня, а если он не принесет больше лидов, пилот будет за наш счёт. Оставить заявку
890
9
Где AI приносит пользу бизнесу быстрее всего? Именно в повторяющихся сценариях с понятной логикой внедрение AI даёт измеримый результат за короткое время.  В новой статье разбираем примеры решений, которые помогли сократить затраты, ускорить работу и разгрузить сотрудников: 🌟AI-база знаний для Альфа-Банка ускорила поиск данных в 20 раз 🌟Чат-бот для банка обрабатывает 97% запросов за 3 секунды 🌟Ассистент для строительной компании помог увеличить конверсию в лид с 38% до 55% Статья будет полезна всем, кто изучает варианты автоматизации и хочет оценить возможный эффект: читать в блоге KTS.
938
10
KTS × Selectel создали ИИ-поиск для компаний, где каждый ответ нужно подтвердить документом В строительстве, производстве, добывающей отрасли и финансах сотрудники работают с большими массивами регламентов, ГОСТов и внутренних документов. При подготовке отчёта, прохождении проверки или аудита данные приходится искать в нескольких системах и сверять с первоисточниками. На это может уходить до нескольких часов в день. Совместное решение KTS и Selectel помогает значительно сократить время поиска информации. Сотрудник задаёт вопрос на естественном языке и получает структурированный ответ со ссылкой на документ и конкретную страницу. Также ассистент умеет: — подключаться к wiki, СЭД, файловым хранилищам и нормативным источникам; — суммаризировать длинные документы; — выделять тезисы, обязательства и риски; — экспортировать ответы в Word и PDF; — учитывать права пользователей через системы управления доступом (IAM и SSO). Безопасность заложена в архитектуру решения на нескольких уровнях. Система автоматически маскирует чувствительные данные, а встроенные механизмы контроля (guardrails) проверяют запросы и ответы ИИ на соответствие заданным политикам безопасности. ИИ-ассистент может закрывать большинство рутинных типовых запросов. Благодаря готовой инфраструктуре KTS AI Platform пилот можно запустить за две недели. Проверьте решение на собственных документах: загрузите их в настроенную базу знаний и оцените качество ответов. Протестировать ИИ-ассистента
1 073
11
Как меняется работа аналитика в AI SDLC В прошлом посте про AI SDLC я писал, что основной прирост эффективности даст не автоматизация отдельных задач, а перестройка всего конвейера разработки. Продолжу эту мысль на примере работы аналитика. Недостаточно сохранить прежний процесс и просто ускорить его с помощью Cursor, Claude или другого инструмента. Так делают все. Преимущество появится там, где AI меняет не скорость отдельных действий, а сам порядок работы. Нужно смотреть на каждый этап и спрашивать: а должен ли я вообще здесь включаться? Сейчас стандартная схема выглядит так: сначала ты думаешь, что и как будешь делать, а затем приступаешь к работе. Но порядок можно изменить. Сначала отдать задачу агенту, получить готовый артефакт, а потом проверить его и при необходимости отправить на доработку. То есть не читать ничего сырого, а работать уже с готовой версией. Этот эффект будет усиливаться с каждой новой моделью: они становятся умнее и получают больше контекста. Возьмём спецификацию. Здесь есть два сценария. Первый: самостоятельно разобрать постановку заказчика, дополнить её и подробно описать требования. Второй: передать модели исходную задачу, посмотреть, что она предложит, и уже потом доработать получившийся вариант. Раньше первый сценарий считался правильным, потому что переделывать было дорого. Сейчас стоимость итерации снижается. Если человек продолжает тратить силы там, где можно сначала получить черновик от модели, он просто теряет время. Чем умнее становятся модели и чем больше контекста у них появляется, тем чаще они смогут предложить вариант лучше того, который человек сформулирует на старте. AI меняет сам порядок действий. Работа аналитика при этом не исчезает. Аналитику всё ещё нужно собрать контекст, понять задачу и проверить решение. Но начинать с чистого листа теперь необязательно. Сильнее будет тот процесс, в котором человек подключается там, где действительно нужен: направляет модель, валидирует готовый результат и отправляет его на следующую итерацию. #максим_павлов 😀 #менеджментkts
1 099
12
❗️Осторожно: мошенники подделывают вакансии KTS Они предлагают работу, а затем просят установить программу, которая крадёт данные. К KTS эти предложения отношения не имеют. Установка подозрительных программ в тестовое задание не входит. Мы не просим кандидатов передавать пароли, коды из СМС, данные банковских карт или доступ к устройству. А вот настоящие вакансии у нас действительно есть: смотрите их на hh.ru. Если вы не нашли подходящую, не грустите и расскажите о своих талантах напрямую нашему HR-отделу: @kts_hr_talent_bot. Берегите данные, откликайтесь или перешлите этот пост тем, кто сейчас ищет работу.
1 016
13
Как геймификация помогает вовлекать сотрудников? Разберем на примере Ozon fresh 📦 Корпоративный праздник — отличный повод по
Как геймификация помогает вовлекать сотрудников? Разберем на примере Ozon fresh 📦 Корпоративный праздник — отличный повод поздравить команду, а заодно прокачать её вовлечённость. Ко Дню работников склада мы с Ozon fresh и первым агентством внимания ЦЕХ за 3,5 недели запустили лендинг с игровой механикой. Что работало на вовлечение: 🔵 Постепенное усложнение. С каждым уровнем рос темп, сохраняя азарт до самого финала. 🔵 Прогрессия. За каждую победу игрок получал новый элемент экипировки персонажа. 🔵 Нативное обучение. Вместе с продуктами игроки собирали алмазы, которые открывали факты о складах Ozon fresh. Так знакомство с компанией вплели прямо в геймплей. 🔵 Статусы и вызов. В финале каждый получал звание — от «Стажёра» до «Легенды склада». Забрать высший статус могли только те, кто прошёл игру без ошибок и собрал все алмазы. За месяц игру прошли почти 2 000 участников, каждый четвертый возвращался снова, а средняя длительность игровой сессии составила 4 минуты.
1 034
14
Два Kubernetes-кластера вместо 35 виртуалок: как мы перестроили инфраструктуру Лазурита Продолжаем рассказывать про DevOps-пр
Два Kubernetes-кластера вместо 35 виртуалок: как мы перестроили инфраструктуру Лазурита Продолжаем рассказывать про DevOps-проекты. Сегодня делимся историей крупного мебельного ритейлера «Лазурит».  Инфраструктура компании годами росла вокруг текущих бизнес-процессов: обработки заказов, распределения звонков, расчёта сроков доставки. Сервисы жили на отдельных виртуальных машинах, рядом лежали базы данных, бэкапы хранились на одном сервере. За мониторинг отвечал подрядчик, и доступ к метрикам шёл через его VPN.  Такая инфраструктура создавала риски: при сбое сетевой зоны могли пострадать данные, а релизы останавливали сервисы на несколько минут. Менеджеры не могли работать с заказами, а разработчики тратили время на ручную диагностику.  DevOps-команда KTS провела аудит и постепенно построила новую отказоустойчивую инфраструктуру: 🌟перевели бизнес-сервисы в Kubernetes: теперь они работают в двух мультизональных кластерах, мониторятся через новый стек и поддерживаются командой KTS; 🌟убрали простой при релизах: после переезда старая версия сервиса функционирует, пока новая не запустилась; 🌟перенесли бэкапы и файловый обмен в S3 и исключили привязку к локальной директории: если контейнер переезжает в другую зону, он подключается к хранилищу и продолжает работу с теми же данными; 🌟развернули новый мониторинг на VictoriaMetrics-стеке: у разработчиков «Лазурита» теперь есть прямой доступ к дашбордам по сервисам, базам, трафику и нагрузке. Это не заменяет сопровождение, но закрывает много мелких вопросов, которые раньше отнимали время. Подробнее о том, как построили новую инфраструктуру на Kubernetes и упростили релизы, читайте в кейсе
1 075
15
От выполнения задач к инжинирингу конвейера разработки Есть стандартный подход к автоматизации: сначала ты делал что-то руками, теперь используешь инструмент. Но опыт автоматизации наших проектов показывает, что основной прирост эффективности лежит в другом: нужно сократить количество передач между людьми. На каждом таком этапе теряется часть контекста. Поэтому пора смещать фокус с выполнения отдельных задач на инжиниринг всего конвейера. Не придумывать решение для каждой новой фичи, а создавать и докручивать систему, которая с каждой итерацией работает всё более автономно. Большая аналитическая часть при этом остаётся за человеком. Нейросеть не может самостоятельно обсудить задачу с заказчиком, собрать требования и проверить все детали. Для анализа и коммуникации по-прежнему нужны люди. Но после этого должны включаться правила, контрольные точки и автоматические проверки. Главный критерий здесь простой: чем реже участникам приходится передавать друг другу сведения, тем лучше. Глобальная цель — перейти от работы над конкретной фичей к инжинирингу конвейера. Разберём это на примере идеализированной технической поддержки. Заказчик пишет в чат, но часто не указывает важные детали. Сотруднику приходится отдельно уточнять, что произошло, при каких условиях возникла ошибка и как её воспроизвести. На это уходит время. При этом клиент уже в негативе: у него что-то не работает. Скорость обработки обращений сильно влияет на впечатление от подрядчика. Для команды это может быть небольшой баг. Для клиента он критичен: останавливает работу или не даёт выполнить нужное действие. В идеальной схеме в чат добавлен бот. Он принимает обращение и сразу запрашивает недостающие данные: шаги воспроизведения, условия возникновения ошибки и другие детали. Затем система исследует код, анализирует проблему, формирует баг-репорт и предлагает план исправления. На следующем этапе AI-агент вносит изменения в отдельной ветке, чтобы не затронуть основной код, и запускает автоматические тесты. Например, с помощью Playwright открывает браузер и проходит нужный путь. После проверки агент описывает внесённые изменения. Человеку остаётся вручную воспроизвести ошибку, согласовать итог или прочитать отчёт и убедиться, что результат соответствует постановке. Если через час или несколько часов заказчик получает протестированный фикс, готовый к выпуску, это впечатляет. К такому уровню сервиса быстро привыкают. Это и есть идеализированный AI SDLC: не отдельный инструмент, а полноценный конвейер разработки. #максим_павлов 😀 #менеджментkts
1 058
16
«Монстропланетяне» в «Магните»: из космоса в офлайн 🛸 Вместе с коллегами из «Магнита» разработали геймификацию, которая подт
«Монстропланетяне» в «Магните»: из космоса в офлайн 🛸 Вместе с коллегами из «Магнита» разработали геймификацию, которая подталкивает зайти в приложение, а оттуда — заглянуть в большие форматы сети. За счёт чего работает: ▫️ Ежедневный азарт. В центре игры автомат-хватайка, в котором каждый день можно вытащить капсулу с призом: купоны на скидки и товары за 1 ₽ и выгоду в магазинах Магнит Семейный, Экстра и Доставке. Для тех, кому не хватает бесплатных попыток, начисляем ещё за бонусы М+ или целевые действия: покупки и продуктовые задания. ▫️ Мостик к полкам. В самих магазинах поселились 7 игрушек-персонажей: Топыч, Ничоськина, Фанич, Смайли, Соняшкина, Энгрич и Норман. Покупаешь монстропланетянина на кассе — получаешь не только физичекую копию, но и цифровой элемент коллекции в приложении. А за всю собранную коллекцию можно получить гарантированные призы и пропуск в финальный розыгрыш. Заходите в приложение «Магнита», знакомьтесь с монстропланетянами и получайте призы 👾
983
17
ИИ вне разработки В прошлых постах много писал про разработку. А что поменялось в процессах других отделов? Сегодня поговорим про эволюцию отдела продаж. За последние несколько месяцев было попробовано много инструментов. Начиналось все, как, думаю, и у всех, с того, что сейлзы начали использовать нейро-инструменты. Например, начали обсуждать с ChatGPT свои сделки. Сами лиды при этом лежат в CRM, сметы считаются в таблицах, КП готовится в фигме, а процесс выработки решения довольно сложный и состоит из встреч с партнерами, клиентом, технической командой и т.д. Когда сейлзы начали использовать ИИ-инструменты, это, как и в случае с разработкой, начало ускорять работу и делать ее местами более качественной за единицу времени. Но это все еще не кратное ускорение / улучшение. Поэтому мы продвинулись чуть дальше. Но перед этим нужно понять классические проблемы отдела продаж (не только нашего). Изучение кейсов и продуктов компании обычно занимает пару месяцев, адаптация сейлза к процессу сбора КП, синхронизация с командой, все это приводит к длинному онбордингу, на который накладывается еще и длинный цикл сделки и в итоге сейлз может начать что-то приносить через полгода. При этом капитализация отдела продаж в основном в: — Контактах в CRM — Отработанных лидах и кейсах (которые часто не структурированы и разбросаны по системам) — Всяческих шаблонах и готовых упаковках — Опыте конкретных людей Соответственно, чтобы выходить на новый уровень качества/скорости, нужно усиливать эту капитализацию с ИИ. Все перечисленные пункты на самом деле раскладываются на 2 задачи: — Накопление знаний (четкая структура, быстрый и простой доступ) — Типовые кросс-командные решения Поэтому первое, что мы сделали, — ИИ-агента с поиском по нашим решениям. Позволяет быстрее ориентироваться в продуктах и кейсах (которых, на минуточку, больше нескольких сотен, и никто не знает про все). А второе — агент, который позволяет оценивать уровень качества КП по оформлению и принятым практикам. Таким образом, регламенты и подходы становятся не просто рекомендациями (которые на практике быстро деградируют), а правилами, заложенными в систему. Но этого было недостаточно. Во-первых, оба инструмента находятся в нашей внутренней системе. Получается, сейлз работает в CRM, сидит в чатах и почте, звонит по телефону, готовит КП вместе с ChatGPT и еще кучу всего делает. А тут ему еще одну вспомогательную систему дали. Мотивации туда заходить не так много. А новые инструменты добавляются централизовано, а значит долго и не извлекают экспертизу и знания конкретного сейлза в общие практики. А артефакты подготовки конкретного КП все так же передаются в гугл-папках, CRM, чатах и тд. И тут становится понятно, что эти проблемы давно решены в разработке: — Экспертиза, знания и правила — это скиллы для ИИ-агентов — Общее хранилище данных — репозитории, где работают все инженеры (вместе с им-агентами) в одном контексте — Генерация артефактов с кодинговыми агентами работает лучше всяких чатов с gpt. Поэтому решение стало очевидным: сейлзы должны начать накапливать знания о своих пресейлах и генерить решения вместе с техническими командами так же, как это делают разработчики. Мы сделали один общий git-репозиторий для продаж. Он содержит: — Схему данных о клиентах и их заявках для накопления всех артефактов о заявках — MCP CRMки — Набор скиллов для работы с кодинговыми агентами Процесс выглядит так: При поступлении новой заявки и начале работы над ней сейлз получает данные о заявке из CRM с помощью скилла. Другой скилл делает предварительный анализ клиента и заявки. Сейлз может поразгонять его в глубину вместе с агентом. Дальше может быть первичный созвон с клиентом. Запись попадает в папку лида в репозитории и агент может использовать ее для помощи в генерации первичного решения. Аналогично с записью брейншторма команды по генерации решения. На основе собранных артефактов сейлз может составить план КП. А партнер или архитектор решения сразу получает весь набор артефактов, просто спуллив апдейт репозитория. Таким образом, и сейлзы, и архитектор, и все участники процесса, включая ИИ-агентов, находятся в одном контексте и капитализируют знания. Эти знания дальше может использовать агент при поиске в том же репозитории. Отдельный кайф в том, что сейлзы в процессе работы создают скиллы для ИИ-агентов в том же репозитории. Например, сегодня один из сейлзов сделал скилл для процесса упаковки технического решения по нашим стандартам. И главное — этот скилл автоматически становится доступным всем другим участникам команды пресейлов (даже если они о нем не узнают, ИИ-агент сам найдет и использует скилл, когда нужно). #сергей_чернобровкин 👨
1 080
18
Стримы, как зона ответственности Глядя на предыдущий пост, становится понятно, что зона ответственности должна быть в размере объекта поставки специалиста — что «под ключ» может сделать специалист. Если атомарной задачей может стать фича целиком, то это и есть новый объект поставки. И специалист тем ценнее, чем больший объем этого объекта он может сделать «под ключ»: условно маленькую фичу или большую, комплексную или простую, с простым пайплайном или сложным. Поэтому в нашей новой матрице грейдов мы отдельно выделили термин объекта поставки, чтобы смещать восприятие, что такое атомарная задача. В мире, где опытный специалист может с клодом сделать фичу так, как он хочет, быстро и почти автономно (реальный кейс нашего архитектора — 39-часовой околоавтономный рефакторинг проекта  с fable 5), этому специалисту просто не хочется дробить задачу и объяснять детали младшим специалистам, а потом за ними проверять, и все это с большой задержкой (часы / дни) вместо минут у клода. Но у этого специалиста все еще остается ограничение — контекстная вместимость и приоритеты. Он не может удерживать в голове 10 разнородных треков. Даже 3 уже сложно. А значит ценно для такого старшего специалиста полностью передать один из этих контекстов на младших специалистов. То есть, чтобы они взяли «под ключ» какой-то из стримов. Сложность этого стрима очевидно должна быть соразмерна грейду специалиста. Как и размер объектов поставки в рамках этого стрима. И поэтому в новой матрице грейдов мы сфокусировали внимание и конкретизировали не только блоки по разработке (техническим скиллам), но и блоки по работе с требованиями, ответственностью и самостоятельностью в достижении бизнес-результата. Эти мета-скиллы всегда были важны, но часто по моим наблюдениям (не только нашей компании) им придавали меньшее значение, чем технике. Сейчас значение этих скиллов будет расти вместе с упрощением / ускорением разработки. Поэтому мы плавно меняем матрицу и фокусируемся на них уже сейчас в развитии и обучении. #сергей_чернобровкин 👨
1 360
19
Монорепы на пути к AI SDLC В прошлом посте рассказывал про то, как мы перенесли документацию в гит и сделали удобный инструмент согласования бизнес-требований с заказчиками. Следующий шаг «сближения» данных и сбора общего контекста для разработчиков и агентов — создание монорепы / общего воркспейса с несколькими репозиториями у проекта. Классическая картинка выглядит так: есть репа с бекендом, есть с фронтендом, и еще несколько вспомогательных реп на какие-то смежные сервисы. Сама структура репозиториев не позволяет одним коммитом добавить функционал: нужно, например, сделать бек, потом фронт, а часто это еще и разные специалисты и разные задачи в трекере, за синхронизацией которых между собой следят менеджеры и тимлиды. Это очевидная точка оптимизации на пути к AI SDLC. Если я могу (утрированно) сгенерить код фронта за час, но мне нужно ждать целый день, чтобы его передать следующему спецу, который сделает бек, а потом это все сливать в стейдж, чтобы отдельно интеграционно потестит, то я теряю уйму времени на передаче контекста и отслеживание статусов атомарных задачек и контроля их синхронизации. Никаким кратным ускорением не пахнет. Соответственно, возможность, которую хочется использовать в AI SDLC — атомарной задачей должна стать сама фича, а не ее кусочки. А для этого мне нужно в одном месте собирать все артефакты: от бизнес-требований (см предыдущий пост) до автотестов. Это место — в идеале монорепа. Тогда я смогу одним коммитом вмержить целый блок функционала: и актуальные бизнес-требования, и техническую спецификацию, и реализацию, и автотесты. Это гарантирует синхронизацию артефактов между собой, сократит время на менеджмент подзадач, позволит агентам точнее выполнять задачу. Идеальный процесс тогда может выглядеть так: – Аналитик собирает требования, кладет расшифровки звонков в репу, любые другие артефакты в процессе анализа, и генерит документацию по бизнес требованиям. Все это в ветке монорепы. – Опционально аналитик может даже сгенерировать прототип в реальном коде на основе своих же бизнес-требований и показать клиенту (автоматический деплой из фича-ветки, такая вот нативная интеграция наших услуг) – Менеджер / тимлид в этой же ветке может загрумить задачки, поразгоняв с агентом. И сразу же завести их в трекере по mcp, если нужно. Автоматически приложив в задачу ссылку на документацию в нашем же сервисе. – Разработчик вместе с агентом реализует фичу в этой же ветке, глядя на согласованные бизнес-требования и прототип (который он потом просто выкинет) прямо в этой же ветке. Обновляет автоматически документацию, если есть изменения в процессе. – Ветка проходит ревью у тимлида целиком. – Тестировщик тестит эту же ветку (снова нативная интеграция фича-стендов) в изолированном окружении и дописывает автотесты. Фича стала набором связанных артефактов и они все одной транзакцией попали в основную ветку при мерже. Я специально на каждом шаге в примере приводил разных специалистов, хотя уже видно, что следующие шаги на пути к AI SDLC — это скиллы, которые позволяют с должным уровнем качества делать эти шаги с помощью агентов. А потом какие-то шаги делать автономно. Про это буду писать в следующих постах по мере реализации на практике. #сергей_чернобровкин 👨
1 158
20
3000 томов без потерь: как Karpov.Courses переехал в российские облака Пока мы рассказывали про менеджмент, AI и продуктовую
3000 томов без потерь: как Karpov.Courses переехал в российские облака Пока мы рассказывали про менеджмент, AI и продуктовую разработку, DevOps-проекты копились в портфолио. Пришло время выпустить их из серверной. Начинаем с истории Karpov.Courses: как перенесли образовательную платформу в российские облака без остановки обучения и потери данных. К моменту нашего подключения платформа выросла из нескольких сервисов на виртуальных машинах до системы в Kubernetes. Часть инфраструктуры оставалась у зарубежных провайдеров. Это стало прямым риском для бизнеса. Платежи проходили с перебоями, часть студентов не могла зайти на платформу из-за блокировок IP, а провайдеры могли в любой момент ограничить обслуживание российских сервисов. Что сделали: — перенесли основную инфраструктуру в VK Cloud и Yandex Cloud; — развели сервисы по требованиям к доступности; — без потерь перенесли около 3000 томов с ноутбуками, датасетами и результатами заданий; — перевели управление приложениями на GitOps. Во время миграции студенты сохранили доступ к платформе и своим данным. После перехода на GitOps цикл от коммита до применения изменений сократился с десятков минут до секунд, а инфраструктура стала независимой от зарубежных провайдеров и готовой к росту. В кейсе подробно рассказали, как спланировали переезд и перестроили работу с инфраструктурой.
1 287