Measure What Matters (Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR) - Part II (Рубрика #Management)

Продолжая рассказ про книгу Джона Дорра, что я начал в постах 1 и 2, расскажу про оставшиеся главы первой части

5) Приоритизация: Remind. Кейс с целеполаганием на платформе для учеников и учителей Remind. Рассказ от лица Бретта Копфа, сооснователя компании. OKR в компании начали использовать с самого начала работы компании и это помогло им в масштабировании бизнеса за счет фокусировки на самом главном.

6) Обязательства: Nuna. Кейс компании Nuna из сферы здравоохранения. Рассказ от лица Джинни Ким, сооснователя и CEO компании. С первого раза OKR не запустились, но потом основательница стартапа перезапустила их, показав как сначала она использует OKR, потом ее управленческая команда, а потом и все остальные сотрудники. По-факту, руководители взяли ответственность за внедрение в свои руки и у них получилось.

7) Суперсила 2: синхронизация и прозрачность. OKR позволяют синхронизировать усилия сотрудников компании - это достигается за счет комбинации постановки целей сверху-вниз и оценки возможных результатов снизу-вверх . Кроме того, с таким подходом достигается прозрачность целей в организации и возможность межфункциональной координации.

8) Синхронизация: MyFitnessPal. Кейс компании MyFitnessPal, что выпускает фитнесс приложение. Рассказ идет от лица Майкла Ли, сооснователя компании. По-факту, ребята использовали OKR у себя внутри, а потом их купила Under Armour, которая потом захотела доработок сразу по всем направлениям. Но ребята смогли показать свои планы и синхронизовать свои возможности с Under Armour, используя OKR подход. Судя по кейсу, без этого наступил бы хаос и анархия:)

9) Прозрачность: Intuit. Кейс компании Intuit, что выпускает финансовые приложения и которой больше 40 лет. Рассказ идет от лица Аттикуса Тайсена, IT-директора компании. Собственно, Аттикус рассказывает о том, как OKR позволяют сделать IT прозрачнее для компании, которая продает облачный финансовый софт.

10) Суперсила 3: мониторинг. Конечно хорошо ставить цели, но еще лучше их отслеживать и корректировать в соответствии с обстоятельствами. Для этого в компаниях обычно заводят роль координатора OKR, который форсирует следование правилам. В Google этим долгое время занимался Джонатан Розенберг, который вместе с Эриком Шмидтом, бывшим CEO Google, написали книгу "How Google Works" ("Как работает Google"), про которую я уже рассказывал. Для мониторинга целей отслеживаются ключевые результаты, которые классифицируются по трем категориям: зеленый (> 0.7), желтый (0.4 - 0.6), красный (< 0.4). Желательно, чтобы результаты были легко измеримы, но к ним можно добавить еще самооценку с ручной корректировкой результата, где надо указывать с чем связана поправка. По сути OKR ориентированы на действие и анализ результатов помогает с этим. Автор предлагает задавать такие вопросы к своим OKR
- Я выполнил все свои задачи? Если да, то что помогло мне добиться успеха
- Если нет, то какие трудности я встретил на своем пути?
- Если бы я мог переписать выполненную задачу, что бы я изменил?
- Из того, что я узнал, что могло бы изменить мой подход к следующим циклам OKR?

11) Мониторинг: Фонд Билла Гейтса
Кейс фонда Билла и Мелинды Гейтс, что посвящен реализации проектов здравоохранения. Рассказ идет от лица Билла Гейтса и Пэтти Стоунсайфер, ex-CEO этого фонда. В 2000 году Билл основал фонд с капиталом 20 млрд долларов и масштабными задачами. Для того, чтобы им управлять пригодились OKR, так как Билл в то время еще был председателем в Microsoft и ему нужно было быстро погружаться в происходящее внутри фонда.

#Management #Leadership #Processes #Engineering #Project

Software architecture 2024 O'Reilly Books (Рубрика #Architecture)

