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

Emerging Patterns in Building GenAI Products (Рубрика #AI)

Интересная статья от Мартина Фаулера и Bharani Subramaniam, в которой ребята рассказывают в формате паттернов про базовые кубики, из которых строятся GenAI приложения. Эта статья характерна для текущего Фаулера - в ней нет совсем ничего нового, но достаточно четко описано то, что уже известно на текущий момент:) Сейчас в списке паттернов присутствуют только те, что приведены ниже, но авторы обещают его постепенно пополнять.

- Direct prompting - пропмптинг из приложения foundation LLM. Не уверен, что это тянет на паттерн, но авторы походу в этом уверены. Думаю, что это примерно как вызов функции назвать дизайн паттерном:)
- Embeddings - здесь авторы рассказывают о переводе текста или картинки в вид многомерного вектора так, чтобы близкие по сути сущности были близки в этом многомерном пространстве. Метрика близости может быть разная, но часто это cosine similarity, когда мы смотрим насколько векторы соноправлены. В примере само преобразование текста в embedding происходит через вызов библиотечной функции (и инженерам не надо думать о том, а как она работает под капотом). Суть в том, что эти embeddings нужны и самой LLM и их также можно дальше использовать для поиска по векторной базе данных. Рекомендую глянуть доклад "A Fun & Absurd Introduction to Vector Databases - Alexander Chatzizacharias - GOTO 2024", про который я рассказывал раньше
- Evals - здесь авторы рассказывают про оценку ответов LLM в контексте конкретных задач. По-факту, это напоминает тестирование обычного софта, но со звездочкой. Звездочка обусловлена тем, что ответ LLM не детерминирован, а значит тестировать в лоб "запрос - ответ" не получится, а надо делать что-то типа нагрузочного тестирования, когда мы тестируем performance модели в плане семантики и точности ответа. Для этого нужны сценарии + ожидания от ответа + какой люфт мы разрешаем в отклонениях от этого ответа.
- Hybrid retriever - здесь авторы рассказывают, что можно комбинировать ответы от векторной базы данных при поиске близких сущностей в плане embeddings с более каноническим поиском, условно, full text
- Query rewriting - можно использовать LLM#2 для того, чтобы переписать промпт и дальше несколько его вариантов скормить LLM#1. Это в теории позволяет улучшить промпт, причем LLM#1 и LLM#2 могут быть как одной и той же LLM, так и разными. Например, LLM#2 может быть обучена делать хорошие промпты из плохих, а LLM#1 отвечать качественно на промпты
- Reranker - При поиске данных может возвращаться много документов, а контекст моделей пока не резиновый, поэтому есть вариант отдельно отранжировать найденные документы и только нужные прокинуть в контекст запроса для LLM
- Retrieval augmented Generation (RAG) - этот паттерн про то, что можно не просто просить LLM сгенерировать ответ, но и позволить ей сделать поиск информации, а дальше найденную информацию прокинуть в контекст запроса. В рамках этого паттерна мы можем использовать Hybrid retriever, Reranker, Query rewriting

Про файнтюнинг моделей обещали написать в следующих сериях, возможно, потом допишут что-то и про агентов.

В общем, статья полезна именно инженерам, чтобы понять базовые примитивы GenAI приложений.

P.S.
Про статью я узнал из канала @startup_architecture моего коллеги, Антона Скогорева, который является техдиром у нас в AI Центре.

#AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

Финансовые результаты МКПАО "Яндекс" за 2024 год (Рубрика #Management)

Сегодня Яндекс опубликовал свои показатели за Q4 и за весь 2024 год, а также прогнозы по вырчке и прибыли на 2025 год. Что можно сказать интересного про группу компаний
- Все показатели на инфографике подросли (если бы не подросли, то их бы не было на инфографике)
- Бизнес-направления агрегируют внутри сервисы, чтобы показывать благополучение направлений в общем, по крайней мере с точки зрения роста
- Проникновение сервисов значительное, поиск 110 млн, go - 53.2 млн, плюс - 39.2 млн
- На инфографике не слишком ясно кто из бизнес-линий является донором денег, а кто реципиентом (и тратит их в качестве инвестиций для развития направления). Условно реклама-поиск зарабатывают и делятся с райдтехом, автономными технологиями, а яндекс плюс как бы связывает экосистему

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

#Economics #Engineering