Книжный куб

Practitioners guide to MLOps: A framework for continuous delivery and automation of machine learning - Part II Продолжая первый пост про этот whitepaper, надо рассказать про capabilities ML платформ, которые нужны для того, чтобы выстроить хорошие MLOps процессы: - Experimentation - совместное выполнение исследовательского анализа данных, создание архитектуры прототипов моделей и реализация процедур обучения - Data processing - возможность обработки данных, что позволяют готовить и преобразовывать большие объемы данных в конвейерах непрерывного обучения - Model training - возможность эффективно и экономично запускать мощные алгоритмы для обучения моделей машинного обучения - Model evaluation - возможность оценки модели в интерактивном режиме во время экспериментов - Model serving - возможность развертывать и обслуживать модели в продакшен - Online experimentation - возможность провести онлайн-эксперименты, чтобы понять, как недавно обученные модели работают в продакшене по сравнению с текущими моделями (если таковые имеются) перед выпуском новой модели в производство - Model monitoring - возможность мониторинга моделей позволяет отслеживать эффективность и результативность развернутых моделей для обеспечения прогнозируемого качества - ML pipelines - возможность выстроить сложные пайпланы для тренировки и эксплуатации моделей в проде - Model registry - централизованный реестр моделей (регистрация моделей, описание зависимостей, документации и метаданные, интеграция с экспериментами и мониторингом, а также раскаткой и откаткой моделей) - Dataset and feature repository - хранилище наборов данных и фичей позволяют унифицировать определение и хранение данных для ML моделей. Наличие центрального хранилища свежих высококачественных данных обеспечивает возможность совместного использования, обнаружения и повторного использования. - ML metadata and artifact tracking - хренение различные типов артефактов ML, что создаются в разных процессах жизненного цикла MLOps, включая включая описательную статистику и схемы данных, обученные модели и результаты оценки В итоге, объединяя capabilities платформ и понимая целевой необходимые шаги конвейра, можно собрать отличный процесс, где ML не будет оторван от работы с данными и разработки, а значит строить и эксплуатировать ML системы станет проще. P.S. Конечно читая между строк этого документа можно понять, что внутри Google Cloud есть ML платфома со всеми этими возможностями, что позволяет из коробки выстроить MLOps ... если вы используете нужное облако:) Но это не умаляет хорошего описания фреймворка для MLOps, который приведен в этой статье #ML #Devops #Data #AI #Software #Architecture #Processes

Practitioners guide to MLOps: A framework for continuous delivery and automation of machine learning - Part I Постоянные читатели канала могли заметить, что я часто говорю про инженерные процессы и упоминаю так или иначе DevOps, SRE, Platform Engineering. Но у термина DevOps, который был про сближение разработки и эксплуатации очень быстро появлялись похожие по смыслу термины, но из своих областей: DevSecOps, DataOps, FinOps, ..., MLOps. Подробнее про эти метаморфозы можно посмотреть в докладе "The Pipeline-Driven Organization • Roy Osherove • GOTO 2022", про который я уже рассказывал. Но сегодня я хотел рассказать про простенький whitepaper 2021 года от Google Cloud на тему MLOps, раз уж у нас сейчас расцвет AI и ML:) Сам документ состоит из трех частей - Overview of MLOps lifecycle and core capabilities - Deep dive of MLOps processes - Putting it all together В первой части приводится определение MLOps

MLOps is a methodology for ML engineering that unifies ML system development (the ML element) with ML system operations (the Ops element). It advocates formalizing and (when beneficial) automating critical steps of ML system construction. MLOps provides a set of standardized processes and technology capabilities for building, deploying, and operationalizing ML systems rapidly and reliably.

И показывается четкая связь между data engineering, app engineering и собственно ml engineering. Причем выстроенные процессы работы с данными нам нужны как пререквизиты для эффективной работы над ML моделями, а app engineering нужен для того, чтобы обученные модели хорошо работали в проде и сервили свои запросы. В документе рассказывается про этапы процесса, которые напоминают стандартные истории из app engineering и devops, но с небольшой спецификой - ML development - эксперименты с данными, выбор модели и архитектуры, оценка вариантов и выбор лучшего - Training operationalization - выстраивание пайплайна обучения модели - Continuous training - непрерывное обучение в ответ на новые данные, изменения кода или просто по расписанию - Model deployment - развертывание модели (очень напоминает развертывание обычных приложений) - Prediction serving - модель работает в проде и обрабатывает запросы (онлайн/оффлайн) - Continuous monitoring - мониторинг работы модели (тут как обычные параметры работы приложения, так и отслеживание метрик эффективности модели, дрифта данных, изменения распределения процесса, что мы предсказываем) - Data and model management - это центральная, сквозная функция управления артефактами ML, обеспечивающая возможность аудита, отслеживания и соответствия требованиям. Эта функция помогает с совместной работой, повторным использованием,и возможностью обнаружения какие ML модели уже есть и работают. Продолжение про capabilties ML платформ во второй части поста. #ML #Devops #Data #AI #Software #Architecture #Processes

О Gregor Hohpe В продолжении предыдущего поста про доклад "Build Abstractions Not Illusions" хотелось вспомнить в общем про Грегора, который 1) Больше 20 лет назад написал книгу "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions", про которую я уже рассказывал. Эта книга описывала паттерны интеграции и до сих пор концепции из нее достаточно полезны 2) Успел поработать в Google, а сейчас работает в AWS в области FaaS (function as a service) и евангелирует использование AWS и даже написал книгу "Cloud Strategy: A Decision-based Approach to Successful Cloud Migration" (ее я еще не читал) 3) В 2020 году написал книгу "The Software Architect Elevator ", про которую я тоже рассказывал. Книга посвящена роли архитектора в современных условиях, когда крупные компании занимаются переводом на цифру всего и вся Но я рассказывал не только про его книги, но и про выступления: - The Magic of Platforms - I Made Everything Loosely Coupled. Does My App Fall Apart? #Architect #Person

Build Abstractions Not Illusions • Gregor Hohpe • YOW! 2023 В этом докладе Gregor Hohpe говорит про абстракции и их пользу, а также как чрезмерное абстрагирование и исключение важных вещей приводит к созданию иллюзий (и протекающих абстракций). - Intro - автор показывает свой стандартный пример с различными географическими картами, которые отличаются в зависимости от цели и аудитории. - Platform abstraction - автор переходит к platform abstraction и вспоминает про уменьшение когнитивной нагрузки для пользователей платформы. И тут появляется аналогия с машинами и платформами, которые использовались в автомобильной индустрии для выпуска машин разных марок на базе одной "платформы". Это позволяло экономить, разработав качественную платформу и переиспользовать ее для разных продуктов - Abstractions vs composition - Автор продолжает приводить примеры из области автомобилестроения и говорит про педаль газа (хотя это скорее не педаль газа, а педаль ускорения, что еще очевиднее, если мы рассматриваем элетрические автомобили). Дальша он приводит SQS-Lambda-SQS из AWS, а потом переходит к паттерну scatter-gather pattern, который изначально назывался broadcast aggregate. Проблема в том, что в этих случаях описывается не сама абстракция, а ее реализация. Дальше автор рассказывает про электрическую розетку, которая является отличной абстракцией и автор объясняет почему (разделение интерфейса и реализации, стандартизация интерфейса, ...). Но даже электрическая розетка протекает как абстракция, если происходит глобальное отлючение энергии (в розетке заканчивается ток). Ну и напоследок автор говорит про абстракцию сокетов (sockets и packet routing). В итоге, автор говорит про то, что композиция бывает полезна, но она отличается от абстракции, так как объединение элементов в этом случае не предоставляет новую абстракцию - Abstractions vs Illusions - Автор описывает абстракции, которые зашли слишком далеко. Например RPC (remote procedure call), который он описывает так, как было принято в начале 2000х, когда RPC пытались сделать похожим на локальный вызов и скрыть всю сложность. С тех пор утекло много воды и так никто не делает, но вьетнамские флешбеки Грегора тут выглядят странно. В итоге, проблема описывает так, что в иллюзиях мы выкидываем важные детали или излишком обобщаем до состояния, когда наша модель начичнает вводить людей в заблуждение. Дальше автор рассказыывает про абстракцию платформ. Интересно, что как представитель AWS он катит бочку на создателей IDP (internal developer platform) внутри компаний поверх публичных облаков - по мнению Грегора часто это не добавляет никакого value, а только отнимает его (мне эти аргументы кажутся очень biased). И дальше Грегор показывает хорошую по его мнению абстракцию в виде ledger database из двух dynamo db и event bridge pipes посередине. Суть этих размышлений сводится к тому, что IDP внутри компаний должны не просто уменьшать возможности публичных сервисов, закручивая гайки, а скорее создавать новые абстракции, которые полезны для пользователей внутри компании. И дальше автор говорит, что "good abstractions support broad usage". - Distributed system abstractions - В этой части автор напирает на асинхронную работу с сообщениями (asynchronous messaging) и добавляет к абстракции data flow еще и control flow, который бывает полезно понимать. Речь идет примерно про puller, pusher, pool и driver Ну а дальше Грегор показывает как понимание работы control flow позволяет сделать стандартные абстракции полезными - Summary - в заключение Грегор подводит итог и говорит, что

Good abstractions reduce cognitive load because they form a cohesive language and a mental model. Omitting relevant details is tempting but leads to dangerous illusions.

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

Аудиоподкаст "Code of Leadership" на Я.Музыке Многие просили сделать аудиподкаст в каком-то удобном месте. Я сначала завел его на podster.fm, а потом заполнил заявку в Яндекс Музыке на добавление подкаста и ... забыл об этом. Но ребята из Я.Музыки не забыли ... Вчера после очередного комментария на Youtube на тему того, что нужна аудиоверсия в VK или Яндекс Музыке, я решил проверить как поживает моя заявка и увидел, что подкаст уже есть:) Так что теперь можно слушать аудиоверсию подкаста в фоне и в привычном интерфейсе. #Management #Leadership #Processes #Software #Engineering #Architecture

Modern Platform Engineering: 9 Secrets of Generative Teams • Liz Fong-Jones • GOTO 2023 Интересный доклад от Liz Fong-Jones, Field CTO из Honeycomb. Сначала Liza вспоминает что такое DevOps, потом SRE, а потом переходит к теме Platform Engineering. В части про devops идет речь про стремление к culture, automation, lean, measurement и sharing. А DORA метрики позволяют измерить насколько хорошо это получается у команд. Но эти метрики имеют ряд проблем: - Путь улучшений не слишком ясный - Сами улучшения сложно померить (плюс мы измеряем запаздывающие показатели) - Есть дилемма с самой моделью зрелости и непрерывными улучшениями (модели зрелости предполагают, что можно попасть на определенный уровень зрелости, а дальше уже улучшаться не требуется - кстати, в "Accelerate" для решения этой проблемы предлагали использовать capabilities model - я рассказывал про это в обзоре книги) - Как достигать консистентности в разных командах В итоге, Liz предлагает модель с 9 секретами, что способствуют генеративной культуре по Веструму (я уже писал про этот подход к типизации культур) 1. Reproducible deploys (If it ain't in Git it don't exist!) - нам нужна повторяемость в сборках и деплоях. Про это шла речь еще во времена появления 12 factor app, а сейчас это стандарт де-факто:) 2. Fast CI/CD (I wanna go fast!) - ускоряем циклы обратной связи, помогаем разработчикам быстрее видеть результаты своего труда. 3. Observability (Don't drive with snow on your windshield!) - дефолт для понимания того, что происходит с нашим приложением. Без этого не ясно как определять наличие проблем, а также траблшутить их. 4. Feature flagging (Smaller boom, less fear!) - в комплекте с TBD (trunk-based development) позволяет правильно делать CI (подробнее в докладе) 5. Code ownership (You build it, you run it! (with a twist)) - мантра, которая убирает забор между dev и ops (sre) командами. По-факту, SDEs (software development engineers) владеют не только кодом, но и самим приложением, что крутится в продакшене 6. Blameless culture (No one wins the shame game!) - здесь посоветую сразу несколько статей и выступлений - Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?" - A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative) Мои выступления на связанные темы - Культура постмортемов - От монолита к микросервисам и обратно 7. Service level objectives (SLOs) (If you liked it you shoulda put an SLO on it!) - про это я говорил в докладе "Проектируем надежные системы - стоит ли игра свеч" 8. Chaos Engineering (Test your assumptions!) - рекомендую на эту тему глянуть выступление Kelly Shortridge "Practical Magic: The Resilience Potion & Security Chaos Engineering" 9. Platform teams (to tie it all together and systematise it) - рекомендую почитать книгу Team Topologies про team-first подход при проектировании архитектуры программных систем, так и организации. В ней очень хорошо рассказывается про платформенные команды. А вот как сама Liz характеризует эти команды

Platform teams outsource as much as possible, write as little code as possible. Platform teams are experts in outsourcing. It’s a very high-leverage role; they use their infra expertise to offload as much operational burden as possible.

В итоге, в модели Liz платформенные команды помогают всем остальным 8 пунктам и позволяют построить генеративную культуру и высокоэффективные команды. #Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #Devops #PlatformEngineering #Process #Culture #SRE

Стажировки в Тинькофф (Тинькофф Старт) Открылась очередная программа стажировок в Тинькофф. В этот раз набор идет на 16 направлений: ML-разработка, Java, Python, Go, SRE, .NET, Scala, Android, iOS, Frontend, QA, DWH, Аналитика, Маркетинг, Дизайн, помощник персонального менеджера в Инвестиции. Стажировки у нас оплачиваются и во время них вы будете работать над реальными задачами, у вас будет ментор, который поможет вам адаптироваться, а по итогам лучшие стажеры будут приглашены в штат компании. Стажироваться можно в рамках гибкого графика - от 20 часов в неделю, удаленно или в офисе, в России или в соседних странах (Беларусь, Казахстан). Для попадания на стажировку надо будет пройти экзамены, которые начнутся в конце марта. Экзамены для разных направлений различаютсяя, подробнее можно почитать на странице с описанием программы. А стартовать стажировку можно будет ближе к лету (это позволит совмещать это с учебой). #Career #Software #Engineering

Code of Leadership #8 - Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики) В восьмом выпуске подкаста Code of Leadership я пообщался со своим коллегой, Андреем Цыбиным, техническим директором продуктовой аналитики и a/b платформы в Тинькофф. В этом интервью Андрей вспоминает с чего начинался его путь в компании, как он занялся Statist, который изначально предназначался для метрик производительности, а потом стал полноценной заменой Amplitude и стандартом де-факто в Tinkoff. В этом выпуске мы не стали говорить про нашу a/b платформу, поэтому в следующем интервью где-то через полгода Андрей расскажет про нее отдельно. #Management #Software #Processes #Analytics #Engineering #Leadership #Architecture

Code of Leadership #6 Staff+ инженеры, архитектура и SDLC Вот только дошли руки сесть и написать расшифровку нашего общения с Лешей Тарасовым про инженеров высоких грейдов, которые в западной практике называются Staff+. В этом выпуске мы вместе с Лешей обсуждали как выглядит матрица SDE (software development engineer), какие треки развития есть у инженеров, как выглядит процесс роста внутри и найм сотрудников снаружи. Также ближе к концу дискуссии мы обсуждаем один из этапов собеседований, который называется "Architecture & SDLC", который мы проводим для кандидатов на Staff+ уровень. Для любителей послушать выпуск есть аудиоверсия, а для любителей посмотреть - видеоверсия подкаста. Ну и напомню, что многое из этого выпуска я уже рассказывал в других выступлениях и статьях - Архитектура в масштабе на ArchDays 2020 - System Design Interview на ArchDays 2021 - Как подготовиться и пройти System Design Interview на ArchDays 2022 - Варианты роста инженера, если он уже Senior на Tinkoff Meetup 2023 - Как нанимать технических руководителей на Teamlead Conf 2023 - Книга Will Larson "Staff Engineer" и мои обзоры этой книги в двух частях: 1 и 2 #Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

Is Software Engineering Real Engineering? • Hillel Wayne • GOTO 2023 Это выступление Hillel Wayne пытается ответить на философский вопрос: software engineer - это тварь дрожащая или право имеет называться инженером:) Этот вопрос появился из цитат ученых по computer science навроде цитаты Gerald Weinberg

If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.

Ну и в тему этой цитаты автор вспоминает историю с leftpad. Для поиска ответа автор пошел через опросы настоящих инженеров, которые одновременно работали в области software engineering, а дальше устроил им интервью с тремя вопросами

I. Are we really engineers? II. How similar are we to engineers? III. What can we learn from each other?

1) Первый вопрос потянул за собой выяснение термина "engineering", на который было три варианта ответа: physical, consequential, licensed. Дальше автор разбирает каждый пункт и приводит примеры, отвергая все гипотезы. В итоге, остается самое простое, что engineering - это то, что делают инженеры ("what engineers do"). Забавная рекурсия:) Тут еще автор проходится по подходу "Software craftmanship", в котором авторы пытались отстроится от традиционных инженерных дисциплин (без понимания того, как они работают). 2) Дальше автор переходит к сходствам и отличиям между software engineering и традиционными инженерными областями. В итоге, получается, что - В сходствах: итеративность, высокая степень непредсказуемости, неформальность (в традиционных дисциплинах не всегда) - В различиях: скорость изменений - быстрая в software и медленная в традиционных инженерных дисциплинах, наличие жестких ограничений (в традиционных дисциплинах - это законы физики), консистентность - в диджитал мире корректно написанная программа будет работать, а в реальном мире работоспособность зависит от окружающих условий (температура, давление, ветер, ...) В общем, тут тоже отличия не критичны. 3) Ну и последний вопрос, а чему мы можем научиться друг у друга Здесь автор отмечает два момента: - Up-front planning time - Responsibility Забавно, что с этим сталкиваются все, кто проектируют API и контракты, систему плагинов или любой as-a-Service продукт. В итоге, автор приходит к выводу о том, что если мы хотим себя называть инженерами, то никто нам не может помешать это делать:) #Management #Leadership #Engineering #Software #Philosophy

Практическое руководство по статистическому управлению процессами Эту книгу Юрия Адлера и Владимира Шпера я читал несколько недель. И дело не в том, что книга скучна, а скорее в том, что она сложна для восприятия и требует понимания статистики и системного мышления. Авторы пропагандируют использование контрольных карт Шухарта, которые в свое время популяризировал сам Шухарт и его коллега Деминг, который приложил руку к японскому экономическому чуду. Все это укладывается в цикл PDCA Шухарта-Деминга (plan - do - check - act). Сама книга состоит из восьми глав

1. Что такое системное, статистическое и визуальное мышление и для чего оно нужно? 2. История возникновения статистического мышления. Основы теории вариабельности. 3. Основы теории вариабельности (продолжение). Анализ стабильности процессов. Игра "Красные бусы" 4. Правила построения и интерпретации ККШ (контрольных карт Шухарта). Классификация типов ККШ 5. Построение и анализ гистограмм. Диаграммы ствол-и-листья (stem-and-leaf) и ящик-с-усами (box-and-whisker). Вероятностные сетки и законы распределения 6. Индексы воспроизводимости процессов (ИВП) 7. Проблемы и трудности при построении и применении ККШ и гистограмм на практике. Алгоритм процесса анализа стабильности и воспроизводимости 8. SPC, AI, Big Data и новые идеи в области ККШ

Если кртако, то книга посвящена тому, как анализировать вариабельность процессов. Как оценивать причины вариабельности, где авторы говорят про - общие причины вариабельности, что присущи самому процессу - особые (assignable) причины вариабельности, что возникают из-за внешних по отношению к процессу воздействий Особые причины требуют локального вмешательства в процесс, а общие причины вариаций требуют вмешательства в систему (оно обычно должно осуществляться со стороны высшего менеджмента). Дальше в книге рассказывается про статистическое мышление

Это философия обучения и действий, основанная на следующих фундаментальных принципах: - любая работа осуществляется в системе взаимосвязанных процессов - во всех процессах есть вариации - понимание и снижение вариаций - ключ к успеху

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

1. Как выбрать показатели, требующие изменения? 2. Сколько таких показателей надо измерять? 3. Каким методом следует измерять каждый выбранный показатель? 4. Как часто надо измерять каждый показатель? 5. С какой точностью надо измерять каждый показатель? 6. Кто должен анализировать каждый показатель?

Каждый из вопросов скрывает под собой кучу интересного, но мне бы хотелось отметить ответ на 6 вопрос, где авторы говорят о том, что показатели надо анализировать владельцам самих процессов, так как они знают сущностную составляющую процесса и его особенности. В общем, в книге еще много интересного и я думаю, что ее полезно изучить менеджерам как в реальном, так и в digital производстве. #Management #Process #Statistics #Math #Metrics #Leadership

How to Take Great Engineers & Make Them Great Technical Leaders • Courtney Hemphill • GOTO 2017 Интересное выступление про технических лидеров, которому уже много лет:) Автор достаточно часто упоминает разные источники и аудитория про них никогда не слышала - семь лет назад я тоже про многие из них не знал, но к текущему моменту я читал уже все книги и исследования, которые упоминала автор. А вообще структура презентации очень хороша. Автор рассказывает про вещи, которые важны для технических лидеров, что вырастают из инженерки 1) Communication (general management 101) Здесь автор говорит про правильный подход к написанию документов от Барбары Минто "pyramid principle", где начинать нужно с ответа на главный вопрос, дальше приводить поддерживающие аргументы, а дальше приводить факты и данные. Та же Барбара придумала подход SQCA к сторителлингу: situation, complication, question, answer. А дальше автор переходит к целеполаганию и рассказывает про OKR (objectives and key results) от Энди Гроува. 2) Culture Здесь автор вспоминает про Проект Аристотель от ребят из Google (я рассказывал про это), где авторы выяснили, что основной фактор эффективных команд в Google - psychological safety. Еще можно почитать про генеративную культуру Веструма (я рассказывал про это). Также автор отмечает важность менторства как внутри компании, так и с людьми извне. А заканчивается pairing:) 3) Authenticity (be a human) Здесь автор рассказывает про радикальную прямоту (radical candor), а также про использование ретроспектив. 4) Paths (dual track leadership) Тут автор говорит про два трека развития: engineering management и individual contributors. Про возможность расти не только как менеджер, но и как инженер. Мы про это общались с моим коллегом, Лешей Тарасовым, в шестом выпуске Code of Leadership про Staff+ инженеров. #Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

Книги от ДМК Пресс на тему экспериментов и статистики На следующей неделе выйдет серия "Code of Leadership" с Андреем Цыбиным, техническим директором нашей продуктовой аналитики и a/b платформы, которую мы в этом году должны масштабировать на всю компанию. В интервью мы обсуждали вопросы продуктовой аналитики, а про a/b решили поговорить в следующий раз. Но сама тема для меня ключевая - 7.5 лет назад, когда я приходил в Тинькофф, то a/b платформа для привлечения уже входила в мой контур ответственности. Дальше она много лет эволюционировала, но всегда была ограничена вебом и мобилкой. А теперь мы с Андреем сделаем ее всеобъемлющей:) И так как мне эта тема глубоко интересна, то у меня уже была целая пачка книг на эту тему, а буквально вчера мне доехала еще коробка новых книг:) #AB #Experiments #Statistics #Engineering #Math

Why Most Data Projects Fail & How to Avoid It • Jesse Anderson • GOTO 2023 Интересное выступление про data проекты от Jesse Anderson, автора книги "Data Teams". Автор говорит о ключевых вопросах, которые стоит задать при старте проектов - Who - Автор говорит про правильный состав команды для data проектов. Собственно автор про это написал целую книгу и он говорит про баланс data scientists, data engineers, operations. - What - Автор задает вопрос про бизнес значение того data продукта/проекта, которым вы занимаетесь. Автор говорит о том, что фразы "Мы делаем AI" от CEO не хватает для data strategy:) В общем, надо понимать как ваш проект принесет ценность для бизнеса. Причем помимо стратегии нужен план и его execution. Особенно во времена, когда tech компании занимаются сокращениями в направлениях, что не приносят деньги. - When - Автор говорит о том, а когда эта бизнес ценность будет создана. Нужен проект с понятными временными границами, чтобы он не был слишокм долгим, чтобы быть отмененным где-то посердине и не слишком коротким, обещающим золотые горы, которым на самом деле будет невозможно соответствовать. - Where - И вот мы наконец-то добрались до первого технического вопроса, а где собственно эти данные будут обрабатываться, как будет выглядеть архитектура решения. И тут для ответа тоже не хватает фразу "Мы будем использовать технологию XYZ вендора ABC". Проблема в том, что вендор может пообещать все что угодно, но это обещание не факт, что выполнимо, более того, не факт, что оно оптимально для заказчика:) - How - Здесь речь идет про план выполнения и про фокусировку на приоритетных направлениях. Хотя часто такие data проекты пытаются успеть сразу везде, а дальше теряют эффективность на context switches и застывают на месте, переставая генерировать какую-либо ценность кроме рассказов о наступлении AI:) Автор интересно рассказывает про то, как бизнес заказчикам перпендикулярно на конкретные технические решения, но важно какую бизнес-ценность они могут получить по результатам выполнения плана. - Why - Автор задает вопрос, а почему же эти данные обладают ценностью? Просто отгружать данные и гонять ETL/ELT пайпланы не достаточно. Важно понимать как использование данных в новых проектах позволит обеспечить нужный ROI (return on investments), причем автор говорит о том, что он ищет 10x ROI для data проектов Напоследок автор говорит о том, что для AI и data проектов важно понимать, что такие проекты сложны и требуют навыков, людей и организационных изменений для своего успеха. И это достаточно сложно и не все способны приносить пользу в таких проектах. Конкретно, автор рассказывает про то, что если запускать data и AI проекты внутри DWH команд, то такие проекты обречены на неудачу ("the team where good data projects go to die). Это обусловлено не тем, что DWH технологии плохие, а потому, что это скорее проблема людей ("people problem"), которые очень специфично разбираются с проблемами и очень специфичным образом выстраивают свою работу. В общем, автор говорит о том, что эта не та команда, которая должна отвечать за data и AI проекты нового типа. P.S. Такое же выступление было на YOW 2022 и я про него рассказывал раньше. Выступление получилось хорошим и автор заново его рассказал уже на goto конференции в 2023 году:) P.P.S. Мне мысли автора нравятся и я запланировал прочитать его книгу еще год назад, но до сих пор не прочитал:) #Management #Leadership #Data #DataScience #AI #Engineering #Software #SoftwareDevelopment #ML

Layers of Leadership • Lee Campbell • YOW! 2023 Интересное выступление от Lee Campbell, VP of Engineering at VGW, которое состоит из следующих частей — Leadership challenges - рассказ про вызовы, что стоят перед лидерами: people, delivery, operations. Для лидера при работе с людьми важно работать на competency (build it right, run it right), performance (right thing, right time) и alignment (right people, right place). Дальше он переходит к — Start-up challenges - тут автор говорит про формирование команды и погружается в вызовы стартапов. Автор предлагает метафору direction - map - path, которые позволяют стартапу и его команде двигаться в условиях неопределенности. Автор говорит про троицу —— Competency (what) -> reference example —— Performance (how) -> performance expectations —— Alignment (why) -> outcome focused — Teamwork challenges - здесь автор говорит про вопросы людей вида "кто и что сделает и когда?", "Как я могу вырасти в компании" и на уровне системы: "Что должна делать эта система?", "Плох ли технический долг?". Для ответов на эти вопросы автор предлагает использовать maps and measures —— Competency (what) - competency matrix для сотрудников —— Performance (how) - maturity models для систем и команд —— Alignment (why) - measurable outcomes для измерения результатов команд — Org. challenges - тут речь про следующие вызовы: —— Большие проекты никогда не приоритизируются и будут выполнены примерно никогда —— KPI, OKR - когда решение становится outcome, про разделение между работой и целями и метрики, на которые напрямую не повлиять Для решения этих проблем автор предлагает использовать —— Driver trees - деревья, которые позволяют выстроить связь от "Что" до "Как" через набор драйверов, на которые мы можем повлиять —— Paths & practices - автор говорит про обучение, а также про работу над performance себя и своих команд и приводит пример с работой над улучшением работы в рамках инцидентов —— Coordinated strategy - приведено на снимке #Leadership #Management #Culture #Software

Зимние аналитические выходные (Winter Analytical Weekend) Недавно я был на первом зимнем аналитическом weekend от создателей летнего аналитического фестиваля (ЛАФ). Он прошел пару недель назад и я участвовал там в круглом столе, посвященном роли аналитика в современном мире. Основной мотив этой панельной дискуссии звучал примерно так: должен ли аналитик подстраиваться под рыночные тренды и динамику меняющейся реальности? В нашей дискуссии участвовало трое людей — Ирина Гертовская — модератор круглого стола, аналитик, консультант и соавтор профессионального стандарта РФ "Системный аналитик" 2023 года — Ирина Спицына — руководитель проектов по управлению клиентским опытом — и я Про свои мысли о вопросах круглого стола я уже писал в статье, а тут подоспели и фотографии:) #Career #Analyst #Software #SoftwareArchitecture #Architecture #Engineering

Code of Leadership #7 Your brain at Work Седьмой выпуск Code of Leadership посвящен тому, как мы принимаем решения и как работает наш мозг. В этом выпуске в гости пришел Эрнесто Инаркиев - чемпион Европы по шахматам, гроссмейстер, который входит в ТОП-100 лучших шахматистов мира и в ТОП-30 по быстрым шахматам. Эрнесто создал курс "Эффективное мышление", который я проходил в прошлом году и который мне понравился В выпуске мы обсуждаем метафоры автора книги, в которых - кратковременная рабочая память представлена сценой для актеров - префронтальная кора - это stage director - долговременная память - это члены аудитории и так далее. А также мы делимся своими историями из жизни о том, как мы сами принимаем решения и рефлексируем о способах улучшения мышления. P.S. Прошлой осенью я публиковал подборку материалов про наше мышление и мозг, поэтому если вам нравятся эти темы, то вы сможете найти там еще много интересного для изучения. #Brain #SelfDevelopment #Thinking #Management #Leadership

Мастер и Маргарита (МХАТ) Вчера со старшим сыном, который в этом году уже поступает в университет, ходили на постановку романа Михаила Булгакова. Идея сводить туда сына появилась, когда в последнем классе школы он заинтересовался гуманитарной темой и решил поступать на геймдизайн в Вышку, а также записался в театральный кружок при школе:) В общем, мы сходили на постановку и мне она понравилась - знаменитый роман выглядел классически - актеры играли хорошо - сцена была минималистична и все эффекты достигались за счет проекторов, света и железных пластин, что висели на сцене и в разное время были то страницами книги, то столбами, на которых висели приговоренные, ... В общем, ходить в театры интересно, а если ходить в них с детьми, то еще интереснее:) #Theater #SelfDevelopment

Спортивное программирование (Competitive programming 3) Мне нельзя подходить к книжным магазинам, так как я слишком легко превращаюсь в шопоголика. В итоге, я туда редко захожу, но сегодня меня позвали в гости на конференцию DevOps Conf в Сколково и уже тут я наткнулся на локальный развал книг от ДМК Пресс. В итоге, я не смог уйти без покупки и приобрел книгу по спортивному программированию:) Мне конечно уже поздно заниматься таким спортом, но почитать книгу будет интересно:) #SelfDevelopment #Algorithm #Software #SoftwareDevelopment