Research Insights Made Simple #8 "Measuring developer goals" (Рубрика #DevEx)

В этом выпуске подкаста про инсайты ко мне в гости пришел Александр Кусургашев для того, чтобы поговорить про гугловую статью "Measuring developer goals":) Александр работает в Т-Банке в подразделении Core Tech и занимается развитием нашей внутренней платформы разработки. Он верит в законы физики, платформизацию и пользу от переиспользования. Для него важно, чтобы IT системы Т-Банка работали эффективно - от уровня физической инфраструктуры до конечных сервисов для потребителей. Большую часть своей IT карьеры Саша провел разрабатывая платформенные решения для low latency и ultra low latency electronic trading.

За время подкаста мы обсудили темы:
- Опыт работы Саши и его зона ответственности в Т-Банке
- Обсуждение critical user journeys для определения измеримых и объективных целей инженеров
- Гранулярность и декомпозиция целей
- Комплексный подход к оптимизации
- Важность систематического процесса выделения целей
- Эволюция обратной связи в опросах Engineering Satisfaction Survey
- Переход от инструментов к целям
- Измерение метрик и мониторинг процессов
- Вариативность инструментов и сложность стандартизации
- Научный подход к улучшению процессов

Выпуск доступен на Youtube, VK, Podster.fm, Ya Music

P.S.
Я уже разбирал этот whitepaper полгода назад.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Как я чувствую себя, когда иду на работу ... А вообще это обычный поход моего младшего сына в сад.

10 Developer Productivity Boosts from Generative AI (Рубрика #DevEx)

Глянул очередное интересное и короткое видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом видео Мартин рассказывает про то, как Gen AI может помочь повысить продуктивность разработчиков, а я про эту тему рассказывал много и подробно раньше, например, в последнем докладе про то, как и зачем мерить developer productivity. Но давайте вернемся к мыслям Мартина

1) Elemenating repetitive tasks. Генеративный ИИ может помочь исключить повторяющиеся задачи, ускоряя рутинную работу.
2) Natural language interface. Интерфейс на естественном языке позволяет запрашивать генерацию кода и контроль версий.
3) Code suggestions. Подсказки помогают начать работу с незнакомыми библиотеками и пакетами.
4) Code improvements. Это улучшения для устранения избыточных и неэффективных частей кода, почти как при pair programming, но где пару составляет AI ассистент
5) Code translation. Трансляции кода с одного языка на другой, которая может быть полезна для масшабной миграции, например, со Scala на Java/Kotlin
6) Code testing. ИИ может создавать тестовые сценарии и оценивать результаты.
7) Bug detection. Автоматическая идентификация и даже исправление багов
😍 Personalized dev environment. Как я понял это история про тюнинг IDE и других инструментов под стиль разработчика
9) Generation documentation. Генерация документации на основе кода

В конце автор говорит о том, что сейчас Gen AI скорее не замена разработчика, а помощь для расширения его возможностей. Это хорошо перекликается с мыслями из статьи "What Do Developers Want From AI?", про которую я рассказывал раньше.

P.S.
Автор не забыл про десятый пункт - он предложил зрителем самим написать в комментах:)

P.P.S.
У Мартина есть интересное видео про тренды AI в 2025 году, про которое я уже писал в канале.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

CTO Conf X (Рубрика #Management)

В этом году пройдет CTO Conf X, первая профессиональная конференция для технических директоров, от компании "Онтико". Я много выступал на других конференциях этой компании, например, Highload++, Teamlead Conf, Teachlead Conf, а теперь вошел в программный комитет этой новой конференции. Мы в программном комитете долго обсуждали какие доклады будут полезны посетителям конференции и получилось следующее
- Как CTO быть партнером бизнесу, а не просто исполнителем
- Как CTO создавать и актуализировать технологическую стратегию
- Как не утонуть в операционке и уделять еще время стратегии и тактике
- Как управлять командами разработки на масштабе (когда помнить все про всех уже не возможно)
- Как и зачем появляются внутренние платформы разработки (IDP) внутри компаний
- Как CTO смотрят на использование AI в SDLC (Software Development Life Cycle)

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

P.S.
Интересно, что еще до появления этой конференции я часто сам рассказывал доклады, которые могли бы присутствовать на ней:
- Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - Highload++ 2021
- Как нанимать технических руководителей - Teamlead Conf 2023
- Эволюция роли технического руководителя от инженера до CTO - SouthHub 2022
- Как формировать структуру команд под запросы бизнеса - YaTalks 2023
- Как и зачем измерять инженерную продуктивность в крупной компании - MTS True Tech Days 2024

#Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture

Gartner 2024 Hype Cycle for Emerging Technologies (Рубрика #Management)

Недавно столкнулся с картинкой из отчета "Gartner Hype Cycle™ for Emerging Technologies", что вышел летом прошлого года. Несмотря на то, что это по большей части маркетинг Gartner как тренд сеттера в технологиях, часто бывает интересно глянуть отчет и посмотреть, а что в нем есть кроме красивой картинки. Конкретно в этом отчете перечислены 25 прорывных технологий, сгруппированных в самые хайповые темы Autonomous AI (автономный ИИ), Developer Productivity (продуктивность разработчиков), Total Experience (общий опыт), and Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность). Именно эти темы будут определять будущее бизнеса и технологий в ближайшие годы по мнению Gartner

1. Autonomous AI (автономный ИИ)
Здесь фокус на развитии ИИ-систем, способных выполнять задачи с минимальным участием человека. Эта тема включает в себя такие технологии, как мультиагентные системы, обучение с подкреплением, гуманоидные роботы и machine customers. Для бизнес это означает переход к системам ИИ, которые могут динамически взаимодействовать с окружающей средой и принимать решения в сложных сценариях.

2. Developer Productivity (продуктивность разработчиков)
Здесь объединены инструменты и подходы для повышения эффективности работы разработчиков. Основные технологии: ИИ для поддержки разработки ПО, GitOps, prompt engineering и внутренние порталы для разработчиков. Цель — создать условия для "потока" в работе разработчиков, улучшая их удовлетворенность, сотрудничество и качество результатов. Я на эту тему много уже писал на канале, например, "Как и зачем измерять инженерную продуктивность в крупной компании"

3. Total Experience (общий опыт)
Этот пункт объединяет стратегии клиентского опыта (CX), опыта сотрудников (EX), пользовательского опыта (UX) и многоканального взаимодействия (MX). Здесь авторы говорят про такие технологии, как цифровые двойники клиентов, пространственные вычисления, суперприложения и 6G. Здесь цель в том, чтобы обеспечить бесшовное взаимодействие на всех точках контакта для повышения удовлетворенности, лояльности и вовлеченности.

4. Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность)
Эта тема направлена на создание доверия за счет мер безопасности, которые учитывают пользовательский опыт и совместное управление рисками. Конкретные технологии такие: AI TRISM (управление доверием, рисками и безопасностью ИИ), цифровые иммунные системы и архитектура сетевой безопасности. Здесь поощряется прозрачность, этичность и проактивное выявление угроз для повышения устойчивости организаций.

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

#Strategy #Management #Leadership

Картинка с самим Gartner 2024 Hype Cycle for Emerging Technologies

[1/2] The Mythical Man-Month (Мифический человеко-месяц) (Рубрика #Management)

Эта книга Фредерика Брукса была впервые издана 50 лет назад, в 1975 года, но она до сих пор переиздается, а цитаты из нее стали классическими. Я решил вспомнить про нее к юбилею и посмотреть насколько она еще актуальна.

В заглавие книги вынесена идея о том, что "добавление сотрудников в отстающий проект только увеличивает задержки" из-за роста коммуникационных издержек, времени на адаптацию новых членов команды и неделимости некоторых задач. Брукс критикует ошибочное предположение, что труд (измеряемый в "человеко-месяцах") можно масштабировать линейно, сравнивая это с невозможностью девяти женщин родить ребенка за один месяц. Это относится к области управления проектом/продуктом и так же актуально, как было 50 лет назад. Еще он подчеркивает важность концептуальной целостности - согласованной архитектуры системы под руководством единого видения - для предотвращения хаоса, вызванного "проектированием при помощи комитетов". Этот тезис относится к проектированию софта. Следующая ключевая идея относится к "эффекту второй системы" (перегрузка сложностью при создании следующей версии). Вот эта проблема кажется уже решена, так как продукты часто сейчас строятся итеративно и понятие версии системы вообще размывается:) Ну и последняя идея, которую стоит отметить - это различие между essential complexity (существенной сложностью, что присуща задаче) и accidental complexity (случайной сложностью, которая возникает из-за неэффективных инструментов или процессов).

Если провести параллели между разработкой во времена Брукса (1970-е годы и засилье мейнфреймов), то мы получим следующее

1) Закон Брукса vs Agile и гибридной работы
- Agile подходы снижают риск неожиданностей и даже работая проектно мы на поздних стадиях получаем меньше рисков, это соответствует мыслям Брукса о важности прототипирования в больших проектах
- Гибридная работа - современные инструменты (GitHub, Jira, Slack) снижают барьеры для коммуникаций, но правило про квадратичный рост затрат на коммуникацию от роста команды никуда не девается (помним, что в полном графе n*(n-1)/2 связей)
- Брукс рекомендовал использовать локализованные "хирургические команды", а у нас теперь есть two-pizza teams
2) Модульность и мокросервисы
- У Брукса вызывала опасения монолитная система, что они делали для мейнфрейма, но в наше время у нас пронеслись перед глазами SOA, микросервисы, FaaS и теперь людям монолит уже не кажется таким плохим вариантом для старта
- По-факту, нам нужна модульность нашего кода, а как он разворачивается можно решить потом (условно модульный монолит можно нормально разделить на отдельные микросервисы при необходимости)
3) Инструменты против человеческого фактора
- Одна из ключевых мыслей Брукса была про то, что серебрянной пули для повышения производительности разработки нет
- Но мы видим, что хорошие инженерные практики постепенно повышали продуктивность инженеров - речь про CI/CD и всю автоматизацию
- А сейчас мы живем во время, когда щепотка AI, добавленная в SDLC (software development life cycle) навроде GitHub Copilot обещает в будущем грандиозный эффект (если LLM продолжат также прогрессировать)
- Но пока мы все еще видим AI в качестве ассистента, а значит нам нужно обращать внимание на человеческий фактор, тут есть классная колонка про "Human approach to developer productivity" от Google, про которую я уже рассказывал раньше

Продолжение обзора в следующем посте.

#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps

Предпоказ спектакля «Лукич» в Мельник центре (Рубрика #ForKids)

Вчера днем мы были на детской постановке "Лукич" на сцене "Мельников". Это было новое прочтение «Чиполлино» для детей 6+, но мы взяли с собой четерехлетного и девятилетнего сына - обоим понравилось. Нам с женой постановка тоже показалась интересной, так как юмор был двухуровневым - детишки смеялись над гэгами и поведением героев, а взрослые на отсылки к окружающей реальности или намеки на романтические взаимоотношения овощей. Сам спектакль был в двух частях. В первом акте принц Лимон и рыцарь Помидор захватили власть в саду, а остальные овощи с переменным успехом боролись с ними. Второй акт начинается с того, что Лукич и другие овощи оказались за решеткой, но Черешенка, замотивированный Клубничкой, отправился их спасать ... В общем, постановка была авангардной, включала музыку, шутки и вообще смотрелась бодро и динамично. Главное, что детишки были в восторге и классно провели время, а родители тоже не скучали.

#ForKids #ForParents #Culture

[2/2] The Mythical Man-Month (Мифический человеко-месяц)

Продолжая рассказ про классическую книгу Брукса (1 и 2), расскажу про то, в какую сторону его идеи можно развивать сейчас

1) Для профилактики задержек в графике сдачи проекта
- Не стоит копить техдолг, который выстрелит ближе к сдаче проекта
- Не стоит использовать мифические человеко-месяцы, а взять метрики реальной производительности: cycle time, throughput и другие
2) Архитектурные принципы
- Стоит поддерживать концептуальную целостность с самого начала проекта - я бы тут предложил использовать RFC (request for comments) для обсуждения архитектурных вопросов, решения фиксировать в ADR (architecture decision records). Я про это как-то рассказывал в докладе про масштабирование архитектурных процессов лет 5 назад
- Также стоит инвестировать в документацию, положить ее поближе к коду и максимально автоматизировать
3) Коммуникации
- Желательно сократить по максимуму встреча, а те что исчезли перевести в асинхронный режим, а значить писать больше документов и комментить их асинхронно
- Выделять сфокусированное время для работы - это позволит не рвать поток работа (flow state)
4) Масштабирование команд
- Здесь я просто рекомендую глянуть подход из Team Topologies, который хорошо описывать типа команд и форматы их взаимодействия. Про эту книгу я много рассказывал и даже разбирал в первой серии подкаста Code of Leadership вместе со Стасом Халупом, моим бывшим коллегой
- По-факту, тут получается 2 основных типа команд: stream-aligned и platform. Первая наносит бизнесовую пользу, а вторая делает платформенные инструменты, что используют stream-aligned команды
- Ну и важно учитывать числа Донбара для понимания границ масштабирования из-за накладных расходов на коммуникации

