Книжный куб

The way we play. Theory of game design (Гейм-дизайн. Как создаются игры) - Part I (Рубрика #Design) Недавно я прочитал эту книгу Майкла Киллика (Michael Killick), в которой автор просто и доступно рассказывает про гейм-дизайн, разбирая на примерах из успешных игрушек. Пара глав показывает как сделать базовые вещи с помощью движка Unity. Интересно, что сам автор преподает уже много лет преподает геймдизайн студентам, поэтому он знает не понаслышке о том, о чем рассказывает в книге Книга состоит из предисловия, 11 глав и приложения 1. Начало путешествия в мир гейм-дизайна - в этой главе автор рассказывает про топовые игры по продажам, где есть Mario Kart, Super Mario Bros, Pokemon, GTA, PUBG,, Minecraft, Tetris и другие игры. Дальше идет речь про документы, что создают обычно геймдизайнеры - One-pager - одностраничник с самой базовой информацией: название, игровые механики, возраст целевых игроков, рейтинг игроков, краткое описание сюжета с акцентом на геймплее, понятные режимы геймплея, уникальное торговое предложение, возможные конкуренты - Ten-pager - более подробный документ, где подробнее изложены моменты из one-sheet, а также добавлены отдельные страницы с деталями про: общую структуру игры, персонажа, геймплей, игровой мир, игровой опыт, игровые механики, врагов, кат-сцены, а также дополнительные материалы, что замотивируют на повторное прохождение - Beat chart - это одностраничный документ, описывающий структуру всей игры целиком (весь контент, механики, нарратив и т.д.) - подробнее можно прочитать здесь - Game design document (GDD) - это очень подробный документ по дизайну программного обеспечения для видеоигры. GDD создается и редактируется командой разработчиков и в основном используется для организации усилий внутри команды. Подробнее в Wikipedia 2. Видеоигры изнутри - в этой главе автор рассказыает про то, какие роли и ответственность есть в команде, что создает видеоигры, а также он рассказывает про разные жанры игр и откуда можно брать идеи Продолжение в следующем посте! #Games

The Rise of the CAIO (Рубрика #Management) Недавно мне на глаза попаслась забавная статья про найм CAIO - Chief AI Officers. Я ничего не имею против разнообразных CxO, но по этим новым неймингам можно отслеживать тренды хайпа. Я попробовал вспомнить что из интересного появлялось или набирало популярности за последние 20 лет - CTO - Chief Technology Officer - когда технологии стали модными - CKO - Chief knowledge officer - когда стала популярна идея про обучающиеся организации Питера Синге - CGO - Chief Growth Officer - последние 15 лет, когда все гнались за бешенным ростом (пример с контентными платфомами и соцсетями) - CDTO - Chief Digital Transformation Officer - когда все внезапно загорелись цифровой трансформацией (даже изначально не digital бизнес) - CDO - Chief Data Officer - когда данные стали называть новой нефтью - CAIO - Chief Artificial Intelligent Officer - когда все побежали заниматься искусственным интеллектом B общем, интересно какой тип C...O нас ждет дальше:) P.S. Отдельно отмечу, что часто после появления термина начинается его инфляция - я видел примеры, когда помимо главного CTO и остальных технических руководителей начинали называть CTO примерно так - CTO больших продуктов (~500 инженеров) - Дальше CTO отделов (~70 инженеров) - Дальше CTO команд (~ 10 инженеров) Финальной точкой может быть сам себе режиссер CTO:) #AI #Management #Humor #Future

When to write strategy, and how much? (Рубрика #Management) Интересная статья про создание стратегии от Will Larson (Lethain) в его крутом блоге. Кстати, Вилл написал уже три книги, каждую из которых я прочитал и каждая по своему мне понравилась:) Собственно, эта статья представляет главу из еще не написанной книги на тему стратегии. Здесь Вилл размышляет о том, когда пора писать стратегию и насколько она должна быть обширной. Вот основные мысли, что я извлек для себя 1) Когда писать стратегию? Организация может быть в трех стратегических состояниях: глобально консистентном (все понимают что и зачем делают), консистентным внутри отдельных команд, совсем разобранном, когда у инженеров мало согласия относительно того, как решать задачи. Собственно, смысл в формализации стратегии есть, если есть неконсистентность. С другой стороны многое зависит от того, куда направлен тренд изменений - если все идет не туда, то есть смысл делать стратегические изменения:) Но даже если все идет не туда, то надо сначала оценить насколько вы понимаете происходящее в организации для написания полезной стратегии. Эффект от стратегии может сведен на нет, если организация слишком часто меняет направление. 2) Насколько много должно быть стратегий? Это важный вопрос, так как стратегий относительно разных активностей может быть много, но если не ограничивать WIP (work in progress), то по каждой из них результаты будут мизерными. В итоге, тут важна приоритизация и выделение самого важного. Заодно можно часть вещей делать не фундаментально на все времена, а начинать по шагам, которые не пугают участников своим объемом, но приближают вас к цели 3) Масштаб и высота стратегии Здесь Вилл предлагает поделить стратегии на разрешительные и запретительные. Первые предлагают вариант решения аля (golden path), но не запрещают остальные варианты. В итоге, движение по такому пути выглядит менее напряжным для участников и растягивается во времени. По-факту, тут работа идет через доработку golden paths и adoption инструментов. В запретительных стратегиях есть разрешенный вариант, а все остальное запрещено. Возможны эскалации, но они должны быть единичны. Это более жесткий и быстрый путь. В итоге, разрешительных стратегий может быть запущено одновременно больше, чем если мы будем делать те же самые изменения через запретительные стратегии. Суть в том, что они требуют меньше усилий. 4) Не слишком ли много стратегий вы имплементируете? Вилл парадоксально отмечает, что хоть и многие инженеры в компаниях считают, что у их компании нет четкой инженерной стратегии, но гораздо больше руководителей терпят неудачу, пытаясь много работать над стратегией, а не мало:) Определить это можно, оценив насколько прошлые стратегические инициативы, повлияли на последующие решения. P.S. Книги Вилла в порядке их выхода - "An Elegant Puzzle" - мой рассказ о книге - "Staff Engineer" - мой рассказ о книге - "The Engineering Executive's Primer" - мой рассказ о книге

"Founder Mode" и "Notes on Founder Mode" (Рубрика #Management) Недавно я рассказывал про интересное интервью Брайана Чески, CEO и co-founder Airbnb (1 и 2). В этом интервью Брайан говорил о том, как он поменял схему управления компанией от сильно распределенной обратно в режим основателя компании (founder mode). Брайан подробно объяснял что его побудило сделать такие изменения, а также то, чего они добились со времени изменения. Недавно, а точнее в сентябре, вышла статья за авторством Paul Graham, сооснователя Y Combinator. В этой статье Пол рассматривал "founder mode" и "manager mode" и отмечал, что до этого момента масштабирование стартапа в Кремниевой Долине неявно предполагало переход от режима основателя к режиму менеджера. Но пример Брайана показывает, что это не обязательно идет компании на пользу. Пол даже вспоминает Стива Джобса и его выезды с ключевыми сотрудниками, которые не относились к самым высоким чинам в корпоративной иерархии. А это нарушает этот иерархичный организационный подход из manager mode

Whatever founder mode consists of, it's pretty clear that it's going to break the principle that the CEO should engage with the company only via his or her direct reports. "Skip-level" meetings will become the norm instead of a practice so unusual that there's a name for it. And once you abandon that constraint there are a huge number of permutations to choose from. For example, Steve Jobs used to run an annual retreat for what he considered the 100 most important people at Apple, and these were not the 100 people highest on the org chart.

Дальше вышла понравившаяся мне статья Anu Atluru, в которой разбирались тезисы Пола Грехема. Вот основные тезисы из нее: 1) Most founders are in “founder mode” and most of them fail anyway - Most early-stage startup founders are in founder mode by default - Many founders are first-time founders with zero management experience. - Founder mode has a dark side risk that can hurt the company and employees 2) Companies don’t fail because founders switch leadership modes. They fail because the mode switch is set up to fail, ill-timed, and rigid Сценарии, когда classical management приводит к проблемам - There’s no clear vision and strategy for the company - The people being managed aren’t the right fit for the job. - The context is evolving while the “leadership mode” stays rigid. 3) The best CEOs (founder or not) know how to switch between founder mode and management mode — and when they need either one - Founder mode is akin to the wartime CEO mode. Management mode is more akin to peacetime CEO. - “Founder mode” and “management mode” can’t be seen as static opposites. 4) A founder’s unique leadership style will put them in their zone of genius and make them happy (mostly) - Founders need to find their own ideal leadership mode - The tricky part? It takes practice to figure out. В итоге, мне кажется, что это очень важные вопросы для крупных компаний, которым важно не застыть во времени и пространстве, а оставаться гибкими и способными реагировать на рыночные изменения и появление конкурентов. Актуально в этом плане посмотреть на Intel и как они из лидера рынка превратились в аутсайдера, которого Qualcomm планирует выкупить и распродать дальше по частям:) #Management #Leadership #Processes #Engineering #Project #Software #Design #ProductManagement #BusinessStory

Sber Enterprise Architect Framework (SEAF) (Рубрика #Architecture) Интересное выступление про корпоративный архитектурный фреймворк от Сбера, которая позволяет посмотреть на один их подходов к документированию архитектуры. Основные тезисы, что я почерпнул для себя - Этот фреймворк делала несколько лет команда экспертов для для решения проблем управления архитектурой и обеспечения его интеграции в производственный процесс - Философское наполнение этого фреймворка описано в статье "Архитектор 2.0" на Хабре - Фреймворк не противопоставляет себя другим фреймворкам, а скорее дополняет их, накапливая и оцифровывая практики - в иллюстрациях приведены DDD, TOGAF, C4 Model, ... - Фреймворк содержит внутри себя инструменты, пркатики, методологию и артефакты (хорошо, что онтологий нет) - Целью фреймворка создать цифровую модель предприятия, которая будет иметь неоспоримые характеристики и позволит производить производные. - Инструментом для автоматизации является DocHub, который я отношу к категории инструментов architecture documentation as a code - Инструмент позволяет создать рабочее место для архитекторов разных мастей, которые теперь будут рисовать на квадратики и стрелочки для визуализации - теперь они смогут писать это в yaml файлах. Все также как и раньше будет дуализм: 1) то, что происходит в коде и на инфраструктуре и 2) то, что нарисовал архитектор в своих yaml. Зато теперь это можно называть as a Code - Фреймворк подходит для федеративного управления архитектурой, которая может быть расширяема и адаптирована под нужды каждого домена - В списке инструментов есть пакетный менеджер, который позволяет скачивать и управлять пакетами с метаданными. - SEAF стимулирует сообщество к адаптации фреймворка под свои нужды и использовании успешных методологий - Автор агитирует к переходу от архитектора 1.0 к архитектору 2.0. Архитектор 1.0 - это человек, который визуализирует визуальную схему и модель, в то время как архитектор 2.0 - это человек, который создает архитектуру и постоянно работает над улучшением и заимствованием практик. - В докладе автор рассказывает про метамодель, которая описана еще и на Github - Для структурирования метамодели выбран подход разделения ее на слои и вертикали. - Слои выделяют функциональные области, в то время как вертикали пронизывают их и связывают. Выделяются слои: - Бизнес-архитектура; - Прикладная архитектура; - Техническая архитектура. Вертикали: - Информационная архитектура; - Управление требованиями. - Важным принципом метамодели является - адаптивность. Она должна легко подстраиваться под нужды использования. Предусматривать частичное применение, возможность расширения и модификации. Таким образом, решение о фактическом объеме использования метамодели предоставляется пользователю. В общем, это хорошая попытка создания фреймворка для реализации подхода architecture documentation as a code. P.S. На тему управления архитектурой уже было недавно несколько постов, которые тоже интересно почитать - Архитектура как код - Роман Пионтик - ArchDays 2022 - Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022 - Материалы к моему докладу "Architecture at T-Bank: how we design our solutions" - Раз архитектура — «as Code», почему бы её не покрыть тестами?! - Проводим архитектурное ревью продуктовой фичи - Опыт использования подхода «Архитектура как код» в ГК Самолет - Роман Пионтик, Валентин Козлов - ArchDays 2023 - Генерация архитектурных схем и метаданных - Кирилл Ветчинкин - E-community 2023 #SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems

Обзор 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

Финал ICPC Ребята из МФТИ, моей альма-матер, отлично съездили на финал ICPC (International Collegiate Programming Contest), взяли второе место и получили золотую медаль. Поздравляю ребят с таким результатом и отрадно видеть, что 3 из 5 ребят имеют отношение к Т-Банк (подробнее в посте Т-Образования). Отдельно хочу отметить, что команды из Asia East и Asia Pacific взяли большинство медалей, например, две золотых выбили китайские команды, одну - японская. Еще одну золотую выбили как раз ребята из МФТИ, которые защитили честь Northern Eurasia, а пару бронзовых медалей зацепили команды из North America: Massachusetts Institute of Technology, Swarthmore College. P.S. Интересно, что как раз сегодня я опубликовал интервью с Женей Соколовым с факультета компьютерных наука ВШЭ, где мы говорили про современный подход к образованию для software development engineers%) #Software #Engineering

Code of Leadership #19 - Interview with Evgeny Sokolov about Modern Education Интервью с Евгением Соколовым, доцентом факультета компьютерных наук НИУ ВШЭ, про то, как выглядит современное образование для software development engineers (Youtube, Yandex Music). Евгений руководит бакалаврской программой «Прикладная математика и информатика», преподаёт машинное обучение. В 2014-2019 годах работал в Яндексе, где успел позаниматься внутренними инструментами для ML, проектами по DS для внешних заказчиков, рекомендательными системами в Дзене. В этом выпуске мы обсуждаем темы - Как Евгений пришел в образование из индустрии - Как ВШЭ выстраивает свое партнерство с компаниями на рыке - Философия образования - Архетипы студентов на факультета компьютерных наук (ФКН) ВШЭ - Продуктовый подход - Важность фундаментальных знаний  - Важность понимания дизайна - Практическое применение знаний - Взаимодействие с новыми сотрудниками - Обсуждение дизайна и преподавания - Типы преподавателей и их привлечение - Преподаватели из индустрии - Советы для преподавателей #Architecture #Software #Management #Leadership #Processes #Education

Подборка книг для поста про распродажу в издательстве "Питер"

Осенняя распродажи в издательстве Питер (Рубрика #Sales) В издательстве Питер очередная распродажа по конец сентября со скидками в 40% на бумажные книги. Для получения этой скидки надо использовать промокод "Бумажная" при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг, что еще не успел прочитать, но это не помешает мне порекомендовать их опять - Data mesh в действии - тема очень интересна в контексте ухода от стандартного DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale" и поэтому решил почитать другую книгу:) - Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:) - Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок - Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:) - Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT и GPT-4, я ее уже прочел и даже рассказывал в отдельном посте. - Распределенные данные. Алгоритмы работы современных систем хранения информации - в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture" - Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу - Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее. - README. Суровые реалии разработчиков - книга про будни разработчиков и практиками инжиниринга, которые сейчас являются стандартом де-факто. Если книга зайдет, то дам ее почитать 18-летнему сыну, что пошел в этом году на направление геймдизайн (и наконец-то начал читать книги по программированию) - Software: Ошибки и компромиссы при разработке ПО - эта книга подкупила меня своей второй главой, которая называется "Дублирование кода не всегда плохо". - Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас уже начал ее читать - Грокаем Continuous Delivery - я вроде неплохо понимаю в CI/CD, но хочется почитать про него подробнее в очень простых примерах, опять же, если книга окажется хорошей, то я смогу ее рекомендовать для начинающих (навроде, моего старшего сына) - Грокаем функциональное программирование - лет 10 назад еще на Coursera я проходил 5 курсов по ФП, где мы разбирали Scheme, Racket, Scala и другие эзотерические языки программирования. Я так их и не ипользовал в проде, но хочется побботать их опять - вдруг я чуток лучше начну их понимать - Дизайн для разработчиков - я довольно много книг читаю про дизайн для дизайнеров (1, 2, 3), а тут хочу посмотреть как это подают разработчикам - Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО - в рамках работы над книгой про engineering management полезно изучить другие источники - Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании - для инженеров и технических руководителей сейчас полезно думать продуктово, особенно если вы работаете не в галере. Яуже писал про книги на эту тему: 1, 2, 3, 4, 5 - Паттерны проектирования API - я люблю паттерны, люблю хорошие API, плюс мне понравилось оглавление. - Чистый Python. Тонкости программирования для профи - я уже больше полугода решаю задачки на Leetcode, используя Python 3. До этого я когда-то использовал Python 2, но и тогда это был мой 3-4 язык из доступного набора по частоте использования. Именно поэтому я решил взять книгу и преисполниться python way по мере ее чтения:) #Sales

The C4 Model - Misconceptions, Misuses & Mistakes - Simon Brown - GOTO 2024 - Part II (Рубрика #Architect) Заканчивая обзор интересного выступления от Simon Brown, я хотел бы рассказать про оставшиеся мифы и советы, которые давал Саймон своим слушателям - Message-driven architecture и как ее отображать в C4 Model - автор рекомендует отображать не центральный Kafka брокер как контейнер, а отображать отдельные топики как containers или просто указывать их текстом на стрелках, что соединяют контейнеры с разными сервисами - Общие библиотеки и компоненты - Общие библиотеки и компоненты часто путают, но их следует представлять по-разному. Общие библиотеки лучше изображать как компоненты C4, а не как самостоятельные приложения. - Микросервисы - микросервисы часто неправильно моделируют как контейнеры с API и схемами баз данных. Микросервисы следует моделировать как программные системы, контейнеры или группировки контейнеров. Важно понимать, что микросервисы могут быть представлены как группа контейнеров или как отдельный контейнер. - Закон Конвея и микросервисы - по мере роста компании и увеличения количества команд, микросервисы могут стать более сложными. Важно учитывать закон Конвея и создавать микросервисы таким образом, чтобы они были масштабируемыми и интегрируемыми. - Контекстная диаграмма и разделение сервисов - команда создает веб-приложение, но сервисы передаются отдельным командам. Контекстная диаграмма теперь показывает сервисы как отдельные программные системы. Важно не видеть детали внутренней реализации сервисов, а использовать API. - Масштабирование и диаграммы - при масштабирования C4 для больших архитектур появляются проблемы. Решение: создание отдельных диаграмм для каждого сервиса. Инструменты, такие как Visio, могут усложнить процесс создания диаграмм, но у C4 Model есть Structurizr - Модели как код и структура диаграмм - при использование моделей как кода для создания диаграмм мы получаем преимущества: разделение модели на части и предоставление нескольких представлений. Недостатки: упущение общей картины. - Интерактивные диаграммы и инструменты - интерактивные диаграммы помогают изучать сервисы и компоненты. Можно добавлять метаданные и взаимодействовать с объектами. - Рекомендации по созданию диаграмм - Саймон предлагает фокусироваться на одной программной системе, избегать показа внешних контейнеров, чтобы избежать зависимости от деталей чужой системы. В качестве примера он показывапет использование общей базы данных как границы между системами. В конце Саймон напоминает, что C4 Model подходит для создания иерархических абстракций и диаграмм. C4 Model независима от нотаций и инструментов. #Software #Architect #SystemDesign #SoftwareArchitecture #Processes

The C4 Model - Misconceptions, Misuses & Mistakes - Simon Brown - GOTO 2024 - Part I (Рубрика #Architect) Очередное интересное выступление от Simon Brown, создателя C4 Model, на тему моделирования архитектуры. Конкретно в этом выступлении он выступает в качестве человека, который развеивает мифы об использовании C4 Model для этих целей. Начнем с описания того, что Simon говорит о том, что такое C4 Model

- A set of hierarchical abstractions (software systems, containers, components, and code). - A set of hierarchical diagrams (system context, containers, components, and code). - Notation independent. - Tooling independent.

Суть в том, что C4 Model позволяет рассказывать разные истории разным аудиториям - автор показывает это на примере Google Maps, где мы можем от уровня всего Земного шарика спуститься до уровня Google Street View и посмотреть как выглядит наш домик:) Если же переходить к элементам C4 Model, то у нас есть системный контекст, что описывает систему и ее окружение, а контейнеры показывают технологические составляющие и их взаимодействие. А дальше автор перечисляет набор мифов и дальше разбирается с ними - C4 Model новвая штука на рынке - нет C4 Model существует с 2007 года и обладает общирным тулингом - С4 Model была создана для замены UML - Нет C4 не создавала как замена UML, она его дополняет структурированным подходом к созданию иерархических абстракций и диаграмм - C4 Model стала популярна в последние 5 лет? - да, она стала популярнее после пандемии, особенно среди организаций, работающих удаленно. - Почему Model C4 называется C4, а не C3 - Саймон считает важным, чтобы диаграммы заземлялись на реальность, а именно на компоненты и код (нижние 2 уровня) - Синий и серый цвет в нотации скучный - Саймон говорит, что вы можете выбрать свой любимый цвет - C4 модель может быть не ясна, если в ней много текста - Саймон рекомендует использовать много текста, который помогает передать больше информации о системе. А наличие метаданных на диаграммах помогает устранить двусмысленность и правильно интерпретировать диаграммы. - C4 не создана для фиксации решений по архитектуре прямо на диаграммах - Саймон говорит, что их лучше описывать отдельно в виде ADR (architecture decision records), прикладывая диаграммы из C4 Model для ясности и наглядности - C4 не содержит deployment схемы - C4 была вдохновлена UML и моделью 4+1 Филиппа Крачтена, в которых deployment схема очень важна. В итоге, вы можете при помощи C4 Model собрать свою deployment диаграмму, где будут контейнеры, системы и инфраструктура. - Мы не используем C4 Model, так как мы используем DDD вместо этого - это просто бессмысленная штука, которая показывает, что люди, которые так говорят не шарят - Нейминг container и component не очень хороши - да, но их лучше не переименовывать, так это запутает людей еще больше - C4 Model is too limiting - автор показывает что 4 уровня абстракции помогают оставаться на определенном уровне абстракции. Если снять ограничение на уровни абстракций, то легко попасть в N-уровней, которые уже сложно различать даже на уровне слов. Саймон показывает пример с неймингом database - это сервер баз данных? конкретная база данных? конкретная схема? В общем, Саймон говорит, что ограниченный набор уровней позволяет внести ясность в обсуждение, а не провалиться во фрактальную история с системами, подсистемами, подпод....системами, в которых сам черт ногу сломит. - Может добавить дополнительные абстракции? - Саймон объясняет почему следующие термины не очень хороши: подсистемы, bounded contexts, layers. Эти абстракции не добавляют пользы в диаграммах. Часть из этих терминов - это не абстракции, а элементы организации элементов Продолжение обзора в следующем посте. P.S. Я уже рассказывал про другие выступления Саймона на тему моделирования архитектуры - The lost art of software design by Simon Brown at Devoxx Belgium 2022 - C4 Models as Code • Simon Brown • YOW! 2022 - Continuous Architecture in Practice Eoin Woods & Simon Brown • GOTO 2021 #Software #Architect #SystemDesign #SoftwareArchitecture #Processes

Дискуссия про эффективность в рамках встреч Сергея Щербинина и команды "безвотэтоговотвсего" и СРО/СТО клуба Авито (Рубрика #Management) Уже через полтора часа в офисе Авито на Лесной начнется встреча с обсуждением хайповой темы эффективности. Для тех, кто не сможет быть лично, есть трансляция (Youtube, VK) Приглашенными гостями будут ⁃ Влад Плющев, СТО B2C Сбера ⁃ Ярослав Тулупов, Директор по разработке Avito Pro ⁃ Илья Лосев, СТО Яндекс Crowd ⁃ Александр Поломодов, техдир Т-Банка (автор этого канала) А модерировать дискуссию будет бессменный ведущий, Сергей Щербинин На встрече предполагается обсудить следующие вопросы ⁃ Как управлять эффективностью команд разработки? ⁃ Что вообще блин такое эта самая эффективность в разработке? ⁃ Какими метриками должны быть обложены Discovery и Delivery, чтобы легче дышалось лидерам? ⁃ Как все это масштабировать на десятки и сотни команд? Если тема вам нравится и вы хотите посмотреть обсуждение лично, то регистрируйтесь здесь. P.S. Я на тему эффективности уже достаточно много рассказывал, поэтому приведу основные посты - Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" - Какие подходы были в академической среде: DORA и Accelerate, SPACE, DevEx - тезисы со ссылками на материалы доступны здесь - Как это делают в Bigtech, например, в Google используют подход QUANTS - тезисы доступны здесь - Что есть на рынке в виде коммерческих платформ - тезисы и ссылки здесь - Мое выступление "Как формировать структуру команд под запросы бизнеса на YaTalks 2023", так как структура часто влияет на эффективность - Мое выступление "Совершенствование потока разработки программного обеспечения" - Недавние мои обзоры whitepapers от Google: мой обзор whitepaper "Measuring Developer Goals" и мой обзор whitepaper "Developer productivity for Humans, Part 7: Software Quality" #Processes #Management #Architecture #Leadership #SoftwareDevelopment #Software #SoftwareArchitecture

Message from Amazon CEO Andy Jassy: Strengthening our culture and teams (Рубрика #Management) Интересная записка от CEO Amazon на тему усилиения культуры компании и команд. Если говорить кратко, то заметка кажется интересной для больших организаций, которые за время пандемии набрали много людей и перешли на гибридный подход к работе. Amazon проанилизировал эффективность работы и принял решения об 1) Уменьшении уровней в оргструктуре за счет сокращения процента менеджеров по отношению к individual contributor 2) Переходу на пятидневную рабочую неделю в офисе вместо трех дней в офисе и двух дней удаленно Если разбирать тезисы заметки подробнее, то - Andy отмечает, что часть устоявшихся направлений развиваются эффективно Stores, AWS, Prime Video, как и часть новых: GenAI, Kuiper, Healthcare - В этом развитии важную роль играет кульутра компании и поддержание и развитие культуры является топ приоритетом для топ-менеджеров - Andy говорит, что "We want to operate like the world’s largest startup", а это раскладывается в -- Constantly inventing for customers -- Strong urgency (for most big opportunities, it’s a race!) -- High ownership -- Fast decision-making -- Scrappiness and frugality -- Deeply-connected collaboration -- Shared commitment to each other У топ-команды было два вопроса, над которыми они думали в последнее время

1) Do we have the right org structure to drive the level of ownership and speed we desire? 2) Are we set up to invent, collaborate, and be connected enough to each other (and our culture) to deliver the absolute best for customers and the business that we can?

Оба вопроса привели к идеям о том, как улучшить оргструктуру и совместную работу 1) Оргструктура По поводу оргструктуры Andy говорит, что за годы непрерывного роста и найма умных и квалифицированных людей появилось много менеджеров, которых нанимали для организации процессов работы, что привело к сайд эффектам вида

- Pre-meetings for the pre-meetings for the decision meetings - A longer line of managers feeling like they need to review a topic before it moves forward - Owners of initiatives feeling less like they should make recommendations because the decision will be made elsewhere - ...

Но эти решения по структуре команд обычно были two-way doors (обратимыми), поэтому сейчас оргструктуру решено менять в сторону более плоской. Цель выглядит примерно так So, we’re asking each s-team organization to increase the ratio of individual contributors to managers by at least 15% by the end of Q1 2025. Эта реорганизация, выполненная верно, должна привести к следующим результатам - Increase our teammates’ ability to move fast - Clarify and invigorate their sense of ownership - Drive decision-making closer to the front lines where it most impacts customers (and the business) - Decrease bureaucracy - Strengthen our organizations’ ability to make customers’ lives better and easier every day. Энди даже завел специальный Bureaucracy Mailbox, куда можно присылать примеры бюрократии и ненужных процессов. 2) Эффективная совместная работа По поводу эффективности совместной работы Энди говорит, что к началу января все сотрудники Amazon должны будут вернуться к обычной пятидневке в офисах (если нет смягчающих условий: заболел ребенок, чрезвычайная ситуация дома, вы в дороге к партнерам или клиентам, ...). Аргументируется это тем, что совместная работа в офисах более эффективна

We continue to believe that the advantages of being together in the office are significant ... We’ve observed that it’s easier for our teammates to learn, model, practice, and strengthen our culture; collaborating, brainstorming, and inventing are simpler and more effective; teaching and learning from one another are more seamless; and, teams tend to be better connected to one another

#Management #Leadership #Processes #Bigtech #Software

Measure What Matters (Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR) - Part IV (Рубрика #Management) Продолжая рассказ про книгу Джона Дорра, что я начал в постах 1, 2, 3 и 4 я расскажу про вторую часть книги "Новые методы работы" 15) Непрерывное управление производительностью: OKR и CFR В этой главе авторы предлагают замену стандартным подходам к управлению производительностью. Условно, автор предлагает заменить ежегодное performance review на CFR (conversations, feedback, recognition). Суть в том, что люди работают над своими целями круглый год, поэтому кажется, что и работа с эффективностью сотрудников должна идти непрерывно. Суть этого CFR примерно такая - C (conversations) - обсуждения: искреннее, насыщенное и хорошо структурированное общение между менеджером и сотрудником, призванное повысить результативность работы - F (feedback) - обратная связь: двустороннее и взаимосвязанное общение между коллегами ддля того, чтобы оценить прогресс и наметить будущие улучшения - R (recognition) - признание заслуг достойных сотрудников за их вклад любого масштаба Как по мне перечисленное в этом подходе уже стало базой, поэтому не ясно в чем инновация подхода 16) Избавляемся от ежегодных проверок производительности: Adobe Пример Adobe, где они ушли от ежегодных review к непрерывным. Интересен только момент, что ребята ушли от формальной оценки и ранжирования сотрудников. Менеджер сам определяет размер зарплаты и доли в компании ежегодно в зависимости от результатов работы. В общем, тут как обычно за общими фразами сложно понять действительную реальность того, что было и стало. 17) Вкуснее с каждым днем: Zume Pizza Пример пиццерии, что применяла OKR и CFR прямо с первого дня. Как по мне пример слабоват:) 18) Культура Глава начинает с фразы Питера Друкера о том, что культура съедает стратегию на завтрак. В итоге, для того, чтобы добиваться высоких целей надо уметь создавать культурные ценности и защищать их по мере роста компании. OKR помогает тем, что это надежные хранилища для лидерских приоритетов и убеждений, а CFR обеспечивают их распространение. В этой главе опять идут отсылки к Энди Гроуву, который был примером высочайших культурных стандартов Intel. Другой пример отсылает к проекту "Аристотель", в котором ребята в Google пытались понять что делает команду эффективной. Кстати, я уже рассказывал про это исследование. В общем, автор делает вывод, что

OKR и CFR обеспечивают синхронизацию сверху вниз, объединяют команды и гарантируют автономность и вовлеченность снизу вверх: это столпы любой живой, ценностной культуры

19) Преобразование культуры: Lumeris Пример того, как M&A медицинской компании привел к тому, что пришлось делать трансформацию двух компаний и фактически определять культуру. Формально компания пыталась запустить OKR, когда была в таком шизофреническом состоянии, но у нее не получилось. Потом было принято решение об HR-трансформации, создании новой компании под одним брендом и дальше с этими преобразованиями отлично зашел OKR 20) Изменение культуры: Боно, ONE Campaign Пример того, как звезды могут заниматься благотворительностью. Конечно в книгу он попал из-за громкого имени артиста ... 21) Задачи на будущее Глава начинается с того, что идеи придумать не сложно, но сложно воплотить их в жизнь. А OKR и CFR помогают как раз с этим. Автор предлагает думать о них, как о стартовой платформе для предпринимателей и новаторов. Автор продолжает свою работу над OKR и узнать про нее можно на сайте WhatMatters.com 22) Посвящение - автор рассказывает про тренера Билла Кэмпбелла - подробнее про него можно узнать в статье в Forbes Ну и в конце автор в приложениях приводит отцензурирование документы Google про OKR - Google: стратегия и тактика OKR - Примерный цикл OKR - Обсуждаем качество работы - Резюме #Management #Leadership #Processes #Engineering #Project

Обзор whitepaper "Developer productivity for Humans, Part 7: Software Quality" На днях я прочитал интересную статью, вышедшую в начале 2024 года, в которой рассказывалось про измерение того, как software quality связано с продуктивностью разработчиков:) В этой статье Ciera Jaspan и Collin Green (два лида из Google) рассказывали о том, что для холистического измерения продуктивности надо обращать внимание на speed, ease и quality для того, чтобы не получить кратковременные улучшения за счет долговременного негативного влияния как например

After all, we can easily increase velocity…by removing code review or test suites.

А дальше ребята фокусируются на теме качества, которая затрагивает процессы, код, систему и продукт целиком. Мне эта тема очень близка, так как она очень тесно пересекается с архитектурой и архитектурными характеристиками систем, которые часто называют атрибутами качества:) В итоге, мне подход авторов очень понравился, как понравиились и выводы, поэтому я решил сделать обзор этой статьи. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes #Quality

The new Airbnb - Part II (Рубрика #Management) Продолжение обзора интересного интервю Braian Chesky, co-founder и CEO Airbnb, о том, как компания перешла к founder mode от стандартного мультипродуктового подхода. В этой части подробнее про саму трансформацию управления в компании и напоследок советы от Брайана на тему саморазвития. - В 2022 году ребята вернулись к основам и CEO погрузился в детали -- Они сократили количество проектов, убрали уровни управления и перешли к функциональной модели. -- Они также сократили количество сотрудников и сделали каждого руководителя экспертом в своей области (а не просто people manager) -- Они провернули изменения с продуктовой и маркетинговой функцией -- Само создание продукта было делегировано в program managers, которые и до этого управляли разработкой. По-факту, они взяли на себя работу с командами разработки по созданию того продукта, что нащупала маркетинго-продуктовая функция -- Они создали внутреннее креативное агенство и объединили функции UX и написания текстов - Все эти изменения привели к тому, что потребовался поиск компромисса между тем, как основатель хочет управлять компанией и тем, как сотрудники хотят управлять компанией. - Брайан считает, что все хотят ясности и быстрого движения в одном направлении, и что -- Основатель должен вовлечен в разработку продукта и быть экспертом в своей области, а также знать о том, что делают его сотрудники -- Каждый менеджер по продукту должен быть взаимосвязан и знать, что делают другие. -- Engineering и дизайн должны быть взаимосвязаны, и каждый менеджер по продукту должен быть специалистом в своей области. - Дальше Брайан рассуждает о целепологании и что постановка амбициозных целей может помочь командам мыслить масштабно и находить решения для проблем. - Также важно проявлять лидерство и мотивировать команды, чтобы они могли достичь своих целей. Важно видеть в них потенциал, который они не видят в себе. - Важно создать организацию, ориентированную на рост, где чем больше ты участвуешь, тем больше ты веришь в себя и видишь в себе больше потенциала. Дальше Брайан рассказывает о том, что он - Не является образцом баланса между работой и личной жизнью. Но он старается поддерживать здоровые отношения, заниматься спортом и питаться здоровой пищей. - Старается поддерживать отношения с друзьями и выделять время на встречи с ними - Старается поддерживать баланс за счет определения приоритетов и четкого "нет" тем вещам, что не имеют значения - Старается оставаться новичком и смотреть на мир глазами ребенка и что ему все еще нужно многое доказать и преодолеть некоторые рубежи знаний. - Не стесняется обращаться за помощью к другими людям и оказывать ее сам В самом конце интервью Брайан рассказывает о себе и как он от увлечения искусством, архитектурой и промышленным дизайном пришел к созданию Airbnb, который поменял мир путешествий:) #Management #Leadership #Processes #Engineering #Project #Software #Design #ProductManagement #BusinessStory

Designing Data-Intensive Applications (Рубрика #Architecture) Я прочитал эту книгу в 2018 году и она реально помогла мне подтянуть знание в проектировании приложений, которые интенсивно работают с данными. Я писал про нее в своей популярной статье "Как прокачаться в проектировании программного обеспечения", где советовал 16 крутых книг по проектированию, которые отвечали на вопросы "Что делаем", "Как делаем" и "Как это эксплатируем". Но в этом канале эту книгу я не вспоминал, поэтому решил исправить это упущение, особенно с учетом того, что я уже начал читать готовящееся второе издание книги на платформе O'Reilly (там пока есть только 3 главы, а вся книга будет готова к концу 2025 года). Поэтому пока актуально еще первое издание, я расскажу о своих впечатлениях - У меня есть бумажная версия книги на русском и на английском языках - книжка заслуживает быть в моей библиотеке в бумажном виде - Иллюстрации в книге отличные (в новом издании они тоже хороши) - Книгу в первый раз я читал долго, но теперь она читается очень легко - Сама книга состоит из трех частей и 12 глав, ниже перечислены названия частей -- Основы информационных систем -- Распределенные данные -- Производные данные Первая часть является вводной и состоит из глав: 1. Надежные, масштабируемые и удобные в сопровождении системы 2. Модели данных и языки запросов — SQL, NoSQL, Map Reduce, Cypher и SparQL 3. Подсистемы хранения и извлечения данных — SSTables, LSM, B-Tree, Звезды и снежинки, столбцовое хранение данных 4. Кодирование и эволюция — json, xml, thrift, protobuf, avro. Миграции данных:) Вторая часть включает в себя главы: 5. Репликация — синхронная/асинхронная, master/slave, master/master, no-master 6. Секционирование — типа ключ/значение, по диапазонам ключе, секционирование и репликация, секционирование и вторичные индексы, перебалансировка секций 7. Транзакции — ACID/BASE, 2PL(two-phase locking), SSI (serializable snapshot isolation) 8. Проблемы распределенных систем — сбои и отказы, ненадежные сети, ненадежные часы, знание/истина/ложь 9. Согласованность и консенсус Часть 3 состоит из глав: 10. Пакетная обработка 11. Потоковая обработка 12. Будущее информационных систем P.S. Книга позволяет увидеть хорошее overview разных тем для тех, кому приходится проектировать/разрабатывать системы, которые хранят/обрабатывают данные:) P.P.S. С момента первого прочтения книги я прочел много других книг и мой изначальный восторг от книги Мартина Клеппмана поблек, но второе издание книги я жду с большим интересом. А чуть позже я сделаю обзор тех частей, что доступны в early preview этого второго издания. #DistributedSystems #Architecture #SystemDesign #Software #SoftwareArchitecture

The new Airbnb - Part I (Рубрика #Management) Интересное интервью Braian Chesky, co-founder и CEO Airbnb, о том, как компания перешла к founder mode от стандартного мультипродуктового подхода. Мне интервью понравилось, так как оно хорошо описывает то, что происходит в больших продуктовых компаниях - в Airbnb порядка 4к инженеров. При росте компании фаундеры отходят от непосредственного управления, нанимают мененджеров и передают им полномочия. В какой-то момент внутри компании появляется куча отдельных продуктовых направлений со своими mini-CEO, которые развивают эти продукты в свою сторону. И это приводит к проблемам - Разные группы внутри компании могут работать на разных технических платформах, которые переизобретают по четвертому разу колесо, что приводит глобально к накоплению технического долга. - Зависимости между командами могут создавать проблемы и бюрократию - Отсутствие подотчетности и большая степень автономности подразделений могут привести к потере фокуса:) В 2022 году Airbnb пережил кризис и Брайан фундаментально поменял схему управления компанией - В основе лежит идея, что основатель и CEO должен быть главным специалистом по продуктам в продуктовой или технологической компании. - Для управления продуктом Брайан решил использовать инструмент для определения приоритетов и составления дорожных карт - Jira Product Discovery, который позволяет собирать все идеи о продукте в одном месте и расставлять приоритеты - В компании убрали функцию управлению продуктом, но людей, что ее исполняли оставили. Уменьшили количество отдельных групп, но сделали их более продвинутыми - Функции по управлению продуктом разъезхались в две стороны: маркетинговая и инженерная - Основная идея разделения была в том, что вы не сможете создать продукт, если не будете знать, как говорить о нем. - В итоге, маркетинг и продуктовая стратегия объединились: -- Маркетинг эффективности хорош для балансировки спроса и предложения, но не создает накопительных преимуществ. -- Маркетинг как образование: рассказывать людям об уникальных преимуществах продуктов. -- План действий на два года вперед, обновление дорожной карты продуктовой стратегии каждые шесть месяцев. -- Продакт-менеджмент занимается маркетингом продукции, выясняет, как люди узнают о продуктах, делает демонстрационные ролики, работает над историей и активами. - Брайан упоминает про эксперименту (a/b тесты), отмечая, что просто так их гонять бесполезно - в основе тестов должны лежать гипотезы, а так должна быть целостная система метрик для измерения результатов (у ребят в Airbnb высокая культура и хороший тулинг для a/b тестирования) - Брайан рассказывает про проблемы делегирования и то, что CEO должен иметь четкий vision того, что делает компания Продолжение обзора интверью во втором посте. #Management #Leadership #Processes #Engineering #Project #Software #Design #ProductManagement #BusinessStory

Куртки я думаю, что тоже