Code of Leadership #10 - An Elegant Puzzle - System of Engineering Management (часть 2)

В десятом выпуске Code of Leadership заканчивается обсуждение крутой книги "An Elegant Puzzle: Systems of Engineering Management" (начало в выпуске 9), про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management.
Книгу мы продолжаем разбирать с Eugene Sergueev, senior engineering manager во Flo health, приложении для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения.

В этом выпуске только вторая половина обсуждения, так как весь выпуск получился длинной больше трех часов:) А если кратко, то за 2 часа мы успели обсудить все темы со второй половины третьей части по окончание книги, а точнее

3. Tools - как проводить инженерную реорганизацию (и стоит ли это вообще делать), как формировать свои карьерные нарративы, как подходить к продвижению сложных тем без формального authority с использование подхода model-document-share, как делать презентации топ-менеджменту и управлять своим временем
4. Approaches - как не погрязнуть в управлении исключениями к собственным policies, как говорить нет, формулировать свою философию менеджмента, как понимать где у engineering managers возникают проблемы, как быть в партнерских отношениях со своим менеджером, находить себе зону ответственности и устанавливать направление развития организации
5. Culture - как формировать культуру инклюзивной организации с использованием возможностей и membership, как выбирать лидов проектов, делать своих peers первой командой, как балансировать positive и negative freedoms в культуре компании, отказаться от культуры героев в пользу устойчивого роста
6. Careers - как выстраивать процесс интервью, как проводить холодный sourcing, работать над воронкой найма, использовать performance management для развития уже нанятых сотрудников через понятные карьерные лестницы, как создавать специализированные роли вроде SRE или TPM (technical product manager), как проектировать циклы собеседований для желаемых позиций
7. Appendix - как оперировать в растущей оранизации: на уровне линейного менеджмента, уровне middle management и дальше менеджмента всей организации, а напоследок автор приводит список книг и white papers по интересным для него темам

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

CTO Day Light от Yandex

Вчера была интересная тусовка для технических директоров от Yandex в центре Москвы.
Мероприятие получилось для меня очень интересным, так как удалось пообщаться с умными людьми и обсудить интересные вопросы от полушуточных до серьерзных, например
- Как выстраивать end-to-end процессы продуктовой разработки и какие проблемы тут могут быть
- Как выстраивать оргструктуру под требования бизнеса и как понять оптимальна ли структура под текущие запросы
- Что такое культура компании и как она влияет на взаимодействие команд и процессы
- Как подходить к процессам архитектуры и проектирования - тут и про написание дизайн доков, про нотации моделирования, про описание стейта архитектуры vs изменений, про TLA+ и не только
- Кто такие системные аналитики и что они делают в командах разработки
- Как выглядит работа в европейской компании vs российской:)
- и так далее

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

P.S.
Спасибо организаторам, что позвали в гости на это мероприятие.
Кстати, оно было продолжением того, что было на CTO Day в Дубае, про которое я рассказывал раньше.

#Engineering #Software #Management #SystemDesign #SystemEngineering #Leadership

The Engineering Executive's Primer: Impactful Technical Leadership

Сегодня друг подарил мне эту книгу Will Larson в бумаге, которая больше квартала ехала из США. Я уже предвкушаю как прочитаю эту книгу для инженерных топ-менеджеров:) Суть в том, что мне нравится бложик Вилла Ларсона lethain.com и его предыдущие книги
- Staff Engineer - эта книга является классным источником информации по карьерному пути для инженеров, которые переросли уровень senior и отправились покорять новые моря. Я про нее уже рассказывал: 1 и 2
- An Elegant Puzzle. Systems of Engineering Management - крутая книга для engineering managers, про которую я рассказывал раньше, а потом было две серии подкаста "Code of Leadership" с разбором этой книги вместе с Eugene Sergueev, senior engineering manager из Flo health: 1 и 2

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

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Обсуждение книги "Learning Domain-Driven Design" вместе с ребятами из клуба { между скобок } (Рубрика #Architecture)

Сегодня вечером в 19:00 я приду к ребятам в гости, чтобы обсудить последнюю, четвертую часть книги, которая называется "DDD и другие методологии и паттерны". Вся книга очень интересна и я рассказывал об этом раньше. Кроме того, последние главы мне настолько понравились, что я даже в свое время сделал отдельные разборы каждой главы
14 глава. DDD и микросервисы
15 глава. DDD и event-driven architecture
16 глава. DDD и data mesh
Поэтому я с большой радостью откликнулся на приглашение Гриши Скобелева обсудить эту книгу вместе.

#Management #Architecture #SoftwareArchitecture #DDD #SystemDesign #Leadership #DistributedSystems #SystemEngineering #SoftwareDevelopment

Архитектурный чекап здоровья систем - Андрей Шалунов, Яндекс Плюс (Рубрика #Architecture)

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

P.S.
Выступление мне зашло по трем причинам
1) Я на этой неделе выступал внутри на бизнес-стендапе с 10 минутным рассказом про эволюцию архитектуры Т-Банка и направлении дальнейшего развития. И это выступление начиналось с того, что я объяснял почему строительная метафора вредна, а метафора природы и живых организмов полезна, правда я там говорил про леса и рисовые поля, где как и в архитектуре часто сложно узнать что происходит за поверхностью воды или интерфейса:)
2) Я в последнее время много времени уделяю медицинским процедурам и прохожу этакий чекап, посещая невролога, кордиолога, окулиста, ... И кажется, что чекап надо было делать раньше, а не забивать на него.
3) Недавно у меня был выпуск подкаста "Code of Leadership" с Антоном Костериным, заместителем технического директора в Т-Банке, про наш процесс управления архитектурными изменениями и при желании часть активностей оттуда можно было бы назвать архитектурным чекапом