Если подводить итоги, то книга Брукса до сих пор не устарела и может быть применена к современным проблемам. Несмотря на то что Agile и DevOps решают проблемы *случайной сложности*, его предупреждения о перегрузке ресурсами и фрагментации дизайна остаются актуальными. Команды достигают устойчивой продуктивности благодаря балансу автоматизации и процессов, ориентированных на людей — подтверждая взгляд Брукса на разработку ПО как на процесс, прежде всего зависящий от человеческого фактора. В условиях роста масштабов распределенных систем возвращение к идеям *Мифического человеко-месяца* предлагает как предостережения, так и вдохновение: инструменты меняются, но динамика команд определяет успех проекта.

#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps

#60 – Agile Metrics (Рубрика #Management)

Наткнулся тут на очередной комикс от Comic Agile на этот раз на тему метрик, которая является очень интересной. Авторы комикса заслуженно иронизируют над velocity, burndown, predictability, lead time и business value, обыгрывая стандартные способы покраски этот метрик в зеленый. Дальше они отмечают, что эти метрики могут помогать с идентификацией зон для улучшений, но по их скромному мнению есть 2 метрики, что стоит мерить
- NPS (net promoter score) - удовлетверенность клиентов
- The hapiness of team members - удовлетворенность членов команды
Забавно, что NPS - это супер-общая метрика, которую сейчас берут все и используют по принципу "не знаешь что показывать по продукту - покажи NPS". А вторую метрику авторы предлагают мерить при помощи Spotify Squad Health Check, про который я рассказывал раньше (1 и 2). Интересно, что эти метрики как и остальные приведенные в обсуждении могут быть испорчены, например, продукт есть и пользователи им довольны, команда тоже довольна своей работой, только фичи не катятся - а смысл напрягаться, когда NPS высокий:) Но дальше авторы говорят коронную фразу про outcome

We must remember that working agile is a means to an end and not the goal, itself. Therefore, thinking about what outcome we want by working agile is what we should measure.

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

#Management #Leadership #Engineering #Software #Metrics

Code of Leadership #29 "Think like a CTO" (Рубрика #Management)

В очередном выпуске подкаста Code of Leadership обсуждается неоднозначная книга "Think like a CTO" ("Думай как CTO"). В разборе помогает крутой гость, Саша Шевченко. Саша - мой коллега, который является техническим руководителем в управлении цифровых экосистем. Возглавляет 10+ продуктовых команд мобильного банка. Под его управлением развивается главный экран и приватный профиль, треки UX, ESG и не-клиентов, и другие ключевые продукты и сервисы. Кстати, я уже рассказывал про эту книгу в двух частях: 1 и 2

Выпуск доступен в Youtube, VK, Podster.fm, Ya Music


За час мы успели обсудить темы
- Роль и зоны ответственности CTO
- Жизненный цикл компании и как меняется роль CTO
- Управление ожиданиями и коммуникация
- Формирование команды и её управление
- Технологическая стратегия и долгосрочное видение
- Управление бюджетом и проектами
- Качество инженерных практик: QA, reliability, security, ...
- Процессы и важность документации
- Саморазвитие и подготовка преемника

Рекомендации для изучения от Саши Шевченко

Управление
- "Идеальный руководитель" | Адизес Ицхак - подробнее в моем посте
- "Карьера Software Engineering Manager" | Стэньер Джеймс - есть у меня на полке, но пока не прочитал
- "The Elegant Puzzle" ("Элегантная головоломка") | Уилл Ларсон - разбирали вместе с Eugene Sergueev в эпизодах Code of Leadership 9 и Code of Leadership 10

