Flexible work update (Рубрика #Management)

Недавно Microsoft объявила об обновлении политики гибридной работы: ожидается присутствие сотрудников в офисе не менее трёх дней в неделю. Это решение изложено в письме за авторством Эми Коулман, исполнительного вице-президента и директора по персоналу Microsoft. Аргументами стало то, что в эпоху AI личное общение повышает энергию, инновации и эффективность команд, поэтому компании важно чаще собирать людей вместе офлайн. Новый стандарт будет раскатываться постепенно, начиная со штаб-квартиры в Сиэтле, дальше по США, а потом и по всему миру. Отдельно подчеркивается, что это не про сокращение штата, а про улучшение совместной работы.

После этой новости мне стало интересно чекнуть, а как дела с политикой RTO (return to office) у других бигтех компаний и выяснилось примерно следующее
- Google с весны 2022 года ввёл гибридный режим, который был относительно мягким. Но в июне 2023 Google разослал сотрудникам внутренние меморандумы, сообщив, что отныне офисная посещаемость (3/5 дней в офисе) будет отслеживаться (через пропускные бейджи) и учитываться при оценке эффективности работы. В апреле 2025 г. сообщалось, что Google требует от ряда полностью дистанционных работников вернуться в офис, иначе их роли могут попасть под сокращение в рамках оптимизации затрат. Сейчас в Google 3/5 дней надо проводить в офисе.
- Запрещенная в России компания Meta в первые пандемийные годы поощрала удаленку. А в сентябре 2023 Meta официально обновила политику: всем офисным сотрудникам предписано работать из офиса минимум три дня в неделю - ставка была на личное взаимодействие для повышения культуры и «эффективности» в их «год эффективности».
- Amazon традиционно до пандемии культивировала офисную культуру, но в 2020–2021 гг. также была вынуждена перейти на удалёнку для офисных сотрудников. В начале 2023 года генеральный директор Энди Джасси разослал меморандум, где объявил, что офисное присутствие необходимо для укрепления культуры и эффективного сотрудничества. В феврале 2023 г. Amazon официально потребовала от сотрудников присутствовать в офисе не менее 3 дней в неделю, начиная с 1 мая 2023. В сентябре 2024 г. Энди Джасси выпустил новое обращение к персоналу, где заявил, что компания «возвращается к офисному режиму работы, как до COVID», то есть к 5/5 дней в офисе:)

Если смотреть на другие компании, то аналогичные шаги сделали Apple (с 2022 - 3 дня в офисе, несмотря на протесты сотрудников), IBM (для менеджеров - либо 3 дня в офисе, либо увольнение), Salesforce (с 2024 отдельные категории сотрудников должны быть на месте 4-5 дней), Dell (в 2025 вовсе отменила гибридность, вернув всех, кто живёт рядом, на 5/5 график) и многие другие. То есть, Big Tech и крупный бизнес в целом двигаются к схеме, где удалёнка уступает место гибридному или полностью офисному формату. Можно ожидать, что в течение ближайших пары лет все крупнейшие корпорации унифицируют свои политики примерно до одного стандарта, а пандемийный эксперимент с тотальной удалёнкой фактически уже завершён - компании считают, что он себя исчерпал и несёт больше рисков (для культуры, обучения молодых сотрудников, творчества), чем плюсов.

Причин для этого решения видится две:
1. Руководители действительно рассчитывают поднять продуктивность оставшихся работников: мол, теперь нужно делать больше меньшим составом, а для этого людей надо собрать вместе и мотивировать, исключив расслабленность удалёнки.
2. Негласно RTO подталкивает к естественному оттоку тех, кого компания, возможно, и так считала лишними. Как указывалось выше, жёсткие требования могут привести к тому, что часть сотрудников сами уволятся (по семейным обстоятельствам, из-за релокации, нежелания менять образ жизни).

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

#Software #Engineering

Большое исследование AI в инженерной культуре России (Рубрика #AI)

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

Мы решили провести такой опрос для того, чтобы
- Получить актуальные данные о том, как AI‑решения применяют в России. Пока есть информация только о международных практиках, но к российскому рынку это почти неприменимо
- Отделить хайп от реального эффекта. Многие компании экспериментируют с AI, но не всегда ясно, помогает ли это повысить продуктивность и качество. Исследование поможет измерить реальные результаты;
- Понять, как AI влияет на бизнес‑результаты. Например, на пользовательский опыт и удержание сотрудников;
- Помочь компаниям и инженерам. Компаниям - понять, где они находятся в контексте рынка и какие AI‑решения правда работают, а инженерам - оценить, насколько их опыт совпадает с опытом коллег.

Мы ожидаем, что в опросе поучаствуют
- Инженеры и технические специалисты: разработчики, DevOps/SRE, инженеры данных, QA‑инженеры, специалисты по ML и AI;
- Технические лиды и менеджеры: тимлиды, Engineering Managers, руководители групп разработки;
- Руководители и топ‑менеджеры: CTO, Heads of Engineering, директоры по продукту.

Если вы хотите поучаствовать в опросе, то вот ссылка на его прохождение (ориентировочно, опрос занимает полчаса), сам опрос закончится в конце ноября, а результатами мы поделися в конце января или начале февраля следующего года. На выходе будет большой отчет + описание методологии, которое базируется на подходе DORA (про этот подход я рассказывал в деталях и не раз: 1, 2, 3, 4, 5).

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

#AI #Software #Engineering #Management #RnD #Leadership #Data

Релиз мобильного Т-Банка на iOS с оплатой по bluetooth:)

Code of Leadership #55 Interview with Alexey Kashin about management, architecture & reliability (Рубрика #Leadership)

Интервью с Алексеем Кашиным, моим коллегой, который в Т-Банке руководит направлением разработки сервисов неклиентских профилей в нашей платформе профилей. Интересно, что параллельно этому Леша выполняет роль chief reliability officer, главного за надежность в той же profiles platform. За полтора часа мы обсудили множество тем

- Вступление и текущая роль (платформа профайлов)
- Ранние годы и первые шаги в программировании
- Вуз: поступление, SQL/БД, диплом
- Старт карьеры: финуправление и администрирование
- Внедрение документооборота: процессы, обучение, модель работы
- Переход к руководству и запуск BPM-направления (стоимость, импортозамещение, Java)
- Первый продукт на новой платформе; смена стека и переход в другую компанию
- Формат работы и инфраструктура; проблемы многопоточности и зависаний
- Рост команды и обучение; «единая кредитная заявка» и финмаркетплейс
- Платформа и технические улучшения; переход в Тинькофф и реинжиниринг CRM
- Архитектура домена компаний и бесшовная миграция (репликация, Kafka, сверка данных)
- Инструменты и надёжность: инциденты, метрики, шардирование/кастом БД, миграции
- Инженер vs менеджер, распределёнка и роль офисов
- Work/liffe баланс и советы слушателям

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

#Software #Engineering #Management #Career #Leadership #Architecture #Reliability

Как измерять продуктивность инженеров на разных уровнях (Рубрика #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