Книга “На пике” за авторством Брэда Сталберга и Стива Магнесса посвящена тому, как поддерживать максимальную эффективность без выгорания. Она состоит из трех частей, девяти глав, предисловия, введения и заключению.
В предисловии авторы делятся своими историями, когда они были на пике: один как подающий надежды бегун, который в юношестве выиграл национальную гонку в своей возрастной категории, а второй как перспективный молодой консультант, которого пригласили работать над государственным законопроектом.
Правда, этот пик стал профессиональной вершиной как для бегуна, так и для адвоката — они выгорели и не смогли поддерживать этот уровень эффективности. После этих событий прошло пару лет, дальше авторы познакомились друг с другом и сошлись на почве исследования эффективности, в результате чего появилась эта книга.

Подробный обзор по ссылке - https://apolomodov.medium.com/review-peak-performance-53940a4395cb

#PopularScience #Motivation #Performance #ExternalReview

Вчера я дописал статью, в которой рассказываю о том, как у меня в комадах разработки был выстроен привычный уже всем процесс performance review:)
Я принес его в свои команды порядка 5 лет назад, но тогда я еще не вел Medium или tg, поэтому поделиться им было негде. Интересно, что тогда этот процесс еще не был принят у нас во всей компании. А мне он был нужен для повышения эффективности моих команд, а также для мотивации и объяснения моим разработчикам того, как они могут расти у нас в компании. Интересно, что около трех лет назад я рассказывал на конференции как у меня в привлечении Tinkoff была выстроена часть с наймом и мотивацией сотрудников, где я достаточно подробно рассказывал про performance review как часть этих процессов. В статье я привел ссылку на видеозапись и сделал текстовую расшифровку части про review.

https://apolomodov.medium.com/performance-review-basics-20793141f4c5

#Software #Management #Performance #Processes

Visualizing Performance - The Developers’ Guide to Flame Graphs • Brendan Gregg • YOW! 2022

Интересный доклад про визуализацию производительности при помощи Flame graphs от Brendan Gregg, который их когда-то и придумал. Помимо этого он придумал еще и USE методологию (utilization, saturation и errors). Конкретно в этом докладе Грегг рассказывает про
1. Какие существуют реализации flame graphs
2. Как работают flame graphs для профилирования использования CPU и как он дошел до их изобретения (spoiler: через flame charts)
3. Какие были проблемы со стеками и символами - тут Грегг делится тем, что пришлось доделывать в gcc, java, jit symbols, чтобы стеки в профилировщике работали правильно
4. Куда еще можно вкрутить flame graphs для улучшения визуализации - например, page faults, disk i/o requests, tcp events, cpu cache misses, ...
А еще чем так хорош eBPF для отслеживания проивзодительности:)

В общем, это полезный доклад, даже если вам не часто приходиться заниматься оптимизацией проивзодительности приложения:)

P.S.
А еще у Грегга есть крутая книга "Systems Performance (Addison-Wesley Professional Computing Series) 2nd Edition", но я ее пока не читал:)

#Performance #Software #SoftwareDevelopment #SystemDesign

Developer productivity - Part I

В большой компании часто сложно понять насколько эффективно работает организация. Конечно можно ориентироваться на разные финансовые показатели, включая Cost to Income Ratio, но у них есть две особенности: они очень общие и сложно понять вклад отдельных частей организации, а также они сильно запаздывают во времени. Поэтому менеджеры высокого уровня обычно желают получить более эффективный инструмент. Когда я думал над этим, то понял, что мне удобнее сначала построить модельку и сузить область размышлений. Я взял модель Run-Change-Disrupt
- Run - это операционные процессы того, как мы делаем business as usual
 - Change - это те процессы, которые направлены на изменение ситуации: создание новых продуктов, развитие существующих продуктов
 - Disrupt -это процессы, связанные с внутренними стартапами, новым бизнес-моделям и трансформациями

Для системных улучшений мы должны работать в каждой области, но сегодня я хотел сфокусироваться на Change. Причем если компания является продуктовой, а не сервисной, то в свою очередь продуктовый процесс тоже разделяется на две части
 - Do the right things - это часть про бизнес и процесс discovery
 - Do the things right - это часть про разработку и процесс delivery

Причем сегодня я хотел обсудить часть delivery, где мне кажется, что обычно практикуют два дуальных подхода к повышению эффективности поставки ценности.

1) Bottom-up - улучшение процессов команд на местах силами линейных менеджеров. Дальше улучшение общих процессов подразделения силами middle менеджеров. Общий драйв к лучшему от топ-менеджеров. Для такого подхода в компаниях часто используются инсутрменты для статистического управления процессами. Этот подход напоминает то, как работает микроэкономическая теория для отдельного предприятия на рынке. То есть руководитель каждой команды сам отвечает за то, чтобы она эффективно работала в условиях спроса и предложения на рынке, внутренних процессов команды, цепочки взаимосвязей с другими командами и так далее.

2) Top-down - улучшение процессов за счет изменения глобальных параметров системы:
 - Создание PaaS и большого количества платформенных команд
 - Выделение функции SRE и системная работа над надежностью
 - QA-стратегия, где фокус на автоматизации
 - Data-стратегия и переход к DWH к Data Mesh
- Активное использование AI к месту и нет
Для таких больших изменений топ-менеджент обычно хочет понимать централизованный эффект, а также в идеале хочет уметь его моделировать. Это чем-то напоминает макроэкономическую теорию и роль государства в ней, которое может влиять на рынок через ставку рефинансирования, налоги, гостраты и так далее. Модели для сбора "макроэкономической статистики" по delivery часто у компаний нет, если не считать отдельные показатели с микроэкономического уровня, которые впрямую нельзя сравнивать и зачастую агрегировать. Но зачастую хотелось бы иметь показатель developer productivity и уметь на него влиять в положительную сторону.

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

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Developer productivity - Part II

Продолжая тему developer productivity, поднятую в первой части статьи, хотелось вспомнить о том, а как к этому вопросу подходят во всем мире.

"Accelerate" и DORA метрики
- Книга вышла в 2018 году и ее написали  Forsgren, Humble, Kim.
- Все содержимое книги основано на опросах инженеров aka Devops Reports, что собирались пять лет примерно с 2012 года
- DORA метрики  состоят из  двух категорий:
-- Темп поставки: deployment frequency и lead time for changes
-- Стабильность: change failure rate и time to restore service
- В общем, эта фундаментальная история, которую хорошо бы знать. И у меня есть краткое саммари книги в трех частях: 1, 2 и 3

Фрейворк из whitepaper "The SPACE of Developer Productivity"
- Научная статья вышла в марте 2021 года и ее написали Forsgren, Storey Zimmermann, Houck, Butle
- В этом фреймворке пять категорий метрик, что объединяются в акроним SPACE (Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow), каждый из которых раскладывается на 3 уровня (индивидуальный, командный, e2e)
- Интересно, что тут у нас уже комбинация метрик из опросов (satisfaction & well being) и метрик из процессов. Потенциально тут можно получить достаточно полную картину, но надо очень тщательно работать с данными и их интерпретацией
- Есть краткое саммари от меня

Фреймворка из whitepaper "DevEx: What Actually Drives Productivity"
- Научная статья вышла в мае 2023 года и написали ее Noda, Storey, Forsgren, Greiler
- В этом фреймворке три категории: feedback loops, cognitive load, flow state
- Каждая категория раскладывается на три части: perceptions, workflows (system & process behaviors) и KPIs (north star metrics)
- Авторы отмечают, что часть про perceptions можно вытащить только из опросов, а вот workflows надо тянуть из самих систем. А дальше они съезжают в часть дизайна опросов.
- Два из соавторов этого whitepaper представляют платформу DX (getdx.com), чей инструмент devex360 даже попал в техрадар от ThoughtWorks в сентябре 2023 года и эта платформа основана на опросах
- Есть краткое саммари от меня

Развитие фреймворка DevEx (DevEx in Action)
- Научная статья вышла в январе 2024 года и ее написали Forsgren, Kalliamvakou, Noda, Greiler, Houck, Storey
- Этот whitepaper продолжает "DevEx: What Actually Drives Productivity"
- Категории все те же
- В этой статье проведен статистический анализ результатов опросов на платформе getdx.com, которую используют разные компании для проведения опросов по developer exp (примеры компаний: Etsy, Dropbox, Ebay, Amplitude, Monzo, P&G, DHL, …)
- Цель выяснить того, как каждая из трех категория влияет на outcomes трех уровней: individual, team, organization. Цель была достигнута и влияние продемонстрировано и это очень полезно для продаж платформы:)
- Есть краткое саммари от меня

А в последней части этой статьи я расскажу про платформы на рынке и то, что у нас есть в Тинькофф:)

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Developer Joy – How great teams get s%*t done - Sven Peters - NDC Porto 2023 - Part II

Начало обзора этого выступления есть в первом посте. А здесь надо еще расскаать про использование регулярных опросов разработчиков, чтобы узнать их мнение о различных аспектах работы. Результаты опроса помогают определить области, требующие улучшения и обсудить их с командой. В Atlassian команды используют 10% времени для исправления ошибок и улучшения производительности разработчиков. Некоторые команды проводят "week of developer joy", а другие включают планирование в спринт и работают над проблемами производительности. А также команды распространяют знания и делятся с коллегами полученными выводами - например, команда создала пост в блоге о своем решении проблемы и его использовании в других командах.

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

P.S.
На похожую тему я размышлял в постах про developer productivity: 1, 2 и 3.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Architecture Modernization: Aligning Software, Strategy, and Structure - Nick Tune

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

Architecture Modernization is about converting architecture from a competitive disadvantage to a competitive advantage.

И дальше его подход содержит три пункта
1) Architecting for flow - проектирование для улучшения потока создания ценности и взаимосвязи изменений
2) 5 Essential tools for architecture modernization - инструменты для модернизации архитектуры
3) Kickstarting and enabling architecture modernization - как начать модернизацию

В первой части автор говорит про stream-aligned команды из team topologies, которые формируют вокруг value-stream. Отдельно надо отметить, что иногда между системами команд бывают зависимости, которые влияют на flow. Поэтому все и мечтают создавать автономные команды (про это было много в докладе, о котором я рассказывал вчера):)

Дальше спикер говорит про fullstack модернизацию по всем уровням

- User interface - modernize the UI to enable a better UX improving user happiness and productivity
- Software - modernize tech and alignment to domain model for code that is easier to understand and evolve.
- Domain model (conceptual) - modernize the conceptual domain model, creating a better shared understanding and language improving collaboration & innovation
- Domain - modernize the domain by adding new and better capabilities which create new business and customer value.

Дальше речь идет про инструменты:
1) Активное слушание - оно помогает понять бизнес-цели и проблемы заинтересованных сторон
2) Impact mapping - в этом подходе создается связка: strategic business objectives - actor - impact - deliverables. Подробнее можно почитать в книге "Impact mapping", про которую я писал раньше
3) Wardley mapping - здесь компоненты архитектуры связаны с цепочкой создания ценности, а также стадиями жизненного цикла продукта. Интересная концепция, про которую я узнал впервые и которую можно использовать для определения текущего состояния и эволюции компонентов архитектуры.
4) Event storming - это интересный подход lkz проведения воркшопов для коллаборативного изучения сложного бизнес домена ... Подробнее можно прочитать в моем посте
5) Modernization strategy selector - график для обсуждения вариантов модернизации через раскладывание по осям platform modernization и product, domain, software modernization
В конце перечисления автор еще вспоминает CodeScene - инструмент для поведенческого анализа кода.

Дальше автор рассказывает, а с чего стоит начать модернизацию и показывает матрицу 2x2 (риски - эффект). В итоге, у нас есть
1) "низковисящие фрукты" (риск небольшой, а эффект значительный)
2) проекты, для тех, кто уклоняется от риска (риск и эффекты незначительные)
3) проекты, для тех, кто готов к большим ставкам (риски и эффекты большие)
4) "последняя паста в тюбике" (рисковые проекты с низким эффектом) - такими часто вообще не занимаются никогда:)

В итоге, надо сорвать низковисящие фрукты и выдать результаты в первые 3 месяца - полгода, но продолжать работу над крупными изменениями параллельно. Во время модернизации стоит сделать команду поддержки для процесса модернизации, но потом ее надо вовремя распустить. Отдельно стоит отметить, что у успешной компании есть свои плюсы и минусы, такие как сложность и унаследованные процессы, но это цена успеха. Зато у стартапов таких проблем нет и они могут внедрять инновации быстрее. Также модернизация должна быть больше, чем просто техническое усовершенствование, и что технология сама по себе не решит все проблемы. Ну и финально спикер выступает капитаном очевидность и говорит о том, что важно не переоценивать инвестиции в неправильные области и не недооценивать их в нужных областях.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

Let's talk about DX, Baby! - Jo Franchetti - NDC London 2024

Этот доклад Джо Франкетти на конференции NDC {London} 2024 посвящен теме developer experience (DX, DevEx), по которой относительно недавно вышло несколько whitepapers. Эта тема мне импонирует, поэтому я расскажу кратко о чем была речь в этом докладе:
- Автор рассказывает про важность DX, рассказывая историю о разработчике, который столкнулся с трудностями при интеграции нового инструмента.
- Из этого выводятся три составляющие подхода DX: cognitive load, flow state и feedback loops
-- Когнитивная нагрузка - это объем информации, который разработчик должен обработать для выполнения задачи.
-- Состояние потока - это состояние ума, когда человек полностью погружен в свою деятельность и чувствует себя мотивированным и эффективным.
-- Циклы обратной связи - это скорость и качество ответной реакции на произведенные действия
- Дальше звучит тезис о том, что если работать над улучшением опыта разработчика, то это может снизить когнитивную нагрузку и повысить продуктивность.
- Для попадания в состояние потока нам нужна среда, где есть баланс между уровнем мастерства и задачами, которые ставятся перед разработчиками. Это позволяет разработчикам чувствовать, что они контролируют процесс и могут использовать инструменты.
- Циклы обратной связи позволяют разработчикам получать информацию о том, правильно ли они выполняют задачи и где они испытывают трудности (условно запуски CI/CD с прогоном тестов дают полезную обратную связь, но если мы ее ждем часами, то мы теряем в эффективности)

- Для измерения и оценки изменений можно использовать опросы (NPS, CSAT), оценку качества кода (code complexity, code coverage, number of bugs, number of issues), developer productivity (тут мерить можно по разном), development lifecycle
- Дальше автор предлагает разделять Internal DX и External DX
-- Internal DX - тут фокус на улучшении продуктивности, выравнивании с бизнес-целями
-- External DX - тут фокус на adoption rates, вовлечении коммьюнити и промотировании продукта более широкой аудитории
- А дальше автор показывает гигиенические факторы при создании репозиториев с кодом:
-- Соблюдение стандартов кодирования
-- Использование dev контейнеров и codespaces
-- Избегание глобальных настроек
-- Создание всеобъемлющего readme, включающего введение, цели, задачи, ключевые особенности, использование, настройку, ограничения, рекомендации по внесению изменений, контактные данные, кодекс поведения, лицензию.Грамотное написание технических текстов, понимание аудитории, создание образа читателя.
-- Создание понятного кода - функций без побочных эффектов, функций с меньшим количество аргументов, promises over callbacks, ранний возврат из функций, etc. Важно отслеживать читаемость кода, так как большую часть времени мы поддерживаем уже созданный код, а не создаем новый. Сложный код увеличивает когнитивную нагрузку и ухудшает developer experience

В конце автор призывает к улучшению опыта разработчиков и призывает к обсуждению и обмену мнениями о том, как сделать код более понятным и удобным для чтения.

P.S.
Я уже писал на тему developer productivity и developer experience несколько статей
- В общем про подход к теме developer productivity
- Обзор whitepapers
- Обзор доступных коммерческих платформ

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Доклад про инженерную продуктивность на конференции MTS True Tech Day (Рубрика #Management)

Сегодня на главной сцене конференции от MTS я буду выступать с докладом про developer productivity. У этой конференции интересный слоган: "код науки и технологии", который мне понравился. Мое выступление у меня будет отчасти экспериментальным, так как часть доклада мне придется рассказывать в формате стендапа без слайдов (не уложился в дедлайн их отправки).

Update: ребята успели зарелизить все слайды и рассказ вышел полноценным и без экспериментов. Респект команде МТС!

У меня есть полная версия со всем визуалом и расшифрокой в виде статьи в моем блоге. План выступления примерно следующий
- Затравка про важность этого вопроса
- Как я предлагаю сузить границы рассмотрения только продуктовыми компаниями и частью delivery без discovery
- Какие подходы были в академической среде: DORA и Accelerate, SPACE, DevEx - тезисы со ссылками на материалы доступны здесь
- Как это делают в Bigtech, например, в Google используют подход QUANTS - тезисы доступны здесь
- Что есть на рынке в виде коммерческих платформ - тезисы и ссылки здесь
- Как это делаем мы в Тинькофф - тут я расскажу про наш инструмент T-Meter
- Ну и какие выводы из этого всего следуют

P.S.
Так как мой доклад - это не питчинг раунда финансирования для стартапа, то я решил исключить часть про влияние AI на developer productivity, что тянет на отдельный доклад (который недавно как раз рассказывал VP of Product из GitHub)

P.P.S
Получить достууп к трансляции можно так
- создать аккаунт здесь https://lk.truetechday.ru/login
- перейти на страничку https://lk.truetechday.ru/broadcast и выбрать интересующий трек (рекомендую в 14.15 открыть главный зал)

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership