Как измерять продуктивность инженеров на разных уровнях (Рубрика #DevEx)

Появилась запись выступления Станислава Моисеева, директора R&D‑центра Т‑Банка с Big Tech Night. В этом докладе Стас делает обзор лучших практик последних лет и связывает их с волной GenAI‑инструментов. За 5 лет ландшафт сильно изменился: ковид → удалёнка → внедрение AI. Компании инвестируют в ИИ‑инструменты для разработки, но без измерений сложно доказать ROI. Доклад показывает, какие метрики и на каком уровне отвечают на вопрос «что реально ускоряет поставку ценности», и упоминает методологию индустриального опроса 2025 для оценки влияния GenAI на разработку.

Если говорить про уровни, то они такие IC (индивидуальные контрибьюторы) -> команды -> компании -> индустрия целиком. И работает это так

- IC (индивидуальный инженер): следить стоит не за «строками кода», а за временем потока (сколько часов без переключений), cycle time своего PR, долей переделок/rollback’ов, качеством ревью. Это помогает видеть, как инструменты (IDE‑плагины, ассистенты, автотесты) влияют на вашу личную скорость и аккуратность. Осмысленный набор метрик хорошо описывается рамкой SPACE (удовлетворённость, performance, activity, communication, efficiency).
- Команда: классический набор DORA (частота деплоев, lead time for changes, доля неудачных изменений, MTTR) + операционные метрики потока: WIP, размер PR, доля «ожидания» vs «работы», стабильность спринтов. Эти показатели коррелируют с предсказуемостью поставки и качеством.
- Компания: здесь важны сквозные метрики: cost‑per‑change, time‑to‑value, скорость онбординга, покрытие автотестами критичных путей, утилизация платных AI‑мощностей на разработку vs «игрушки», экономия инженерных часов от ассистентов. Цель - связать инженерные метрики с P&L: сколько стоил прирост скорости и как он отразился на бизнесе.
- Индустрия: бенчмарки и сравнительные опросы. В докладе заявлен подход к индустриальному исследованию 2025 года по влиянию GenAI — чтобы компании могли соотнести свои практики с «средней температурой по цеху» и отделить хайп от эффекта (я уже рассказывал про это исследование раньше)

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

#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership

AI в SDLC: от ассистентов к агентам

3 октября на конференции AI Boost я буду выступать с таким докладом. Саму конференцию про реальное ускорение разработки с помощью AI организовали ребята из Surf и где-то месяц назад они предложили мне выступить с продолжением моего доклада "Интегрируем AI в процессы разработки в большой компании", который я рассказывал летом на CTO Conf.

В новом докладе я планирую поговорить про переход от режима AI-«ассистентов» (GitHub Copilot, Cursor и др.) к агентному подходу - когда автономные ИИ-агенты становятся полноценными участниками SDLC и взаимодействуют между собой. Будут затронуты следующе темы
1. Почему про это так много говорят - экономические предпосылки и эффект на workforce
2. Почему для эффективности AI-агентов критически важны чёткая постановка задач и знание контекста проекта
3. Как роль инженера смещается в сторону тимлида команды AI-агентов и какие для этого требуются навыки и образ мышления
4. Как мы дошли до жизни такой и какие агентские инструменты появились или засияли в 2025 году (Claude Code, OpenAI Codex, ...)
5. Как мы создали свой агентский режим для разработки и как он себя показывает на наших сценариях
6. Как это связано с модным "вайб-кодингом", где новым многообещающим языком программирования видят ... английский

Если вам нравится эта тема, то покупайте билеты на конференцию и приходите слушать и задавать вопросы. А если вам интересно общее состояние дел о том, как AI влияет на инженерную культуру, то предлагаю пройти опрос от Т-Банка на эту тему. О чем этот опрос и почему его результаты будут интересными я уже рассказывал раньше.

#AI #Engineering #Software #Management #ML #DevEx

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

Angular: The Documentary | An origin story (Рубрика #Engineering)

Посмотрел интересный документальный фильм про создание и развитие фронтового фреймворка Angular. Этот фильм интересно посмотреть даже если вам не интересна история фронтовых фреймворков (кстати, про react тоже есть документалка и я уже про нее рассказывал). Фильм рассказывает как Angular родился как внутренний эксперимент в Google, который поначалу отмахнули большие команды (Gmail и Maps), а затем стал массовым фреймворком и прошёл через болезненную «вторую жизнь» (Angular 2+). А теперь чуть

1. Как Angular появился внутри Google (локальная инициатива)
Старт проекту дала команда, работавшая над Google Feedback. Она утонула в 17 000 строк фронтенда и низкой тестопригодности. Тогда Ми́шко Хевери предложил дерзкий ход: переписать всё за две недели своим хобби‑проектом (GetAngular/AngularJS). Вышло за три, но код сжался до ~1 500 строк, и это стало моментом истины — менеджмент увидел в подходе ценность и дал зелёный свет на развитие. В общем, видно, что Angular родился не как глобальная инциатива "сверху-вниз", а скорее как локальная инженерная идея, доказавшаяся прототипом лечение реальной боли команды.
2. Борьба за ресурсы и «нет» по дороге
На старте AngularJS не получал аппрув от флагманов внутри Google - многие говорили что-то в стиле "хорошая игрушка, удачи". Поддержка пришла после демонстрации драматической экономии сложности/кода и скорости разработки. Сначала - маленькая команда, много скепсиса, мало ресурсов; дальше - органический рост вокруг первых успешных внедрений. Итого, в большой компании лучше один раз радикально показать ценность на рабочем кейсе, чем долго убеждать словами.
3. Как в Angular появился Dart и почему далее произошёл «раскол» AngularJS и Angular
Следующей развилкой стала производительность, статанализ и tree‑shaking. Внутри Google к этому моменту крепки были позиции Dart (с его dart2js и агрессивным tree‑shaking), а команда Angular экспериментировала между JS, AtScript и Dart. В итоге Google и Microsoft сошлись на TypeScript: ключевые идеи AtScript попали в TS 1.5, а Angular 2 строили уже на TypeScript, параллельно поддерживая AngularDart для крупных внутренних продуктов (Ads/AdSense). Это и закрепило исторический «раскол»: AngularJS (1.x) и Angular (2+) — два разных мира. В итоге, видно, что Dart повлиял на выделение дополнительных ресурсов, архитектуру фреймворка и компиляцию (статичность, AOT, tree‑shaking), но "языковая ставка" в открытой экосистеме ушла в сторону TypeScript.
4. Большие миграции
У Angular было две ключевые миграции:
- Архитектурный разрыв AngularJS → Angular (2+) - без обратной совместимости. Перепроектирование ради мобильности, модульности, типизации и будущей компиляции. Это самая болезненная точка истории.
- Смена движка рендера на Ivy (Angular 9) - уже внутренняя замена View Engine на новый компилятор/рендерер, специально спроектированный под мелкогранулярный tree‑shaking и меньшие бандлы. Переход стал дефолтом в v9 и принёс ощутимую экономию размера без переписывания приложений с нуля.
Обе миграции были болезненны, но кажется, что необходимы.
5. Как Angular чувствует себя сейчас и планы
Angular снова на подъёме: зрелая реактивность (Signals), сильный SSR/гидрация, фокус на DX и производительности, аккуратные мажоры без «лома мира». А Google планирует переносить фичи Wiz (внутреннего фреймворка внутри Google) в публичный Angular. Акутальная дорожная карта есть на angular.dev/roadmap.

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

#Software #SoftwareDevelopment #Architecture #Engineering #Management #OpenSource

Большая энергетика. Что почем и как с этим жить (Рубрика #Economics)

Прочитал уже вторую книгу Андрея Косько, популяризатора науки, который в своей первой книге "Да будет свет... и тепло! Сколько стоит энергия" уже обращался к теме энергетики. Я про нее уже рассказывал, но если кратко, то там он на пальцах объяснял, что такое энергия и откуда она берется, отвечал на вопросы вроде «Когда закончится нефть?» и «Пересядем ли мы на автомобили с солнечными панелями?» - опираясь на основы физики, экономики и политики. Во второй книге "Большая энергетика" 2022 года Андрей продолжает эту тему на более глобальном уровне, но как и первое издание, она написана для широкой аудитории и не требует специальных знаний выше школьного курса. Правда, теперь автор смещает фокус с бытовых аспектов к "большой энергетике" - мировой энергетической системе, рынкам и геополитике. Это логичное развитие: получив в первой книге базовое понимание об энергии, читатель во второй погружается в сложные вопросы международной энергетики и получает ответы на вопросы вида
- Что нас ждет с изменением климата?
- Почему во всем мире так активно внедряется электротранспорт?
- Что вызывает ценовые шоки на нефтяных и газовых рынках и управляет динамикой поставок углеводородов?

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

Структура книги

Книга логично поделена на четыре части, каждая из которых отвечает на конкретный блок вопросов
Часть I: «Статистика. Что и сколько?» - здесь собраны данные о ключевых энергетических ресурсах: нефть, природный газ (включая сжиженный - СПГ), уголь, электроэнергию и их роль в мировом энергобалансе.
Часть II: «Торговля. Кто и кому?» - посвящена глобальному энергетическому рынку. Обсуждается, что такое рынок энергоносителей и как энергоресурсы превращаются в товар.
Часть III: «Экология. Что делать?» - сфокусирована на климате и экологии. Здесь автор разбирает проблему глобального потепления, парникового эффекта и их прямую связь с энергетикой.
Часть IV: «Политика. Как с этим жить?» - заключительная часть об энергетической политике и безопасности. Косько описывает понятие энергетической безопасности и вспоминает энергетические кризисы прошлого, чтобы показать их уроки. Даётся обзор деятельности международных энергетических организаций и анализируются региональные стратегии.

Хотя книга вышла в 2022 году, её содержание остается весьма актуальным на конец 2025 года. За последние годы энергетический ландшафт претерпел резкие изменения, но описанные Косько тренды только усилились. Рынок углеводородов по-прежнему лихорадит: после волатильности 2022–2023 гг. цены на нефть и газ то взлетают, то падают, реагируя на геополитику, санкции и решения ОПЕК. Электротранспорт продолжает набирать популярность по всему миру, выполняя прогнозы книги. Одновременно искусственный интеллект и цифровая экономика предъявляют новый запрос на электроэнергию: мощности дата-центров и суперкомпьютеров для ИИ растут экспоненциально. По оценкам, уже сейчас 5–15% потребления энергии дата-центров приходится на задачи ИИ, а к 2030 году эта доля может возрасти до 35–50%. Вопросы экологии тоже никуда не делись: 2023–2025 годы принесли рекордные природные аномалии, подчёркивая срочность борьбы с изменением климата – тем самым поддерживая важность обсуждения климатической повестки, рассмотренной в книге.

#Engineering #History