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

Дискуссия про эффективность в рамках встреч Сергея Щербинина и команды "безвотэтоговотвсего" и СРО/СТО клуба Авито (Рубрика #Management)

Уже через полтора часа в офисе Авито на Лесной начнется встреча с обсуждением хайповой темы эффективности. Для тех, кто не сможет быть лично, есть трансляция (Youtube, VK)

Приглашенными гостями будут
⁃ Влад Плющев, СТО B2C Сбера
⁃ Ярослав Тулупов, Директор по разработке Avito Pro
⁃ Илья Лосев, СТО Яндекс Crowd
⁃ Александр Поломодов, техдир Т-Банка (автор этого канала)
А модерировать дискуссию будет бессменный ведущий, Сергей Щербинин

На встрече предполагается обсудить следующие вопросы
⁃ Как управлять эффективностью команд разработки?
⁃ Что вообще блин такое эта самая эффективность в разработке?
⁃ Какими метриками должны быть обложены Discovery и Delivery, чтобы легче дышалось лидерам?
⁃ Как все это масштабировать на десятки и сотни команд?

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

P.S.
Я на тему эффективности уже достаточно много рассказывал, поэтому приведу основные посты
- Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании"
- Какие подходы были в академической среде: DORA и Accelerate, SPACE, DevEx - тезисы со ссылками на материалы доступны здесь
- Как это делают в Bigtech, например, в Google используют подход QUANTS - тезисы доступны здесь
- Что есть на рынке в виде коммерческих платформ - тезисы и ссылки здесь
- Мое выступление "Как формировать структуру команд под запросы бизнеса на YaTalks 2023", так как структура часто влияет на эффективность
- Мое выступление "Совершенствование потока разработки программного обеспечения"
- Недавние мои обзоры whitepapers от Google: обзор whitepaper "Measuring Developer Goals" и обзор whitepaper "Developer productivity for Humans, Part 7: Software Quality"

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

The C4 Model - Misconceptions, Misuses & Mistakes - Simon Brown - GOTO 2024 - Part I (Рубрика #Architect)

Очередное интересное выступление от Simon Brown, создателя C4 Model, на тему моделирования архитектуры. Конкретно в этом выступлении он выступает в качестве человека, который развеивает мифы об использовании C4 Model для этих целей. Начнем с описания того, что Simon говорит о том, что такое C4 Model

- A set of hierarchical abstractions (software systems, containers, components, and code).
- A set of hierarchical diagrams (system context, containers, components, and code).
- Notation independent.
- Tooling independent.

Суть в том, что C4 Model позволяет рассказывать разные истории разным аудиториям - автор показывает это на примере Google Maps, где мы можем от уровня всего Земного шарика спуститься до уровня Google Street View и посмотреть как выглядит наш домик:) Если же переходить к элементам C4 Model, то у нас есть системный контекст, что описывает систему и ее окружение, а контейнеры показывают технологические составляющие и их взаимодействие. А дальше автор перечисляет набор мифов и дальше разбирается с ними

- C4 Model новвая штука на рынке - нет C4 Model существует с 2007 года и обладает общирным тулингом
- С4 Model была создана для замены UML - Нет C4 не создавала как замена UML, она его дополняет структурированным подходом к созданию иерархических абстракций и диаграмм
- C4 Model стала популярна в последние 5 лет? - да, она стала популярнее после пандемии, особенно среди организаций, работающих удаленно.
- Почему Model C4 называется C4, а не C3 - Саймон считает важным, чтобы диаграммы заземлялись на реальность, а именно на компоненты и код (нижние 2 уровня)
- Синий и серый цвет в нотации скучный - Саймон говорит, что вы можете выбрать свой любимый цвет
- C4 модель может быть не ясна, если в ней много текста - Саймон рекомендует использовать много текста, который помогает передать больше информации о системе. А наличие метаданных на диаграммах помогает устранить двусмысленность и правильно интерпретировать диаграммы.
- C4 не создана для фиксации решений по архитектуре прямо на диаграммах - Саймон говорит, что их лучше описывать отдельно в виде ADR (architecture decision records), прикладывая диаграммы из C4 Model для ясности и наглядности
- C4 не содержит deployment схемы - C4 была вдохновлена UML и моделью 4+1 Филиппа Крачтена, в которых deployment схема очень важна. В итоге, вы можете при помощи C4 Model собрать свою deployment диаграмму, где будут контейнеры, системы и инфраструктура.
- Мы не используем C4 Model, так как мы используем DDD вместо этого - это просто бессмысленная штука, которая показывает, что люди, которые так говорят не шарят
- Нейминг container и component не очень хороши - да, но их лучше не переименовывать, так это запутает людей еще больше
- C4 Model is too limiting - автор показывает что 4 уровня абстракции помогают оставаться на определенном уровне абстракции. Если снять ограничение на уровни абстракций, то легко попасть в N-уровней, которые уже сложно различать даже на уровне слов. Саймон показывает пример с неймингом database - это сервер баз данных? конкретная база данных? конкретная схема? В общем, Саймон говорит, что ограниченный набор уровней позволяет внести ясность в обсуждение, а не провалиться во фрактальную история с системами, подсистемами, подпод....системами, в которых сам черт ногу сломит.
- Может добавить дополнительные абстракции? - Саймон объясняет почему следующие термины не очень хороши: подсистемы, bounded contexts, layers. Эти абстракции не добавляют пользы в диаграммах. Часть из этих терминов - это не абстракции, а элементы организации элементов

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

P.S.
Я уже рассказывал про другие выступления Саймона на тему моделирования архитектуры
- The lost art of software design by Simon Brown at Devoxx Belgium 2022
- C4 Models as Code • Simon Brown • YOW! 2022
- Continuous Architecture in Practice Eoin Woods & Simon Brown • GOTO 2021

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes

The C4 Model - Misconceptions, Misuses & Mistakes - Simon Brown - GOTO 2024 - Part II (Рубрика #Architect)

Заканчивая обзор интересного выступления от Simon Brown, я хотел бы рассказать про оставшиеся мифы и советы, которые давал Саймон своим слушателям

- Message-driven architecture и как ее отображать в C4 Model - автор рекомендует отображать не центральный Kafka брокер как контейнер, а отображать отдельные топики как containers или просто указывать их текстом на стрелках, что соединяют контейнеры с разными сервисами
- Общие библиотеки и компоненты - Общие библиотеки и компоненты часто путают, но их следует представлять по-разному. Общие библиотеки лучше изображать как компоненты C4, а не как самостоятельные приложения.
- Микросервисы - микросервисы часто неправильно моделируют как контейнеры с API и схемами баз данных. Микросервисы следует моделировать как программные системы, контейнеры или группировки контейнеров. Важно понимать, что микросервисы могут быть представлены как группа контейнеров или как отдельный контейнер.
- Закон Конвея и микросервисы - по мере роста компании и увеличения количества команд, микросервисы могут стать более сложными. Важно учитывать закон Конвея и создавать микросервисы таким образом, чтобы они были масштабируемыми и интегрируемыми.
- Контекстная диаграмма и разделение сервисов - команда создает веб-приложение, но сервисы передаются отдельным командам. Контекстная диаграмма теперь показывает сервисы как отдельные программные системы. Важно не видеть детали внутренней реализации сервисов, а использовать API.
- Масштабирование и диаграммы - при масштабирования C4 для больших архитектур появляются проблемы. Решение: создание отдельных диаграмм для каждого сервиса. Инструменты, такие как Visio, могут усложнить процесс создания диаграмм, но у C4 Model есть Structurizr
- Модели как код и структура диаграмм - при использование моделей как кода для создания диаграмм мы получаем преимущества: разделение модели на части и предоставление нескольких представлений. Недостатки: упущение общей картины.
- Интерактивные диаграммы и инструменты - интерактивные диаграммы помогают изучать сервисы и компоненты. Можно добавлять метаданные и взаимодействовать с объектами.
- Рекомендации по созданию диаграмм - Саймон предлагает фокусироваться на одной программной системе, избегать показа внешних контейнеров, чтобы избежать зависимости от деталей чужой системы. В качестве примера он показывапет использование общей базы данных как границы между системами.

В конце Саймон напоминает, что C4 Model подходит для создания иерархических абстракций и диаграмм. C4 Model независима от нотаций и инструментов.

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes

Осенняя распродажи в издательстве Питер (Рубрика #Sales)

В издательстве Питер очередная распродажа по конец сентября со скидками в 40% на бумажные книги. Для получения этой скидки надо использовать промокод "Бумажная" при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг, что еще не успел прочитать, но это не помешает мне порекомендовать их опять

- Data mesh в действии - тема очень интересна в контексте ухода от стандартного DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale" и поэтому решил почитать другую книгу:)
- Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:)
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок
- Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:)
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT и GPT-4, я ее уже прочел и даже рассказывал в отдельном посте.
- Распределенные данные. Алгоритмы работы современных систем хранения информации - в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture"
- Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу
- Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее.
- README. Суровые реалии разработчиков - книга про будни разработчиков и практиками инжиниринга, которые сейчас являются стандартом де-факто. Если книга зайдет, то дам ее почитать 18-летнему сыну, что пошел в этом году на направление геймдизайн (и наконец-то начал читать книги по программированию)
- Software: Ошибки и компромиссы при разработке ПО - эта книга подкупила меня своей второй главой, которая называется "Дублирование кода не всегда плохо".
- Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас уже начал ее читать
- Грокаем Continuous Delivery - я вроде неплохо понимаю в CI/CD, но хочется почитать про него подробнее в очень простых примерах, опять же, если книга окажется хорошей, то я смогу ее рекомендовать для начинающих (навроде, моего старшего сына)
- Грокаем функциональное программирование - лет 10 назад еще на Coursera я проходил 5 курсов по ФП, где мы разбирали Scheme, Racket, Scala и другие эзотерические языки программирования. Я так их и не ипользовал в проде, но хочется побботать их опять - вдруг я чуток лучше начну их понимать
- Дизайн для разработчиков - я довольно много книг читаю про дизайн для дизайнеров (1, 2, 3), а тут хочу посмотреть как это подают разработчикам
- Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО - в рамках работы над книгой про engineering management полезно изучить другие источники
- Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании - для инженеров и технических руководителей сейчас полезно думать продуктово, особенно если вы работаете не в галере. Яуже писал про книги на эту тему: 1, 2, 3, 4, 5
- Паттерны проектирования API - я люблю паттерны, люблю хорошие API, плюс мне понравилось оглавление.
- Чистый Python. Тонкости программирования для профи - я уже больше полугода решаю задачки на Leetcode, используя Python 3. До этого я когда-то использовал Python 2, но и тогда это был мой 3-4 язык из доступного набора по частоте использования. Именно поэтому я решил взять книгу и преисполниться python way по мере ее чтения:)

#Sales