Карта гипотез (Рубрика #Manangement)

Наконец-то дошли руки прочитать книгу Александра Бындю про стратегическое планирование. Вообще, это уже вторая книга Александра, предыдущая называлась "Антихрупкость в IT" и я раньше про нее уже рассказывал, а потом мы с Александром записали серию подкаста "Code of Leadership", где разобрали эту книгу. В новой книге Александр рассказывает фокусно про свой метод карты гипотез, который развивает идеи метода impact mapping от Гойко Аджича. Кстати, у Гойко есть книга "Impact mapping", про которую я рассказывал раньше. Собственно, Александ творчески расширяет этот подход и предлагает следующую структуру метода, которую он раскрывает в первой части книги "Структура карты гипотез"
1) Цель - по каким критериям в конце работы мы поймем, что достигли успеха
2) Субъект - тот, чью жизнь мы хотим поменять с помощбю гипотезы, чтобы изменение привело нас к цели
3) Гипотеза - формализованная идея, с помощью которой мы собираемся изменить поведение субъекта
4) Задача - список активностй, с помощью реализации которых мы будем проверять, насколько верны наши гипотезы
Основная суть изменений между impact mapping и картой гипотез в том, что в карте основной фокус на том, чтобы через гипотезы зафиксировать ответ на вопрос а почему мы думаем, что определенные задачи приведут нас к цели. Гипотеза формулируется в виде

Если <действие1> и <действие2> ..., то <следствие>, потому что <идея>

Во второй части "Тонкости составления карты гипотез" автор подробнее рассказывает о том, что цели надо ставить по SMART, субъектов надо описывать четко, а не аморфно "все потребители", гипотезы должны быть правильные по форме, в них должен быть смысл, задачи не должны висеть в воздухе и зачастую они объединяются в цепочки для выполненияя.
В третьй части "Этапы работ с картой гипотз" автор рассказывает как ее создавать и когда стоит прекратить, а потом делится подходом к валидации карты, который позволяет понять, а не фигню ли мы сделали.
В четвертой части автор рассказывает про преимущества подхода, которые включают в себя
1) Осмысленный подход к решению
2) Стратегию в виде схем как доступный способ ее коммуникации
3) Возможность варьировать реализацию
4) Конкурентное преимущество из-за четкой и гибкой стратегии
5) Фильтр для проектов без идеи (которые любят вкидывать сверху)
6) Передачу знаний внутри компании
7) Переключения майндсета с "затрат на проекты" на "инвестиции в реализацию стратегии"

В общем, вторая книга Саши Бындю мне понравилась больше. Видно, что он он пишет сфокусированно о том инструменте, который он использовал очень часто для работы со стратегией. И этот инструмент по моим ощущениям может быть достаточно эффективным. Подробнее про карту гипотез можно прочитать на сайте картагипотез.рф

#Software #SoftwareDevelopment #Management #Processes #Strategy #Leadership #ProductManagement

Research Insights Made Simple #2 - Обсуждение paper "Defining, measuring and managing technical debt" (Рубрика #Management)

Это второй выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Дмитрий Гаевский, Technical CPO (Chief Product Owner) нашей внутренней платформы разработки Spirit. Для второго выпуска мы взяли научную статью про технический долг и то, как он влияет на продуктивность инженеров. Эта статья от ребят из Google вышла в 2023 году.

Основные материалы
- Whitepaper доступен здесь
- Мой разбор whitepaper есть в блоге

В этом выпуске мы успели обсудить темы
- Исторический контекст и метафора технического долга
- Долг или инвестиции в качество кода
- Исследование технического долга в Google
- Категории технического долга в общем
- Категории, выбранные для исследования
- Измерение технического долга
- Проблемы с метриками и целевыми состояниями
- Концепция opportunity cost
- Проблемы с термином "технический долг"
- Управление техническим долгом
- Альтернативы термину "технический долг"
- Результаты работы с техническим долгом в Google
- Объединение объективных и субъективных данных
- Проблемы разделения технической и продуктовой работы
- Альтернативные подходы к техническому долгу

#Architecture #Software #Management #Leadership #Engineering #Podcast

What Is Your Definition of Software Architecture (Рубрика #Architecture)

Пока готовился к своему выступлению на ArchDays в пятницу, наткнулся на paper почти 15-летней давности от Software Engineering Institute с названием "What Is Your Definition of Software Architecture". В нем авторы сделали подборку определений архитектуры программного обеспечения с начала времен по 2010 год. Среди определений встречаются примечательные

1) Из книги "Documenting Software Architectures: Views and Beyond (2nd Edition)", Clements et al, AddisonWesley, 2010:
The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.
2) Из книги " Software Architecture in Practice (2nd edition)", Bass, Clements, Kazman; AddisonWesley 2003, которую я перечитывал пару раз
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
3) Из стандарта ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
4) Из RUP (Rational Unified Process)
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition

В итоге, можно выделить следующие взгляды на программную архитектуру
- Высокоуровневая структура - организация системы, структурных элементов и их интерфейсов. Фокус на взаимодействии элементов
- Абстракция и композиция - архитектура представляет собой абстракцию, что скрывает реализацию. Такие абстракции позволяют проще думать о взаимодействиях компонентов. Эта тема была отлично раскрыта John Osterhout в книге "A Philosophy of Software Design", что я рассматривалась в 21 выпуске подкаста "Code of Leadership"
- Набор структур - этот набор позволяют комплексно размышлять о программной системе, в этот набор обычно включают элементы, их взаимосвязи и свойства
- Руководящие принципы - это история про governance:) Суть в том, что архитектура - это про принципы, политики, модели, стандарты. В общем, тут фокус на стратегическом роли архитектуры. Недавно я вспоминал книгу про "Continuous API Management", где тема governance была отлично раскрыта
- Компромиссы и принятие решений - это история про принятие фундаментальных структурных решений, что стоят дорого для будущего. Фокус на поиске компромиссов между функциональными и нефункциональными требованиями
- Архитектурные стили и паттерны - это практический подход, который фокусируется на выделении повторно используемых подходов к построению архитектуры. Недавно вспоминал про книгу "API Design Patterns"
- Коммуникация со заинтересованными сторонами - здесь фокус на том, что нам надо обсуждать и согласовывать архитектурные решения со стейкхолдерами для принятия дорогих решений.

В итоге, определений много и перефразируя Джорджа Бокса, все они неправильные, но некоторые полезны:)
Главное понимать их границы применимости и использовать по назначению. У меня вроде картинка за 20 лет работы в IT сложилась:)

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance #ArchBook

CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async (Рубрика #ComputerScience)

Я часто рассказываю про то, что надо знать базу для того, чтобы развиваться в software engineering. Но обычно сложно описать, а что же входит в это определение "база" и является джентельменским набором хорошего инженера. Но тут мой коллега, Женя Козлов, крутой инженер, написал серию статей про процессоры, модели памяти, многозадачность и конкурентность. В этой серии разбираются моменты, которые полезны инженерам, что делают высоконагруженные системы, которые плотно работают с данными. Собственно, сам Женя у нас лидит команду, что занимается Statist - это наша система продуктовой аналитики, которая давно заменила нам Amplitude и по всем характеристикам тянет на data intensive application. В общем, я очень рекомендую вам эту серию статей от Жени, если вам интересно понять как компьютер обрабатывает под капотом те программы, что вы пишите на своем любимом языке программирования.

1) Начальный пост про многозадачность в OS
2) Про развитие процессоров и взаимодействие OS с ними
3) Про Hyper Threading
4) Процессы. Начало
5) Процессы в Linux
6) Потоки. Начало
7) Потоки в Linux
😍 Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
9) Multiplexed IO
10) Asynchronous IO

#Software #ComputerScience #Engineering #SRE #Architecture

Code of Leadership (Рубрика #Management)

Примерно год назад я стартанул подкаст про engineering management с названием Code of Leadership. За это время получилось выпустить 21 эпизод, но я не планирую на этом останавливаться:) Подкаст доступен в Youtube и Ya Music.
Вот ссылки на материалы по каждому эпизоду:

1) Team topologies со Станиславом Халупом
2) "Antifragility in IT" с Александром Бындю
3) "Herding Cats" с Женей Кузовлевым
4) "Turn the ship around" с Екатериной Шестимеровой
5) "Project Phoenix" с Иваном Михеевым
6) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
7) "Your brain at Work" с Эрнесто Инаркиевым
8) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
9) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым

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

"Архитектура в Т-Банке: вчера, сегодня, завтра" на конференции ArchDays 2024 (Рубрика #Architecture)

Сегодня в 15.40 я выступаю на конференции ArchDays с докладом "Архитектура в Т-Банке: вчера, сегодня, завтра", в котором я расскажу про развитие подходов к проектированию и архитектуре в Т-Банке с начала времен и до текущего момента. Я постараюсь объяснить какие причины побуждали нас меняться и как мы осуществляли сами изменения. Я расскажу про процессы и людей, которые занимаются у нас проектированием и почему архитектор - это не должность, а роль. А закончу тем, что расскажу куда мы движемся дальше.

Вот дополнительные материалы для изучения, которые я рекомендую к своему выступлению
1) "Эволюция web’а tinkoff.ru за последние 3 года" (youtube) - мое выступление на ArchDays 2019, в котором я рассказываю как мы переходили от коробочного решения к собственной разработке в одном из доменов
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" (youtube, статья с расшифровкой) - мое выступление на ArchDays 2020, в котором я рассказываю про архитектурные подходы, к которым мы пришли по итогам масштабной собственной разработки и какую мы ставку делали на платформизацию
3) "DevOps-эры в Тинькофф: культура, люди, инструменты" - выступление моего бывшего коллеги Станислава Халупа на Kuber Conf 2021 года, где он рассказывал про platform engineering и почему это направления стало важным для нас (мое саммари по выступлению, само выступление на youtube)
4) "Technical Governance для IDP на 7000 разработчиков" - статья Дмитрия Гаевского про governance для нашей внутренней платформы разработки Spirit (это расшифровка его выступления на Highload++ 2021)
5) Раздел про технологии на нашем сайте - здесь можно почитать про наши платформенные решения
6) "Code of leadership #17 - Interview with Anton Kosterin about Architecture" (youtube, ya music, пост) - серия подкаста с Антоном Костериным, моим замом, который помогает мне строить architecture governance
7) "Research Insights Made Simple #1 - API Governance at Scale" (youtube, ya music, пост) - первая серия подкаста с разбором научных статей, где я с моим коллегой разбирал подход к API Governance в Google, а также мы активно проводили параллели с architecture governance в нашей компании
8) "Measuring Developer Goals" - мой обзор статьи от Google на тему того, куда стоит двигаться платформе разработки, чтобы оптимально поддерживать цели инженеров при разработке софта

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

Открытая менторинг сессия со мной на SouthHub (Рубрика #Management)

12 ноября в 19:00 я проведу открытую сессию менторинга на канале SouthHub. Менти выберут организаторы канала SouthHub, а подать заявку на участие может любой желающий. Запрос по менторингу может быть на одну из следующих тем
- Как выбрать орг. дизайн команд под задачи бизнеса: как понять, что требуется, как организовать команды.
- Как выстроить процессы в командах — discovery & delivery, архитектурные процессы и процессы обеспечения надежности.
- Как измерять эффективность процессов — какие метрики бывают и насколько им можно верить.
- Как осуществлять крупные изменения в больших компаниях.
- Как работать над техническим брендом параллельно с основной работой.

Сама сессия будет доступна в виде видео на канале SouthHub.

#Management #Leadership #Processes #Engineering #Software

Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management)

Через 3 недели я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для начинающих маркетологов. В этот список вошли
- Умение планировать свое время (а дальше если повезет и своей команды)
- Умение и желание брать на себя ответственность (и главное доводить сложные дела до конца)
- Навыки общения с коллегами и договороспособность (эта часть часто западает)
- Навыки самомотивации и мотивации окружающих (правда, если разбираться в вопросе, то внешняя мотивация - это скорее стимуляция)

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

Конференция пройдет очно 23 ноября в Пространстве Весна, Спартаковский п., 2с1. Купить билет можно здесь

#Leadership #Processes #Management

Ухожу в Stand Up! (Mastering Stand-Up) (Рубрика #Humor)

Это не утверждение, а название очередной книги, которую я дочитал буквально этой ночью. Книга попала ко мне интересным образом - пару месяцев назад меня позвали выступить на внутреннее мероприятие на всю компанию в формате стендапа. Я немного подумал над темами и выбрал одну из двух, про которые я обычно рассказываю - это была тема "Архитектуры", потому что про менеджмент шутили два других спикера. Как обычно, когда я сталкиваюсь с новой темой, то покупаю книги по ней - кажется, что еще с детства у меня пошла история о том, что получение книги == получению знаний из книги. В итоге, выступление на стендап я подготовил, но книгу прочитать не успел. Хорошо, что я заявился с этой же темой "Архитектура в Т-Банке: вчера, сегодня, завтра" на ArchDays и взял книгу в проработку. На прошлой неделе я рассказал этот доклад, а ночью дочитал последние страницы книги. Конечно, конференция по архитектуре - это не стендап-шоу, поэтому пришлось разбавлять шутки занудной теорией до гомеопатического состояния, но часть пользователей в отзывах к докладу отметила чувство юмора (ладно, это заметил один человек).

Если говорить о самой книге, то ее написал Стивен Розенфилд, основатель Американской школы комедии, который поставил обучение комиков на поток и в этой трехсотстраничной книге поделился своими рецептами становления хорошим стендапером. В книге 5 частей
1) Начинаем сотрудничать - в этой части автор подбадривает читателя и рассказывает о пути, который ему предстоит пройти, чтобы стать успешным: выясни в чем, твоя оригинальность, научись писать тексты для стендапа, отточи мастерство выступлений, придумай сценического персонажа, постоянно выступай и так далее
2) Виды стендап-комедии - здесь автор перечисляет виды, показывает примеры и объясняет разницу между ними. Например, он говорит о комедии наблюдений, сторителлинге, стендап-скетчах, акт-аутах, унижениях знаменитостей или людей из своего окружения, самоиронию, юмор на грани фола и так далее
3) Руководство по созданию материала для стендап-комедии - здесь автор рассказывает что делать до того как сесть за черновик, дальше как работать с черновиком, как обкатывать материал из него, как дорабатывать шутки формата сетап - панчлайн через фидбек аудитории на выступлениях (тут используется принцип working backwards для шлифовки и усиления шуток)
4) Руководство по выступлению со стендап-комедией - автор описывает что делать с волнением перед выступлением, как вести себя на сцене, как уложиться в регламент и что делать если шутка не зашла:)
5) Как добиваться непревзойденного мастерства - здесь автор рассказывает про классификацию шуток "A", "B", "C" и описывает как составить сет из шуток класса "А". Как создать удачный сценический образ, который должен быть оригинальным, правдоподобным, ярким, вызывать симпатию, иметь сценическое обаяние и смешную суть. Прикольно, что автор дает список причин почему шутка, которая раньше разрывала зал, стала уходить в тишину - а дальше он дает рекомендации как это можно исправить. Финалит последнюю часть автор рассказом про то, как быть ведущим и как победить свой внутренний голос, который мешает достигать своих целей (в данном случае быть смешным).

В общем, книга мне показалось интересной и полезной, даже с учетом того, что я не ухожу в StandUp!

#Humor #PublicSpeaking #Leadership #SelfDevelopment

Обзор paper "Build Latency, Predictability, and Developer Productivity" (Рубрика #Management)

Я продолжаю читать и писать о статьях из серии developer productivity от исследователей из Google. В четвертом whitepaper с заголовком "Build Latency, Predictability, and Developer Productivity" речь идет про скорость сборок и как она влияет на продуктивность разработчиков (вот мой обзор). Эта связь кажется довольно очевидной, но авторы находят очень элегантный способ для измерений. Вообще, авторы в своей статье дают ответ на следующие вопрос

- How fast do builds need to be for developers to stay productive?
- Are there changes we can make to build systems besides just “make builds faster” to improve productivity?
- And how much of a productivity improvement can we reasonably expect by improving build latency, anyway?

P.S.
Вот список статей из этой колонки "Developer Productivity for Humans", большую половину из которых я уже разобрал раньше
1) A Human-Centered Approach to Developer Productivity - разбор у меня в блоге
2) Hybrid Productivity - разбор у меня я в блоге
3) Defining, Measuring, and Managing Technical Debt - разбор у меня в блоге
4) Build Latency, Predictability, and Developer Productivity - это сегоднящняя статья
5) Onboarding and Ramp-Up
6) Measuring Flow, Focus, and Friction for Developers
7) Software Quality - разбор у меня в блоге
😍 Creativity in Software Engineering

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

Research Insights Made Simple #3 - Обсуждение paper "Security by Design at Google" (Рубрика #Security)

В третьем эпизоде подкаста мы обсуждаем интересный whitepaper "Secure by Design at Google" от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. В разборе мне помогает крутой гость - Артем Мерец, мой коллега. Артем был разработчиком и 10 лет назад перешел в информационную безопасность. Он активно строил AppSec, когда он начал зарождаться в России как стрим, а затем увлекся атаками и несколько лет ломал инфраструктуру и приложения разных компаний в России и за ее пределами. С 2021 года Артем помогает выстраивать защиту Т-Банка в роли архитектора.

Сама научная статья доступна на сайте Google, а в моем блоге есть разбор

В этом выпуске мы обсудили следующие темы
- Общие впечатления от статьи
- Логические уязвимости и подходы Google
- Сложности безопасной разработки
- Концепция Security by Design
- Примеры безопасности из автомобильной индустрии
- Проблемы аудита кода
- Принципы безопасного дизайна
- Проблемы с инвариантами
- Автоматизация и категоризация инвариантов
- Применение инвариантов
- Проблемы безопасности в системах
- Примеры защиты от злонамеренных действий
- Дизайн для безопасности
- Shift left everything в разработке
- Проблемы и решения в безопасности
- Проект Yaga в Т-Банке
- Логические уязвимости
- Безопасная экосистема разработки
- Проблемы с памятью и микросервисной архитектурой
- Проблемы с безопасностью и инфраструктурой
- История о стажере-саботажнике в ByteDance
- Контроль артефактов и безопасность
- Экосистема для разработчиков

#Architecture #Security #CI #CD #Devops #Software #Management #Leadership #Engineering #Podcast

Масштабирование комплаенс-контроля надежности на сотни сервисов - Салих Фахрутдинов, Т-Банк

Интересный доклад моего коллеги, Салиха, который Staff SRE инженер в Origination Business Platform. В этом докладе Салих рассказал о том, как можно обеспечивать надежность сотен разных сервисов за счет контроля инвариантов, который реализован через стороннее приложение. В этом приложении настраиваются различные правила для проверок, например, использование разных портов для проб (liveness, readiness, startup), настроек java приложений (падение от OOM), параметров СУБД, наличие алертов на критические SLA и так далее. Дальше эти правила можно пополнять реактивно (после инцидентов) или проактивно по результатам исследований на улучшение надежности приложений. Само это приложение собирает информацию о соблюдении правил и позволяет сформировать отчет в виде leaderboard. Те руководители, чьи сервисы оказываются внизу лидерборда, обычно имеют нехилую мотивацию на устранение найденных проблем.

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

P.S.
В software architecture такие проверки предлагается делать через fitness functions, которые предлагались в книге "Building evolutionary architecture". Вот эпизод подкаста "Code of Architecture", в котором мы говорили об этом концепте.

#Architecture #Management #Leadership #SRE #Engineering #Software

В выходные у нашего младшего сына Кирилла был день рождения, ему исполнилось 4 года. На день рождения мы придумали активность для него и всех гостей - пойти в детский клуб, где дети побесились 3 часа в сумме, причему последний час был посвящен раскаршиванию помещения и друг друга. Так у меня появилась новая красочная аватарка:)

Кем может стать системный аналитик - подкаст InSAйт (Рубрика #Career)

Недавно сходил в гости к своим коллегам на подкаст InSAйт, который ведут Павел Каравашкин, руководитель группы разработки T-API, и Есения Киселева, старший системный аналитик, управление разработки продуктов эквайринга в Т-Банке. Темой разговора было карьерное развитие системных аналитиков, о котором я когда-то размышлял на конференции Flow. В итоге, мы обсудили темы
- Почему я когда-то не захотел быть системным аналитиком, а Паша – системным архитектором;
- Можно ли одновременно сохранять фокус на менеджерских и технических скиллах;
- Кем может стать системный аналитик и какие навыки ему важно качать;
- Что такое white paper и чем этот формат может быть полезнее книг;
- Как сделать доменные области более понятными для разработчика.

У этого подкаста есть свой канал в tg (@insight_t_bank), подписавшись на который можно узнавать о новых выпусках.

#Analyst #SoftwareDevelopment #Career #Podcast #SystemDesign #SystemThinking

The Engineering Executive's Primer - Part III (Рубрика #Management)

Продолжая первые посты об этой крутой книге (0, 1, 2) с обзором книги, я хотел бы рассказать про следующие главы.

7) Participating in Mergers and Acquisitions
В этой главе автор говорит про участие ИТ топ-менеджеров в merge & acquisitions процессах. Для начала автор разбирает про сложные мотивы для m&a действий - условно цели команды, что ведет сделки, отличаются от целей инженерных команд. В общем, важен общий взгляд на процесс и понимание бизнес-стратегии, чтобы оценить соответствует ли поглощение целям компании и выявить потенциальные риски. Отдельно автор описывает структурированный подход к оценке поглощений с инженерной точки зрения, куда входит создание шаблонов для оценки сложности внедрения, проблем интеграции, масштабируемости, безопасности, соответствия требованиям, затрат и инженерной культуры. Важно также запланировать интеграции между объединяемыми компаниями - важен четкий план интеграции для эффективного управления переходом после поглощения. Это включает решения по интеграции технологий, реструктуризации команд и роли лидерства. А дальше надо управлять этим процессом.

😍 Developing Leadership Styles
Автор предлагает модель из трех подходов к управлению
- Leading with policy - для повторяемых решений, которы надо делать консистентно разными людьми внутри организации
- Leading from consensus - для нечастых решений с контекстом, который распределен между несколькими заинтересованными сторонами.
- Leading with conviction - для решений без четкого предложения, когда вовлеченные лица сильно расходятся во мнениях или когда решение оказывает значительное долгосрочное влияние на вашу организацию
В этой главе автор приводит примеры из своего опыта в разных компаниях (Digg, Uber, Stripe, Calm). А дальше говорит о том, что надо уметь работать над прокачкой тех стилей лидерства, что несвойственны вам. Это позволит вам стать более универсальным руководителем:)

9) Managing Your Priorities and Energy
В этой главе автор рассказывает про свою стратегию к решению задач вида "Компания - Команда - Я". Изначально автор рекомендовал принимать решения, основываясь на иерархии: сначала компания, затем команда, и в последнюю очередь — личные интересы. Этот подход использовался для обеспечения соответствия решений целям компании, а не личным или командным предпочтениям. Однако позже автор осознал, что такая жесткая структура может привести к выгоранию и потере мотивации среди сотрудников. Но дальше автор подчеркивается важность управления энергией как процесса с положительной суммой. Предполагается, что предоставление людям возможности заниматься работой, которая их вдохновляет, даже если она не соответствует непосредственным приоритетам, может повысить общую продуктивность и удовлетворенность работой.

В итоге, концепт "Company, Team, Self" изменяется на подход "Eventual Quid Pro Quo", которая балансирует приоритеты компании с личными потребностями в энергии. Этот подход поощряет приоритизацию вдохновляющей работы при необходимости для поддержания долгосрочной вовлеченности и эффективности. Автор подчеркивает необходимость гибкости в применении стратегий. Утверждается, что хотя следование правильным приоритетам важно, это не должно происходить за счет личной энергии и мотивации. Лидеры должны адаптировать свои подходы в зависимости от личных нужд и контекста их ролей.

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

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

DuckDB: Crunching Data Anywhere, From Laptops to Servers • Gabor Szarnyas • GOTO 2024 (Рубрика #Architecture)

Интересный доклад про аналитическую реляционную базу данных DuckDB, которую можно запускать на своем ноутбуке и успешно обрабатывать объемы где-то до 1 Tb сильно эффективнее, чем на кластере Apache Spark. DuckDB имеет полную поддержку SQL и может читать/писать такие форматы, как CSV, Parquet и JSON. Он построен в соответствии с современной архитектурой, которая позволяет выполнять сложные запросы параллельно и выгружать на диск рабочие нагрузки, превышающие объем памяти.

В этом докладе Габор, технический писатель из DuckDb, рассказывает про ключевые составляющие DuckDB и демонстрирует, как DuckDB может обрабатывать сотни ГБ данных на ноутбуке или терабайты данных на одном сервере. Основные моменты следующие

1) Демо работы с CSV файлом на 15 Gb для анализа информации о задержках прибытия поездов - в демке видно, что все работает очень быстро. В продолжении демки Габор показывает, что можно увеличить количество данных в 40 раз и дальше после 15 минут загрузки данных те же самые запросы будут уже занимать десятки секунд, но это все равно быстрее, чем грузить данные в облако и дальше выполнять их там. Потом Габор показывает как DuckDB поддерживает стандартные SQL функции вида rank over, pivot, unpivot
2) Архитектура DuckDB выглядит как single-file database:) Условно, вы взаимодействуете с ней внутри вашего приложения и отдельного сервера как такового нет. Здесь она похожа на SQLite, который похожим образом работает для OLTP нагрузок, а DuckDB предназначен для аналитических нагрузок
3) Дальше автор переходит к обсуждению хранения и обработке данных и вспоминает про строчное и колоночное хранение (row-oriented vs column-oriented)
- Транзакционные системы используют строчное хранение, а системы на основе столбцов — столбцовое.
- Столбцовое хранение позволяет эффективно сжимать данные и удалять ненужные столбцы.
- Выполнение по столбцам удобно для аналитики, но может привести к нехватке памяти.
И дальше он рассказывает про векторизацию и кеш процессора, которая позволяет обрабатывать данные векторами, что экономит память. Векторы выбираются такого размера, чтобы помещаться в кэш процессора. Вообще, векторизация кода усложняет перенос между архитектурами, но современные компиляторы автоматически векторизуют код. И в DuckDB используются zonemaps для оптимизации индексации, а также DuckDB не имеет внешних зависимостей, что делает его портируемым на разные архитектуры.
4) DuckDB поддерживает множество форматов и протоколов, включая CSV, Spark, JSON, Delta и Iceberg. Есть поддержка протоколов HTTPS, AWS S3 и Azure Blob. Существует возможность подключения к транзакционным базам данных и интеграция с Pandas и NumPy.
5) У DuckDB есть интеграция с Pandas и NumPy что позволяет читать данные без создания копий. DuckDB работает параллельно, что ускоряет чтение данных по сравнению с самим Pandas
6) DuckDB в июне выпустил обновление и достиг 19 тысяч звезд на GitHub и 30 тысяч подписчиков в LinkedIn и Twitter. Недавно вышла версия Snow Duck с акцентом на стабильность и обратную совместимость.
7) У DuckDB есть множество расширений, которые основаны на механизме для добавления новых функций, типов данных и операторов. Примеры расширений: HTTPFS, JSON, Parquet
😍 DuckDB можно использовать для сокращения расходов на облачные хранилища данных за счет выполнения части вычислений локально. Автор показал TPC-H эксперимент с обработкой Parquet файлов через DuckDB и Apache Spark. Если файл небольшой, то затраты на координацию в Spark убиывают всю производительность
9) У DuckDB есть ограничения - она не поддерживает параллельные запросы на запись, а также работает на одной ноде
10) DuckDB финансируется за счет прибыли и консультирует крупные компании, фонд DuckDB обладает правами на код, а MotherDuck сооздает облачную версию DuckDB

#Database #Architecure #Software #Data #SystemDesign