Книжный куб

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

Research Insights Made Simple #2 - Обсуждение paper "Defining, measuring and managing technical debt" (Рубрика #Management) Это второй выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Дмитрий Гаевский, Technical CPO (Chief Product Owner) нашей внутренней платформы разработки Spirit. Для второго выпуска мы взяли научную статью про технический долг и то, как он влияет на продуктивность инженеров. Эта статья от ребят из Google вышла в 2023 году. Основные материалы - Whitepaper доступен здесь - Мой разбор whitepaper есть в блоге В этом выпуске мы успели обсудить темы - Исторический контекст и метафора технического долга - Долг или инвестиции в качество кода - Исследование технического долга в Google - Категории технического долга в общем - Категории, выбранные для исследования - Измерение технического долга - Проблемы с метриками и целевыми состояниями - Концепция opportunity cost - Проблемы с термином "технический долг" - Управление техническим долгом - Альтернативы термину "технический долг" - Результаты работы с техническим долгом в Google - Объединение объективных и субъективных данных - Проблемы разделения технической и продуктовой работы - Альтернативные подходы к техническому долгу #Architecture #Software #Management #Leadership #Engineering #Podcast

Иллюстрации для книги "Карта гипотез"

Карта гипотез (Рубрика #Manangement) Наконец-то дошли руки прочитать книгу Александра Бындю про стратегическое планирование. Вообще, это уже вторая книга Александра, предыдущая называлась "Антихрупкость в IT" и я раньше про нее уже рассказывал, а потом мы с Александром записали серию подкаста "Code of Leadership", где разобрали эту книгу. В новой книге Александр рассказывает фокусно про свой метод карты гипотез, который развивает идеи метода impact mapping от Гойко Аджича. Кстати, у Гойко есть книга "Impact mapping", про которую я рассказывал раньше. Собственно, Александ творчески расширяет этот подход и предлагает следующую структуру метода, которую он раскрывает в первой части книги "Структура карты гипотез" 1) Цель - по каким критериям в конце работы мы поймем, что достигли успеха 2) Субъект - тот, чью жизнь мы хотим поменять с помощбю гипотезы, чтобы изменение привело нас к цели 3) Гипотеза - формализованная идея, с помощью которой мы собираемся изменить поведение субъекта 4) Задача - список активностй, с помощью реализации которых мы будем проверять, насколько верны наши гипотезы Основная суть изменений между impact mapping и картой гипотез в том, что в карте основной фокус на том, чтобы через гипотезы зафиксировать ответ на вопрос а почему мы думаем, что определенные задачи приведут нас к цели. Гипотеза формулируется в виде

Если <действие1> и <действие2> ..., то <следствие>, потому что <идея>

Во второй части "Тонкости составления карты гипотез" автор подробнее рассказывает о том, что цели надо ставить по SMART, субъектов надо описывать четко, а не аморфно "все потребители", гипотезы должны быть правильные по форме, в них должен быть смысл, задачи не должны висеть в воздухе и зачастую они объединяются в цепочки для выполненияя. В третьй части "Этапы работ с картой гипотз" автор рассказывает как ее создавать и когда стоит прекратить, а потом делится подходом к валидации карты, который позволяет понять, а не фигню ли мы сделали. В четвертой части автор рассказывает про преимущества подхода, которые включают в себя 1) Осмысленный подход к решению 2) Стратегию в виде схем как доступный способ ее коммуникации 3) Возможность варьировать реализацию 4) Конкурентное преимущество из-за четкой и гибкой стратегии 5) Фильтр для проектов без идеи (которые любят вкидывать сверху) 6) Передачу знаний внутри компании 7) Переключения майндсета с "затрат на проекты" на "инвестиции в реализацию стратегии" В общем, вторая книга Саши Бындю мне понравилась больше. Видно, что он он пишет сфокусированно о том инструменте, который он использовал очень часто для работы со стратегией. И этот инструмент по моим ощущениям может быть достаточно эффективным. Подробнее про карту гипотез можно прочитать на сайте картагипотез.рф #Software #SoftwareDevelopment #Management #Processes #Strategy #Leadership #ProductManagement

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

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), которые направлены на то, чтобы уложиться в квартальные/полугодовые планы - Отдельно автор говорит о том, что могут быть еще и периодические ревью, например, каждый месяц. Эти ревью направлены на отслеживание прогресса по выполнению целей компании Продолжение в следующих постах. #Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

The Engineering Executive's Primer - Part 0 (Рубрика #Management) Я уже давно прочел новую книгу Will Larson для IT топ-менеджеров, про которую я писал раньше. Прочел и прочел, но все как-то не доходили руки написать про нее, но сейчас я в очередной раз сижу в аэропорту и жду самолета, поэтому время есть:) Сразу скажу, что книга мне понравилась - у Вилла как обычно отлично со структурой книги, а отдельные главы достаточно емкие и наводят на размышление (интересно, что они обычно появляются как статьи в блоге lethain.com, один из немногих блогов, что я читаю) Продолжение в следующем посте. #Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

System Design Interview - Highload++ 2024 (Рубрика #Architecture) В этом году я зайду в декабре на Highload++, чтобы подискутировать на тему system design interview. Этот формат собеседования стал достаточно популярным в крупных компаниях6 а кто-то его вкручивает в свой процесс собеседований как карго-культ. В этои дискуссии мы обсудим - Что это за тип интервью - Зачем он нужен компаниям и можно ли обойтись без него - Какие у него есть плюсы и минусы Надеюсь, что дискуссия будет интересной и понравится всем зрителям:) P.S. До этого я уже рассказывал про процессы найма в большие компании и типы интервью на примере Т-Банка. Про System Design у меня тоже было много материалов. Например можно посмотреть в общем про system design в Tinkoff, больше про то, как мы оцениваем прохождение собеседования и как подготовиться к собеседованию или публичные интервью на ArchDays #Career #HR #Management #Architecture #Software #Leadership #Processes

Почему DevEx важен при разработке IDP и как его померить - Владимир Калугин (Рубрика #Management) Это интересное выступление моего коллеги Владимира Калугина про developer experience и почему он важен при создании внутренних платформ разработки. Это выступление было в рамках нашей конференции Platform Engineering Night, про которую я рассказывал раньше. Владимир в Т-Банке выступает в роли technical product manager и развивает все, что вокруг кода, сборок и артефактов - то есть, Вова улучшает developer experience всех наших инженеров. Собственно, в докладе Вова рассказывает про модель DevEx, куда входит когнитивная нагрузка на инженеров, циклы обратной связи и состояние потока. Вот как это описывают сами авторы модели

1) Feedback loops Software organizations commonly look for ways to optimize their value stream by reducing or eliminating delays in software delivery. Shortening feedback loops—the speed and quality of responses to actions performed—is equally important to improving DevEx. 2) Cognitive load Software development is inherently complex, and the ever-growing number of tools and technologies is further adding to the cognitive load faced by developers. Cognitive load encompasses the amount of mental processing required for a developer to perform a task. 3) Flow state Developers often speak of "getting into the flow" or "being in the zone." Such statements colloquially describe the concept of flow state, a mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment.

Суть работы над DevEx в том, чтобы уменьшить когнитивную нагрузку, сократить циклы обратной связи и позволить чаще инженерам попадать в состояние потока. Для того, чтобы оценить а насколько это хорошо получается, надо использовать два вида данных: - Опросы инженеров - позволяют собрать информацию о восприятии инженерами того или процесс, инструмента или помехи - Системные данные (логи, метрики, ...) - позволяет собрать фактическую информацию Объединение этих источников данных позволяет получить более релевантную картину Интересно, что Вова показывал несколько примеров из опыта нашей IDP о том, какие данные собирались и как они использовались для того, чтобы сделать опыт инженеров лучше. Напоследок, приводится список материалов для изучения, среди которых 1) Whitepaper "DevEx: What Actually Drives Productivity" - я его уже разбирал в блоге 2) Whitepaper "DevEx in Action" - я его уже разбирал в блоге 3) Whitepaper "DevOps metrics" - я его пока не читал 4) Сайт про внутренние платформы разработки - Internal Developer Platform 5) Статья "The top 10 fallacies in platform engineering" Кроме этого я рекомендую почитать на эту тему колонку исследователей из Google, где они разбирают human centric подход к инженернной продуктивности. В ней пока 8 статей и 4 из них я уже разобрал в деталях. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

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

Testing strategy: avoid the waterfall strategy trap with iterative refinement (Рубрика #Management) Очередная интересная статья от Will Larson, который постепенно создает свою новую книгу про стратегию. В этой главе речь идет про гибкое тестирование стратегии и улучшение ее на основе обратной связи:) Как обычно у Вилла все очень структурно 1) Когда стоит тестировать стратегию? Когда хочется понять насколько она достижима и сколько реально будет стоить. По-факту, автор предлагает перед ее финализацией делать аля PoC (proof of concept), который позволит собрать недостающую информацию. Но иногда это можно не делать - например, при разрешающей стратегии (ее имплементация стоит не дорого), при слишком долгом ожидании обратной связи (вопросы с наймом в разных регионах) или когда мы почти уверены в своей стратегии 2) Как тестировать стратегию? - Выделить узкий и глубокий элемент стратегии, над которым дальше итеративно работать - Дальше по метрикам оценить импакт изменений - Действовать исходя из того, что людьми хорошо управляют, а неудача стратегии обусловлена избытком свободы и плохой эргономикой - Продолжайте совершенствовать стратегию, пока не убедитесь, что детали вашей стратегии работают на практике или что ее надо поменять Не стоит замахиваться на слишком широкую область сразу, не стоит давить слишком сильно для принятия стратегии и не надо слишком привязываться к своему подходу:) 3) Роли для тестирования стратегии Автор выделяет роль спонсора и руководителя (guide). Собственно один авторизует стратегию и помогает ей случиться, а второй ее реализует, отслеживает выполнение и эксалирует в случае проблем. Забавно, что я успел побывать и тем и другим за время карьеры:) Важно, чтобы эта пара могла принимать сложные решения быстро, а не уходила в paralysis of analysis 4) Meetings & Metrics Единственное обязательное требование для этапа тестирования стратегии — спонсор, руководитель и все ключевые лица, работающие над стратегией, должны встречаться каждую неделю. В ходе этой встречи надо смотреть на показатели, что отражают текущие области, которые вы пытаетесь улучшить, обсуждать, чему вы научились на основе предыдущих показателей или данных, а также планировать разовые контрольные проверки, чтобы убедиться в прогрессе. 5) Выявление стратегий, не прошедших тестирование Хотя не все стратегии должны быть уточнены в ходе фазы тестирования, по сути, все неудачные стратегии пропускают фазу тестирования, чтобы перейти непосредственно к реализации. Стратегии, которые пропускают тестирование, звучат правильно, но не достигают многого. Один из самых стандартных паттернов провала - это "давление без плана", когда стратегия представляет собой лишь аспект «звучит правильно» без каких-либо деталей. Я видел много таких стратегий 6) Восстановление после пропущенного тестирования После нахождения зависшей стратегии, что пропустила этап тестирования автор предлагает написать новую стратегию и на этот раз включить туда тестирование отдельным шагом, а дальше начать реализовывать ее. В финале автор говорит о том, что тестирование не поможет понять, а может ли стратегия быть хорошей. Но оно позволит выявить недостающие детали, необходимые для перевода стратегии в работающее состояние:) #Management #Strategy #Leadership #Software

The Tyranny of Metrics (Тирания показателей) - Part III (Рубрика #Management) Помимо выкладывания обложек, рассказа о самой книге, рассказа о последствиях увлечения метриками я решил привести еще и чеклист, который приводит в последней главе Джерри Мюллер, автор книги. Автор приводит его, так как показатели бывают полезны, если соблюдать технику безопасности и при создании очередных показателей проганять себя через чеклист с десятком вопросов 1) Какую именно информацию вы собираетесь контролировать? Чем сильнее объект контроля напоминает неодушевленный предмет, тем выше вероятность того, что его можно оценивать количественно. В противном случае в роль вступает эффект наблюдателя 2) Насколько полезна эта информация? Важно искать не там, где светло, как в анекдоте

Пьяный мужик что-то ищет под фонарем. Тут к нему под ходит полицейский и спрашивает: - Что вы тут делаете? - Ключи от квартиры ищу. - А где потерял? - В парке. - А зачем здесь ищешь? - А здесь светлее.

3) Есть ли польза от увеличения количества показателей? Оценка результативности лучше подходит для выявления отклонений (плохих работников, нарушений дисциплины), но она приносит меньше пользы для работников в средней/верхней части шкалы. Плюс дополнительныые показатели увеличивают стоимость измерений 4) Нанесет ли ущерб отказ от стандартизованных оценок? иногда более эффективными показателями могут быть нестандартизованные метрики 5) В каких целях используются количественные оценки или для кого они предназначены? Автор говорит о том, что существует ключевое различие между данными, что сотрудники используют сами для внутреннего контроля, а также данными, которые используются внешними сторонами в целях поощрения и наказания. Тут вступает в дело внутренняя мотивация и внешняя мотивация (стимуляция). Если идет ориентация на внешние стимулы, то внутренняя мотивация в какой-то момент исчезает, а она очень важна для интеллектуальных профессий 6) Какова стоимость получения показателей? Важно понимать насколько дорого собирать показатели для отчетности и сравнивать с пользой, что они наносят 7) Спросите, почему руководители организации требуют представления показателей результативности - важно понимать для чего их планирует использовать и дальше действовать по обстоятельствам 😍 Как и кто разрабатывает показатели результативности? Если их спускают сверху и создают при помощи магических формулл, то часто они могут иметь низкий эффект. Они имеют больше смысла, если разрабатываются снизу вверх и когда в их разработке участвуют люди, что отвечают за работу на земле. 9) Помните, что даже лучшие показатели могут искажаться и уводить от цели. Здесь надо вспомнить про стандартную схему с агентами и принципалами. В итоге, если мы платим за результативность, то агент имеет мотивацию подкрутить метрики в свою сторону. Это не повод от них отказываться, но надо понимать плюсы и минусы решения 10) Не забывайте, что порой мудрость начинается с признания пределов возможного. Не все проблемы можно решить и еще меньше можно решить при помощи количественных показателей. #Data #Statistics #Management #Leadership #Processes

The Tyranny of Metrics (Тирания показателей) - Part II (Рубрика #Management) Помимо выкладывания обложек и рассказа о самой книге я решил привести список непредвиденных, но предсказуемых отрицательных последствий бездумного введения метрик 1) Подмена целей вследствие концентрации на том, что поддается измерению - когда о результативности судят по нескольким показателям и ставки высоки, то люди фокусируются на их достижениях, забивая на все остальное. По-факту, эти количественные показатели занимают место организационных целей, достижению которых должны были служить 2) Привлечение внимания к краткосрочным результатам - долговременные результаты обычно вытесняются из рассмотрения, так как их сложно покрыть метриками и их наступления ждать слишком долго. Тут сразу вспоминается Ходжа Насреддин с его историей про ишака

Насреддин рассказывает, что как-то раз поспорил с эмиром бухарским, что научит своего ишака богословию так, что ишак будет знать его не хуже самого эмира. На это нужен кошелёк золота и двадцать лет времени. Если он не выполнит условия спора — голова с плеч. Насреддин не боится неминуемой казни: — «Ведь за двадцать лет, — говорит он, — кто-нибудь из нас троих обязательно умрёт — или эмир, или ишак, или я. А тогда поди разбирайся, кто лучше знал богословие!»

3) Потери рабочего времени - мало кто считает стоимость сбора и анализа всех тех данных, что нужны для построения отчетности 4) Рост количества правил - пытаясь остановить поток манипуляций, подтасовок и подмены целей, организации множат правила и бюрократию. 5) Вознаграждение за удачу - зачастую сотрудники имеют не слишком много контроля над результатами, по которым их оценивают. А вознаграждение за такие результаты фактически равносильно вознаграждению за удачу. Тут вспоминается анекдот про рекрутеров

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

6) Подавление охоты идти на риск - рискованные действия часто не приносят результата и никто не оценивает матожидание этих действий (условно произведение вероятности на вознаграждение), а смотрят на итоговый результат. В итоге, рисковать становится опасно. 7) Подавление сотрудничества и стремления к общей цели - вознаграждение на основне результатов способствует конкуренции, а не сотрудничеству. Часть сотрудников или целых подразделений начинает стремится к локальному оптимому своих показателей иногда даже в ущерб коллегам. 😍 Деградация трудового процесса - фокус на узком круге оцениваемых задач приводит к деградации удовлетворенности работой. Работающие под постоянным контролем метрик, установленных кем-то, перестают понимать как они связаны с их реальностью. Они абстрагируются от работы и начинают делать ее механистично. Самые инициативные и предприимчивые начинают покидать такие места 9) Влияние на производительность - автор книги отмечает, что в США производительноссть в последние годы росла только в сфере ИТ. Он задает вопрос, а может это связано с общей тиранией показателей #Data #Statistics #Management #Leadership #Processes

Обложки для книг "The Tyranny of Metrics" и "Тирания показателей"

The Tyranny of Metrics (Тирания показателей) (Рубрика #Management) Эта интересная книга за авторством Muller Jerry вышла в 2018 году в Princeton University Press, а в 2020 году ее перевели в Альпине. Мне понравилось название, которое идет наперекор стандартному подходу к измерению всего и вся:) В итоге, книга напоминает по структуре научную статью. А когда я начал читать эту книгу, то легко узнавал проблемы, которые классно описывал автор. Во многом они рождены из закона Гудхарта "Когда мера становится целью, она перестает быть хорошей мерой". В итоге, автор не предлагает отказаться от показателей, а скорее говорит о том, что помимо них должны быть качественные показатели и мнение разбирающихся в теме людей, которые принимают решение. Иначе получится как с XSolla, где были уволены сотрудники с аргументацией, что "биг дата» показала их невовлеченность". Вот содержание книги 0) Введение - автор рассказывает о том, как он, работая в сфере образования профессором и завкафедрой, оказался вынужден сдавать все больше и больше отчетов по мере обвешивания системы образования метриками. Дальше он заинтересовался историей вопроса и в итоге получилась эта книга 1) Постановка проблемы - в этой части автор рассказывает об одержимости показателями и к чему это может приводить. Делает это он в главах с кратким описанием проблемы и перечнем характерных ошибок 2) История проблемы - так как автор - это учений с интересами в истории, экономики и политики, то он глубоко погружается в историю вопроса и рассказывает про - Происхождение системы вознаграждения в зависимости от результата (pay for performance) - Почему количественные показатели стали такими популярными - Принципалы, агенты, мотивация (внутренняя и внешняя) - Философия и критика 3) Можно ли применять количественные оценки ко всему подряд - тут автор разбирает на конкретных примерах результаты применения чрезмерной количественной оценки - В образовании - автор разбирает колледжи и университеты - Школы - автор рассказывает про зарубежный опыт, но мы все можем видеть результаты ЕГЭ - Здравоохранение - тут автор показывает как рейтинг хирургов на основе успешных операций приводит к тому, что они отказываются от сложных операций и предлагают сразу ехать на кладбище - Охрана правопорядка - тут цель в снижении преступности приводит к тому, что часть преступлений классифицируют как менее тяжкие, которые не входят в рейтинг или просто не реагируют на часть обращений - Вооруженные силы - тут гонка за показателями особенно вредна в сценариях борьбы с террористами, повстанцами и другими иррегулярами - Бизнес и финансы - тут автор проходит по KPI, OKR, вспоминает разгон показателей для радости инвесторов, подделывание отчетности. В итоге, часто менеджеры концентрируются на операционных показателях и перестают думать о стратегии развития - Благотворительность и помощь другим странам - автор говорит о том, что тут методы бизнеса работают не очень, так как вовлеченные в благотворительность часто ориентируются на свою внутреннюю мотивацию, а внешние KPI начинают ее подмывать:) 4) Экскурсы. Автор показывает что иногда прозрачность - это враг результативности. Он делает это на примере политики, дипломатии, разведки и браков:) 5) Выводы. Сначала автор рассказывает о непредвиденных, но предсказуемых последствиях увлечения показателями, а потом говорит о том, а когда и как применять количественные показатели. Про эту часть я расскажу отдельно позже. В общем, книга мне очень понравилась, так как я часто вижу описанные автором проблемы и стремлюсь их исправить. Иронично, что продуктовая аналитика и a/b платформа, что нужна для контролируемых экспериментов, а также metric store, где должны считаться метрики по продуктам для всей организации, сейчас находится в моем юните, а значит правильное применение данных - это отчасти и моя профессиональная задача:) Продолжение в следующем посте. #Data #Statistics #Management #Leadership #Processes

Research Insights Made Simple #1 - Обсуждение paper "API Governance at Scale" (Рубрика #Architecture) Это первый выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Даниил Кулешов, Staff Engineer, который развивает вместе со мной в Т-Банке архитектурную функцию на уровне всей компании. Для первого выпуска мы взяли научную статью про governance, а точнее про API governance от ребят из Google, которая вышла в 2024 году. Сама статья достаточно хорошо раскрывает тему governance, что позволяет закрыв глава подставить на место API слово architecture и многие мысли и выводы авторов останутся корректными. Основные материалы - Whitepaper доступен здесь - https://research.google/pubs/api-governance-at-scale/ - Мой разбор whitepaper есть в блоге - https://tellmeabout.tech/review-whitepaper-api-governance-at-scale-fdab581b8489 - Перечень Google стандартов на API доступен здесь - https://google.aip.dev/ #Software #Architecture #DistributedSystems #Whitepaper #Management #Processes #Leadership

Сервис Unidraw.io от T-Bank - наш ответ Miro - Продолжение (Рубрика #Visualisation) Раньше я уже анонсировал этот инструмент в отдельном посте, а теперь 1) Я уже обкатал этот инструмент при создании обзоров всех whitepapers, про которые я рассказывал с сентября, а также при проведении System Design Interview 2) Пару дней назад на Хабре появился рассказ про бекстейдж развития этого инструмента у нас в компании "Unidraw — путь длиной в два года" Если говорить про обзоры статей, то визуализаций в Unidraw мне хватает и я не часто вспоминают про Miro. Для демонстрации тезиса я решил пошарить все эти доски, чтобы вы могли проверить все сами - ближайший месяц они будут доступны и неавторизованным пользователям, а потом придется все-таки заводить аккаунт, чтобы их посмотреть:) 1) Defining, measuring and managing technical debt - статья с обзором и доска 2) API Governance at Scale - статья с обзором и доска 3) Hybrid Productivity - статья с обзором и доска 4) A Human-Centered Approach to Developer Productivity - статья с обзором и доска 5) Measuring Developer Goals - статья с обзором и доска 6) Software quality - статья с обзором и доска 7) AI-Enhanced API Design: A New Paradigm in Usability and Efficiency - статья с обзором и доска 8) Secure by Design at Google - статья с обзором и доска В общем, я как опытный пользователь Unidraw могу отметить, что инструмент уже работает хорошо, а также в него постоянно доезжают новые фичи:) Кстати, фичу с прямоугольными стикерами сделали по моей просьбе - она мне нужна была как раз для переезда на Unidraw с моими обзорами статей и книг:) Спасибо ребятам, что создали инструмент и продолжают его дорабатывать! У инструмента есть свой канал t.me/unidrawio и чат для пользователей t.me/unidrawiochat, так что у пользователей есть возможность быть в курсе новостей и доносить обратную связь напрямую команде. #Data #Visualization

Architecture Modernization: Aligning Software, Strategy & Structure • Nick Tune • GOTO 2024 (Рубрика #Architecture) Интересный и полезный доклад на тему модернизации архитектуры существующих систем от Nick Tune, principal consultant at Empathy Software. Если сократить доклад, то тезисы примерно такие: - Успешным компаниям часто требуется модернизация архитектуры, так как их прежняя архитектура: предназначена для меньшего объема клиентов и не тяент нужную нагрузку, опирается на старые технологии, которые не позволяют добавлять фичи с нужной скоростью. В итоге, модернизация может превратить недостатки в достоинства - Такая модернизация касается не только технических вопросов - на самом деле надо оценивать весь стек от UX до глубоких бекендов, включая огрструктуру и процессы работы сотрудников - В модернизации могут помочь разные инструменты, но автор выделяет следующие 5 штук 1) Listening Tours - сюда обычно входят опросы, интервью с сотрудниками, фокус-группы, gemba и так далее. Задача в том, чтобы услышать своих сотрудников 2) Impact mapping - это простая методика совместного планирования для команд, которые хотят добиться большого эффекта с помощью программных продуктов. 3) Wardley mapping - это карта бизнес-стратегии, где компоненты располагаются по оси Y, что обозначает положение в цепочке создания стоимости и привязаны к потребностям пользователя, а ось X описывает эволюцию компонентов (от зарождения до commodity) 4) Event storming - это крутая техника проведения воркшопов для коллаборативного изучения сложного бизнес домена, про которую я уже рассказывал 5) Modernization strategy selector - модель выбора оптимальной стратегии модернизации для каждой подсистемы, которая позволяет использовать портфельный подход к модернизации, где оптимальный возврат инвестиций может быть определен на гранулированной основе для достижения оптимального общего возврата инвестиций в модернизацию. - Ну и напоследок автор говорит о том, что для старта надо выбирать область, где модернизация может принести обозримые результаты за ограниченный промежуток времени. В общем, надо уметь срывать низковисящие плоды - это позволяет показать, что модернизация может приносить пользу, а не превратится в очередное бесконечное начинание без конца и без края и без ощутимых результатов:) #Management #Software #Engineering #SoftwareDevelopment #Processes #ChangeManagement #Strategy #Architecture

A Brief Outlook of Enterprise Architecture Role in the Digital Age (Рубрика #Architecture) Когда я выбирал научные статьи с research разделов bigtech компаний, то мне казалось, что большая часть whitepaper интересна. Но тут я решил поискать материалы про enterprise architecture в ACM Digital Library и нашел ... Пока ощущение от их чтения грустное. Конкретно в этой статье 2022 года от Ахмеда из Египта (Ahmed S. Elsheikh) сделано все достаточно топорно и как-то механистически, но давайте ниже я расскажу подробности 1) В абстракте автор начинает с того, что с 1980х годов корпоративная архитектура существует как отдельная дисциплина, которая помогала бороться со сложностью 2) Но с 2010х годов появилась отдельная волна цифровых трансформаций (digital transformation), которая привела к волне подрывных инноваций и бизнес и технологические ландшафты изменились навсегда:) 3) Автор решил исследовать как эти две волны связаны межжду собой через исследование статей на тему digital enterprise architecture 4) Для начала автор рассказывает про святую троицу: Enterprise architecture => TOGAF => Archimate, где корпоративная архитектура - это околонаучная дисциплина, TOGAF - это фреймворк, а Archimate - это фреймворк для моделирования архитектуры. Дальше автор рассказывает про application portfolio management strategy, capability architecture и capability-based planning 5) Но возникает вопрос как это все добро применять с цифровизации, цифровой трансформацией и другими историями про трансформаторов и трансформации:) 6) Автор погуглил словосочетание "digital enterprise architecture" в Clavirate "Web of science" и нашел 55 статей 7) Дальше автор взял базовую статистику по году выхода, авторам, количеству цитат и построил графики - походу статья без графиков не очень научна 😍 Из графиков видно, что с 2015 года пошли не разовые публикации, а косяком, где в 2017 году был пик в 10 публикаций, дальше небольшое проседание и в 2021 году был новый рекорд в 14 публикаций. Из этой статы видно, что исследователи корпоративной архитектуры сразу подхватили тренд цифровой трансформации:) 9) Дальше автор разбил эти 55 статей по 3 группам, выделив отсечку по количеству отсылок к публикациям (количество цитат из них) 10) Получилось 3 группы: - Взаимное влияние корпоративной архитектуры как отдельной дисциплины и цифровой трансформации как отдельной волны подрывных технологий и бизнес потребностей в одно и то же время - Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать корпорации, что цифровые и глобальные одновременно - Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать цифровые трансформации в разных контекстах и секторах индустрии 11) Автор кратко буквально в одной строке характеризуют каждую статью из этих групп (очень глубокая проработка материала) 12) Напоследок автор формулирует направления для исследования примерно так - Связь между глобальными цифровыми корпорациями и конкретные трансформации, например, корпоративная архитектура может отличаться между индустриями - Не хватает некоторых логичных областей (указанные три категории выше не закрывают все сценарии) - Как отличаются корпоративные архитектуры, когда в основе цифровых трансформаций разные подрывные технологии (автор делает отсылку к блокчейну и бигдата - чуток подпротухшими сейчас кажутся предложенные автором disruptive technologies) - Как фреймворки для корпоративной архитектуры и фреймворки для цифровых трансформаций (походу и такая дичь штука есть) В итоге, книга заканчивается выводом, что автор сделал обзор литературы и даже дал рекомендации по новым исследованиям. P.S. А я подумал, что лучше бы я прочитал еще одну научную статью от Google:) #SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment

Обзор paper "Defining, measuring and managing technical debt" (Рубрика #Architecture) Я продолжаю читать и писать о статьях из серии developer productivity, о которых рассказывал в обзоре первого whitepaper "A Human-Centered Approach to Developer Productivity". В третьем whitepaper с заголовком "Defining, Measuring, and Technical Debt" речь идет про технический долг и как он влияет на продуктивность разработчиков. Эта тема часто поднимается, но редко когда можно услышать четкое определение термина, а также объяснение как его считать и что с ним делать. Авторы решили закрыть этот пробел и написать как с этим дела в Google. А я решил сделать обзор этой статьи. #Architecture #Software #Management #Leadership #Engineering