Operationalize a Scalable AI With LLMOps Principles and Best Practices (Рубрика #ML)

Я уже давно заметил, что модность темы можно отследить по наличию связки somethingOps, вот дошла очередь и до LLMOps, про что рассказывается в недавней статье от DZone. Раньше уже была на хайпе темы
- DevOps - тема уже давно на хайпе (подробнее в книге "Accelerate", про которую я рассказывал), сейчас больше говорят про Platform Engineering
- DevSecOps - горячая тема, подробнее в книге "Agile Application Security", про которую я рассказывал или недавней статье "Secure by Design at Google", который я разбирал отдельно
- DataOps - давняя и актуальная тема про выстроенные процессы работы с данными. Они нужна как пререквизиты для эффективной работы над ML-моделями
- MLOps - это очень актуальная тема, которая включает набор практик, которые объединяют ML, DevOps и инженерию данных, которые направлены на создание, деплой и эксплуатацию ML систем в проде надежно и эффеективно. Интересно, что эту тему мы разбирали в выпуске подкаста "MLOps в теории и на практике"
Подробнее про XOps подходы можно посмотреть в докладе "The Pipeline-Driven Organization", про который я уже рассказывал

В этой же статье речь идет про подмножество MLOps подходов, которые сфокусированы именно на LLM приложениях, которые сейчас являются горячей темой. В приведенной ниже статье сначала приводится определение LLMOps. Дальше разбирается разница между MLOps и LLMOps по критериям на чем основной фокус, как выглядит адаптация моделей, оценка качества моделей, управление моделями, включая версионирование и метаданные, как модели деплоятся и как мониторится их работа. Дальше автор разбирает базовые характеристики LLM
- Что они существуют в разных формах: проприетарные модели с платными API, pre-training models, fine-tuned models
- Что существует так называемый prompt engineering, так как многие LLM принимают в качестве входа текст на естественном языке
- Иногда можно добавлять контекст к запросам пользователей (context-based prompt engineering:), чтобы повысить их эффективность, для чего используются новые инструменты, навроде векторных баз данных (про которые был недавно интересный доклад)
- Они достаточно большие, иногда сотни гигабайт, а также им может требоваться GPU не только для тренировок, но и для обработки real-time запросов
- Оценивать их качество достаточно сложно, поэтому часто надо встроить человеческий фидбек прямо в MLOps процесс для оценки и тестирования моделей

Ключевыми моментами приложений с LLM сейчас являются следующие моменты
- Prompt engineering, про который мы говорили выше
- RAG (retrieval augmented generation), который полагается обычно на уже упоминавшиеся векторные базы для семантического поиска, а также на feature store, где хранятся признаки.
- Fine-tuning LLMs - это процесс адаптации предварительно обученной LLM к сравнительно небольшому набору данных, специфичному для отдельной области или задачи.
- Pre-training a model from scratch - это что-то на богатом про процесс обучения языковой модели на большом массиве данных (например, тексте, коде) без использования каких-либо предварительных знаний или весов из существующей модели:)

Дальше автор показывает референсные архитектуры LLM приложений с RAG от Databrics, а финализирует плюсами и минусами LLMOps

+ Minimal changes to base model - большинство LLM приложений можно запустить поверх базовых моделей с небольшими изменениями
+ Easy to model and deploy - LLMOps как раз упрощает использование моделей
+ Advanced language models - можно начинать использовать сложные модели через API, а потом перейти open source модели
- Human feedback - в случае LLM обратная связь от людей необходима, что добавляет сложностей
- Limitations and quotas - при использовании внешних API надо понимать их ограничения и стоимость использования
- Risky and complex integration - при использовании внешних API надо понимать какими данными вы делитесь и насколько это ок

#AI #ML #Software #Architecture #Future

Code of Leadership #21 "A Philosophy of Software Design" (Рубрика #Architecture)

Этот выпуск подкаста посвящен рассмотрению крутой книги Джона Остерхута "A Philosophy of Software Design". В разборе книги  помогает Григорий Скобелев, Java/Go techlead, чей основной профиль это highload приложения, также он является директором программного комитета Podlodka Techlead/Java Crew. А в свободное время он делает свой подкаст/книжный клуб - { между скобок }, LinkedIn

В этой серии рассмотрена первая половина книги, где получилось обсудить темы
- Знакомство с гостем
- История создания книги
- Общее содержание книги
- Философия борьбы со сложностью
- Управление техническим долгом
- Подходы к управлению процессом разработки
- Эволюция и технический долг
- Подходы к приоритизации
- Продуктовый подход и оценка импакта
- Виды сложности и метрики кода
- Когнитивная нагрузка и простота кода
- Принципы обучения и решения задач
- Автоматизация и тесты
- Причины когнитивной сложности
- Исследования в Google
- Стратегическое и тактическое программирование
- Примеры из практики
- Проблемы с накоплением технического долга
- Модуляризация и интерфейсы
- Проблемы с интеграцией через базу данных
- Скрытие информации и абстракции
- Проблемы с монолитными системами
- Генерализованные и специализированные модули
- Централизованное хранилище данных
- Уровни абстракции
- Декораторы и фасады
- Эволюция кода и опыт инженеров

Продолжение обзора книги будет в следующей серии

#Architecture #Processes #Management #Leadership #Software #SystemDesign

Архитектура на старте: подготовка к успеху - Podlodka Techlead Crew (Рубрика #SRE)

Поучаствовал вчера в дискуссии на подлодке насчет проектирования надежных систем. В ней участвовали Олег Бондарь, Филипп Дельгядо и я. Мы поговорили про ключевые принципы для построения надежной архитектуры. Дискуссия была интересной и динамичной. Мы уделили много вопросам observability и я позвал всех участников на конфу T-Observability Day Tech 2024, что пройдет 23 октября в нашем московском офисе T-Space. Кстати, про конфу я уже рассказывал тут в канале

P.S.
Год назад я выступал на конференции с докладом "Проектируем надежные системы — стоит ли игра свеч", про который я уже рассказывал. И тот доклад был основан на солидном списке материалов
- "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем
- "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг)
- "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability)
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность
- "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- Глава про resilience из книги "Continuous Architecture in Practice" - глава крутой книги, в которой буквально на пальцах авторы объясняют чем старый high-availability подход отличается от нового подхода resilience к обеспечению надежности систем
- "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем
- "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем
- "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу.
- "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента
- "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE

Массовое вымирание стартапов: что происходит на глобал tech-рынке и как это влияет на рынок труда (Рубрика #Management)

Интересное интервью Дениса Калышкина, венчурного инвестора из фонда I2BF (инвестируют в американские стартапы) Кире Кузьменко из New HR
Обсуждение было сконцентрировано вокруг тем
— Вымирают ли стартапы или нет?
— Как инвесторы выбирают, куда инвестировать в текущей ситуации?
— Что происходит с внутренними стартапами в крупных компаниях?
— Как оценивать стартап кандидату, который хочет там работать?
— Когда будет дно кризиса и надолго ли текущий кризис с нами?
— Надо ли идти сейчас в предпринимательство вместо найма?

#Startup #Management #Leadership #Invest

Обзор whitepaper "API Governance at Scale" (Рубрика #Architecture)

Я дописал обзор статьи про API Governance от ребят из Google, про которую я уже несколько раз упоминал (1 и 2). В общем, статья получилась интересной и полезной - ее подходы хорошо масштабируются за границы governance именно API, например, мы многое из этого пытаемся применять в процессах architecture governance на уровне компании. В общем, читайте статью, а в следующий понедельник по ней выйдет первая серия подкаста "Research insights made simple", где я буду ее обсуждать со своим коллегой Даниилом Кулешовым.

#Architecture #Management #Governance #SystemDesign #Software #Leadership

Continuous API Management, 2nd Edition (Непрерывное развитие API) (Рубрика #Architecture)

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

1. The Challenge and Promise of API Management - зачем компании хотят управлять своими API, какие проблемы при этом возникают и какие возможности это дает. Здесь авторы рассказывают в общем об основных вопросах, рассмотренных в книге. Отдельно отмечу важность разделения для API интерфейсов (контракты), имплементации (код) и развертывания (инфра)
2. API Governance - глава с фундаментальными концепциями для управления API и какое это значение имеет для принятия решений
3. The API as a Product - глава про важность восприятия API как продуктов (API as a Product). При этом на API можно смотреть с точки зрения целевой аудитории и принимать решения, которые являются лучшими для них
4. The Pillars of an API Product - основные колонны, на которых основаны API. Авторы выделяют следующие области, которые рассматривают детально: strategy, design, documentation, development, testing, deployment, security, monitoring, discovery, change management
5. Continuous API Improvement - глава про то, как жить с непрерывными изменениями и как ими управлять
6. API Styles - здесь авторы рассказывают об основных стилях, которых они насчитывают 5. Вот они: tunnel style (RPC), resource style (REST), hypermedia style (RESTful), query style (graphql), event-based style
7. The API Product Lifecycle - жизненный цикл одного API, который состоит из этапов: create => publish => realize => maintain => retire ... Авторы подробно разбирают как на каждом этапе требуется прорабатывать конкретные pillars
8. API Teams - какие роли нужны в командах для эффективного развития API как продукта. Причем не просто в вакууме, а в зависимости от зрелости самого API
9. API Landscapes - здесь авторы переходят от единичных API к их множеству, которое можно воспринимать как ландшафт. Авторы рассказывают про API Management at Scale, который опирается на принципы, протоколы и практики. Это очень сильно пересекается с paper "API Governance at Scale" от Google, про которое я рассказывал раньше. Плюс авторы вводят модель 8v, которая позволяет управлять ландшафтом, ориентируясь на разные ракурсы. Вот эти восемь V: variety, vocabulary, volume, velocity, vulnerability, visibility, versioning, volatility
10. API Landscape Journey - рассказ о том, а как внедрять API Governance. Авторы предлагают модель enabling team, которая поможет внедрить и раскатить процессы API Governance на всю организацию
11. Managing the API Lifecycle in an Evolving Landscape - здесь авторы пересекают pillars и 8vs и рассказывают о том, как они связаны между собой
12. Continuing the Journey - последняя глава подводит итог книге и готовит читателей к старту Continuous API Management внутри компании

P.S.
Обложки книг представлены в следующем посте.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Как формировать структуру команд под запросы бизнеса (Рубрика #Management)

Недавно меня позвали выступить на митапе с этой темой, которую я рассказывал на YaTalks в 2023 году. Это знаковое для меня выступление, так как я делился основами и принципами дизайна команд, которые помогали мне на протяжении 7 лет работы в Тинькофф. Это приглашение показалось мне отличной причиной рассказать сразу и продолжение о том, как за 2023 и 2024 года мы трансформировали мое подразделение в 1000 инженеров в 5 отдельных самостоятельных технических доменов со своими engineering директорами. Но оказалось, что я не сделал краткого саммари прошлого выступления. Поэтому я решил исправиться и написать расшифровку (а видео досупно на youtube).

В итоге, я сегодня выступаю на митапе в Selectel, где расскажу сокращенную версию доклада про оргдизайн с фокусом на тимлидах, а вот продолжение расскажу на одной из следующих конференций - просто вся история с продолжением не влезла в тайминг + не очень попадает в целевую аудиторию митапа.

Вот список рекомендаций для дальнейшего изучения
Принципы и подходы
- Backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про проектный и продуктовый подход у меня есть хорошая статья
- Про Kanban рекомендую почитать пару книг: “Визуализируйте работу” (“Making Work Visible”), про которую я рассказывал, а также "Канбан Метод. Базовая практика", про которую я тоже рассказывал
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал
Отдельные выступления про их применение
- В 2019 году на ArchDays я рассказывал про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях
- В 2021 году на Techlead Conf я рассказывал про то "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В 2022 году на Highload++ Spb я рссказывал доклад "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

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

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

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

Сервис 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

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

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