Лидерство
- "Вызов лидерства. Пять практик выдающихся руководителей" | Джеймс Кузес, Барри Познер
- "Turn the ship around" ("Разверните ваш корабль") | Дэвид Марке - разбирали вместе с Екатериной Шестимеровой в Code of Leadership 4
- "The Five Dysfunctions of a Team" ("Пять пороков команды") | Патрик Ленсиони - разбирали вместе с Андреем Соколовым в Code of Leadership 16
- "Servant Leadership", "Ситуационное лидерство", "Management 3.0" - книгу про "Management 3.0" я прочитал на 2/3 пару лет назад, но не смог дочитать из-за феерического количества отсылок на другие книги от автора

Создание команд
⁃ "Team Topologies" | Skelton Matthew - разбирали со Стасом Халупом в Code of Leadership 1
- "Реальные полномочия. Самостоятельность сотрудников как ключ к успеху" | Шоул Джон
- "Шесть гениев команды" | Патрик Ленсиони - есть у меня на полке, но пока не читал
- "Уроки выдающихся лидеров" | Питер Симс
- Модель Такмана
- Обратный маневр Конвея

Разработка
- "Learning DDD" ("Изучаем DDD предметно-ориентированное проектирование") | Хононов В - я много писал про книгу и даже обсуждал ее с автором
- "Accelerate" ("Ускоряйся!") | Форсгрен Николь - разбирали вместе с Игорем Курочкиным в Code of Leadership 13
- "Site Reliability Engineering" | Бейер Б - я уже рассказывал про книгу
- "Building Secure and Reliable Systems" ("Безопасные и надежные системы") | Адкинс Х. - я уже рассказывал про эту книгу
- Data Mesh. Новая парадигма работы с данными | Дегани Ж.

Романы про разработку
- Проект «Феникс» | Джин Ким - обсуждали книгу с Иваном Михеевым в Code of Leadership 5
- Цель. Процесс непрерывного улучшения| Голдратт -
- Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения | ДеМарко Том

Управление изменениями
- Наш айсберг тает. Как добиться результата в условиях изменений | Коттер - я уже рассказывал про эту книгу
- Восхождение по спирали. Теория и практика реформирования организаций | Марк Розин

В книге так же есть отсылки к
- Думай медленно... решай быстро | Даниэль Канеман - я уже рассказывал про эту книгу
- Невозвратным затратам или эффекту Конкорда
- Кривой Гартнера - недавно рассказывал про нее

#Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture #SelfDevelopment

[1/2] This Year in Uber’s AI-Driven Developer Productivity Revolution (Рубрика #DevEx)

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

- Uber - это крупная мультинациональня компания с распределенными командами, 156+ млн MAU, 30M поездок в день, 10к городов
- В компании есть IDP (internal developer platform), внутренняя платформа разработки, которая помогает инженерам в их деятельности
- Ребята в платформе фокусируются не на тулинге, а на удобстве инженеров и ориентируются на NPS (net promoter score)
- Uber сталкивается с проблемами техдолга и необходимости миграций кодовой базы, также у них сейчас тоже есть тренд на flat headcount и "do more with less". В итоге, они решили фокусироваться на использовании AI для повышения продуктивности инженеров
- Для решения этих задач была создана отдельная платформенная команды для работы на AI developer experience, которая включает инженеров из всех платформ + специалистов в ML, которые предоставляют модели и абстракции для создания инструментов на основе ИИ.
- Uber практикует AI-хакатоны еще с 2022 года, а сейчас строит свои агентские решения строит на LangChain
- Фокус в применении AI в SDLC был на трех моментах: coding assistance, generating tests, java to kotlin migrations

——— Code assistance ———

- В качестве coding assistant в Uber использовали Copilot, но потом возникла гипотеза, что нужен свой ассистент с дообученной на своем коде моделью. Для этой модели выставили критерии успешности: +10% acceptance rate, latency меньше 1s на 100 токенов, экономическая эффективность, а также интеграция ассистента в рабочие процессы. Проект включал разработку MVP и оценку эффективности различных AI решений
- Проект потребовал много ресурсов и времени, но за полгода MVP было готово. Дальше авторы оценили результаты и решили остановить проект с такими выводами

- MVPs are easy, productionisation is hard
- Latency requirements vary per tool
- User Experience matters
- UI surface cannibalization is a risk
- Follow ecosystem principle
- Continuously evaluate landscape

- Вывод был в том, чтобы использовать индустриальные инструменты, но смогли переиспользовать из своего MVP части про
-- Code context gathering - Summarize & rank code context to provide best input to use-cases (data race fixer, linter warning fixer, crash fixer)
-- Gather telemetry
-- Fine-tuned LLM - Custom model with knowledge of internal libraries, custom frameworks, and company-specific best practices
- Помимо ассистента по коду ребята сделали ассистента для вопросов по базе монореп, которых в Uber 6:) Также ребята проводят воркшопы для обучения инженеров лучшим практикам использования AI, а также активно евангелизируют подход внутри
- В будущем планируют добавить
-- Интеграция с платформами, такими как VS Code и Xcode.
-- Vendor fine tuning и дополнительные возможности по расширению функционала ассистента
-- Использование инструментов для аналитики и рабочих процессов

Продолжение обзора в следующем посте.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

[2/2] This Year in Uber’s AI-Driven Developer Productivity Revolution (Рубрика #DevEx)

В продолжении рассказа, я опишу подход ребятк генерации тестов и миграциям

——— Generating tests ———
- Ребята используют стандартную пирамиду тестирования, где сквозные тесты на вершине, модульные тесты внизу
- Собственно вот идеи для использования AI в тестировании:
-- Сквозное тестирование при помощи AI-агентов. Забавно, что мы у себя пытались лет 5 назад прикрутить crowd тестирование, где e2e проверяли ребята из Klex, нашего внутреннего инструмента типа Я Толоки. А сейчас мможно не крауд привлекать, а AI агентов
-- Анализ качества тестов (мутационное тестирование)
-- Предиктивный выбор тестов для ускорения прогонов
-- А на нижнем уровне можно использовать AI для генерации unit тестов
- Так ребята сделали Autocover с фокусом на регрессионных тестах, повышения code coverage и оставляя разработчиков в цикле взаимодействия с autocover (keep the developer-in-the-loop). Интересно, что ребята делят этапы работы над тестами на детерменистические, а также на вероятностые

——— Java to Kotlin migration ———
- В Uber исторически было много Java кода, постепенно ребята подсели на Kotlin и потом решили полностю мигрировать на него
- Платформенная команда сделала инструмент миграции и предоставила его продуктовым командам в децентрализованном режиме
- Если это делать это постепенно и в ручном режиме, то это миграция закончится где-то за 10 лет, что не попадало в ожидания
- Ребята решили это автоматизировать причем с использованием AI
- Для этого они решили объединить подходы на основе анализа AST (abstract syntax tree) и LLM для улучшения правил работы с AST деревьями
- Этот подход позволил им ускорить процесс миграции где-то на порядок

Итого, ребята в Uber оптимистично смотрят на применение AI в SDLC, но отмечают, что важно правильно выбирать метрики для оценки эффекта улучшений и их побочных эффектов. Они предлагают использовать метрику времени сэкономленного для разработчиков (saved developer hours). Мне это напомнило метрику на часы просмотренного видео через Youtube. Подробнее в моем обзоре книги "Like, Comment, Subscribe" ("Youtube. Как самый популярный видеохостинг завоевал мир?").

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Митап "AI в Software Engineering" в Т-Банке (Рубрика #AI)

Вечером 4 марта в офисе Т-Банка в Москве пройдет митап о том, как AI трансформируют инженерные практики. На митапе будет разговор о том, куда движется RnD в разработке софта и какие у нас есть результаты на этом пути. Мои коллеги продемонстрируют реальные примеры внедрения AI в разные этапы SDLC (software development life cycle). Также будет разговор о том, какие это риски несет: новые security-уязвимости, снижение квалификации инженеров, а также фокус на качестве поддержки AI-генерируемого кода. В митапе примут участие эксперты из RnD центров и техлиды индустрии. В общем, на митапе будет полезно и интересно.

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

#AI #Software #Engineering #Architecture #RnD