Speaker A
Добрый день всем зрителям и слушателям моего канала. Сегодня у нас очередная серия подкаста Code of Leadership. И со мной сегодня в прямом эфире Владимир Долгов, SEO Genetics.
Подкаст Code of Leadership: Владимир Долгов (SEO Genetics) обсуждает, как оценить эффективность разработки, когда агенты пишут код, и какие инструменты для этого использовать.
Key Takeaways
- Традиционные метрики (задачи, пулреквесты, строки кода) плохо отражают эффект от ИИ-агентов
- Нужны инструменты, показывающие фактическое время и процесс работы разработчика
- Рост объёма сгенерированного кода не равен росту реальной доставки ценности
- Руководителям необходимо заново учиться понимать процессы разработки в эпоху агентов
What the video covers
- Ведущий и гость Владимир Долгов обсуждают, что происходит с разработкой, когда агенты пишут код
- Владимир работал в Nokia Siemens и около 13 лет в Сбере, занимаясь CRM, MDM и телеком-системами
- Опыт работы руководителя разработки становится менее актуальным из-за быстрых изменений инструментов
- Сложно понять реальную картину работы разработчиков: трекеры и гиты фиксируют лишь часть информации
- Команды переходят от оценки по задачам к подсчёту пулреквестов, что приводит к искажению метрик
- Обсуждается измерение вклада ИИ: количество сгенерированного кода против реальной доставки (delivery)
- Рассматривается использование токенов и моделей разного уровня в зависимости от грейда разработчика
- Гость рассказывает о платформе для developer productivity (DevAptify), которая показывает реальное время работы над задачами
- Обсуждается риск формальных метрик, которые можно 'накрутить' (например, 'красить траву')
- Упоминаются генеративные подходы в играх как пример кастомизированного продукта
Chapters
- 00:00Вступление и представление гостя
- 06:00Опыт гостя: Nokia Siemens и Сбер
- 12:00Переход к AI и новые продукты
- 18:00Как меняется роль руководителя разработки
- 27:00Инструменты и метрики разработки
- 44:00Проблемы формальных метрик и пулреквестов
- 54:00Оценка эффекта агентов и выхлопа кода
- 70:00Практические примеры и выводы
Full Transcript — Download SRT & Markdown
Speaker A
Да, SEO Genentics. Владимир долго работал в Сбере, занимался, в том числе и инструментами для разработки. И, собственно, поэтому мы сегодня решили собраться и поговорить на тему а что происходит с разработкой, когда агенты пишут код, да, как оценить эффекты, какие вообще инструменты можно
Speaker A
Да, SEO Genetics. Владимир долго работал в Сбере, занимался, в том числе и инструментами для разработки. И, собственно, поэтому мы сегодня решили собраться и поговорить на тему: а что происходит с разработкой, когда агенты пишут код? Да, как оценить эффекты, какие вообще инструменты можно использовать для AI-фикации разработки? И классно, что, Владимир, у тебя есть опыт как в большой компании, так и в уже небольших компаниях, потому что из Сбера-то ты ушёл. Но давай я передам тебе слово, ты расскажешь немного про себя,
Speaker A
как бы про свой опыт, а потом мы вернёмся к нашей теме сегодняшней дискуссии и пойдём по шагам.
Speaker A
как бы про свой опыт, а потом мы вернёмся к нашей теме сегодняшней дискуссии и пойдём по шагам.
Speaker A
Поработал в Nokia Siemens, где занимались и сотовой связью. И последние порядка 13 лет работал в Сбере, где занимался несколькими крупными направлениями, разрабатывал CRM-системы, МДМ системы, телекоммуникационные.
Speaker A
Добрый день. Разработкой занимаюсь уже достаточно давно, наверное, больше 30 лет. Прошёл различные компании. Это были телеком-компании, разрабатывали биллинги, в том числе для Билайна.
Speaker A
разработчиков, и он там в некий момент практически обнулился, потому что всё пришлось начинать заново. И работал до последнего года. Э с начала нового года перешёл в свою компанию. Занимаемся, моё любимое слово, цифровые сотрудники, они же агенты. и делаем продукты для
Speaker A
Поработал в Nokia Siemens, где занимались и сотовой связью. И последние порядка 13 лет работал в Сбере, где занимался несколькими крупными направлениями, разрабатывал CRM-системы, MDM-системы, телекоммуникационные.
Speaker A
Вот, наверное, такое небольшое вступление. Это, кстати, очень интересно. Вот ну такой богатый опыт, да, в разных компаниях, в разных индустриях, на разных масштабах. Вот. А можешь рассказать про, ну, почему вот эта тема с э инструментами, да, для разработчиков? То
Speaker A
В последние, наверное, там четыре года мы плавно перешли к теме AI. Начал ей заниматься ещё до того, как вышел GPT. То есть как раз это был один из тех переломных моментов: мы два года работали над продуктом для
Speaker A
ну, как бы не исчезли, но скорее опыт остался, а продукт пришлось стоить заново. Вот. И почему ты сейчас похожий продукт, ну, делаешь? Мы потом ближе к к середине поговорим про платформу, да, для девелопер productivity. Но всё-таки вот хотелось бы понять твой какой-то
Speaker A
разработчиков, и он в некий момент практически обнулился, потому что всё пришлось начинать заново. И работал до последнего года. С начала нового года перешёл в свою компанию. Занимаемся, моё любимое слово, цифровые сотрудники, они же агенты, и делаем продукты для
Speaker A
следующим, что мы хотим всё знать о наших клиентах, о тех людях, которые пользуются нашими инструментами, и понимать, что у них происходит. И фактически в некий момент я понял, что мы знаем очень много о клиентах. Мы знаем, чем занимаются наши сотрудники в
Speaker A
различных компаний: фэшн, брокерских, чарных. И, наверное, сейчас достаточно увлекательный этап моей жизни — это переход от корпоративной разработки к малым проектам, где нужно очень чётко доказывать свою эффективность.
Speaker A
глубокие вопросы, то реальные картинки очень трудно сложить. То есть и, да, внедряются многие инструменты, трекеры, гиты, которые позволяют как-то снимать информацию. Но на самом деле, э, мы действительно не всегда понимали, а что делает разработчик, а какой у него
Speaker A
Вот, наверное, такое небольшое вступление. Это, кстати, очень интересно. Такой богатый опыт, да, в разных компаниях, в разных индустриях, на разных масштабах. А можешь рассказать про то, почему тебе эта тема с инструментами для разработчиков? То
Speaker A
долгое время жить. То есть ты понимал, какие задачи сколько делаются. Вот эта задачка маленькая, там 2 дня, это четыре, один разработчик синьор и так далее. А в тот момент, когда мы начали заниматься внедрением Ии полтора года до GPT, за два даже, то
Speaker A
есть почему, во-первых, тебе было интересно заниматься ею ещё до того, как все ими занялись, когда ChatGPT случился и стало понятно, что это будет прорыв? А дальше немного опиши своё впечатление, когда, условно говоря, годы работы фактически
Speaker A
нужно что-то, что позволит понять, а что произойдёт. позволит тем руководителям, которые пытаются руководить разработчиками, вообще понимать, как меняется жизнь разработчика, что он делает, как он до делает в новых условиях, как он сейчас применяет агентов. И потому что предыдущий опыт становится, ну, во
Speaker A
ну, не исчезли, но скорее опыт остался, а продукт пришлось строить заново. И почему ты сейчас делаешь похожий продукт? Мы потом ближе к середине поговорим про платформу для developer productivity. Но хотелось бы понять твою мантру: почему именно это направление тебя так увлекает?
Speaker A
прочувствовал как работают инженеры, да, как выглядит процесс разработки и может принимать осознанные решения. он стал всё менее актуальным. Ну вот когда в нашу жизнь начали входить новые инструменты, и ты должен понимать, как выглядит хzзо работа да вот ну руками какие
Speaker A
Ну, «увлекает» — наверное, не совсем то слово. Скажем так, для меня это было естественным продолжением той работы, которую мы делали и в телекоммуникационных компаниях. Когда я разрабатывал CRM, она звучала примерно
Speaker A
которым ты пользуешься, да? То есть вот как ты стал сапожником с сапогами ифицировал свои процессы разработки, ну, ту же самую платформу, которую вы делаете, или проекты. Можешь рассказать про вот этот набор инструментов, чем ты пользуешься, как?
Speaker A
так: мы хотим всё знать о наших клиентах, о тех людях, которые пользуются нашими инструментами, и понимать, что у них происходит. И фактически в некий момент я понял, что мы знаем очень много о клиентах. Мы знаем, чем занимаются наши сотрудники в
Speaker A
Ээ и и прямо будем смотреть. А может сразу, кстати, сказать, что за инструмент, чтобы не не этот не как не откладывать на потом, чтобы было сразу понимание, к какому дему он готовится. Коротко инструмент, ну, название его devaptify, но там основная
Speaker A
колл-центрах буквально по секундам, но мы очень часто не можем сказать, чем занимаются разработчики. То есть большие руководители, тимлиды очень часто говорят: «Я всё понимаю, я всё знаю». Но в некий момент стало понятно, что если ты начинаешь действительно задавать
Speaker A
поверхностей, через которые разработчик уже сейчас может создавать код. И более того, сейчас он, если он раньше писал код один, садился, то теперь появились агенты. И тоже нужно понимать, что он делает сам, что происходит параллельно и так далее. И в принципе вот этот как бы
Speaker A
глубокие вопросы, то реальную картину очень трудно сложить. Внедряются многие инструменты, трекеры, гиты, которые позволяют что-то снимать как информацию. Но на самом деле мы не всегда понимали, что делает разработчик, какой у него
Speaker A
Я такое немножко отклонение. Когда работал много лет назад, у меня была коллега, которая работала до этого на водонасосной станции, и она говорила, что самая проблема, когда начинается турбулентный поток и и тогда идёт пыль, муть и всё, начинаются проблемы с водой.
Speaker A
клиентский путь и чем он занимается в конкретное время. И в принципе это было вполне нормально, пока изменения происходили не так стремительно. Раньше ты занимался разработкой, накапливал опыт, и потом на этом опыте мог достаточно
Speaker A
даже не выровнялись как достаточно маленькая команда именно с точки зрения правильности планирования вот этого ламинарного потока.
Speaker A
долго жить. Ты понимал, сколько какие задачи делаются. Эта задачка маленькая, там два дня, это четыре, один разработчик синьор и так далее. А в тот момент, когда мы начали заниматься внедрением ИИ полтора года до GPT, а за два даже, то
Speaker A
достаточно большом объёме затраченные токены, да, и поэтому мой набор инструментов, он состоит там из нескольких подписок разных инструментов.
Speaker A
есть тогда была только одна компания, Tabnine, которая этим занималась, стало понятно, что жизнь разработчика может кардинально измениться: меняется то, как он будет работать, меняется то, как его нужно считать, изменится всё, включая оценки. И стало понятно, что
Speaker A
Ээ с одной стороны есть кодекс, я его называю фронтдером, справа клодэнer, ну и и для дополнительных исследований.
Speaker A
нужно что-то, что позволит понять, что произойдёт. Это позволит тем руководителям, которые пытаются руководить разработчиками, вообще понимать, как меняется жизнь разработчика, что он делает, как он делает в новых условиях, как он сейчас применяет агентов. Потому что предыдущий опыт становится, ну, во
Speaker A
понятно, что многие инструменты не исчезли, они всё равно остались и стандартные. Знаешь, у меня примерно те же инструменты есть, но у меня ещё OpenCД используется и у меня часть есть линуксовых компов. Мне нравится там как раз код с какими-нибудь китайскими
Speaker A
многом бесполезен, я бы так сказал.
Speaker A
знаешь, там с локальным инфиденсом поиграться или эвалы какие-нибудь погонять. ну, достаточно мм детерминированны, ну, простые, где не нужно, ну, долго думать. И обычно у тебя там какой-то комп, ну, в смысле, сбоку стоит, шушит, вот, а ты обычную работу
Speaker A
Угу. Я тебя понял. У меня похожие мысли бывают относительно того, что годами накопленный опыт, благодаря которому ты мог стать умудрённым жизнью инженеринг-менеджером, инженеринг-директором, человеком, который как-то прочувствовал, как работают инженеры, как выглядит процесс разработки и может принимать осознанные решения, стал всё менее актуальным. Когда в нашу жизнь начали входить новые инструменты, ты должен понимать, как сейчас выглядит работа, какими инструментами пользуются руками, какие есть возможности, чтобы понимать, на что способны твои команды, и как меняются процессы. С учётом этого я хотел задать небольшой, конкретный вопрос про набор инструментов, которым ты пользуешься. Как ты, будучи сапожником с сапогами, ифицировал свои процессы разработки, ту же самую платформу, которую вы делаете, или проекты? Можешь рассказать про этот набор инструментов, чем ты пользуешься и как?
Speaker A
подписки на них и дальше учишься их вместе, ну, использовать заодно и проверяешь, насколько у тебя переиспользуеммы между разными моделями, разными ханосами, те же самые скилы, Agence, MD, ну там и другие вещи, потому что зачастую ты хочешь, чтобы не было
Speaker A
Ну, первое, что могу сказать: тот инструмент, который мы создаём, мы сами им пользуемся. И я буду показывать пример прямо из реальной жизни команды. Это не какое-то демо. Увидим, как люди работают параллельно,
Speaker A
Тут получается сразу экономическая целесообразность практически умирает. Ээ поскольку сейчас дотация, ну, то есть стоимость в токенах там 10-20x получается, то есть он становится не конкурентноспособным инструментом.
Speaker A
и будем смотреть прямо на процесс. А может, сразу сказать, что за инструмент, чтобы не откладывать на потом и было сразу понимание, к какому демо он готовится? Коротко: инструмент называется DevAptify, но основная мысль в том, что мы поняли, что если хотим понимать, что происходит у разработчика, мы должны встроиться в те инструменты, где он живёт. Если раньше это была только IDE, то теперь это браузеры, это Slack, достаточно много
Speaker A
прямо вот умеют зажигать с одним вот с одними промтами, с одним подходом, с одним инструментом. Просто берёшь другую модельку, и она становится такой: "Э-хей". вперёд. Так что, да, вот всё-таки у модели не только есть там крутость с точки зрения написания кода, но на самом
Speaker A
поверхностей, через которые разработчик уже сейчас может создавать код. Более того, если раньше он писал код один, сидя за клавиатурой, то теперь появились агенты. И нужно понимать, что он делает сам, что происходит параллельно и так далее. В принципе, этот инструмент позволяет нам, в том числе, понять, как выровнять поток.
Speaker A
Он, да? действительно интересный, но там, по-моему есть в Artificial analisс, чего только нет. Ну, то есть разных банчей есть, по-моему, и про характеры моделей. Вот.
Speaker A
Я немного отвлекусь. Когда я работал много лет назад, у меня была коллега, которая до этого работала на водонасосной станции, и она говорила, что главная проблема, когда начинается турбулентный поток, тогда идёт муть, и всё, начинаются проблемы с водой. В принципе, сейчас мы находимся в этом турбулентном потоке. Я даже покажу на графиках, как мы что-то ускоряли, оценки падали в одну сторону, потом в другую. Мы на самом деле ещё для себя
Speaker A
Вот. демо будет. Это прикольно. А на каком масштабе вот такие инструменты уже нужны? Ну то есть как бы сколько должно быть человек у тебя в компании, в команде, чтобы имело смысл ээ ну собирать вот эти все трейсы, все
Speaker A
не выровнялись, как достаточно маленькая команда, именно с точки зрения правильности планирования этого ламинарного потока.
Speaker A
до 10ти человек. Согласен. То есть там, наверное, такого инструмента не надо, поскольку ты управляешь маленькой командой, и ты, в принципе, знаешь, чем люди занимаются. Хотя вот если уж там брать наш опыт, то даже нам оказалось полезно даже на наших маленьких
Speaker A
Это чуть позже. Что касается инструментов, подход достаточно прагматичный и, опять же, обоснованный некой финансовой экономичностью. Все знают, что есть много инструментов лучше и хуже, но также все понимают, что сейчас существующие подписки во многом компенсируют достаточно большой объём затрач
Speaker A
инструменте там можно выставить ограничение, что человек может видеть только себя либо может видеть свою команду. И тогда он понимает там, кто делает сколько задач, то есть кто как использует иишку, кто там больше токенов, кто меньше, какие модельки используются. То есть достаточно много
Speaker A
информации, которая позволяет то, что мы называем повысить прозрачность в команде и доверие. Ну либо найти проблему, если она есть.
Speaker A
А, и некоторые вещи, особенно вот в стартапах, когда люди даже не всегда понимают, а сколько человек работает.
Speaker A
Вот, скажем, из трекера не всегда понятно, он сидит там ночью или не сидит ночью. А я сейчас сегодня покажу прямо пример, где видно там подсказка. Смотри, там у тебя человек в полночь зашёл и что-то делал и он 12 часов работал. А ты
Speaker A
вообще посмотри, что у него происходит. Ээ, может, он застрял где-то, а тебе, ну, не хочется ему тебе жаловаться, а ты просто видишь, что он перерабатывает. И нали на выходном вышел, вышел, полдня выходных работал. Тоже такой пример покажу. То есть вот
Speaker A
некоторые вещи, когда э первое техлит может упустить, а второе вот мы все технори интроверты, и нам трудно разговаривать с людьми.
Speaker A
И мы сделали вариант, когда по аналитике, по человеку мы подсказываем технорю, о чём спросить человека, где у него могут быть проблемы, вот подсказать вообще о чём поговорить, на что обратить внимание, да? Потому что, э, то, что я думаю, и это вот прямо происходит
Speaker A
сейчас, что вот это умение разговаривать с людьми, э, понимание то, которое сейчас нужно технарям, оно прямо опускается на джунов.
Speaker A
ээ, которые должны общаться с агентами. И на самом деле вот аналитика наших промптов, которые тоже мы сейчас делаем внутри, показывает, что Тимлид с агентами быстрее добивается результата просто потому, что он понимает, как с ним разговаривать, понимает, что ему
Speaker A
нужно объяснить и добрыми словами сказать. А молодые люди очень часто матерятся без вопроса. Не потому, что это плохо, а просто потому, что они эмоционально пытаются заставить сделать то, что агент не понимает. Это на самом деле так же, как и и с людьми. И вот это
Speaker A
сказать проблема, что нужно всех уже стажёров учить коммуникационным навыкам и смотреть, где возникают проблемы. Она сейчас вне фокуса текущих темдов, потому что у них нет такого очень часто опыта, да. Вот нет понимания, что молодых надо этому уже спрашивать, учить, помогать им это
Speaker A
делать. И поэтому вот этот инструмент в том числе полезен и нам. Вот мы смотрим, как меняется команда.
Speaker A
Да, это интересно. Но, знаешь, это как раз продолжает там тезисы, которые я там с другими гостями обсуждал на тему того, что инженер как будто становится менеджером, но менеджером агентов, и ему нужно уметь коммуницировать фактически с, ну, вот уже не с людьми, а с
Speaker A
агентами. Ээ явно выражать, ну, свои мысли, уметь давать обратную связь, как бы работать. Ладно, с возмножениями работать ему не нужно, да, но если там, например, агент тебе застрял, не поможет, если ты ему скажешь: "Старайся, ну, больше". Да, надо всё-таки как-то
Speaker A
разобраться, понять и дать какую-то, ну, направление так, чтобы он мог сдвинуться с места. Но давай мы к агентной разработке чуть позже вернёмся. Мне кажется, классно чуть поговорить по тему на тему developer productдуity, ну, на тему продуктивности инженеров. Почему?
Speaker A
Потому что, э, то, как ты описывал свой, мм, свой путь, да, к ээ этой платформе, а он был как раз про то, что хочется понять, а что делают инженеры, да, ну, что у них получается, что нет, ээ, как
Speaker A
бы какими они инструментами пользоваться и так далее. Можешь немного рассказать про то, как вот ты на эту тему смотрел, ну, вот как-то системно, да? То есть что такое продуктивность инженеров для тебя?
Speaker A
как её можно оценивать, как, не знаю, по каким осям, какие данные для этого нужны. То есть, как бы, кажется, тема важная.
Speaker A
Ой, очень интересная тема. Я могу сказать, что в эту тему я заходил примерно раз семь [смех] всё время с разным с разным результатом.
Speaker A
И фактически можно сказать, что мы по-разному, в разное время по-разному пытались решать эту проблему и двигались циклами, условно говоря, как-то ни странно, поднимаясь всё выше и выше. Я попытаюсь объяснить, что это такое. Вот поскольку мы занимались разработкой, понятно, что есть некоторые вещи. Вот
Speaker A
есть люди, есть департамент, который занимается производительностью да например эффективностью разработчиков. У него есть IT-руководители, а дальше есть бизнес-руководители.
Speaker A
И в принципе бы вот наш жизненный цикл, он был примерно таким образом построен. То есть сначала мы придумали метрики для финансистов.
Speaker A
Потом, когда мы пришли к руководителям ИТ, они сказали: "Это всё классно, это не то, что нам надо". Ээ, а потом, когда мы после этого пришли к бизнесу, они сказали: "Ну, ну да, я просто лучше на примере расскажу". То
Speaker A
есть, в принципе, мы начали с того, что занимались искусственным интеллектом, начали считать, какой процент кода создаёт искусственный интеллект в Сбере. И процесс пошёл достаточно энергично. И у нас в некий момент там количество создаваемого нового кода приблизилось к 50%
Speaker A
ишкой создаваемою. Ну то есть мы могли, поскольку у нас были инструменты и дэшка наша, и плагины наши, мы чётко понимали вот прямо до символов, сколько у нас чего создаётся. И мы с этим радостно пошли. И на какой-то встрече руководству
Speaker A
сказали: "Вот мы сейчас генерим 50% кода иш". Он говорит: "Спасибо, я могу уже завтра сократить 50% разработчиков?" Мы такие сказали: "Нет". Он говорит: "А10".
Speaker A
Я го Нет. А5: "Нет". Почему? Потому что, ээ собственно производительность разработчиков мало, наверное, кого интересует, а всех, наверное, интересует полный процесс и каким образом вот эта эффективность будет выражаться для бизнеса.
Speaker A
И в итоге мы прошли путь, когда мы отсрочек кода дошли до количества пулреквестов. И это мы договорились с бизнесом. То есть мы просто посчитали количество пулреквестов на человека, да? Причём мы считали всё честно.
Speaker A
Сберу - это легко. Есть большое количество команд, есть контрольная группа которая не знает, что она контрольная. Есть группы, которые работают. которые используют и инструменты. И мы в некий момент поняли, что как бы реально там, не знаю, количество полреквестов увеличилось там на 10%. То
Speaker A
есть мы там статистически доказали, что идёт улучшение. И тут пришёл бизнес и сказал: "Всё классно, но я не вижу в результате".
Speaker A
И тогда стало понятно, что для бизнеса нужны ещё одни метрики, то есть количество задач.
Speaker A
Э, ну, в конце концов, мы договорились про количество задач, поскольку это, наверное, только та метрика, которая не углубляется в финансовый результат, который очень трудно посчитать от отдельной фичи, но в то же время позволяет бизнесу оценить, насколько ускоряется разработка её
Speaker A
функциональности. К чему я это всё говорю, что на самом деле не существует серебряной пули одной метрики. На самом деле всегда должно быть набор метрик на разных уровнях. И с другой стороны должен быть набор контрметрик, которые те эту метрику приземляют.
Speaker A
Условно говоря, если ты пишешь больше кода, ты должен проверять, а насколько больше багов у тебя стало или возвратов.
Speaker A
Если ты как бы смотришь на задачи, ты должен понимать, какой объём задач, чтобы не получилось, что люди просто их побили на более мелкие и этим решили свою метрику. То есть всегда должны быть корецелён корреляция по метрикам. Но что
Speaker A
самое главное, это та метрика будет полезная, о которой вы договоритесь с бизнесом. Вот я я вот так скажу, вот то, что бизнес готов признать за результат и что он хочет увидеть, именно то и будет вашей ценностью.
Speaker A
И именно это вы должны научиться считать, по большому счёту. Вот как-то так. Это, кстати, очень хороший тезис. Это многие вещи, которые я тоже упорно объяснял, сказал. Например, история про невозможность там взять одну метрику, что тебе нужна система метрик,
Speaker A
про балансирующие метрики, да, контрметрики, которые позволяют, ну, почелленджить основную целевую метрику и проверить, насколько она, ну, скажем, не бумажная, да, с размером задач историю.
Speaker A
У меня был реальный пример, э, в жизни, э, ну, у меня были там delвеy-менеджеры на управление, по-моему, фронтовая какое-то, и на очередной встрече там они мне показывают результаты, по-моему, там за чуть ли не за последние полгода. Ну, типа очень решили показать, как они
Speaker A
удано поработали. показывает, что, условно говоря, ну, полугодие к полугодию пропускная способность команды выросла по задачам в два раза, ну или там 50%, ну, прямо сильно значимо. Вот я спрашиваю: "О'кей, как вы это трактуете?" Ребята: "Ну вот мы же старались". Вот. Вот. Я говорю: "А
Speaker A
вы на задачи смотрели?" Они такие: "А что с задачами?" Я говорю: "Ну, смотрите, в прошлом году вот было очень много платформенных задачек, которые мы делали для того, чтобы у нас появился общий инструмент на платформенный, для того, чтобы дальше продуктовые
Speaker A
изменения, ну, по переезду с старого решения на новое, можно делать было как горячие пирожки". Вот так вот. Вы показываете мне общую по платформенным продуктовым командам. Вот. И, ну, какой-то объём вот задач, ну, вот как бы в прошлом полугодии был такой. Потом мы
Speaker A
к концу полугодия это доделали. И, ну, выкатили, отдали продуктовым командам. И, ээ, часть платформных команд, как enйблинг team работала, но помогала, ну, это решение затащить. И дальше мы продуктовых задачек и ну станиц принесли вот, ну, типа очень много. Ээ там они
Speaker A
как задачи оформляли, всё нормально, но профиль задачи поменялся. И дальше, ну, вот вы мне показываете график, говорите, что всё всё замечательно, что вы поработали. Я спрошу: "Почему вы мне не можете ответить?" Ну, типа, ну, смотрите, ребят, вы как бы тут не
Speaker A
четырили, ничего, но вас самих-то не не смутило, ну, вот такой, ну, как бы сильный рост. То есть вы вы захотели сделать deep пдайв, понять, что не так, короче говоря. Ну, то есть можно ли атрибуцировать это всё на успех, не
Speaker A
знаю, вот этих процессных изменений, которые вы рассказывали. Ну, в общем целом, и это ещё были хорошие ребята, понимаешь, да? То есть они типа действительно работали, не помогали этим изменениям случиться, да? То есть они сопровождали эти процессы просто, э, как
Speaker A
бы недостаточно глубоко проработано. Я видел кучу примеров, где люди, условно у них на графиках ээ должно быть, ну, попадание в какие-то ожидания по длине задач. Они, когда не попадают по длине, ну, они берут, трешат задачу, заводят новую и закрывают её там, условно, через
Speaker A
неделю и говорят: "Идеально, наши задачи просто замечательные". И ты такой думаешь: "Ну, о'кей, если нужно красить траву, вот эти люди будут красить траву, чтобы их там метрики были зелёными". Так что, [фыркает] ну, это очень забавно. А знаешь, ещё какой момент ты не упомянул?
Speaker A
Иногда есть момент, когда тебе говорят: "А мы хотим сравнивать команду А с командой Б". Ну, например, команду, которая, не знаю, спецпроекты делает, какие-нибудь лендинги, и команду, которая, не знаю, процессинг банковский делает. Вот хотим, ну вот хотим вот так
Speaker A
вот сравнивать, типа команду с командой, человека с человеком. Ты говоришь: "Ребята, у них профиль работы разный".
Speaker A
Тебе говорят: "Ничего, ты же можешь универсальные метрики сделать". Ты такой: [смех] "И можно сделать любые метрики вопрос: какие выводы будете делать из них?" Слушай, с с метриками, на самом деле, очень интересная вещь. У нас в Сбере такая и сейчас осталась была
Speaker A
достаточно хорошая аналитическая команда. И на самом деле в некий момент времени просто после аналитики, вот как команды меняют там свои скорости, как меняется численность, как меняется структура, мы поняли, что вообще жизнь команды, она становится всё более динамично. И на самом деле, э,
Speaker A
фактически, когда ты оцениваешь команду, нужно не только понимать, это там продуктовая или платформенное, на самом деле нужно понимать, в какой момент жизни продукта эта команда существует.
Speaker A
Э, потому что с точки зрения начального этапа просто жизни, затухания команды, там могут быть разные показатели, и при этом они могут быть совершенно разные. То есть команда, когда продукт заканчивает жизнь, вообще может мало деливерить, да?
Speaker A
То есть у него вообще задача другая. То есть спокойно дать продукту дожить, иногда быстро там исправляя какие-то ошибочки. Это как бы с точки зрения летаейма команды. Второе, что команда у продукта на самом деле тоже может и на самом деле должна меняться, потому что
Speaker A
на разных стадиях продукта вначале должны быть инноваторы, потом должны быть такие, я бы назвал их производственники, а в конце без обид должны быть люди, которые не очень амбициозны, должны дать спокойно дожить продукту, как бы спокойно жизнью. Это просто другой
Speaker A
психотип людей. Потому что только вот когда на определённом этапе ты понимаешь, какие люди нужны, тогда они наиболее эффективны, потому что иначе начинают из команды уходить, аначе всё время там приходит спокойный умирающий продукт, амбициозный и сразу уходит. У тебя
Speaker A
получается поток постоянно вот эта турбулентность. Вот. И поэтому на метрике вообще нужно очень аккуратно смотреть и понимать, в какой точке жизни продукта и команды вообще всё это существует.
Speaker A
Я лет пять назад рассказывал на Хайлоде доклад про роль сео и как она зависит от жизненной стадии компаний, да, и, ну, то есть, условно говоря, от стартапа до корпорации, то есть стартап скила какая-то уже такая, ну, бюрократическая машина, где ты извлекаешь там ценности и
Speaker A
у тебя как раз ламинарное течение, как ты неплохо отметил. То есть у тебя вот процессы появляются, бюрократия, и есть момент, когда у тебя рынок сжимается, и ты уже играешь играешь скорее в косткатинг для того, чтобы, ну, маржинальность в продукте оставить
Speaker A
определённую. У тебя уже нету какого-то м задела на расширение доли рынка, да, на получение дополнительных прибылей за счёт роста, но у тебя есть задел на то, чтобы более эффективно сёрвить текущих клиентов. И, ну, фактически у тебя такая дойная корова для других бизнесов
Speaker A
получается, да? [тяжело вздыхает] В общем, прикольно, прикольно. А давай теперь с тобой чуть-чуть двинемся в сторону агентной разработки. Вот мы классно поговорили про метрики, девелопер, продуктивити, даже про твои личные инструменты, но давай немного поговорим про то, а как агентная
Speaker A
разработка выглядит вот с точки зрения мм как бы компании. То есть что меняется-то? Ну, то есть как выглядит производственный процесс, где там инженеры, где агенты, может быть, с собой Darkфактори обсудим, насколько мы близкие к ним. То есть, ээ, мне кажется,
Speaker A
что это классная подводка будет к тому, как мы уже к Devtify перейдём и ты, ну, начнёшь показывать сам продукт.
Speaker A
То есть я вот долго пытался пытаться понять, будет ли что-то кардинально меняться, потому что когда мы 2 3 года назад у нас была такая строцессия, и у меня там было много лозунгов, там процесс разработки полностью изменится и или не или не изменится. И мы так
Speaker A
долго пытались понять, ээ, и как он выглядит, что он вообще будет совсем другим, но постепенно как-то я начал, видимо, возвращаться к мысли, что вот с точки зрения там глобальных подходов создания, может быть в ближайшее время и ничего не
Speaker A
изменится. Ну, скажем так, если мы кардинально не перейдём там в некое другое создание софта, когда сейчас уже есть такие примеры, когда софт генерится на литу, то есть у тебя есть задача персонализированная, ты, человек кликает на какую-то закладочку, в это время код
Speaker A
разрабатывается собирается запускается, и он получает уже там прямо кастомизированный продукт под себя. В принципе, сейчас такие уже похожие реализации есть в некоторых играх. когда можно пройти. И вот именно там эти новые комнаты, они прямо генерятся в ходе твоего создания, прохождения. Это тоже
Speaker A
как вариант такого, наверное, немножко вообще другой жизни. Но если пока мы будем идти там по пути стандартного создания кода, то по большому счёту я бы агентов мне нравится, это моё личное ощущение, рассматривать просто как сотрудников, потому что вот
Speaker A
сейчас в новой компании, которую мы делаем, мы как раз попытались для себя решить задачу, а что человека, когда попытались понять, что такое хороший агент, да, вот как он становится хорошим агентом, там что-то, что это такое. Поняли, что мы должны
Speaker A
понять, а что человека делает хорошим агентом, хорошим работником, да? Вот какие у него знания должны быть, там базовые знания, это моделька, какие-то корпорати, ну, специфические знания, он должен уметь, не знаю, там писать код. У него должны быть инструменты, в которых
Speaker A
он должен уметь работать. И вот это нас там подвигло к такому термину, как Agentics user Experience. AX Agentic Experience, то есть должна быть среда.
Speaker A
которая позволяет агенту работать. И последнее, он должен знать свои ограничения, что он может делать, что он не может делать. По большому счёту, вот ничего как бы нового от сотрудника, да.
Speaker A
Ну и пятое, последнее, как он должен заходить в компанию легко. Вот и мы там как бы сейчас посмотрим, чтобы вместо глубоких интеграций иногда делать обычное интервью. Поговорил с начальником, он тебе рассказал, что можно делать, что нельзя делать. Ты всё это все записал
Speaker A
агент, и это вот твои правила. Или он сгрузил в тебе какую-то документацию, определил тебя как А ты не думал, что интервью агенту вот скоро будут делать? Ну, в смысле, ты приходишь, говоришь: "Я вам сделаю агентов". Они такие: "Давай-ка мы с
Speaker A
твоим агентом пообщаемся". Нене, вот я же я же как раз это и сказал, что мы поняли, что Да, да, но ты ты сказал про анбодинг агента через вот, ну, начальника, да, поговорил. Я говорю, что в обратную сторону начальник будет говорить: "Не,
Speaker A
не надо нам, ну, рассказывать про то, какие ваши агенты". Мы им, короче говоря, сейчас устроим, короче, какой-то этот А это, кстати, вполне может быть, да, по большому счёту, ты должен, то есть должен понять, ээ, какие-то граничные условия, что-то поспрашивать и и как он
Speaker A
это делает. Вот именно поэтому, как это ни странно, вот эта как бы тема цифровые сотрудники, да, она как бы мне а так проще и для себя воспринимать.
Speaker A
Во-вторых, когда я общаюсь с агентом как с цифровым сотрудником, я понимаю, то есть, ну, условно говоря, я приближаю к себе вот как я жил в жизни, да, что я спрашивал с людей. И это людям позволяет проще сделать вот этот шаг, не какой-то
Speaker A
там непонятный агент какое-то железо, а ты должен за ним следить, ты должен с него спрашивать, ты должен понять, что он имеет ограничения.
Speaker A
Также есть джуны, там моделька санет, такоя вот задачка, опус такая задачка. И это просто позволяет воспринимать весь цикл разработки с точки зрения стандартного потока. И и дальше ты просто вот этих новых агентах ставишь на разных этапах, и у них есть разный
Speaker A
уровень автономности. И вот ты свой процесс, в том числе строишь настолько автономно, насколько ты доверяешь этим агентам, по большому счёту, насколько ты можешь им доверять, настолько ты им даёшь им уровень доверия там по принятию, не знаю, тех же пулреквестов.
Speaker A
Я вот мы у себя в некий момент поняли, что там вот последние модельки пишут уже настолько хорошо, что ты за ними уже там, когда они делают ревью, ты уже я я ничего уже не могу там дать полезного.
Speaker A
Ну, условно говоря, я понимаю, что я не могу ни такой объём посмотреть, ни ничего не могу от себя толком добавить, потому что они пишут код уже достаточно хорошего уровня. И поэтому как бы фактически там код ревью уже как бы
Speaker A
очень часто не проводится только на каких-то сложных задачах, а так вот простые задачи уже идут просто напрямую.
Speaker A
Я, знаешь, сейчас, может, пошарю картинку. Я тут делал, м дней пять назад мм ревью ну, в смысле, вот на таком же выпуске, только про всякие пейперы, про агентные обвязки, ээ, ревиил даже не обвязку, а была история от Anтроop то, как
Speaker A
поменялась работа внутри антропик, да, и там было очень прикольно, что, во-первых, там рассматривали не только инженеров, а и других ребят. Плюс, эээ, ну, я назвал этот выпускропик, что остаётся человеку в компании агентов. И что там интересного было, что у ребят,
Speaker A
ээ, был такой график, э, где они показывали, а, сколько аутпута выдают агенты, ну, условно говоря, сколько от них выхлопа, да, и можно ли этот выхлоп на самом деле даже прочесть просто. А, и сейчас я пошарю экранчик и покажу тебе вот эту штуку. Мм,
Speaker A
смотри, это, э, за неделю э агенты, которые, ну, которых попросили что-то сделать инженеры или исследователи, то есть это именно агенты, которые триггерятся людьми. Вот они сгили 424 часа [смех] чтения аутфута их и как бы там вот в принципе
Speaker A
не в человеческих силах это всё прочитать. То есть это в принципе ну нереально. Не нереально. То есть ну мы с этим же столкнулись. Там у нас динамика вот по команде у нас показывается, сколько человек пишет руками, сколько пишет кодом. И ты
Speaker A
просто понимаешь, что ты физически, если ты начинаешь ревью, ты становишься бутылочным горлышком. Значит, ты должен, как процесс ламинарный, ты должен все бутылочные горлышки расшивать.
Speaker A
Соответственно, значит, сейчас ревьюинг, и даже у нас там где-то видно, он там даже у нас там периодически бутылочное горлышко, там где мы ещё не совсем доверяем. Но, к сожалению, я думаю, что это будет чем дальше, тем больше. Я даже
Speaker A
более скажу, что в принципе вот сам процесс производства продукта, да, похоже, как бы немножко меняется, поскольку раньше была очень длительная продуктовая часть, где был дизайнер, ээ, который рисовал, потом были исследователи, которые делали аналитику на людях, какие-то формочки рисовали, те
Speaker A
их прокликивали. И в принципе всё это делалось только потому, чтобы потому что код писать было дорого, и ты как бы делал все предварительные этапы для того, чтобы, ну, прикинуть, а как эта функциональность будет жить. На самом деле сейчас ты можешь просто
Speaker A
за короткое время генерить этот код функциональный, выкладывать его на а-тестирование на пять человек, и они прямо вживую могут смотреть, и ты это можешь делать гораздо более точную аналитику. То есть вот сам жизненный цикл продукта ончи может, ну и на самом
Speaker A
деле он меняется, да? Смотри, вместо того, чтобы сделать презентацию по продукт, просто сделай продукт и покажи. Я бы правда отметил что, ну, пять пользователей обтест тебе стат значимость никакую не даст. Вот.
Speaker A
Так что это скорее, ну, вариант типа посмотреть глазами и потом тебе всё равно на кого-то нужно катануть. Но, знаешь, я хотел ещё одну вот такую показать историю. Эторопик, где количество, ну, фактически агентских часов, которые были опять стриглены людьми, да, то есть розовое - это все
Speaker A
сотрудники, синенькая - это всякие RnнD подразделения, ну, в смысле, инженерные. И видно, что условно где-то в апреле инженеры пробили паритет один к одному, то есть агентов. А сейчас ну условно в сентябре уже там 19 раз больше агентского времени
Speaker A
на ну чем и людского приходится. И к чему-то приходит приводит, что у тебя на самом деле вон там комитов на инженера стало там в пять раз больше. Но я к чему, это примеры из антропик, да, понятное дело, у них там безлимитные
Speaker A
токены, короче, сколько хочешь агентов спаунишь и фронтильные модели. Но если смотреть на результаты, например, ребята из НТОК рассказывали, как они написали, да, ну, [фыркает] фактически это, ну, система контроля версий, которая позволила им обработать, то есть у них с
Speaker A
мая по сентябре количество мквестов выросло в 12 раз. с 2.500 в день до 30.000 в день. Ну а понимаешь, да, они в 12 раз не выросли по количеству людей.
Speaker A
То есть это агенты нашмаляли. И вот дальше крутись как хочешь. [смех] Как как это переживать? Если бы это всё проходило через ревью людей, ну, Любеди, наверное, бы вскрылись там. Мы просто сказали: "Сранян, ребята, мы не можем столько ээ ну столько отревьюить, и они
Speaker A
бы просто ЛГТМ бы бахали, да, кто to meе. Соответственно, я я советую всегда смотреть это, ну, как бы немножко оглядываясь назад. Как человек, начинавший с перфокартами, мы же мы же не не смотрим за ээ компиляторами тот двоичный код, который
Speaker A
они написали. Ну, как бы условно говоря. Хотя там в начале там разрабатывали на ассемблере, отслеживали там стейки всякие и и там были ошибки. И сейчас есть ошибки в компиляторах. Есть, есть там, ну, их меньше, да, но, в принципе,
Speaker A
новые какие-то всегда есть. Соответственно, это то же самое. Мы же там не смотрим весь код двоичные. По идее, если ты не доверяешь, ты должен везде доверять. А то, знаешь, у нас какой разговор, я там суперпрограммист, а спроси, как там спринг, да, там
Speaker A
реализован. То есть ты я его использую, а вот а на самом деле как бы а сколько реально кода твоего в использовании? То есть вот мы там в Сбере, когда делали аналитику по продуктам, у нас как наш код самый секретный, самый лучший.
Speaker A
Сделали аналитику, оказалось, что 70% кодасоourсного затянуто. туда там, причём неважно, там с джипэльками какими-то. Причём, если агент хоть проверяет лицензи, могу сказать, проверяй лицензию, он будет исполнять.
Speaker A
То как бы разработчик, он там качает, что накачал и и то ладно, всё, всё пойдёт путём. А у меня один из инженеров когда-то, знаешь, это куски бездидра копировал в свой код там движка для знаешь для [откашливается] сплита трафика
Speaker A
абплатформы, короче, ээ там десятняя давность. Мы потом спрашивали: "Гриш, зачем?" У Гриш ответа нет. Он очень си просто любил C++ уже не котировался. И в общем целом библиотеки подключать он тоже не любил.
Speaker A
Надо было вот, значит, найти хороший кусок кода и скопировать к себе. Вот. Ну, в общем и целом на тему лицензий.
Speaker A
Эта лицензия не позволяла так делать, свой продукт втягивать. [смех] [тяжело вздыхает] Смотри, кажется, мы про агентную разработку чуток поговорили, взгляды сходятся. Давай теперь перейдём к самому продукту DevoptiFi. Что это такое? Ну, ты чуть-чуть рассказал, но ты можешь подробнее сейчас рассказать, показать,
Speaker A
ну, продемонстрировать. Мне кажется, что, ээ, пользователям будет интересно вот увидеть продукт такого класса. Давай. Я не буду описывать всю функциональность, потому что там достаточно много вещей. Мне просто кажется так чтобы не заскучать, поскольку он реализует всякие стандартные метрики. Я скорее
Speaker A
покажу вот как можно посмотреть на работу. команды одним взглядом и что можно увидеть. Так, сейчас так.
Speaker A
Угу. У тебя есть возможность презент делать? Ну, под подтянуть экранчик, если О, всё отлично. Сейчас мы эту stage сделаем.
Speaker A
Так, ну, у меня просто сейчас только этот экран будет, поэтому я потом когда остановлю. Так. Угу.
Speaker A
Демонстрация идёт, правильно? Да. Да, да. То есть, [откашливается] буквально, ещё раз напомню слово. То есть мы в некий момент поняли, что мы хотим понимать что происходит у разработчика. И чтобы понимать, что происходит у разработчика, нужно жить в тех инструментах, в
Speaker A
которых, э, он в текущий момент работает. И в принципе вот сейчас я открыл там дшборд команды, и на самом деле вот в этот момент времени я вижу буквально, кто чем занимается. Вот у меня несколько разработчиков прямо в онлайне не работают над этими задачами.
Speaker A
Это не то, что у них это выбрано ээ в джире, потому что в джире может быть или там в каком-то трекере там и пять задач в Н прогрессе. Это означает, что в этот момент времени ээ сотрудник работает именно над вот
Speaker A
этой задачей. Это, ну, скажем так, не столько, что нужно контролировать. Это просто позволяет посмотреть, кто активен, не активен. И, в принципе, показывает, что на самом деле мы именно ведём реальную активность людей. Теперь мы можем посмотреть вот что у нас за последние 7
Speaker A
днем. ней происходило с командой. Здесь есть некий набор вещей, которые я просто поясню. Тут на метрик много, но достаточно так важно. Вот есть метрика, которая вот центральная называется точность планирования. Вот сейчас это та одна из тех метрик, над которыми мы не
Speaker A
над метриками работаем, мы пытаемся научиться выстроить ламинарный поток. Метрика построена следующим образом. Влево. Это означает, что ээ люди недооценивают задачи, а вправо, что они переоценивают. И на самом деле просто вы сейчас видите результат, скажем так, второго этапа, поскольку на первом этапе
Speaker A
все занимались как бы переоценкой, говорили, эта задача делается там 5 дней, а потом делалась один день, и мы там пытались пытались как бы привести к точности планирования. И, к сожалению, для нас в некий момент это качнулось в другую сторону, когда появилась некая
Speaker A
эйфория от и инструментов, и у нас произошло, начала происходить некая недооценка. То есть вот это отклонение влево означает, что мы делаем сейчас команда делает задачи очень часто дольше, чем она спланировалась.
Speaker A
При этом, если посмотреть по работе, у нас тут, в принципе, распределение нормально. Люди работают в браузинге для исследований, код пишут. Ну и вот количество встреч 10% тоже отлично.
Speaker A
Ээ используем достаточно большое количество моделей. Здесь сводная может быть не столько показательная. Потом мы пойдём по людям. Я просто покажу, что вот нам очень важно, какие люди используют модельки иногда. И есть такое интересная вещь называется delivy. Это то, что делится руками. А
Speaker A
это ещё есть я Delivery. И в принципе это у нас такая так называемая вот контролирующая метрика. Скажу почему.
Speaker A
Потому что вот справа у нас есть такая продуктивность и сверху идёт продуктивность разработчиков. И вот она там типа 62% означает, что примерно половину времени в день человек занимается разработкой.
Speaker A
А снизу идёт ключ иишной разработки. Здесь видим, что вот иишка делает кода там вчной разработке в шесть раз больше. Но тем не менее как бы с точки зрения и delivy у нас нет такого прямо пере перевеса. Ну и в принципе можно на самом
Speaker A
деле посмотреть, почему. И тут мы для себя поняли, что у нас на самом деле очень много идёт Discovery. То есть, по большому счёту яишка используется в исследованиях, в на текущий момент написании кода мы используем её меньше. Это вот такая
Speaker A
картинка в первой с точки зрения, как идёт ламинарный поток команды и чего она вообще как бы делает.
Speaker A
А можно немного про классификацию задачи рассказать? Вот Discovery, Delivery. То есть у вас там какой-то классификатор стоит по, ну, типа промтам, которые улетают по запросам. То есть как-то вы, да, то есть у нас, да, в том числе стоит
Speaker A
по промтам и по тем задачам, которые потом идут в код и и которые не идут в код. То есть, в принципе, ну, то есть мы экспериментируем достаточно много с промктами, да, с аналитикой промтов. Ну, например, у нас там была такая фича,
Speaker A
которая там сейчас более детально исследуем, что если есть задача, у которой в промтах тональность меняется на истерическую, то значит задача может быть под срывом, потому что человек где-то, сказать, запутался в этой задаче, он её создаёт сиишкой и немножко
Speaker A
подзапутался. И это как бы такой сигнал, что надо на эту задачу посмотреть. Ну, это как пример, да, вот в в аналитике промптов.
Speaker A
которые происходит. И вы не смотрели разбивку по людям, потому что люди бывают, знаешь, характер стойкий нардический versusс характер там истерический.
Speaker A
А вот а это мы возвращаемся к моему, помнишь, предыдущему обсуждению в начале, что вот характер-то характером, но модельки-то на твой характер, знаешь, всё равно ей нужно уметь нормально объяснять.
Speaker A
Ну, условно говоря, вот, ну, простой пример. Есть и начальники разного характера, и вызывает сотрудника, который плохо отработал. И один говорит: "Ты сделал неправильно, нужно вот это поправить и вот это сделать и прийти, объяснить". А второй как бы полчаса
Speaker A
говорит: "Ты козлина, сделай нормально". Уходят люди. Вот какая вероятность, что второй сделает более правильно, чем первый? Дани никакой.
Speaker A
[смех] Смотри, у меня просто вопрос был не про то. нужно как, а про то, что это может быть не зависит, ну, не не только зависит от задачи и её возможности срыва, но и от психотипа человека, ну, его стиль общения. И ты слышал новость,
Speaker A
что антропик вроде говорила, что теперь, если ты будешь там условно их обижать модель, тебя ещё забанят могут.
Speaker A
Дада. Но я-то на самом деле сказал очень важную фразу: тональность меняется, да? То есть, когда ты живёшь в одной тональности, там всё время истеришь, то это не признак. А вот когда ты начал делать спокойно, а потом в некий момент
Speaker A
как бы ты начал немножко истерить. Ну опять же, это эксперименты, да? То есть я сейчас на самом деле многие вещи, о которых я говорю, это в том числе наши эксперименты над тем, что мы сейчас исследуем, как лучше понимать.
Speaker A
Не, это супер интересно, Владимир. Это супер прикольно. Ну, что вы, ну, типа, пытаетесь, ээ, вот по таким факторам, ну, собрать дополнительные какие-то дополнительную информацию и, видимо, её предоставить к, ну, руководителю, да, или там самому сотруднику, чтобы он понимал,
Speaker A
да. Ну, то есть фактически вот у нас здесь есть некие неделя, где можно посмотреть вот что люди работают. Вот здесь, ну, как бы стартап он и в Африке стартап. Вот видим, выходные дни люди работают, да, практически все. Мы на
Speaker A
самом деле можем посмотреть, а что же мы вообще, чем человек занимался в это время? И тут посмотреть, что, э, делал реализации, там, как делал миграцию, фокус продвижение нагрузка и встречи не было. На что обратить внимание, да? Что вот Иишка
Speaker A
преобладает и вот тут вот ночная работа в начале суток. А чего он там? Ну я здесь в данном случае знаю, что Антон просто делал миграцию, да, ну как обычно ночью, но по большому счёту вот это те вещи, на которые тоже можно обращать
Speaker A
внимание и которые руководителю помогают вообще понимать, что происходит. Не шариться там спрашивать всех, а просто зашёл и и посмотрел, что происходит ээ по сотруднику.
Speaker A
Дальше понятно, что у нас есть неделя. Ну вот, кстати, тоже интересная вещь, что вот неделя работы и вот есть разработчики. И вот, например, есть Антон, у которого он может как бы, если его раскрыть, мы увидим, что он как бы
Speaker A
делал 19 задач, из которых куча делал параллельно. Вот это вот у нас как бы лидер и разработки максимально её использует. Вот мы видим, насколько как бы он может распараллелить свою работу в течение там дня, по большому счёту. Дальше там увидим, каким
Speaker A
образом. То есть, если смотреть обычную команду, обычно ламинарный поток, одна задача в день, ну, как бы две там, и там вот по чуть-чуть она в течение недели движется. Здесь мы видим, что вот параллельность задач как бы у некоторых
Speaker A
людей очень сильно увеличивается. Ну, тех, скорее, которые привыкли, ну, в режиме такого менеджера агентов работать. Ну, то есть раздал задачи. Где же вопрос, что мы смотрим, вот когда мы делаем аналитику, мы пытаемся найти, кто это делает, и дальше ты должен
Speaker A
проанализировать, что этому позволяет делать и что не позволяет другим людям это делать, да, и людей подтягивать. Ну, потому что иначе, ну, сам понимаешь, что разрыв чем дальше, тем будет как бы накапливаться. И в конце концов Да-дада.
Speaker A
То есть это просто аналитика позволяет тебе посмотреть. Это вот самое правильное не говорить там плохие, хорошие люди. То есть мы должны понять, у кого не получается, и прийти к нему и чем ему помочь для того, чтобы у него
Speaker A
начало получаться там, не знаю, на какое-то обучение дополнительное, что-то ему подсказать. Но они, в принципе, и задачи могут разные делать, но просто видя эту картинку, ты можешь делать какую-то аналитику. Пока у тебя там аналитики нет, но ты можешь делать
Speaker A
только предположение, кто там лучше, кто хуже работает. Я согласен. Но Антон здесь выглядит как этот, как знаешь, аA чемпион, которого обычно отправляют. Мы сейчас к нему вернёмся. У него есть тоже как бы проблемы, да, которые мы сейчас чуть
Speaker A
позже вернёмся. В принципе, ну я, например, дальше ээ немножко буквально скажу. Вот здесь как бы по команде видно, что есть некое, в которой мы сейчас пытаемся разобраться, неравномерность, да? То есть вот в течение недели вот идёт такой вот как бы рост, как будто есть какие-то
Speaker A
вещи, которые потенциально в начале недели что-то нужно людям разогнаться почему-то. Ну вот как бы потому что по-хорошему должен быть опять же такой плюс-минус ламинарный поток, когда все люди делают задачи в определённом объёме. Здесь получается, что в том числе у нас не
Speaker A
всегда получается выдержать эту вещь. И, ну, как бы активность встреч, да, вот, ну, как бы из интересных вещей, ээ вот есть активность встреч. Тут, например, у нас тут получается какая-то встреча была вот 243. Ну, тоже иногда интересно посмотреть, что же это была
Speaker A
там за встречай, где сидело несколько человек, как бы, и долго обсуждали. Так, здесь встреча. Тут можно посмотреть примерно, что было на встрече.
Speaker A
Ну вот у нас разные люди инструменты используют. вот в некоторых встречах, да, то есть там, где мы как бы уже научились ээ вот сейчас не знаю, ну и мне достаточно, смотри, ответа. Ну что часть интеграции есть и в принципе
Speaker A
просто ээ ну только то делаем интеграции, что можно посмотреть вообще, чем обсуждалось на этой встрече, что там делалось, какие там решения были приняты.
Speaker A
А, ну тут было две встречи. Вот, да, вот длинная встреча. Вот, кстати, можно, да, посмотреть вот что обсуждали, какие приняли решения, поручения, кто какие получил. Вот как бы вот, ну, здесь то ли ретро делалось, ну, вот, ну, в принципе нормально, да, тут как бы
Speaker A
вроде полезно поговорили. То есть это, кстати, тоже такой вот как аналитики чего с этим делать.
Speaker A
Так, ну я я дальше дальше, наверное, сказать не буду это время тратить. Ну, кстати, вот интересная вещь инструменты, что как бы многие компании используют, например, там куча всяких подписок, в том числе там идей, ещё каких-то подписок. И здесь просто мы смотрим, а
Speaker A
чем реально пользуются. Если, например, там все начали переходить там в антигравити куда-то или там вр, по идее уже мало пользуется, то может надо вернуться, посмотреть, может там половина этих подписок надо уже отменить. Ну просто потому что люди начинают всё
Speaker A
меньше и меньше этим пользоваться. Это как такой вот аналитика, в каких инструментах люди продолжают работать.
Speaker A
Угу. Ну и возвращам очень очень интересно, короче, инструменты. А это доступно только тебе как руководителю или все могут про себя тоже посмотреть или на соседей по команде тоже? Как вы управляете?
Speaker A
Можно посмотреть на себя и в настройках можно выставить, чтобы видела команда. То есть это в настройках выставляется ээ команд.
Speaker A
Ну, если по человеку, вот у нас есть Антон, которого сказать уже несколько раз упомянули как яишного лидера.
Speaker A
И, ну вот у него видно, что как бы, да, у него проблемы с оценкой сейчас в другую сторону, да, но мы над этим работаем. Ну, по крайне мере видно, да, что я потом покажу другого человека, где точность прямо у него хорошая.
Speaker A
Видим, что у него вот он немножко разрабатывает, а всё остальное время у него там пашут агенты.
Speaker A
По большому счёту, в принципе, он очень много перерабатывает. Тут на самом деле жёлтеньким это просто он на удалёнке он сидит. На самом деле можно взять вот здесь любой день по нему клацнуть и по-хорошему можно посмотреть как бы чем
Speaker A
человек занимался в течение этого дня, то есть какие задачи делал, на что обратить внимание. Ну тут слишком много иш. Ну, ну, в принципе, похоже, да, немножко. Слишком много ишки, ночная работа и так далее.
Speaker A
На самом деле, как бы то, что ещё ты щёлкнул просто по воскресенью. Вот так-то.
Speaker A
А я специально воскресень [смех] щёлкнул, потому что что работал в воскресенье, это уже какой-то знак, что или срочная работа какая-то была, или он в принципе тотудоголик.
Speaker A
Ну, смотри, у нас же тоже нужно думать, чтобы люди не выгорали, да? То есть вот, в принципе, здесь мы как раз работаем над Алексеем, чтобы и как-то его привести, потому что, ну, где-то, сказать, и мы не правы, да, потому что
Speaker A
слишком много на него задач сваливается. Но вот сейчас как раз мы пытаемся найти тот баланс, как немножко вот с него вот это сказать перенагрузку снять. В принципе, здесь можно по нему также сделать аналитику за период, за за эту неделю.
Speaker A
Чем он занимался сейчас? Оно немножко сказать занимает времени, к сожалению. Ну, как любая аналитика, если она не предрассчитана изначально, да, клубы какие-нибудь построены или даже банды. Вот если это хок нет, она просто считается, но просто он что-то за это время успел сделать. То
Speaker A
есть я там сделал предварительно, чтобы он показать, но он уже на самом деле успел нагнать новых событий. Она видит, что он что-то дополнительно сделал и начинает пересчитывать. То есть, по большому счёту, ну, и здесь, в принципе, вот за
Speaker A
эту неделю чем он занимался, ээ, какая динамика. Ну, и здесь вот, например, у нас есть вопросы один к один. Здесь ээ были задачи, которые возвращались обратно с котревь. То есть нужно понять, почему так получилось, что очень много иишки
Speaker A
вот работал по ночам. если как бы нерешённые риски, да, ну, то есть вот некие подсказки, на что в принципе можно поспрашивать, где мы видим, что что-то сбоит в его потоке, что, в принципе, мне тоже кажется, ну, даже даже мне это
Speaker A
полезно, потому что, ну, человек работает, особенно на удалёнке, и ты там не видишь его в офисе, не видишь, как он выглядит, очень часто там только на синках там пересекаетесь. И поэтому иногда вот такая активность позволяет это увидеть.
Speaker A
Ну и, в принципе, здесь то же самое. Можно опуститься на уровне задач. Сколько человек задач сделал за неделю. Вот у него, кстати, тоже вот этот график получается лесенкой.
Speaker A
И где, так сказать, большие задачи, где, так сказать, мелких много задач по токенам. Потоки нам очень интересная вещь. То есть мы сначала просто смотрели на их количество, потом поняли для нас важный момент. То есть мы поняли, что мы
Speaker A
должны анализировать, то есть не просто смотреть а например чтобы джуны не пожирали куча токенов, потому что они очень тоже любят на маленькие задачи дать модельку. Вот, буквально вот недавно мы поймали, там в идеешке можно там сделать массовую замену там
Speaker A
идентификаторов, и человек вместо того, чтобы запустить команду вдшки стандартную без ничего, естественно, решил сделать это через модельку. Как бы пожрал куча токенов ещё там даже не сделал маленькую модельку, а сделал большую модельку взял. И она, естественно, как бы много чего пожрала.
Speaker A
И это как бы тоже те вещи, почему как бы за потреблением токенов нужно смотреть.
Speaker A
Ну и как будто там плюс-минус стандартный подход. Чем больше синьор, тем обычно у него больше токенов, потому что задачи сложнее и модельки там нужны по по посложнее.
Speaker A
Вот так. Угу. Ну и смотри, можно тут просто был вопрос, что за программа? Э, ну и я продолжу, наверное. А как как ей воспользоваться?
Speaker A
может немного рассказать про, ну, не саму платформу мы сейчас к ней вернёмся, а немного про, ну, про то, как это выглядит этот продукт, на кого вы ориентируетесь, есть там self-сервиice или это, ну, типа кастомная интеграция.
Speaker A
Чуть-чуть про продуктовую составляющую. То есть вообще данный продукт существует в двух ипостасях. Он существует в кладной версии, и я потом куда-то, ну, на самом деле достаточно просто, если набрать devoptify.ru, это как бы сайтик приложения уже я скинул и в анонсе есть, и в этом в
Speaker A
чате сейчас есть, да, то там есть пространство. Это кладная инсталляция, она сейчас бесплатная. Э, туда можно прямо подключиться.
Speaker A
Единственное что ну понятно как всякая кладная версия, там нужно доверять, да, то есть нужно будет доверие к репозиториям дать и поставить, э, плагины. Плагины существуют кдэшкам.
Speaker A
Сейчас я вернусь. Так, настройки, то есть, то есть, в принципе, оно всё очень похоже. Плагины существуют ко всем идэешкам. к браузерам и лайкам. То есть, в принципе, можно использовать там во всех инструментах, но даже лучше, если снимать полную картинку, то лучше это
Speaker A
всё подключать к себе сразу. Также есть onп premis версия, но это вот можно с нами как бы связываться, я потом оставлю контакты. То есть, в принципе, для тех компаний, которые, понятно, что не хотят делиться там своим кодом или открывать
Speaker A
свои корпоративные сети, есть он премиснляция. По железу требования не очень большие, поскольку основная аналитика делается без моделей. Модели используются только вот там, где написано и запросы. Но там, в принципе, можно подключать достаточно любую модель, поскольку там в основном проводится саморизация. То есть
Speaker A
там глубокой аналитики не делается, то есть там прописаны у нас внутри агенты, которые знают, как работать с базами данных. Если он не может посчитать, он не будет придумывать, он скажет: "Я это посчитать не могу".
Speaker A
Но, в принципе, как бы то, что он может посчитать, он может посчитать. Э, и, ну, как бы самое главное, что мы в некий момент поняли, что дышборды дэшбордами, но очень многим компаниям у них свои дэшборды, свои там метрики, и
Speaker A
поэтому есть возможность с этими системой интегрироваться по MCP, подключаться и скачивать себе метрики и получать свои какие надо отчёты.
Speaker A
Ну и буквально сказать такая интересное, что поскольку мы поняли, что дышборды бесконечно, но всё равно непонятно, какой нужен конкретным людям, то есть мы придумали, ну, у нас есть дата wizard, который, в принципе, позволяет делать запрос. Я просто буквально покажу
Speaker A
пять запросов, которые вот я тут сделал. То есть первое, я просто спросил, например, какие задачи возвращались работу больше одного раза за последние 2 недели. Вот мне как бы выдался список задач. Я тут могу по ней кликнуть, перейти посмотреть
Speaker A
кто делал, кто исполнял. Можно даже кликнуть и получить аналитику. Например, вот покажи график изменения литайма. Вот.
Speaker A
Она даже как бы сделает прямо писа покажи график изменений летаема за последние полгода. Сделал аналитику.
Speaker A
Э, есть горб, да? Вот у нас там мы причёсывались некий момент времени. Вот видим, как менялся наштайм.
Speaker A
Ээ, ну вот из интересных вещей мы как бы я, например, такой запрос сделал. Посмотри, как соотношение багов к остальным задачам, как бы по количеству и по потраченному времени, да? И вот он посчитал, что вот вроде по количеству получается много багов, то
Speaker A
есть один баг на две и две задачи. Но если смотреть по времени, то получается, что фактически мы только 17% времени, то есть получается один по времени, один к к пяти получается. То есть, ну вот. А давай такое спрошу. Смотри, про время.
Speaker A
Э, как это время реальное решение задачи, ну, с телеметрии. То есть это не время, что задача висела in проogress где-нибудь там жира или ещё какие-то, ну, вот эти вещи типа бумажные метрики.
Speaker A
Да-дада. Это именно то время, э, когда человек именно решал именно эту эту задачу. Вот именно эту задачу. Причём там как бы можно даже посмотреть вот в какой период времени это делать. Там считается достаточно непросто. То есть, в принципе, мы берём те веточки, над
Speaker A
которыми человек работает, и делаем некое связывание активности вот над этой веточкой. То есть смотрим, что он может, он же на самом деле может поработать в идшке, потом зайти в браузер, что-то посмотреть, потом все лайки что-то написать. И в принципе мы как бы
Speaker A
стараемся, то есть у нас есть такое понятие фокусного времени над задачей. И мы вот как бы то время, когда он непрерывно работает над этой задачей, оно как бы суммируется именно с точки зрения поступления событий. Да, там есть понятный перерыв между событиями. У нас,
Speaker A
по-моему, там, э, 5 минут, когда он может почитать. Если перерыв 10 минут, то, в принципе, означает, что он либо оставил задачу, либо ушёл куда-то отдыхать. Ну, либо ничего не делает. То есть именно после этого время перестаёт считаться. То есть, сон говори, если ты
Speaker A
открыл кучу задач, там идешку, браузер, и там ничего не делаешь, не порождаешь события именно логические, что мы смотрим, что открыл файл, начал набирать код, то это время всё не считается, как его время работы.
Speaker A
У, знаешь, в чём фишка? Я тут на в одной из предыдущих серий разбирал, помнишь, когда мы с тобой познакомились и ну договорились об этом, а об этом по прямом эфире, я рассказывал про там серию Developer Productivity, тебе тоже
Speaker A
скидывал, и я сделал обзор всех ээ выпусков, там 20 плюс статей. И в одной из них как раз была история про то, что, э, метрики по именно по работе классно снимать из тех систем, где человек работает. И, ну, мы обсуждали как раз,
Speaker A
что есть события, да, и можно их ловить. Ну, то есть можно ловить запись логи, делать события, потом события по вот по определённым правилам, как ты рассказываешь, собирать в сессии, ну, и считать время, ну, активное работы в рамках этой сессии над этой задачей. И
Speaker A
дальше вот из этого, ну, делать, ээ, как бы делать какие-то метрики уже целевые, которые тебя интересуют в разделе сессии артефакта, который получен или артефактов, да, если это код, не знаю, билд какой-то или там, не знаю, ещё что-нибудь, что он делает. И прикольно,
Speaker A
что ну у вас в систему положено вот это вот этот подход, ну, про который Google в своё время рассказывал, что у них [фыркает] так, потому что я, ну, часто вижу, когда люди все свои метрики, ну, или там большую часть делают по
Speaker A
какой-нибудь жира или там ещё какой-нибудь системе задач и молятся на неё и дальше говорят: "Вот там видно, как мы, ну, с какой, какими задачами работаем, сколько времени, как быстро, сколько стоит такой смотришь на них и думаешь: "О, в общем, ты думаешь, что, ребята,
Speaker A
вы, конечно, можете мерить, что хотите, но у вас получается такая, короче, знаете, как бумажная отчётность, которая мало совпадает с реальностью и чем-то напоминает". Помнишь, когда была большая четвёрка, пятёрка аудиторов, вот, и потом осталась четвёрка, потому что один из аудиторов ээ был кровно
Speaker A
заинтересован в результатах. и те то, что он проверял и как там метрики считала. В общем, ну вот, кстати, да, к разговору из этого я просто честно скажу, я готовился, но в некий момент я забыл, где это было, где
Speaker A
у меня в аналитике по одному человеку прямо написала так: "Смотри, с этим человеком нужно поговорить, потому что я вижу, что он начал на работать над этой задачей, но она у него стоит всё ещё в туду, как бы пойди с ним, пойди с ним,
Speaker A
поговори про качество. В общем, надо хотя бы задачи переводить плюс-минус. другое состояние, когда если взял в работу. То есть она, в принципе, смотрит статус задачи, смотрит активность. Если статус как бы неправильный, то она может тоже как бы руководителю
Speaker A
просигнализировать, что этот человек, ну, как бы с ним нужно поговорить именно про точность. Ну, это просто как бы я тут вспомнил, что хотел по Ренату вот сказать, вот человек точно планирует и вот очень аккуратно живёт, правильно, в рабочие дни работает, в
Speaker A
нерабочие. раньше не работал, вот опять выходные пошёл работать. Вот мы начали смотреть тоже, что там случилось. Но в целом это вот как бы видно, что человек, ну, он живёт немножко по-другому.
Speaker A
Достаточно много пишет разработка. Это фронтен, вот пишет код менее сложный, поэтому использует set не не opus. Ну и у него, в принципе, и ручное delivy, и как бы основное дели совпадают. Ну, потому что много там он руками правит фронтендер, но агентов
Speaker A
используют достаточно интенсивно, особенно как бы для аналитики. Вот можно посмотреть вот для Discoverovery прям очень активно используют иишку.
Speaker A
Вот как бы второй как бы срез человека. Ну и и вот он такой прямо фокусный как бы по по задачам более фокусно работает.
Speaker A
Опять же, это не хорошо, неплохо. Это просто означает, что вот разные люди могут жить в разном ритме, и просто мы видим, да, как люди работают, и поэтому можем более персонализированно работать с этими людьми. Вот вообще отлично. Давай сейчас, э, от
Speaker A
платформы чуток отойдём и поговорим скорее про Ну, смотри, у вас есть продукт, вы его делаете. поговорим про то, как вообще, ну, с таким продуктом быть, как его внедрять, как, ну, с чего начинать, в принципе, как инженеры к такому продукту
Speaker A
относятся, не нарушает ли он какой-нибудь их ээ мироощущение относительно того, что ой, за нами теперь этот, э, пристально наблюдают.
Speaker A
Короче, как вы боретесь вот с этими скажем, отношением пользователей и как технологически, ну, насколько сложно такую штуку внедрить и, например, настянуть на крупную организацию? То есть я вижу, как это на уровне команды работает. На уровне команды выглядит всё, ну, прикольно. Ну, то есть если бы
Speaker A
я был тимледом, у меня был такой инструмент, я бы такой: "О, классно, а как такой инструмент работает, например, на уровне руководителя отдела 50 человек или там техническом директоре на 200 человек или, не знаю, там суперруководители там каким-нибудь инженеринг на 1.000 человек?" То есть у
Speaker A
вас есть какой-то там каскад? Ээ, то есть, в принципе, разные подходы для разных компаний. Сразу скажу, вот нижние как бы, если брать немножко снизу, то как бы нижний [откашливается] уровень компаний маленьких, он, наверное, там наиболее простой, поскольку там всё
Speaker A
достаточно гибко и там есть глубокая заинтересованность тимледов, да. Вот это как бы проникновение, он строится на интересе Тимлида, понимать, что происходит с командой, упростить, уменьшить некое количество встреч, уменьшить вот этих созвонов, контролей, потому что он, в принципе, многие вещи
Speaker A
начинает видеть онлайн, ему меньше нужно собирать статусы. Он понимает, какие задачи, кто чем занимается сегодня. То есть не то, что там одно дело, когда сказал: "Я буду заниматься этой задачей", с другой стороны открыл дэшборд и видит, что эта
Speaker A
задача была в работе сегодня, да, там вот и переведён статус, ему не надо куда-то ходить и что она реально как бы делалась. Э и есть такой верхний большие корпорации, там тоже вот с точки зрения распространения иногда немножко проще, потому что та
Speaker A
очень часто есть инструменты, то, что называется наката. Ну, скажем, в Сбере там есть возможность там внутреннее хранилище софта и там в инструменты в видешку можно прошить любые плагины, и ты можешь поставить только уже как бы с инструментом, да? То есть там это не
Speaker A
вопрос выбора или не выбора. Понятно, что средний слой он как бы самый сложный, но здесь, по большому счёту мы всё-таки отдаём на откуп именно темдам, потому что, э, первое, то есть мы чётко говорим, люди понимают, что видят, поскольку там есть белые списки,
Speaker A
если человек работает над своим проектом, то это не читается. То есть мы не комментируем все активности. Мы чётко говорим, что вот если, э, условно говоря, в браузере он работает, то его работа то, что он делает на компанию. Он
Speaker A
может ходить куда угодно, это мы не отслеживаем, но до нужно понимать, что это тоже не будет включено в его работу.
Speaker A
Условно говоря, сидеть над своим проектом, как бы это не будет зачтено в его работу, поскольку это другой путь.
Speaker A
Э, но по большому счёту, да, согласен, это не просто. И в основном, ну, как бы из простых доводов вопрос: "А от чего тебе прятать-то?" Ну, условно говоря, если ты работаешь спокойно, да, то есть и и делаешь свои задачи и делаешь их хорошо,
Speaker A
как бы, ну, к тебе никто не не придёт и не скажет. Во-первых, у тебя тоже защитная реакция. То есть, когда тебе придут и скажут: "У нас просто был такой разговор, там пришли к человеку, ты типа ты не сделал задачи". Он открыл свой как
Speaker A
бы дэшборд, сказал: "Смотри, вот продактунер, на прошлой неделе видишь, сколько как бы ты мне задач насовал, как бы помимо того, что я собирался делать.
Speaker A
Вот видишь, прямо сколько задач я сделал в этот день. Естественно, я что-то не успел сделать. Вот, ну, как бы давай тогда договариваться, чтобы у нас тоже такой картинки не было. И это, кстати, тоже как бы один из вариантов, что
Speaker A
человек тоже видит, как как его видит руководитель, да? То есть у нас получается одна точка зрения со стороны работника и со стороны руководителя.
Speaker A
Если работник с чем-то не согласен с аналитикой, он приходит, сказать: "Я не согласен". Да. И вот и здесь что-то показывается не так. И это неправильно.
Speaker A
И может об этом поговорить уже в тот момент, когда он увидел, а не когда начальник тебе себе что-то накрутил.
Speaker A
Как-то так. Угу. Это прикольно. Ну то есть я с тобой согласен. Смотри, тут есть вопрос прямо про, ну, как бы продукт, да? То есть вот есть, ты говоришь вариант в облаке пользоваться, есть вариант онпрем поставить. И, ну, люди спрашивают: "А
Speaker A
есть крупные пользователи?" Ну, и возможно, как эти крупные пользователи себя чувствуют. Если есть какие-то пилоты, не называя имён, можно сказать, что есть, ну, пилот.
Speaker A
Ну, на текущий момент мы входим, на самом деле, в несколько пилотов крупных в России, да? То есть у нас есть несколько за границей, ну, а я думаю, что, как все говорят, обычно это нерелевантно, да, там все инструменты.
Speaker A
То есть в России мы сейчас заходим э порядка трёх пилотов с достаточно, ну, скажем, я сказал, с компаниями, у которых там больше 2-3.000, да, человек, у которых, будем честны, достаточно простые вещи, которые они пытаются решить. Они понимают, что, э, иишка меняет их жизнь.
Speaker A
Они не понимают, как и и что с этим делать, и и как на это реагирует.
Speaker A
Поэтому у них достаточно простая задача для начала просто понять вообще, что происходит, чтобы потом на основании этого, ну, принимать некие некие решения, там, туда мы движемся, не туда.
Speaker A
Вот у нас говорят, что все начали использовать яишки, а вообще, а реально кто-то использует и или нет? Вот мы как А вот эти токены, которые жгутся, они жгутся на задачи или на кулинарные секреты? Вот можешь по-разному токены сжигать, если просто некоторые компании
Speaker A
имели неосторожность, успех считать количеством сожённых токенов. Как бы это это уже другая история. Токен максинг, да. Да, когда ты можешь потом этот, не знаю, попросить агентов поэмы писать или пи вычислять или ещё что-нибудь делать. И там токены жгутся только так. У тебя
Speaker A
топ- один человек в Лидербонде, пользы только от этих токенов нет. Но у меня, знаешь, уточняющий вопрос. 2.000 там 3.000 ты про инженеров говоришь или в принципе размер компании?
Speaker A
Не, инженеров. Я сейчас говорю про инженеров. Про инженеро, да, да. Но это уже значительный масштаб.
Speaker A
И мне кажется, что ну когда пилоты пройдут успешно, ээ, наверное, у вас на сайте появятся шилдики этих компаний. И можно будет я надеюсь. Ну, причём хочу сказать, что по большому счёту пилоты проводят холдинги, да? То есть, условно говоря, даже когда мы говорим про про
Speaker A
компанию, которая там у них не супербольшая, но мы просто как бы для себя где-то внутри с ними договорились, что этот пилот делается полностью на холдинг. Если как бы в одной компании это успех, то это значит успех для для
Speaker A
всего холдинга, как бы с с распространением. То есть эти компании, естественно, мы будем вывешивать. Ну, единственное, что, скорее всего, это не получится достаточно быстро, поскольку они подходят серьёзно. И на самом деле пилот он же, чтобы его доказать, то есть это
Speaker A
просто честно скажу, что это обычно порядка до месяца снятия статистики, чтобы ты понимал, что происходит. После этого ты делаешь некие выводы, проводишь некие разговоры, делаешь некие активности, которые должны изменить результат. И после этого ты должен ещё месяц посмотреть.
Speaker A
что результат реально изменился, да, потому что у нас, в принципе, как бы пилоты, они идут с доказательной повышением эффективности, а не просто то, что я посмотрел и это, ну да, показывает и и что теперь с этим делать, но посмотрел и классно. Нет, я хочу все
Speaker A
компании хотят понимать, как они на основании этого будут делать выводы и как будут добиваться повышения своей там эффективности или поддержки трансформации.
Speaker A
В общем, круто, на самом деле. Я хотел, знаешь, ну мы вроде по всему уже пробежались. Я хотел сделать такую отсылку. Люблю я этот пример. Год назад Отлачи акции там за год или за два раза в три просели, вытащили из кармана 1
Speaker A
млрд долларов и купили платформу DX. Платформа DX была основана ребятами, которые делали доsessment, которые сделали, ну там Space, Devx и другие фреймворки.
Speaker A
основана она была в начале двадцатого года. Они написали несколько статей на тему как раз метрик измерения продуктивности инженеров. Сказали, что можно мерить через опросы. Сделали опросы, интегрируемые в разные поверхности разных компаний. Потом сделали коннекторы ко всем системам и по
Speaker A
своим же пейперам, которые они писали, начали собирать активити всякие данные, вот как примерно ты показывал сейчас.
Speaker A
Вот в какой-то момент они поймали волну аификации, ну что процессы инженерные меняются и нужно уметь мерить.
Speaker A
Быстро к своему код DX4 фреймворку, который я, кстати, в одной из серий года три назад разбирал или там два, вот они добавили фреймворк для оценки AI эффектов примерно там в три стадии.
Speaker A
Сначала измеряешь ээ такие базовые вещи про Aдоoption, про потребление токенов, лицензии, всё такое. Потом как раз изменяешь эффекты на те джабы, ну, где используют инструменты, что там есть, ну, как бы проигранение инструментов, агенты помогают с ними и как-то, ну,
Speaker A
сами задачи начинают меньше времени тратить. И третья история уже переходишь к экономике. И вот они как бы так развивались. В какой-то момент компания ATLН, которая пыталась сделать ээ как раз свою систему компас для девелопер Productivity, сказала: "Сорян, мы
Speaker A
обосрались, короче, у нас не получилось, но мы купили компанию, которая у большинства наших клиентов уже, ну, типа зашла к ним со своими инструментами м по, ну, по оценке эффективности и по факту, ну, ребята, вот помнишь, я рассказывал про тех людей, которые
Speaker A
делали бумажные метрики поджира. То есть вот некоторые компании вот в этом направлении очень сильно продвинулись. И когда ты им рассказываешь про то, что, ребят, смотрите, даже компания Самаджира, да, ну, в смысле, которая владеетла, она сказала, что это немного
Speaker A
не то и нужно делать вот, ну, типа другой инструмент. Вот мы вам с вами вот общаемся, почему-то вы всё равно делаете тот старый. То есть, ну, как бы, если ваш пародитель идеи, короче, уже отказался от этого, может, вы тоже
Speaker A
посмотрите, ну, в другую сторону. Но это, на самом деле, достаточно такой сенситив вопрос. Очень сложно развернуть назад, когда у тебя карьера поставлена на эту историю. Ты будешь всем рассказывать, что это лучший подход.
Speaker A
В итоге, ээ, финализирую, хочу сказать, что сам инструмент прикольный. Кажется, ну, из того, что мы обсудили, он соответствует тем подходам, которые ну стоит использовать для оценки developer productivity. Понятное дело, что любой инструмент можно использовать как во влада, так и во вред, но мы, ну,
Speaker A
э, в общем, знаешь, можешь ножик человеку дать один будет, не знаю, мясо классное готовить или, ээ, ну, как бы классное блюдо людей порежется, да, или затыкает людей. Вот.
Speaker A
И мне кажется, что классно, что на российском рынке тоже, ну, появляются, ну, инструменты, ээ, не просто какие-то, а с какой-то, ну, методологией, которая стреет за ними, которые позволяют, ну, сами процессы свои оптимизировать.
Speaker A
Надеюсь, что у вас всё получится. Вот. И мы как-нибудь через год вернёмся к этому вопросу. Ты расскажешь, как закончились пилоты и куда развился продукт дальше.
Speaker A
обязательно, что пришёл в гости. Вот пообщаться. Всё, было очень было, было очень интересно. Тема бесконечного обсуждения, [смех] да? Приходите в следующий раз, я думаю, ещё что-нибудь интересное обсудим. И подписывайтесь, если вы ещё не подписаны.
Topics:AI-агентыdeveloper productivityразработкаметрики разработкиСберLLMруководство командойDevAptifyэффективность разработкиинженерный менеджмент