В издательстве O'Reilly выходит много книг про software architecture, которые бывает интересно почитать. И вот ребята сделали подборку на humblebundle для тех, кто хочет купить их сразу пачкой и заплатить не 1k+ вечнозеленых, а всего 25$. Если пробежаться по книгам из подборки, то там есть
- Learning Systems Thinking - судя по теме, книга должна быть очень полезной. Из того, что я читал на эту тему рекомендую Донелла Медоуз "Системное мышление" и вообще книги из списка "Книги про системное и критическое мышление", который я составлял ранее
- Building Multi-Tenant SaaS Architectures - должно быть интересная книга, так как перейти от single tenant архитектуры к multi-tenant часто бывает сложно, а по умолчанию люди проектирую часто single tenant системы. Думаю, что эта книга подсветит многие вопросы, которые надо учитывать при проектировании multi-tenant систем
- Head First Software Architecture - я такую книгу не читал, но думаю, что она может быть полезна для начинающих вкатываться в тему архитектуры
- Enabling Microservice Success - кажется, что эта книга чуток запоздала, так как многие сейчас двигаются в обратную сторону от микросервисов:)
- Serverless Development on AWS - книгу не читал, поэтому сложно сказать насколько она хороша
- Communication Patterns - эту книгу я прочитал уже на 2/3 и даже планирую обсудить ее с одним из гостей в подкасте "Code of Leadership"
- Building an Event-Driven Data Mesh - тема data mesh сейчас очень хайповая, поэтому книга может прийтись в самый раз тем, кто имеет дело с данными
- Building Evolutionary Architectures, 2nd Edition - эту книгу мы разбирали в подкасте "Code of Architecture"
- Mastering API Architecture - книгу не читал, но тема актуальная, поэтому добавил себе в список
- RESTful Web API Patterns and Practices Cookbook - книги из серии cookbook обычно бывают полезны для начинающих
- Software Architecture Patterns, 2nd Edition - это книга Марка Ричардса, которую я не читал, но зато я читал его книгу "Microservices Patterns", над которой надругались при переводе
- Foundations of Scalable Systems - эту книгу я не читал, но тема является очень актуальной для меня, поэтому добавил себе ее в список
- Software Architecture Metrics - я эту книгу читал и даже рассказывал о ней. Она является вольным дополнением книги "Building Evolutionary Architectures"
- Software Architecture: The Hard Parts - эту книгу мы разбирали в подкасте "Code of Architecture"
- Learning Domain-Driven Design - эту книгу мы разбирали в подкасте "Code of Architecture" и я отдельно написал обзор этой книги в нескольких частях
- Building Microservices, 2nd Edition - эту классическую книгу я читал уже давно, когда хайп про микросервисы только начинался
- Practical Process Automation - у меня эта книга есть в бумаге, но руки пока до нее не добрались
- Flow Architectures - у меня эта книга есть в бумаге, но руки пока до нее не добрались
- Building Event-Driven Microservices - еще одна книга про микросервисы ...
- The Software Architect Elevator - крутая книга Gregor Hohpe, про которую я уже рассказывал
- Fundamentals of Software Architecture - эту книгу я читал давно и рассказывал о ней, а в подкасте "Code of Architecture" мы разбирали ее продолжение "Software Architecture: The Hard Parts"
- Monolith to Microservices - эту классическую книгу я читал уже давно и даже рассказывал о ней раньше. Она продолжает книгу "Building Microservices"
- Technology Strategy Patterns - это крутая книга, которую мы разбирали в "Code of Architecture"
- Designing Distributed Systems - это интересная книга, которую я читал давно и про которую уже писал раньше

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

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

Code of Leadership #18 - Interview with Pavel Akhmetchanov about Processes and Tools (Рубрика #Management)

В 18 выпуске подкаста Code of Leadership (аудиоверсия в Ya Music) я беру интервью у Павла ControlChart Ахметчанова про процессы разработки и инструментарий, который позволяет эти процессы сделать проще и эффективнее как для технических руководителей, так и для инженеров.

Паша работает в компании T-Bank руководителем направления улучшения процессов разработки и создает инструменты, которые облегчают инженерам и менеджерам выстраивание процессов. Он является автором плагина jira-helper, а также продакт менеджром инструмента для коллаборативной работы https://unidraw.io . Паша является гуру Канбана (Kanban Coaching Professional) и евангелирует использование количественного анализа для улучшения процессов в бизнесе.

За время интервью мы успеваем обсудить темы
- Путь Паши в компании
- Внедрение метрик и управление процессами
- Опыт внедрения Канбан в компании и распространение знаний
- Инструменты для управления процессами: T-Meter и Plancast
- Инструменты для task tracking и knowledge database
- Инструменты для коллаборативной работы: unidraw.io
- Продуктовый подход к разработке
- Менеджмент изменений и их цикличность
- Важность эмоционального интеллекта

Напоследок, Паша рекомендовал следующие книги
- "Канбан Метод. Базовая практика" - я эту книгу читал и уже рассказывал про нее
- "Principles of product development flow", Donald G. Reinertsen
- "Forecasting and Simulation Software", Troy Maggines
- "Actionable Agile Metrics for Predictability: An Introduction", Daniel S. Vacanti
- "Sapiens" - Юваль Ной Харари
- "The Heart of Change" — Джон Коттер и Дэн Коэн

P.S.
Рекомендую попробовать наш сервис https://unidraw.io, который мы плотно обсуждали с Пашей часть интервью.
https://unidraw.io — бесплатный сервис для коллективного творчества, активно развиваемый одной из команд направления Базовых Технологий.

Сервис был создан для внутреннего использования в Т-Банк как замена Miro. Команда решила вывести сервис в общий доступ и поделиться им с пользователями за пределами Т-Банка. Unidraw.io активно развивается, и его Road Map во многом зависит от пользователей и обратной связи, которую они предоставляют. У сервиса есть свой телеграм-канал: https://t.me/unidrawio и чат в Телеграме: https://t.me/unidrawiochat.

В отличие от конкурентов, сервис предоставляется бесплатно и имеет историю версий. Также в нем присутствуют следующие функции:
- Копирование из Miro
- Шаблоны
- Фреймы, стикеры, набор базовых элементов
- Группировка
- Табличное выравнивание и многое другое.

Команда запустила FAQ прямо на доске

Road Map пока не публичен, однако известно, что команда активно работает над расширением функционала, включая:
- Увеличение количества фигур (Shapes)
- Добавление методов авторизации
- Возможность входа на доску без авторизации
- Улучшение визуального движка для коллективной работы
- Модули для презентаций
- Интеграции с различными сервисами
и другими задачами

Им можно пользоваться уже сейчас, возвращать обратную связь которая обязательно будет учтена в разработке.

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

ACM Professional Membership (Рубрика #ComputerScience)

Сегодня в день программиста (256 день в году) я оформил себе профессиональное участие в ACM (Association of Computing Machinery) за 280 долларов.
Эта подписка дает много бенефитов для continuous learning. Как минимум там есть три пункта
1) Professional Membership
Эта подписка дает доступ к печатной и онлайн подпиской на "Communications of the ACM", доступ к MemberNet, TechNews, CareerNews, доступ к ACM Career и Job Center
2) ACM Skills Bundle Add-On
Тут есть доступ к онлайн-книгам, курсам, тренировочным видео от O'Reilly, Skillsoft Percipio, Pluralsight
3) ACM Digital Library Add-On
Доступ к ACM Digital Library, в котором есть 2 миллиона проприетарных и third-party текстов, больше миллиона биографических цитат, и так далее

Чуть позже я разберусь с тем, что в реальности доступно и расскажу насколько это участие эффективно. Но если кто-то уже хочет оформить подписку, то ее оформление доступно здесь.

#Software #Architecture #SoftwareDevelopment #SystemDesign

Обзор whitepaper "Measuring Developer Goals" (Рубрика #Management)

На днях я прочитал интересную статью ребят из Google, вышедшую осенью 2024 года, в которой рассказывалось про измерение того, как software engineers достигают своих рабочих целей:) В этой статье Ciera Jaspan и Collin Green (два лида из Google) рассказывали о том, что понимание и эффективное измерение целей критически важно для улучшения опыта разработчиков и повышения их эффективности. Эта статья является продолжением первой статьи "A Human-Centered Approach to Developer Productivity", о которой я рассказывал год назад. В общем, тема для меня актуальна, поэтому я решил написать на нее обзор.

Начинается все с того, что часто требуется ответы на вопросы вида

- Как часто разработчикам приходится дебажить упавший тест?
- Как долго разработчику настроить новый сервер?
- Сколько разработчиков использует конкретный инструмент для проверки качества кода?
- Действительно ли мы улучшили способы выполнения разработчиками их работы?

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

Дальше ребята описывают свой подход к формулированию списка из 30 целей, покрывающих весь SDLC (software development lifecycle), выполнение которых можно отследить по логам инструментов, а также по ежеквартальному опросу удовлетворенности инженеров ...

А что ребята получают в результате такого подхода можно почитать в моем обзоре:)

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

A Fun & Absurd Introduction to Vector Databases - Alexander Chatzizacharias - GOTO 2024 (Рубрика #ML)

Интересный доклад про векторные базы данных для хранения embeddings, которые активно применяются в современном мире в AI приложениях:) Классно, что тут мало сложных слов и много понятных и забавных примеров для объяснения этой нетривиальной темы. Основные тезисы в докладе такие

- Все начинается с определения вектора, который является математической конструкцией, в которой определена длина и направление
- Дальше говорится о том, что векторы используются повсюду, но для ML важными вехами были
-- Word2vec - 2013 год - модели, предназначенные для получения векторных представлений слов на естественном языке (не учитывается контекст при векторизации)
-- GloVe (Global Vectors) - 2014 год - model for distributed word representation (не учитывается контекст при векторизации)
-- BERT (Bidirectional Encoder Representations from Transformers) - 2018 год - Model the learned by self-supervised learning to represent text as a sequence of vectors (учитывается контекст при векторизации)
-- CLIP (Contrastive Language-Image Pre-Training) is a neural network trained on a variety of (image, text) pairs (учитывается контекст при векторизации)
- Дальше автор переходит к обсуждению того, а что такое векторная база данных, для чего она нужна и как она работает
-- Это не general база данных - в нее не стоит сувать все подряд
-- В ней хранятся и индексируются векторы с большими размерностями
-- Данные забираются из базы с использованием Nearest Neighbor Search (NNS)
- Векторная база данных из коробки позволяет делать семантический поиск по данным, часто такие базы данных используются в качестве системы хранения для AI систем
- Индексирование в векторных базах данных очень интересно
-- Есть точные способы для поиска соседей: linear search, k-nearest neighbors, space partitioning, ...
-- Есть приблизительные способы: inverted file with flat compression (IVFFlat), locality-sensitive hashing (LSH), approximate nearest neighbors oh yeah (ANNOY), hierarchical navigable small world (HNSW), ...
-- Все эти способы используют определенные метрики расстояния/близости: euclidean distance/similarity, cosine distance/similarity, hamming distance, manhatten distance, dot product, ..
-- Вычисление дистанций и индексирование происходит в одном и том же векторном пространстве
- Сейчас очень популярна тема создания отдельных векторных баз, а также создание расширений внутри существующих (pg, redis, elastic)
- У некоторых баз данных есть встроенная функциональность, что позволяет автоматически векторизовать данные
- У большинства баз есть python клиент, javascrip клиент или REST API

У выступающего отличные демки, где он показывает как можно использовать векторные базы данных. Для этого он используют игровые визуализации на Unity, код на Kotlin и векторную базу Weaviate, которая open-source, модульная, может сама векторизировать данные, а также есть java клиент и документация. В демо используется косинусное расстояние и HNSW (hierarchical navigable small world).

Демки показывают следующие сценарии
- Векторизация названий вооружений и дальше их семантический поиск, как искал когда-то Нео в Матрице
- Векторизации заклинаний из Dungeon & Dragons и дальше их семантический поиск
- Векторизация изображений покемонов и поиск по ним
- Векторизация музыки и дальше поиск по ней

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

#Software #Architecture #DistributedSystems #SystemDesign #Database

Measure What Matters (Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR) - Part III (Рубрика #Management)

Продолжая рассказ про книгу Джона Дорра, что я начал в постах 1, 2 и 3 расскажу про оставшиеся главы первой части

12) Суперсила 4: стремление к выдающимся результатам
В этой главе появляется BHAGs (Big Hairy Audacious Goals) из книги Джима Коллинза "Built to Last" ("Построенные навечно"). Эта книга отличный пример того, как авторы подгоняют и черри-пикают данные под свои идеи:) Прочитать книгу стоит, так как на нее есть много отсылок и в ней излагается вдохновляющая чушь история, но вот ориентироваться на статистику не стоит, так как ребята не сделали поправку на ошибку выжившего.
Но Джон Дорр рассказывает про концепцию Google j разделении OKR на приоритетные и амбициозные. Приоритетные нужно достичь кровь из носу и все, что меньше 1.0 будет восприниматься как неудача. Ради попадания в приоритетные OKR можно менять план работ и перераспределять работу. А амбициозные OKR скорее отображают масштабный, рискованные и ориентированные на будущее идеи. Там работают зелено, желто, красный сфетофор, который говорит о том, что и 0.7 результата для такой цели - это ок. Здесь звучит тезис про мантру десятикратного роста, который форсирует людей думать революционно о решении задачи. Суть в том, что улучшить работу на 10% можно с помощью эволюционного инкремента, а вот достичь десятикратного роста так уже не получится, а значит придется посмотреть на проблему под другим углом.

13) Завышенная планка: Google Chrome
Кейс компании Google о том, как они запускали Chrome. Рассказ от лица Сундара Пичаи, CEO компании, который отвечал за Google Chrome во времена его запуска. Это очень интересная история о том, как Google решил сделать платформу для приложений Web 2.0 в виде браузера в самом начале пути, когда страницы научились быть динамичными при помощи Ajax. У Google Chrome были очень амбициозные цели по количеству еженедельно активных пользователей. Но ребята знали, что им нужен очень быстрое исполнение js-кода для запуска веб-приложений, поэтому они сделали движок V8, который работал на порядок быстрее конкурентов. Потом они добавили добрую щепотку рекламы (так что реклама Chrome стала крупнейшей оффлайн-кампанией в истории страны). В итоге, амбициозная цель была достигнута.

14) Завышенная планка: Youtube
Кейс компании Youtube, в котором рассказывается о переходе к количеству просмотренных часов как целевой метрике, а дальше постановке цели увеличить эту метрику в 10 раз за 4 года. Рассказ от лица Сьюзан Войжитски, что была тогда CEO Youtube, а также Кристоса Гудроу. Это очень интересная история, про которую можно подробнее прочитать в книге "Like, Comment, Subscribe: Inside YouTube's Chaotic Rise to World Domination" ("Youtube. Как самый популярный видеохостинг завоевал мир?"), про которую я уже писал

#Management #Leadership #Processes #Engineering #Project

ЦЕХ 4 - Урок #19 "Продвижение автора. Эксперт — Екатерина Северина" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела Екатерина Северина, у которой есть опыт работы PR менеджером и книжным обозревателем
Мне запомнились следующие тезисы из этой лекции:
- Есть формула бестселлера, где правильный человек в правильном месте рассказывает о правильной книге для правильной аудитории.
- В книжном маркетинге много значит сарафанное радио (как и в консалтинге)
- Личный бренд и медийность автора может помочь в продвижении книги
- Его можно развивать для создания потенциальной читательской базы, эффективно это получится сделать только, если это соответствует ценностям и желаниям автора (некоторые не горят быть публичными персонами)
- Иногда может помочь использование псевдонима - так можно вести разные проекты под разными именами и разводить разную аудиторию по разным псевдонимам
- Есть успешные авторы как с псевдонимами, так и без
- Личный бренд строится на трех китах: кто вы как автор, авторский голос и аватар.
- Если автор публичен, то ему может быть полезна контент-стратегия, которая включает регулярность, формат и каналы общения с аудиторией
- Лучше использовать свой уникальный стиль и идеи, а не копировать кого, а также надо быть упорным и терпеливым (я, например, много лет писал свои статьи в Google+ /dev/null)
- Лучше использовать не только текст, но и визуальные элементы - я персонально люблю схемы и инфографику
- Также хорошо бы смотреть на аналитику того, как аудитория принимает ваши тексты - это позволяет тестировать гипотезы и выбирать оптимальные
- Есть теория архетипов, которая помогает понять как люди реагируют на контент: познающие мир, меняющие мир, объединяющие мир и поддерживающие мир. Полезно понимать на какие архетипы вы ориентируетесь. Мне персонально ближе познающие мир и чуть меньше меняющие.
- Для продвижения своих книг можно
— Участвовать в различных мероприятиях: книжных клубах, литературных вечерах, etc
— Продвигать книги через бартер с другими авторами, а можно писать статьи для СМИ:)
— Участвовать в различных литературных конкурсах и премиях
— Вести соцсети и постить материалы, относящиеся к книге
— Организовывать встречи с читателями, проводить опросы и голосования, ...
— Взаимодействовать с книжными блоггерами (подкасты, видео, совместные посты, ...)
- Для автора важно, чтобы у него был джентельменский набор: хорошие фотографии и биография (краткая и расширенная)

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

The new Airbnb - Part I (Рубрика #Management)

Интересное интервью Braian Chesky, co-founder и CEO Airbnb, о том, как компания перешла к founder mode от стандартного мультипродуктового подхода.
Мне интервью понравилось, так как оно хорошо описывает то, что происходит в больших продуктовых компаниях - в Airbnb порядка 4к инженеров. При росте компании фаундеры отходят от непосредственного управления, нанимают мененджеров и передают им полномочия. В какой-то момент внутри компании появляется куча отдельных продуктовых направлений со своими mini-CEO, которые развивают эти продукты в свою сторону. И это приводит к проблемам
- Разные группы внутри компании могут работать на разных технических платформах, которые переизобретают по четвертому разу колесо, что приводит глобально к накоплению технического долга.
- Зависимости между командами могут создавать проблемы и бюрократию
- Отсутствие подотчетности и большая степень автономности подразделений могут привести к потере фокуса:)

В 2022 году Airbnb пережил кризис и Брайан фундаментально поменял схему управления компанией
- В основе лежит идея, что основатель и CEO должен быть главным специалистом по продуктам в продуктовой или технологической компании.
- Для управления продуктом Брайан решил использовать инструмент для определения приоритетов и составления дорожных карт - Jira Product Discovery, который позволяет собирать все идеи о продукте в одном месте и расставлять приоритеты
- В компании убрали функцию управлению продуктом, но людей, что ее исполняли оставили. Уменьшили количество отдельных групп, но сделали их более продвинутыми
- Функции по управлению продуктом разъезхались в две стороны: маркетинговая и инженерная
- Основная идея разделения была в том, что вы не сможете создать продукт, если не будете знать, как говорить о нем.
- В итоге, маркетинг и продуктовая стратегия объединились:
-- Маркетинг эффективности хорош для балансировки спроса и предложения, но не создает накопительных преимуществ.
-- Маркетинг как образование: рассказывать людям об уникальных преимуществах продуктов.
-- План действий на два года вперед, обновление дорожной карты продуктовой стратегии каждые шесть месяцев.
-- Продакт-менеджмент занимается маркетингом продукции, выясняет, как люди узнают о продуктах, делает демонстрационные ролики, работает над историей и активами.
- Брайан упоминает про эксперименту (a/b тесты), отмечая, что просто так их гонять бесполезно - в основе тестов должны лежать гипотезы, а так должна быть целостная система метрик для измерения результатов (у ребят в Airbnb высокая культура и хороший тулинг для a/b тестирования)
- Брайан рассказывает про проблемы делегирования и то, что CEO должен иметь четкий vision того, что делает компания

Продолжение обзора интверью во втором посте.

#Management #Leadership #Processes #Engineering #Project #Software #Design #ProductManagement #BusinessStory

The new Airbnb - Part II (Рубрика #Management)

Продолжение обзора интересного интервю Braian Chesky, co-founder и CEO Airbnb, о том, как компания перешла к founder mode от стандартного мультипродуктового подхода. В этой части подробнее про саму трансформацию управления в компании и напоследок советы от Брайана на тему саморазвития.

- В 2022 году ребята вернулись к основам и CEO погрузился в детали
-- Они сократили количество проектов, убрали уровни управления и перешли к функциональной модели.
-- Они также сократили количество сотрудников и сделали каждого руководителя экспертом в своей области (а не просто people manager)
-- Они провернули изменения с продуктовой и маркетинговой функцией
-- Само создание продукта было делегировано в program managers, которые и до этого управляли разработкой. По-факту, они взяли на себя работу с командами разработки по созданию того продукта, что нащупала маркетинго-продуктовая функция
-- Они создали внутреннее креативное агенство и объединили функции UX и написания текстов
- Все эти изменения привели к тому, что потребовался поиск компромисса между тем, как основатель хочет управлять компанией и тем, как сотрудники хотят управлять компанией.
- Брайан считает, что все хотят ясности и быстрого движения в одном направлении, и что
-- Основатель должен вовлечен в разработку продукта и быть экспертом в своей области, а также знать о том, что делают его сотрудники
-- Каждый менеджер по продукту должен быть взаимосвязан и знать, что делают другие.
-- Engineering и дизайн должны быть взаимосвязаны, и каждый менеджер по продукту должен быть специалистом в своей области.
- Дальше Брайан рассуждает о целепологании и что постановка амбициозных целей может помочь командам мыслить масштабно и находить решения для проблем.
- Также важно проявлять лидерство и мотивировать команды, чтобы они могли достичь своих целей. Важно видеть в них потенциал, который они не видят в себе.
- Важно создать организацию, ориентированную на рост, где чем больше ты участвуешь, тем больше ты веришь в себя и видишь в себе больше потенциала.

Дальше Брайан рассказывает о том, что он
- Не является образцом баланса между работой и личной жизнью. Но он старается поддерживать здоровые отношения, заниматься спортом и питаться здоровой пищей.
- Старается поддерживать отношения с друзьями и выделять время на встречи с ними
- Старается поддерживать баланс за счет определения приоритетов и четкого "нет" тем вещам, что не имеют значения
- Старается оставаться новичком и смотреть на мир глазами ребенка и что ему все еще нужно многое доказать и преодолеть некоторые рубежи знаний.
- Не стесняется обращаться за помощью к другими людям и оказывать ее сам

В самом конце интервью Брайан рассказывает о себе и как он от увлечения искусством, архитектурой и промышленным дизайном пришел к созданию Airbnb, который поменял мир путешествий:)

#Management #Leadership #Processes #Engineering #Project #Software #Design #ProductManagement #BusinessStory

Обзор whitepaper "Developer productivity for Humans, Part 7: Software Quality"

На днях я прочитал интересную статью, вышедшую в начале 2024 года, в которой рассказывалось про измерение того, как software quality связано с продуктивностью разработчиков:) В этой статье Ciera Jaspan и Collin Green (два лида из Google) рассказывали о том, что для холистического измерения продуктивности надо обращать внимание на speed, ease и quality для того, чтобы не получить кратковременные улучшения за счет долговременного негативного влияния как например

After all, we can easily increase velocity…by removing code review or test suites.

А дальше ребята фокусируются на теме качества, которая затрагивает процессы, код, систему и продукт целиком. Мне эта тема очень близка, так как она очень тесно пересекается с архитектурой и архитектурными характеристиками систем, которые часто называют атрибутами качества:) В итоге, мне подход авторов очень понравился, как понравиились и выводы, поэтому я решил сделать обзор этой статьи.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes #Quality

Measure What Matters (Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR) - Part IV (Рубрика #Management)

Продолжая рассказ про книгу Джона Дорра, что я начал в постах 1, 2, 3 и 4 я расскажу про вторую часть книги "Новые методы работы"

15) Непрерывное управление производительностью: OKR и CFR
В этой главе авторы предлагают замену стандартным подходам к управлению производительностью. Условно, автор предлагает заменить ежегодное performance review на CFR (conversations, feedback, recognition). Суть в том, что люди работают над своими целями круглый год, поэтому кажется, что и работа с эффективностью сотрудников должна идти непрерывно. Суть этого CFR примерно такая
- C (conversations) - обсуждения: искреннее, насыщенное и хорошо структурированное общение между менеджером и сотрудником, призванное повысить результативность работы
- F (feedback) - обратная связь: двустороннее и взаимосвязанное общение между коллегами ддля того, чтобы оценить прогресс и наметить будущие улучшения
- R (recognition) - признание заслуг достойных сотрудников за их вклад любого масштаба
Как по мне перечисленное в этом подходе уже стало базой, поэтому не ясно в чем инновация подхода
16) Избавляемся от ежегодных проверок производительности: Adobe
Пример Adobe, где они ушли от ежегодных review к непрерывным. Интересен только момент, что ребята ушли от формальной оценки и ранжирования сотрудников. Менеджер сам определяет размер зарплаты и доли в компании ежегодно в зависимости от результатов работы. В общем, тут как обычно за общими фразами сложно понять действительную реальность того, что было и стало.
17) Вкуснее с каждым днем: Zume Pizza
Пример пиццерии, что применяла OKR и CFR прямо с первого дня. Как по мне пример слабоват:)
18) Культура
Глава начинает с фразы Питера Друкера о том, что культура съедает стратегию на завтрак. В итоге, для того, чтобы добиваться высоких целей надо уметь создавать культурные ценности и защищать их по мере роста компании. OKR помогает тем, что это надежные хранилища для лидерских приоритетов и убеждений, а CFR обеспечивают их распространение. В этой главе опять идут отсылки к Энди Гроуву, который был примером высочайших культурных стандартов Intel. Другой пример отсылает к проекту "Аристотель", в котором ребята в Google пытались понять что делает команду эффективной. Кстати, я уже рассказывал про это исследование. В общем, автор делает вывод, что

OKR и CFR обеспечивают синхронизацию сверху вниз, объединяют команды и гарантируют автономность и вовлеченность снизу вверх: это столпы любой живой, ценностной культуры

19) Преобразование культуры: Lumeris
Пример того, как M&A медицинской компании привел к тому, что пришлось делать трансформацию двух компаний и фактически определять культуру. Формально компания пыталась запустить OKR, когда была в таком шизофреническом состоянии, но у нее не получилось. Потом было принято решение об HR-трансформации, создании новой компании под одним брендом и дальше с этими преобразованиями отлично зашел OKR
20) Изменение культуры: Боно, ONE Campaign
Пример того, как звезды могут заниматься благотворительностью. Конечно в книгу он попал из-за громкого имени артиста ...
21) Задачи на будущее
Глава начинается с того, что идеи придумать не сложно, но сложно воплотить их в жизнь. А OKR и CFR помогают как раз с этим. Автор предлагает думать о них, как о стартовой платформе для предпринимателей и новаторов. Автор продолжает свою работу над OKR и узнать про нее можно на сайте WhatMatters.com
22) Посвящение - автор рассказывает про тренера Билла Кэмпбелла - подробнее про него можно узнать в статье в Forbes

Ну и в конце автор в приложениях приводит отцензурирование документы Google про OKR
- Google: стратегия и тактика OKR
- Примерный цикл OKR
- Обсуждаем качество работы
- Резюме

#Management #Leadership #Processes #Engineering #Project

Message from Amazon CEO Andy Jassy: Strengthening our culture and teams (Рубрика #Management)

Интересная записка от CEO Amazon на тему усилиения культуры компании и команд. Если говорить кратко, то заметка кажется интересной для больших организаций, которые за время пандемии набрали много людей и перешли на гибридный подход к работе. Amazon проанилизировал эффективность работы и принял решения об
1) Уменьшении уровней в оргструктуре за счет сокращения процента менеджеров по отношению к individual contributor
2) Переходу на пятидневную рабочую неделю в офисе вместо трех дней в офисе и двух дней удаленно

Если разбирать тезисы заметки подробнее, то
- Andy отмечает, что часть устоявшихся направлений развиваются эффективно Stores, AWS, Prime Video, как и часть новых: GenAI, Kuiper, Healthcare
- В этом развитии важную роль играет кульутра компании и поддержание и развитие культуры является топ приоритетом для топ-менеджеров
- Andy говорит, что "We want to operate like the world’s largest startup", а это раскладывается в
-- Constantly inventing for customers
-- Strong urgency (for most big opportunities, it’s a race!)
-- High ownership
-- Fast decision-making
-- Scrappiness and frugality
-- Deeply-connected collaboration
-- Shared commitment to each other

У топ-команды было два вопроса, над которыми они думали в последнее время

1) Do we have the right org structure to drive the level of ownership and speed we desire?
2) Are we set up to invent, collaborate, and be connected enough to each other (and our culture) to deliver the absolute best for customers and the business that we can?

Оба вопроса привели к идеям о том, как улучшить оргструктуру и совместную работу

1) Оргструктура
По поводу оргструктуры Andy говорит, что за годы непрерывного роста и найма умных и квалифицированных людей появилось много менеджеров, которых нанимали для организации процессов работы, что привело к сайд эффектам вида

- Pre-meetings for the pre-meetings for the decision meetings
- A longer line of managers feeling like they need to review a topic before it moves forward
- Owners of initiatives feeling less like they should make recommendations because the decision will be made elsewhere
- ...

Но эти решения по структуре команд обычно были two-way doors (обратимыми), поэтому сейчас оргструктуру решено менять в сторону более плоской. Цель выглядит примерно так
So, we’re asking each s-team organization to increase the ratio of individual contributors to managers by at least 15% by the end of Q1 2025.

Эта реорганизация, выполненная верно, должна привести к следующим результатам
- Increase our teammates’ ability to move fast
- Clarify and invigorate their sense of ownership
- Drive decision-making closer to the front lines where it most impacts customers (and the business)
- Decrease bureaucracy
- Strengthen our organizations’ ability to make customers’ lives better and easier every day.
Энди даже завел специальный Bureaucracy Mailbox, куда можно присылать примеры бюрократии и ненужных процессов.

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

We continue to believe that the advantages of being together in the office are significant ...
We’ve observed that it’s easier for our teammates to learn, model, practice, and strengthen our culture; collaborating, brainstorming, and inventing are simpler and more effective; teaching and learning from one another are more seamless; and, teams tend to be better connected to one another

#Management #Leadership #Processes #Bigtech #Software