От продуктов к JBTD или как поток изменений влияет на структуру компании (Рубрика #Management)

В прошлом году на YaTalks 2023 я уже рассказывал про то, как формировать структуру команд под запросы бизнеса. В конце этого лета я рассказывал о том, как выглядит схема управления Т-Банком сейчас. А в этой статье я хотел бы рассказать о том, а как она трансформировалась со временем и куда мы движемся сейчас. В своем описании я буду использовать концепцию матричного управления, но баланс матрицы будет постоянно меняться:)
В новой статье есть рассказ про три структуры
1) Функциональная организация - этот этап я назвал "горизонтальным"
2) Продуктовая организация - этот этап я назыал "вертикальным"
3) Организация, ориентированная на сценарии (JBTD) или сегменты - этот этап я назвал "диагональным"

#Management #Architecture #Software #Engineering

Research Insights Made Simple #7 - Interview with Pavel Lakosnikov about Architecture Governance (Рубрика #Architecture)

В этом выпуске подкаста про инсайты ко мне в гости пришел Павел Лакосников для того, чтобы поговорить про управление архитектурой в крупной компании:) Павел руководит юнитом architecture governance в Авито, распилил один монолит, а также любит метрики. Пришел в Авито 9 лет назад на позицию разработчика.

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

P.S.
Выпуск доступен в виде подкаста в podster.fm, а чуть позже будет и на Yandex Music.

#Architecture #Software #Evolution #Management #Governance #Management #Leadership

Database Internals Meetup #5: пять докладов на секции СУБД конференции ISPRAS Open (Рубрика #Architecture)

Две недели назад я был на конференции ИСП РАН, а точнее на митапе Database Internals #5, который проходил в рамках этой конференции. Мне очень понравились выступления и я рекомендую их посмотреть в записи, если уж есть такая возможность. А я расскажу про мысли Андрея Фомичева, которые он рассказывал по итогам разработки YDB на протяжении 10 лет и которые выглядели как keynote этого митапа.

1) Новая СУБД начинается с идеи
2) Необходимо срезать углы, чтобы проверить гипотезу и запуститься. Но по долгам придется платить
3) Иногда заложенная прочность и универсальность пригождаются
4) Новаторские идеи рано или поздно догоняют. И могут осложнить жизнь
5) Производительность - это всегда важно
6) Пользователи хотят all-in-one СУБД
7) СУБД - это не только технологии, но еще и команда, окружение и инвестиции
😍 Новая СУБД начинается с идеи, но идея должна быть амбициозной и на века

В процессе рассказа Андрей не только формулировал эти идеи из практики YDB, но и упоминал другие вещи, такие как статью "What Goes Around Comes Around... And Around... " от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Я рассказывал про нее в трех частях: 1, 2 и 3. Также в докладе были мысли созвучные статье "Big Data is Dead", о котором я уже тоже рассказывал или рассказ про расширение стандартных баз данных на новые сценарии, такие как векторные данные - про этот сценарий и тип данных можно подробнее почитать в моем обзоре доклада "A Fun & Absurd Introduction to Vector Databases".

В общем, митап был крутой - тянул на уровень полноценной конфы ... а так он же и был частью конфы от ИСП РАН.

#Data #Architecture #Software #DistributedSystems #Database

Культурный код (The Culture Code: An Ingenious Way to Understand Why People Around the World Live and Buy as They Do) (Рубрика #Management)

Книга Клотера Рапая "Культурный код: Как мы живём, что покупаем и почему" раскрывает концепцию культурного кода, который представляет собой бессознательный смысл, придаваемый объектам или явлениям в рамках конкретной культуры. Автор книги, Клотер Рапай - французский психоаналитик, маркетолог и бизнес-консультант, который известнен как раз этой теорией «культурных кодов». Он родился во Франции в 1941 году, но позже эмигрировал в США, где построил свою карьеру. Рапай является основателем и CEO компании Archetype Discoveries Worldwide, которая занимается исследованием культурных архетипов и их применением в маркетинге. В этой книге он описывает свою концепцию в научно-популярном стиле и раскрывает основные идеи

1) Импринтинг и эмоции: Запечатленные в детстве образы и связанные с ними эмоции формируют бессознательные ассоциации, которые влияют на восприятие и поведение человека во взрослой жизни. Эти образы являются основой культурных кодов.
2) Различия между культурами: Каждая культура имеет уникальные коды, которые определяют восприятие таких понятий, как здоровье, красота, секс и молодость.
3) Практическое применение: Знание культурных кодов помогает бизнесу адаптировать продукты и маркетинговые стратегии для разных стран. Успех бренда на мировом рынке зависит от его соответствия культурным ожиданиям.

Вот несколько примеров из книги, когда Клоттер описывает конкретные коды, которые он получал в рамках своих исследований по заказам брендов

1) Коды любви, обольщения и секса
1.1) Любовь
- В США любовь ассоциируется с обманутыми ожиданиями.
- Во Франции любовь связана с удовольствием.
- В Италии — с весельем.
- В Японии любовь воспринимается как временная болезнь.
1.2) Обольщение. В американской культуре обольщение связано с манипулированием. Например, компания L'Oréal адаптировала свою рекламу в США, делая акцент на уверенности женщины в себе, а не на соблазнительности.
1.3) Секс. Код секса в США — насилие, что объясняет более терпимое отношение американцев к насилию по сравнению с сексуальностью.

2) Коды красоты и лишнего веса
2.1) Красота. В американской культуре красота ассоциируется со спасением мужчины, так как считается, что женщина может сделать мужчину лучше.
2.2) Лишний вес. Код лишнего веса — бегство от проблем и неудач.
3) Коды молодости и здоровья
3.1) Здоровье
- В США здоровье связано с движением, поэтому продукты, связанные с мобильностью, популярны среди американцев.
- В Китае здоровье ассоциируется с гармонией с природой.
-В Японии здоровье воспринимается как долг перед семьей и обществом.
3.2) Молодость. Молодость в американской культуре символизирует энергию и стремление к новым достижениям.

В итоге, сам автор книги использует культурные коды для создания успешных рекламных кампаний, поскольку они позволяют брендам адаптировать свои сообщения к особенностям восприятия целевой аудитории в разных культурах. Это позволяет
1) Учитывать национальные особенности и ассоциации
2) Адаптировать сообщения для разных культур
3) Использовать локальные образы и традиции
4) Стремиться к созданию эмоционального резонанса
5) Избегать провалов благодаря чувствительности к культуре и ее кодам

#Culture #PopularScience #Management

Satya Nadella | BG2 w/ Bill Gurley & Brad Gerstner (Рубрика #AI)

Интересное интервью CEO Microsoft, что Сатья Наделла дал двум венчерным инвесторам Bill Gurley и Brad Gerstner. В самом интервью много интересного, но основными были следующие темы:
1) Назначение генеральным директором Microsoft
Наделла делится своим опытом, включая стратегическую записку, направленную в комитет по выбору CEO, и трансформацию компании под его руководством с 2014 года, что привело к значительному увеличению доходов, прибыли и рыночной стоимости. Кстати, про это можно почитать книгу Сатья Наделлы "Hit Refresh", про которую я рассказывал раньше
2) Искусственный интеллект и OpenAI
Сатья и ведущие обсуждают инвестиции Microsoft в OpenAI, гонку вооружений в области ИИ и будущее ИИ-агентов. Наделла подчеркивает трансформирующий потенциал ИИ как для потребительских, так и для корпоративных приложений. Про это подробнее ниже
3) Будущее SaaS и ИИ-агентов
Наделла прогнозирует, что ИИ революционизирует SaaS (программное обеспечение как услуга), разрушая традиционные категории приложений и позволяя ИИ-агентам управлять бизнес-логикой через несколько баз данных.
4) Советы для генеральных директоров
Он делится своими мыслями о лидерстве, акцентируя внимание на понимании структуры рынка и использовании партнерств для достижения успеха.
В ходе беседы также рассматриваются стратегия капитальных расходов Microsoft, безопасность ИИ и дальнейшие шаги в развитии OpenAI.

А теперь подробнее про фразу "SaaS is dead", которая суммаризирует мнение Сатьи о дальнейшем развитии enterprise приложений как сервисы. Это мнение раскладывается на следующие тезисы
1) AI Replacing Static Business Logic
Наделла утверждает, что многие SaaS-приложения по сути являются базами данных CRUD (создание, чтение, обновление, удаление) с заранее определенной бизнес-логикой. Он прогнозирует, что ИИ-агенты возьмут на себя управление этими статическими процессами, динамически обрабатывая бизнес-логику через несколько баз данных, что сделает традиционную архитектуру SaaS менее актуальной
2) Shift to AI-First Architectures
В нашем будущем, бизнес-приложения уйдут от статических моделей, с ориентацией на приложения к системам, что ориентированы на агентов. Эти агенты буду выполнять роль интеллектуального слоя, который будет хранить состояние и выполнять оркестрацию запросов к внешним приложениям, чтобы выполнять задачи автономно без заренее прописанных вручную workflow
3) Collapsing Back-End Systems
По мере успешной работы агентных систем потребность в стандартных бизнес-приложениях с кучей коннекторов и интеграцией между ними уменьшится. Теперь агенты смогут сами интегрировать эту функциональность. По-факту, мне все это напоминает чем-то напоминает переходы, что были раньше
- Когда-то был толстый клиент и тонкое приложение, что, по-факту, только хранило данные
- Потом мы пошли в сторону тонких клиентов и большого количества логики на бекенде
- Потом бекендов стало много и им надо было уметь дружить с собой
- А в новом агентном мире бекенды смогут стать простыми, а вся сложность координации вернется на клиента (на агентнскую систему, что выполняет запросы от имени клиента)
4) Transformation of Tools and Processes
Такие инструменты, как Excel, могут превратиться в платформы, где ИИ-агенты выполняют сложные задачи — от планирования до анализа и исполнения. Например, интеграция Python в Excel уже демонстрирует такие изменения
5) Opportunities for Innovation
Хотя этот переход может нарушить существующие модели SaaS, он также открывает возможности для создания адаптивных решений с приоритетом ИИ. Компании, которые примут этот переход, будут лучше подготовлены к новой парадигме

В итоге, Сатья скорее говорит не про смерть SaaS, а про перерождение в более динамичную и интеллектуальную систему под управлением ИИ. Это знаменует значительную эволюцию в проектировании и использовании программного обеспечения. По-моему мнению, это очень интересно влияет на архитектуру и дизайн софта, но об этом как-нибудь в следующий раз.

#Management #Strategy #Leadership #Vision #Bigtech

Инфляция нейминга C*O (Рубрика #Humor)

Последние несколько лет я наблюдаю инфляцию названия позиций в разных компаниях примерно по такому сценарию
1) Когда-то шильдик CTO говорил о принадлежности к топ-менеджменту и такой человек был в компании один. Остальные назывались Directors, VPs и так далее.
2) Потом в крупных компаниях с кучей продуктовых вертикалей шильдик CTO как-то плавно уплыл в сторону технических руководителей этих вертикалей и CTO в компаниях стало десятки. Определенная логика в этом есть - такие вертикали часто были размером больше тысячи человек, но червячок сомнения уже начинал закрадываться.
3) Дальше оказалось, что в таких крупных вертикалях есть отдельные продукты зачастую на 100+ человек - а их руководители тоже стали CTO - это привело к дальнейшему увеличению количества CTO и инфляции названия ...
4) А сегодня я видел кандидата из другого цветного банка, что в своем резюме написал CTO, отвечая примерно за 10 человек, то есть тимлиды уже себя тоже называют CTO.
5) Вангую, что дальше инженеры, дорастая до уровня Senior, начнут называть себя CTO ... хотя постойте также уже происходит в разных банках, откуда к тебе на собеседование приходит исполнительный директор, который исполнял указания задач из Jira в одиночестве. Я таких CTO называю "сам себе CTO", вспоминая передачу "Сам себе режиссер".

В общем, рекомеендую перестать обращать внимание на название позиции и ориентироваться на зону ответственности человека:)

P.S.
Себя я не отношу к категории CTO:)

#Humor #Software #Leadership #Management

Data Mesh in Action (Data Mesh в действии) (Рубрика #Data)

Прочитал за последний месяц эту книгу трех авторов Майхжака, Балнояна и Сивяка. Сама книга может служить простым руководством для понимания и внедрения концепции data mesh (или сетки данных, как указано в переводе), которая децентрализует управление данными для улучшения масштабируемости, доступности и извлечения ценности из данных. Книга состоит их трех частей и девяти глав

Part 1: Foundations
Эта часть посвящена основам и позволяет легко и быстро понять, а в чем собственно весь цимес.
1. The What and Why of the Data Mesh
В этой главе авторы рассказывают как поменялась парадигма работы с данными от централизованного DWH к децентрализованному владения и operations, который должен быть за командами, отвечающими за сами домены. Суть в том, чтобы рассматривать всю социотехническую систему и фокусироваться на людях и процессах, а не просто на технологиях. Цель в том, чтобы убрать узкие места централизованной системы. По-факту, это похоже на историю с микросервисами в общем, а также тем, что эффект от сетки виден только на большом масштабе. Про это есть глава в книге Влада Хононова "Learning DDD", которуя я разбирал в статье "DDD и data mesh"
2. Is a Data Mesh Right for You?
Вторая глава как раз позволяет понять насколько data mesh подходит для ваших потребностей. Здесь рассматриваются преимущества и недостатки централизованного и децентрализованного подхода. Про это мы много говорили с Колей Головым в шестом эпизоде подкаста "Research Insights Made Simple"
3. Kickstart Your Data Mesh MVP in a Month
В этой главе авторы куют железо пока горячо, а точнее рассказывают как запилить MVP для сетки данных за месяц. Они круто объясняют как разобраться со стейкхолдерами, выбрать правильный домен, а дальше из говна и палок собрать прототип, который позволит показать эффект.

Part 2: The Four Principles in Practice
Здесь авторы в деталях разбирают все четыре основных принципа data mesh, как завещала Zhamak Dehghani, автор самой концепции
4. Domain Ownership
Здесь идет речь за ответственность за домен, когда за данные начинает отвечать команда, что находится ближе всего к их генерации. Важно правильно определить границы доменов данных, чтобы они были выровнены относительно бизнес функциональности и помогали взаимодействию технических и бизнесовых стейкхолдеров.
5. Data as a Product
В этой главе описывается принцип о том, что данные становятся first-class citizen среди продуктов, а не побочным эффектом. Это изменение приводит к тому, что у дата продукта появляются свойства: легкого обнаружения, надежность, возможности использования потребителями. Для этого нужно следовать ряду практик: наличию понятных API, метаданных, стандартов качества и так далее.
6. Federated Computational Governance
Этот принцип про децентрализованную федеративную систему для вычислений. Суть в том, что требуется уметь балансировать между центральными политиками партии и локальной автономностью. Это можно достигнуть за счет автоматизации процесса compliance и обеспечения консистентности между границами доменов одновременно с автономной работой самих команд.
7. The Self-Serve Data Platform
И все это счастье должно предоставляться на платформе самообслуживания для того, чтобы позволить командам самим создавать и управлять дата продуктами. Здесь рассказывает про platform engineering и я рекомендую почитать whitepaper про платформы от CNCF (1, 2 и 3)

Part 3: Infrastructure and Technical Architecture
В этой части автор приводит примеры построения self-service платформы, а также дизайна решения.
8. Comparing Self-Serve Data Platforms
Здесь сравниваются платформы поверх Google Cloud Platform, AWS, Databrics, self made over Kafka stack. Авторы приводят примеры и сравнивают применимость каждого.
9. Solution Architecture Design
В этой главе авторы рассказывают как работать с функциональными и нефункциональными требованиями, как проводить дизайн сессии и как использовать C4 Model для моделирования системы.

В общем, книга мне показалась полезной и с нормальным переводом:)

#Data #Management #Processes #Architecture