#Management #Architecture #SoftwareArchitecture #SystemDesign #SystemEngineering #SoftwareDevelopment

Platform Strategy - Gregor Hohpe & James Lewis - GOTO 2024 (Рубрика #Architecture)

Это интересное интервью ребят из книжного клуба GOTO с Gregor Hohpe, который написал недавно очень интересную книгу "Platform Strategy". Gregor - тертый калач и я уже как-то рассказывал про его достижения, среди которых написание книг "Enterprise Integration Patterns" (мой пост о книге), "The Software Architect Elevator" (мой пост о книге), "Cloud Strategy", которую я ее еще не читал и "Platform strategy", которую я читаю сейчас и о которой идет речь.

Основныые тезисы в интервью следующие
- Платформы важны, потому что они помогают снизить когнитивную нагрузку на инженеров
- Классификация платформ: base platform (навроде AWS), а также кастомные платформы внутри компаний, которые должны не повторять AWS, а закрывать специфичные для компании сценарии. На эту тему Грегор рассказывал доклад "Build abstractions not illusions", про который я уже рассказывал. В общем, платформы могут создавать иллюзии простоты, но на самом деле могут быть сложными и требовать принятия решений.
- Платформы должны предоставлять полезные абстракции для создателей приложений и не вводить в заблуждение. Здесь автор вспоминает про книгу "The Software Architect Elevator" и говорит о том, что если для правильного использования платформы требуется погружаться в детали реализации абстракции, то что-то не так с платформой
- Грегор рассказывает про переименование разнообразных систем в платформы. И для того, чтобы понять платформа ли перед вами надо помнить, что платформы не должны делать все за вас, а должны облегчать выполнение задач.
- Во время создания платформ важно общаться с командами разработчиков и наблюдать за тем, что они делают, чтобы понять, как они решают проблемы. А сам Грегор часто помогает командам понять, что они на самом деле сделали, и как это может быть использовано в других контекстах.
- Метафоры могут помочь людям мыслить по-другому и повысить прозрачность в общении. Собственно, сам Грегор использует автомобильные метафоры для рассказа о платформах - в автоиндустрии уже давно начали использовать платформы для шасси, а сверху лепили чуток отличающиеся кузовы. Затраты на создание шасси фактически разделяются между разными моделями автомобилей
- Собственно хорошие платформы гармонизируют основу, а поверх нее позволяют расцвести инновациям - так было в мире автомобилей и то же самое мы видим в мире облачных платформ
- Стандартизация может быть инструментом для инноваций, но важно не превращать ее в самоцель. Это просто инструмент для достижения целей
- Когда мы задумываемся об изменениях, то надо понимать как ограничения, которые устраняются, могут влиять на мировоззрение людей и их работу. Этот переход к новой парадигме может быть трудным для людей, но это может привести к новым возможностям и ограничениям. Одновременно важно задавать вопросы о том, а какие новые ограничения возникают вместе с новыми технологиями.
- При создании внутренней платформы разработки в компании надо создать платформу, которая будет полезна для бизнеса, а не просто для инженеров. Она должна быть сосредоточена на том, что важно для бизнеса, а не на технических аспектах.
- Экономика внутренней платформы может быть хуже, чем у облачного провайдера, из-за меньшего масштаба. Кроме того, она может быть связана с вопросами ценности и долговечности продуктов.

В будущем Грегор планирует написать книгу о стратегии API и интеграции, которая будет учитывать границы и поможет людям усвоить эти концепции. Это будет в некотором роде продолжение книги "Enterprise Integration Patterns", которая вышла больше 20 лет назад.

#Conference #PlatformEngineering #SystemEngineering #Software #Architecture #DistributedSystems #Management

Дисциплины в университете: что изучают студенты ФКН (Рубрика #Career)

Недавно вышел интересный эпизод подкаста "Уютный ФКНчик", в котором обсуждается прикладное значение курсов, которым обучают в университете и их полезность в дальнейшей карьере. Подкаст интересен темой и своим звездным составом
- Евгений Соколов - ведущий подкаста, а также научный руководитель Центра непрерывного образования ФКН, академический руководитель образовательной программы «Прикладная математика и информатика» ФКН
- Иван Пузыревский - гость подкаста, а также директор по технологиям в Yandex Cloud
- Игорь Маслов - гость подкаста, а также директор базовых технологий в Т-Банке

Ребята за час успевают обсудить кучу вопросов, которые могут помочь не только студенту, но и уже сложившемуся инженеру понять как ему прокачиваться дальше
- Сколько и каких языков программирования надо знать хорошему специалисту;
- Что нужно знать про операционные системы, чтобы устроиться в Yandex Cloud;
- Зачем на собеседованиях требуют знания алгоритмов и структур данных;
- Почему необходимо изучать математику и как она пригождается на практике;
- Нужно ли машинное обучение классическим разработчикам;
- Как писать безопасный код и что для этого надо знать.

Подкаст организован Центром непрерывного образования ФКН совместно с Т-Банком.

P.S.
Я с большим интересом послушал этот подкаст, но еще интереснее общаться на эти темы с ребятами вживую:)

#Career #Software #Architecture #SystemEngineering #Engineering

Обзор whitepaper "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" (Рубрика #Architecture)

Недавно я прочитал очень интересное исследование на тему API Governance от академических исследователей и специалистов из Google. Целью исследования было понимание влияния подходов к управлению API (application programming interface) на продуктивность и usability. По итогам этого research исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API. Мне это исследование показалось интересным для написания обзора, так как последние годы я имею отношение на работе к темам
- Architecture governance
- Development productivity
- API management
А этот whitepaper имеет отношение к каждой из этих тем:)

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

В итоге, авторы написали план по углублению и расширению исследований, который поможет точнее оценить эти эффекты, а может быть и лучше натренировать API Architect (файнтюненную LLM), которая помогает с написанием API спек.

Подробнее про этот whitepaper можно почитать в моей статье

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

API Governance at Scale (Рубрика #Management)

Недавно прочитал интересную статью исследователей про API Governance процессы в Google. На самом деле эта статья напрямую предшествует статье "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency", про которую я рассказывал раньше. В статье "API Governance at Scale" авторы в деталях как и зачем авторы меняли подход к построению API. Собственно, они пришли к процессу, что состоит их трех частей
1) API Improvement Proposals - это задокументированный источник правды относительно того, какие правили есть по отношению к дизайну API
2) API Linter - это автоматизированная проверка соответствия API правилам из AIP (круто, что авторы смогли кодифицировать AIPs и дальше проверять их в этом линтере)
3) API Readability - программа обучения и сертификации API Design экспертов. Процесс API Readabity в Google похож на другой их процесс, а точнее на code readability, про который я уже рассказывал раньше

Это исследование рассматривает этот процесс со стороны создателей API и показывает позитивное влияние на качество API как со стороны результата, так и процесса. Интересно, что в уже упомянутой статье-продолжении "AI-Enhanced API Design" этот же процесс рассматривается как со стороны создателей, так и потребителей API и тоже показывает положительное влияние.

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

P.S.
Именно странички из этой статьи послужили иллюстрацией к посту про whitepaper.

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

API Improvement Proposals (Рубрика #Architecture)

Я уже рассказывал про whitepaper "API Governance at Scale", по которому скоро будет обзорная статья, а потом еще и выпуск нового подкаста с обзорами whitepaper. Но сегодня я хотел бы рассказать, что у ребят есть публичные артефакты, которые доступны для изучения всем заинтересованным людям
1) API Improvement Proposals (AIPs) - это задокументированный источник правды относительно того, какие правили есть по отношению к дизайну API. Эти AIPs разбиты по следующим категориям: meta, process, API concepts, resource design, operations, fields, design patterns, compatibility, polish, protocol buffers. Их очень интересно изучить
2) API Linter - это автоматизированная проверка соответствия API правилам из AIP (круто, что авторы смогли кодифицировать AIPs и дальше проверять их в этом линтере). Он работает только для API, определенных с помощью protocol buffers.
3) API Readability - программа обучения и сертификации API Design экспертов. Процесс API Readabity в Google похож на другой их процесс, а точнее на code readability, про который я уже рассказывал раньше. Но публичного это процесса нет:)

Отдельно авторы описали как можно внедрить этот процесс у себя "Adopting AIPs in your company" (еще рекомендую почитать Github)

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

API Design Patterns (Паттерны проектирования API) (Рубрика #Architecture)

В последнее время я много изучаю материалов на тему governance. Туда входит architecture governance, API governance и другие подходы для того, чтобы двигаться в сторону engineering excellence. И так получилось, что я в выходные снял с полки эту книгу "API Design Patterns" из последней закупки на распродаже в издательстве "Питер". Книгу написал Джей Джей Гивакс, соавтор статьи "API Governance at Scale" про подходы в Google. Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta - это видно по заглавной страничке с авторами whitepaper:)

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

P.S.
Я разбирал статью "API Governance at Scale" в первом выпуске нового подкаста "Research Insights Made Simpe" (видео в Youtube, подкаст в Ya Music). Отдельно разбор есть в моем блоге в виде статьи.

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

The Engineering Executive's Primer - Part 0 (Рубрика #Management)

Я уже давно прочел новую книгу Will Larson для IT топ-менеджеров, про которую я писал раньше. Прочел и прочел, но все как-то не доходили руки написать про нее, но сейчас я в очередной раз сижу в аэропорту и жду самолета, поэтому время есть:) Сразу скажу, что книга мне понравилась - у Вилла как обычно отлично со структурой книги, а отдельные главы достаточно емкие и наводят на размышление (интересно, что они обычно появляются как статьи в блоге lethain.com, один из немногих блогов, что я читаю)

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

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

The Engineering Executive's Primer - Part I (Рубрика #Management)

Продолжая нулевой пост с обзором книги, я хотел бы сказать, что Will не поскупился на контент и сгенерировал целых 24 главы, вступление, заключение и еще пяток дополнительных материалов. Разобрать все это добро за один раз не получится, поэтому постов будет много, но начнем мы с первого:)

0) Preface
Во введении автор рассказывает про то, как он пришел к идее этой книги после предыдущих книг "Staff Engineer" и "An Elegant Puzzle. Systems of Engineering Management". Первая является классным источником информации по карьерному пути для инженеров, которые переросли уровень senior и отправились покорять новые моря. Я про нее уже рассказывал: 1 и 2. Вторая книга хороша для engineering managers, про которую я рассказывал раньше, а потом было две серии подкаста "Code of Leadership" с разбором этой книги вместе с Eugene Sergueev, senior engineering manager из Flo health: 1 и 2
1) Getting the Job
Начинает книгу автор с того, чтобы рассказать про то, а как же можно получить работу в качестве engineering executive. Для начала стоит ответить себе на вопрос, а точно стоит в это вписываться? Дальше возникают вопросы, а где это делать: внутри текущей компании или во внешней. Дальше автор обсуждает хаотичный процесс найма топов, который отличается от компании к компании, а дальше еще идет и обсуждение условий. Ну и заканчивается все тем, а как размышлять относительного того, а принимать офер или нет. В общем и целом, глава действительно неплохо описывает этот непростой процесс и дает структуру и подход для взвешенного принятия решений.
2) Your First 90 Days
Здесь автор говорит о том, что в первые 90 дней придется серьезно попотеть и начать с того, чтобы разобраться с тем как работает бизнес и откуда приходят деньги, что определяет культуру компании, как установить здоровые взаимоотношения со стейкхолдерами и своими peers, насколько хорошо функционирует инженерная команда с точки зрения delivery, насколько высоко техническое качество софта и инструментов для поддержки процессов разработки, что с моралью инженерной команды и насколько сама команда устойчива для выбранного темпа развития команды. Дальше важно ограничить количство ранних изменений, что вы делаете в первые 90 дней. Кроме этого важно выстроить доверие с коллегами и позаботиться о поддержке с их стороны. Вообще, классно разобраться как в компании осуществляется работа и как выглядят технологии (включая код и деплой, дежурства, работа с инцидентами, ...)
3) Writing Your Engineering Strategy
Эту главу я разбирал еще тогда, когда она была просто статье в блоге автора. Статья была отличной и она не стала хуже после превращения в книжную главу:)
4) How to Plan
Автор рассказывает про стандартный подход к планированию в компаниях:
- Ежегодное финансовое планирование (включая план по headcount)
- Полугодовые или квартальные планы, например в виде OKRs для команд. Эти планы таргетируют бизнес результаты или список проектов, что надо сделать
- Внутрикомандные процессы управления работой (Kanban, Scrum, etc), которые направлены на то, чтобы уложиться в квартальные/полугодовые планы
- Отдельно автор говорит о том, что могут быть еще и периодические ревью, например, каждый месяц. Эти ревью направлены на отслеживание прогресса по выполнению целей компании

Продолжение в следующих постах: 2

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

The Engineering Executive's Primer - Part II (Рубрика #Management)

Продолжая нулевой пост и первый пост с обзором книги, я хотел бы рассказать про следующие главы

5. Creating Useful Organizational Values
В этой главе автор говорит про организационные ценности и как они влияют на работу компании. Он вспоминает свою работу в Uber и конкретно культурный принцип "Let builders build (People must be empowered to build things)", который повышал diversity технологического ландшафта. Каждый из инженеров считал, что этот принцип про то, что они могут делать то, что хотят:) Подробнее про Uber в книге "Super Pumped", про которую я уже рассказывал.
Дальше автор рассказывает о том какие проблемы решают организационные ценности, должны ли они быть общими для всей организаций или у инженерной части должны быть какие-то свои ценности. Мне нравятся критерии Вилла относительно того, а как проверить насколько ценность сформулирована так, чтобы приносит пользу:

- Reversible: It can be rewritten to have a different or opposite perspective without being nonsensical.
- Applicable: It can be used to navigate complex, real scenarios, particularly when making trade-offs.
- Honest: It accurately describes real behavior.

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

Дальше Вилл рассказывает как раскатывать обновления культутрных ценностей через стандартный процесс раскатки изменений: "identify the opportunity, document potential options, involve stakeholders early to build buy-in, test before finalizing to avoid folks feeling trapped, and iterate until it’s useful". А потом отдельно надо встроить изменения в найм, онбординг, лестницу грейдов. Ну и дальше подсвечивать соответствие новым ценностям во время работы.
Напоследок автор приводит тот список ценностей, что кажется ему полезным

- Create capacity (rather than capture it).
- Default to vendors unless it’s our core competency.
- Follow existing patterns unless there’s a need for order-of-magnitude improvement.
- Optimize for the [whole, business unit, team].
- Approach conflict with curiosity.

6. Measuring Engineering Organizations
Эту главу автор начинает с перечисления подходов к измерениям в инженерных организациях, а дальше он рассказывает про свой подход к измеренями, про паттерны и антипаттерны. И для начала надо отметить, что он делит подходы на измерения для себя и измерения для стейкхолеров. В части "measuring for yourself" он говорит про измерения для планирования, выполнения, оптимизации, а также для вдохновения. В части измерений для стейкхолдеров автор говорит про измерения для CEO и совета директоров, для финансового департамента, для стртегически peers (продукт, дизайн, продажи), для тактических peers.
Дальше автор предлагает алгоритм для измерений
1) Некоторые вещи сложно измерить, поэтому пробуйте это измерить только если вы действительно планируете учитывать это при принятии решения. Если же это нет так, то просто померьте что-то попроще, навроде, прокси-метрики
2) Часть измерений очень проста, поэтому появляется желание сделать эти измерения для построения доверия со стейкхолдерами:) И тут часто желание измерений и усилия, приложенные для их получения, важнее чем реальный результат:)
3) Если возможно, добавляйте по одному измерению за раз, так как если пытаться внедрить слишком много изменений в измерения, то можно облажаться.
Дальше автор приводит список антипаттернов для измерений

- Focusing on measurement when the bigger issue is a lack of trust.
- Letting perfect be the enemy of good.
- Using optimization metrics to judge performance.
- Measuring individuals rather than teams.
- Worrying too much about measurements being misused.
- Deciding alone rather than in community

Интересно, что этот список хорошо пересекается с антипаттернами из книги "Тирания показателей" ("The Tyrany of Metrics"), про которые я рассказывал раньше

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

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

What Is Your Definition of Software Architecture (Рубрика #Architecture)

Пока готовился к своему выступлению на ArchDays в пятницу, наткнулся на paper почти 15-летней давности от Software Engineering Institute с названием "What Is Your Definition of Software Architecture". В нем авторы сделали подборку определений архитектуры программного обеспечения с начала времен по 2010 год. Среди определений встречаются примечательные

1) Из книги "Documenting Software Architectures: Views and Beyond (2nd Edition)", Clements et al, AddisonWesley, 2010:
The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.
2) Из книги " Software Architecture in Practice (2nd edition)", Bass, Clements, Kazman; AddisonWesley 2003, которую я перечитывал пару раз
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
3) Из стандарта ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
4) Из RUP (Rational Unified Process)
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition

В итоге, можно выделить следующие взгляды на программную архитектуру
- Высокоуровневая структура - организация системы, структурных элементов и их интерфейсов. Фокус на взаимодействии элементов
- Абстракция и композиция - архитектура представляет собой абстракцию, что скрывает реализацию. Такие абстракции позволяют проще думать о взаимодействиях компонентов. Эта тема была отлично раскрыта John Osterhout в книге "A Philosophy of Software Design", что я рассматривалась в 21 выпуске подкаста "Code of Leadership"
- Набор структур - этот набор позволяют комплексно размышлять о программной системе, в этот набор обычно включают элементы, их взаимосвязи и свойства
- Руководящие принципы - это история про governance:) Суть в том, что архитектура - это про принципы, политики, модели, стандарты. В общем, тут фокус на стратегическом роли архитектуры. Недавно я вспоминал книгу про "Continuous API Management", где тема governance была отлично раскрыта
- Компромиссы и принятие решений - это история про принятие фундаментальных структурных решений, что стоят дорого для будущего. Фокус на поиске компромиссов между функциональными и нефункциональными требованиями
- Архитектурные стили и паттерны - это практический подход, который фокусируется на выделении повторно используемых подходов к построению архитектуры. Недавно вспоминал про книгу "API Design Patterns"
- Коммуникация со заинтересованными сторонами - здесь фокус на том, что нам надо обсуждать и согласовывать архитектурные решения со стейкхолдерами для принятия дорогих решений.

В итоге, определений много и перефразируя Джорджа Бокса, все они неправильные, но некоторые полезны:)
Главное понимать их границы применимости и использовать по назначению. У меня вроде картинка за 20 лет работы в IT сложилась:)

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance #ArchBook

The Engineering Executive's Primer - Part III (Рубрика #Management)

Продолжая первые посты об этой крутой книге (0, 1, 2) с обзором книги, я хотел бы рассказать про следующие главы.

7) Participating in Mergers and Acquisitions
В этой главе автор говорит про участие ИТ топ-менеджеров в merge & acquisitions процессах. Для начала автор разбирает про сложные мотивы для m&a действий - условно цели команды, что ведет сделки, отличаются от целей инженерных команд. В общем, важен общий взгляд на процесс и понимание бизнес-стратегии, чтобы оценить соответствует ли поглощение целям компании и выявить потенциальные риски. Отдельно автор описывает структурированный подход к оценке поглощений с инженерной точки зрения, куда входит создание шаблонов для оценки сложности внедрения, проблем интеграции, масштабируемости, безопасности, соответствия требованиям, затрат и инженерной культуры. Важно также запланировать интеграции между объединяемыми компаниями - важен четкий план интеграции для эффективного управления переходом после поглощения. Это включает решения по интеграции технологий, реструктуризации команд и роли лидерства. А дальше надо управлять этим процессом.

😍 Developing Leadership Styles
Автор предлагает модель из трех подходов к управлению
- Leading with policy - для повторяемых решений, которы надо делать консистентно разными людьми внутри организации
- Leading from consensus - для нечастых решений с контекстом, который распределен между несколькими заинтересованными сторонами.
- Leading with conviction - для решений без четкого предложения, когда вовлеченные лица сильно расходятся во мнениях или когда решение оказывает значительное долгосрочное влияние на вашу организацию
В этой главе автор приводит примеры из своего опыта в разных компаниях (Digg, Uber, Stripe, Calm). А дальше говорит о том, что надо уметь работать над прокачкой тех стилей лидерства, что несвойственны вам. Это позволит вам стать более универсальным руководителем:)

9) Managing Your Priorities and Energy
В этой главе автор рассказывает про свою стратегию к решению задач вида "Компания - Команда - Я". Изначально автор рекомендовал принимать решения, основываясь на иерархии: сначала компания, затем команда, и в последнюю очередь — личные интересы. Этот подход использовался для обеспечения соответствия решений целям компании, а не личным или командным предпочтениям. Однако позже автор осознал, что такая жесткая структура может привести к выгоранию и потере мотивации среди сотрудников. Но дальше автор подчеркивается важность управления энергией как процесса с положительной суммой. Предполагается, что предоставление людям возможности заниматься работой, которая их вдохновляет, даже если она не соответствует непосредственным приоритетам, может повысить общую продуктивность и удовлетворенность работой.

В итоге, концепт "Company, Team, Self" изменяется на подход "Eventual Quid Pro Quo", которая балансирует приоритеты компании с личными потребностями в энергии. Этот подход поощряет приоритизацию вдохновляющей работы при необходимости для поддержания долгосрочной вовлеченности и эффективности. Автор подчеркивает необходимость гибкости в применении стратегий. Утверждается, что хотя следование правильным приоритетам важно, это не должно происходить за счет личной энергии и мотивации. Лидеры должны адаптировать свои подходы в зависимости от личных нужд и контекста их ролей.

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

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Архитектурные материалы для изучения от облачных провайдеров (Рубрика #Architecture)

Как-то раньше я не писал о том, что помимо книг есть большое количество архитектурных материалов у главной тройки cloud провайдеров.

1) У AWS это называется AWS Well-Architected Framework, у него 6 ключевых столпов
- Operational excellence (операционная эффективность): Фокус на управлении и мониторинге систем для обеспечения бизнес-ценности и постоянного улучшения процессов.
- Security (безопасность): Защита информации и систем с помощью надежного управления идентификацией, защиты данных и обнаружения инцидентов.
- Reliability (надежность): Обеспечение того, что рабочие нагрузки выполняются в соответствии с ожиданиями и быстро восстанавливаются после сбоев.
- Performance efficiency (эффективность): Оптимальное использование ресурсов для удовлетворения требований системы.
- Cost optimization (оптимизация затрат): Помощь в отсутствии ненужных расходов при сохранении производительности.
- Sustainability (устойчивость): Фокус на минимизации воздействия на окружающую среду за счет оптимизации энергопотребления.

2) У Microsoft это называется Azure Well-Architected Framework. Он имеет схожие цели и структуру с AWS фреймворком, в нем даже то же самое название, но столпов всего 5 (выпала часть про sustainability)
- Cost optimization (оптимизация затрат): Максимизация ценности при минимизации расходов.
- Operational excellence (операционная эффективность): Эффективное управление операциями и автоматизация процессов.
- Performance efficiency (эффективность): Обеспечение производительности и масштабируемости приложений.
- Reliability (надежность): Построение отказоустойчивых архитектур, способных восстанавливаться после сбоев.
- Security (безопасность): Защита данных и систем через надежные методы безопасности.

3) У Google это называется Cloud Architecture Framework. Он имеет немного другую структуру, но также фокусируется на ключевых принципах построения облачных решений. У него пять столпов:
- Operational excellence (операционная эффективность): Эффективное развертывание, эксплуатация, мониторинг и управление рабочими нагрузками.
- Security, privacy, and compliance (Безопасность, конфиденциальность и соответствие требованиям): Обеспечение безопасности данных, их конфиденциальности и соблюдения нормативных требований.
- Reliability (надежность): Построение отказоустойчивых систем, способных выдерживать сбои.
- Cost optimization (оптимизация затрат): Максимизация бизнес-ценности за счет оптимизации использования ресурсов.
- Performance optimization (оптимизация производительности): Настройка ресурсов для достижения оптимальной производительности.

Из этого краткого описания фреймворков видно, что у них похожие фокусы на оптимизацию затрат, безопасность, оптимизацию производительности, надежность. В общем, на вопросы, которые важны для клиентов, что планируют заезжать в облака (но важны также и при разворачивании on-prem). Эти фреймворки направлены на то, чтобы помочь организациям постоянно оценивать и улучшать свои облачные архитектуры на основе лучших практик, предоставляемых соответствующими облачными провайдерами. Хотя конкретные детали реализации могут различаться между провайдерами, основные принципы остаются схожими на всех платформах.

Кстати, часть научных статей ребят превращаются в мануалы внутри этих фреймворков. Например, раздел "Deployment archetypes" из документации Google изложен в научной статье "Deployment Archetypes for Cloud Applications", которую я разбирал больше года назад в своем блоге.

#DistributedSystems #ExternalReview #SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemDesign #SystemEngineering #Cloud

Research Insights Made Simple #4 - Обсуждение "AI-Enhanced API Design"

В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability. Исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API.

В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии.

Кстати, эпизод доступен и в подкасте Яндекс Музыки.

Материалы:
- AI-Enhanced API Design: A New Paradigm in Usability and Efficiency
- Мой обзор этой научной статьи
- Публичное T-API для партнеров
- Подкаст InSAйт

Мы обсудили следующие моменты
- Обзор статьи и личные впечатления Павла
- Обсуждение структуры статьи
- Проблемы и аспекты проектирования API
- Процесс разработки API в Google
- Гибкость и стандартизация в разработке API
- Методология исследований в Google
- Подходы к исследованием вокруг API в T-банке
- Проблемы и решения в персонализации
- Использование линтеров и метрик
- Анализ логов и задач разработчиков
- Исследования и метрики в Google
- Генерация контрактов
- Проблемы с архитекторами
- Методология эксперимента в Google и его результаты
- Ограничения эксперимента
- В общем про процесс разработки и помощь автоматизированных средств
- Важность этапа реализации
- Архитектура и улучшение процессов
- Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google)
- Роли в разработке
- Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity (Радикальная прямота) (Рубрика #Management)

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

Часть I - Новая философия менеджмента
1. Выстраивание радикально откровенных отношений. В этой главе описывается основная идея книги - важность сочетания личной заботы о сотрудниках с прямым вызовом. Автор объясняет, как это помогает улучшать рабочие отношения и повышать производительность команды.
2. Получать, отдавать и помогать. Эта глава посвящена методам установления доверительных отношений в команде, что является основой для успешного применения радикальной откровенности. Для этого автор описывает модель, которая визуализируется как двухмерный график. На графике вертикальная ось представляет "Личную заботу", а горизонтальная ось - "Прямой вызов". Цель состоит в том, чтобы работать в квадранте, где оба элемента высоки, создавая среду открытой и конструктивной обратной связи. Это и есть квадрант радикальной откровенности, а также есть разрушительное сочувствие, оскорбительная агрессивность и манипулятивная неискренность.
3. Что мотивирует каждого члена вашей команды. Здесь автор приводит свою модель суперзвезд и надежных сотрудников: фактически есть "суперзвезды", которые находятся на крутой траектории роста, и "надежные сотрудникы", которые предпочитают стабильность и устойчивую производительность. Признание этих различий помогает эффективно управлять ростом команды.
4. Добиться успеха вместе. В этой главе автор рассказывает про свою модель работы с людьми в команде "Выслушать" - "Объяснить" - "Обсудить" - "Решить" - "Убедить" - "Выполнить" - "Усвоить" и дальше опять "Выслушать". На протяжении всей главы автор рассказывает как должен работать этот цикл в компании.

Часть 2 - Инструменты и техники
5. Взаимоотношения. Эта глава посвящена построению и поддержанию эффективных отношений в команде. Автор подчеркивает важность доверия и открытого общения между коллегами. Она предлагает стратегии для улучшения взаимодействия, чтобы создать более сплоченную и продуктивную рабочую среду.
6. Наставничество. В этой главе рассматривается роль наставничества в развитии сотрудников. Автор объясняет, как руководители могут эффективно наставлять своих подчиненных, помогая им расти и развиваться в профессиональном плане. Она делится методами, которые позволяют вдохновлять и мотивировать сотрудников через личный пример и поддержку.
7. Команда. Глава фокусируется на создании эффективных команд. Автор обсуждает, как собрать команду, которая будет работать слаженно и продуктивно, а также как управлять различиями в характерах и навыках сотрудников. Автор подчеркивает важность разнообразия и инклюзивности для достижения лучших результатов.
8. Результаты. Заключительная глава посвящена достижению результатов через применение принципов радикальной откровенности. Автор делится инструментами и техниками, которые помогают руководителям не только устанавливать высокие стандарты, но и достигать их вместе с командой. Она акцентирует внимание на том, как измерять успех и корректировать подходы для постоянного улучшения.

Интересные факты о книге
- Ким Скотт активно использует свой опыт работы руководителем в bigtech компаниях, таких как Google и Apple.
- Она подчеркивает необходимость адаптации радикальной откровенности к различным культурным контекстам, чему она научилась в процессе работы с разнообразными командами по всему миру
- Книга не только теоретическая - она включает практические инструменты, такие как сценарии для сложных разговоров и основы для эффективных встреч.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

TDR — процесс технического дизайн-ревью / Павел Лакосников (Авито) (Рубрика #Architecture)

Интересный доклад Паши Лакосникова из Авито про принятие качественных технических решений в большой компании. Основные тезисы примерно следующие
1) Сам Паша давно работает в Авито и сейчас занимается выстраиванием architecture governance
2) По мере роста компании все сложнее принимать качественные решение из-за роста чимсла команд и усложнения иерархии
3) Компании часто вводят роли техлидов и архитекторов для решения этих проблем
4) Это приводит к тому, что инженеров отстраняют от принятия решения и они теряют мотивацию и ответственность за принятые без них решения
5) Дальше появляется архитектурные комитеты и архревью, где рассматриваются архитектурные артефакты и принимаются решения
6) Если все решения прогонять через архкомитет, то он становится бутылочным горлышком и замедляет работу, а также стоит много-много денег
7) Следующий шаг - это дизайн ревью решений в асинхронном формате
😍 Для этого нужны шаблоны документов для описания технических решений + автоматическая валидация их заполнения. В документе должны быть: автор, команда, юнит, дата создания, уровень влияния (низкий, средний, высокий), сроки ревью.
9) Дальше появляется реестр таких документов и возможность поиска и анализа решений
10) Инициативы делятся на разные уровни, которые требуют ревью разной строгости и формата
11) Уровни влияния помогают разным стейкхолдерам отслеживать только нужные им инициативы, например, техдиры могут отслеживать самые крупные изменения
12) У технических инициатив есть связь с продуктовыми, что позволяет лучше понять для чего мы делаем изменения и насколько они оправданы
13) У инициатив есть жизненный цикл: прототип, эксперимент, масштабирование. Каждый этап имеет свою детальность проработки. А также можно фиксировать зависимости между командами и компонентами для предотвращения ошибок.
14) Так как в инициативах указываются затронутые компоненты, то их владельцы получают уведомления и могут прийти поревьювить инициативу, в которой они упоминаются
15) Наличие реестра обеспечивает историчность принятия решений + позволяет настроить валидацию принятия решений, чем отдельные роли: авторы, контрибьюторы, FIY и owners
16) Реестр можно связать с техническим радаром, который должен быть входной точкой в жизненный цикл технологий.
17) Все это обеспечивает прозрачность появления и развития технологий, а также их depracation и миграции с EOL (end of life)
18) По всей этой машиенрии можно собирать метрики: количество decision records, время их прохожджения, доля успешно доведенных до конца и так далее
19) Внедренный процесс помогает решить проблему с архитектурными комитетами, а также повысить вовлеченность инженеров

P.S.
Про то, как это устроено у нас было в постах
- Серия подкаста "Code of Leadership" - Interview with Anton Kosterin about Architecture Governance
- Мое выступление на ArchDays 2024 - "Архитектура в Т-Банке: вчера, сегодня, завтра"
- Серия подкаста Research Insights Made Simple про "API Governance at Scale", где мы с Даниилом Кулешовым разбирали whitepaper о том, как это устроено в Google, а также говорили про governance у нас в компании

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance