Массовое вымирание стартапов: что происходит на глобал 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

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