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

The Tyranny of Metrics (Тирания показателей) - Part II (Рубрика #Management)

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

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

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

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

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

#Data #Statistics #Management #Leadership #Processes

The Tyranny of Metrics (Тирания показателей) - Part III (Рубрика #Management)

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

1) Какую именно информацию вы собираетесь контролировать? Чем сильнее объект контроля напоминает неодушевленный предмет, тем выше вероятность того, что его можно оценивать количественно. В противном случае в роль вступает эффект наблюдателя
2) Насколько полезна эта информация? Важно искать не там, где светло, как в анекдоте

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

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

#Data #Statistics #Management #Leadership #Processes

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

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

Почему 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Карта гипотез (Рубрика #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

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

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 Denoscription of Software Intensive Systems
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
4) Из RUP (Rational Unified Process)
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition

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

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

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

CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async (Рубрика #ComputerScience)

Я часто рассказываю про то, что надо знать базу для того, чтобы развиваться в software engineering. Но обычно сложно описать, а что же входит в это определение "база" и является джентельменским набором хорошего инженера. Но тут мой коллега, Женя Козлов, крутой инженер, написал серию статей про процессоры, модели памяти, многозадачность и конкурентность. В этой серии разбираются моменты, которые полезны инженерам, что делают высоконагруженные системы, которые плотно работают с данными. Собственно, сам Женя у нас лидит команду, что занимается Statist - это наша система продуктовой аналитики, которая давно заменила нам Amplitude и по всем характеристикам тянет на data intensive application. В общем, я очень рекомендую вам эту серию статей от Жени, если вам интересно понять как компьютер обрабатывает под капотом те программы, что вы пишите на своем любимом языке программирования.

1) Начальный пост про многозадачность в OS
2) Про развитие процессоров и взаимодействие OS с ними
3) Про Hyper Threading
4) Процессы. Начало
5) Процессы в Linux
6) Потоки. Начало
7) Потоки в Linux
😍 Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
9) Multiplexed IO
10) Asynchronous IO

#Software #ComputerScience #Engineering #SRE #Architecture

Code of Leadership (Рубрика #Management)

Примерно год назад я стартанул подкаст про engineering management с названием Code of Leadership. За это время получилось выпустить 21 эпизод, но я не планирую на этом останавливаться:) Подкаст доступен в Youtube и Ya Music.
Вот ссылки на материалы по каждому эпизоду:

1) Team topologies со Станиславом Халупом
2) "Antifragility in IT" с Александром Бындю
3) "Herding Cats" с Женей Кузовлевым
4) "Turn the ship around" с Екатериной Шестимеровой
5) "Project Phoenix" с Иваном Михеевым
6) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
7) "Your brain at Work" с Эрнесто Инаркиевым
8) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
9) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым

#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement

"Архитектура в Т-Банке: вчера, сегодня, завтра" на конференции ArchDays 2024 (Рубрика #Architecture)

Сегодня в 15.40 я выступаю на конференции ArchDays с докладом "Архитектура в Т-Банке: вчера, сегодня, завтра", в котором я расскажу про развитие подходов к проектированию и архитектуре в Т-Банке с начала времен и до текущего момента. Я постараюсь объяснить какие причины побуждали нас меняться и как мы осуществляли сами изменения. Я расскажу про процессы и людей, которые занимаются у нас проектированием и почему архитектор - это не должность, а роль. А закончу тем, что расскажу куда мы движемся дальше.

Вот дополнительные материалы для изучения, которые я рекомендую к своему выступлению
1) "Эволюция web’а tinkoff.ru за последние 3 года" (youtube) - мое выступление на ArchDays 2019, в котором я рассказываю как мы переходили от коробочного решения к собственной разработке в одном из доменов
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" (youtube, статья с расшифровкой) - мое выступление на ArchDays 2020, в котором я рассказываю про архитектурные подходы, к которым мы пришли по итогам масштабной собственной разработки и какую мы ставку делали на платформизацию
3) "DevOps-эры в Тинькофф: культура, люди, инструменты" - выступление моего бывшего коллеги Станислава Халупа на Kuber Conf 2021 года, где он рассказывал про platform engineering и почему это направления стало важным для нас (мое саммари по выступлению, само выступление на youtube)
4) "Technical Governance для IDP на 7000 разработчиков" - статья Дмитрия Гаевского про governance для нашей внутренней платформы разработки Spirit (это расшифровка его выступления на Highload++ 2021)
5) Раздел про технологии на нашем сайте - здесь можно почитать про наши платформенные решения
6) "Code of leadership #17 - Interview with Anton Kosterin about Architecture" (youtube, ya music, пост) - серия подкаста с Антоном Костериным, моим замом, который помогает мне строить architecture governance
7) "Research Insights Made Simple #1 - API Governance at Scale" (youtube, ya music, пост) - первая серия подкаста с разбором научных статей, где я с моим коллегой разбирал подход к API Governance в Google, а также мы активно проводили параллели с architecture governance в нашей компании
8) "Measuring Developer Goals" - мой обзор статьи от Google на тему того, куда стоит двигаться платформе разработки, чтобы оптимально поддерживать цели инженеров при разработке софта

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems