Как делать полезные заметки (How to take smart notes, Zettelkasten) - II

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

Часть 2 - Четыре основных принципа
5) Письмо - единственное, что имеет значение
В этой главе автор говорит про написание научной работы студентами. Причем студентам надо не просто научиться писать, но и "уметь искать факты, обсуждать свои идеи на семинарах и внимательно слушать лекции". И дальше выдвигается тезис о том, что правильный учебный процесс - это исследование и если учиться как можно эффективнее, то можно ускорить переход к моменту, когда появятся вопросы, на которые еще нет ответов и о которых и стоит писать научные работы:)
6) Простота превыше всего
В этой главе автор рассказывает про контейнеры и контейнеровозы, которые продвинули морские перевозки, а дальше сравнивает ящик для заметок транспортрным контейнером мира науки. Он позволяет напомнить владельцу об идеях, которые когда-то были им сформулированы, но потом забыты. Для проявления положительного эффекта в ящике должна накопиться критическая масса заметок, которые бывают трех видов:
- Повседневные заметки - напоминание об информации, их TTL (time to live) пара дней
- Постоянные заметки - TTL - ∞, они содержат необходимую информацию в постоянно доступной форме
- Заметки для проекта - заметки под конкретный проект, после окончания проекта они могут превратиться в постоянные заметки или отправиться в /dev/null
Важно понимать различие заметок разного типа и использовать их в подходящих сценариях.
7) Никто никогда не начинает с нуля
Основная мысль в том, что если вести заметки по интересующим темам, то при старте нового проекта всегда будут материалы, от которых можно будет оттолкнуться. Поэтому написание научных работ, статей, книг не является линейным процессом, но это не означает, что оно хаотично. Напротив, ясная и четкая структура имеет большое значение.
😍 Пусть работа ведет вас вперед
Здесь автор говорит про петлю обратной связи, которая может как порушить все начинания (если вы попадете в петлю сорванных дедлайннов), так и выстроить фундамент ваших достижений (если вы сможете создать приятный повторяемый опыт письма). В общем, важна "установка на рост", когда мы хотим стать лучшей версией себя. А вторая часть - это система обучения, что позволяет на практике создать петлю положительной обратной связи. И система создания заметок Zettelkasten именно такова, ведь делая заметки мы видим как наши знания растут как и содержимое этого ящика:)

Продолжение в третьей части поста.

#SelfDevelopment #Writing #Brain #Processes #SystemThinking #Thinking

Как формировать структуру команд под запросы бизнеса - часть 1

Последние 7 лет я работаю в Тинькофф и за это время видел и отвечал за большое количество изменений: организационных, продуктовых и инженерных. Про многие из них я уже рассказывал в выступлениях и статьях, но там был обычно фокус на конкретном изменении. А в этом посте я бы хотел поговорить про принципы дизайна команд и управленческой структуры, без которых мне было бы гораздо сложнее понимать а что надо менять и почему именно так. Для этого надо вспомнить про несколько базовых вещей

- Подход working backwards или backcasting - о том, что начинать лучше с конца, представляя цель изменений и финальный результат.
- Закон Конвея - утверждение Мелвина Конвея про то, что организации проектируют системы, которые копируют структуру коммуникаций в этой организации
- Обратный маневр Конвея - подход, который рекомендует эволюционировать структуру команд и организационную структуру так, чтобы продвигать желаемую архитектуру в организации.
- Топология команд (Team topology)- плодотворный подход с набором паттернов для структурирования типов команд и их взаимодействий, который вводит 4 вида команд: stream-aligned, platform, enabling, complicated subsystem и три вида взаимодействий: collaboration, facilitating, x-as-a-service.
- Управление измнениями (Change management) - набор подходов для того, чтобы осуществлять изменения на всех уровнях: индивидуальном, командном и организационном.
Теперь, когда я упомянул про сами концепции, то можно описать мой подход к формированию структуры управления.

Алгоритм приблизительно такой
1. Определить какая сейчас долговременная цель у той части компании, за которую вы отвечаете
2. Оценить какая архитектура систем подходит наилучшим образом под эту цель
3. Применить обратный маневр Конвея, чтобы понять какая структура команд будет поддерживать желаемую архитектуру
4. Использовать паттерны из team topologies, чтобы спроектировать структуру команд и виды их взаимодействия
5. Использовать менеджмент изменений, чтобы все спланировать и осуществить (про организационный и командный уровень мы поговорили выше, а индивидуальный здесь обсуждать не будем)

В следующей части я расскажу про применение этого алгоритма в 4 сценариях:
- Проект (запуск новой инициативы)
- Развитие продукта (просто продуктовая разработка)
- Масштабирование разработки вверх (scaling up)
- Масштабирование разработки вниз (scaling down)
Все этапы я в свое время проходил на практике и про многие даже рассказывал:)

P.S.
Накидаю источников для изучения
- Про backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал

#Management #Leadership #Processes #ProjectManagement #Project #Software #SoftwareDevelopment

Coaching Teams Through Team Change • Heidi Helfand • GOTO 2023

Софтовый доклад от Heidi Helfand, в котором она рассказывает про то, как проводить изменения в командах. Отдельно стоит отметить, что Heidi - автор книги "Dynamic Reteaming", и в этом докладе она кратко рассказывает содержимое своей книги. Она начинает со своего карьерного пути в IT, который стартанул в стартапе еще до бума доткомов. Сначала стартап рос, но потом сделал pivot, так как у оригинального продукта не было достаточного market fit. В итоге, перешлось переигрывать состав команд. Дальше автор приводит примеры причин, по которым командам надо меняться
- Products cancelled
- Growth/attrition
- New work or priority
- Knowledge sharing
- Stagnation & learning
И отдельно автор отмечает, что когда ваши команды меняются, то это не значит, что вы сделали что-то не так. И даже более того, можно сидеть и (не)ждать изменений, а выступить их катализатором и отчасти ими управлять:) Дальше автор рассказаыват про 5 самоочевидных паттернов изменений команд
- One by one pattern - добавление людей в команду по одному
- Grow & split pattern - рост команды и разделение ее на отдельные части (зачастую 2 части)
- Merging pattern - объединение двух отдельных команд в одну общую
- Isolation pattern - сбор общей команды из отдельных индивидуумов, которых забирают из их команд
- Switching pattern - переход одного человека из одной команды в другую
Дальше автор отмечает, что делать все эти изменения ради самих изменений не стоит:) Но изменения - это привычный наш спутник, поэтому к ним надо быть готовым. Автор показывает знак бесконечности (∞), который символизирует непрерывные изменения (а не только devops), а дальше переходит к софтовым историям про то, как с этим всем жить:) Их я пересказывать не буду, так как есть оригинальное выступление и слайды презентаций, которые доступны здесь.

#Management #Leadership #Processes #ProjectManagement #Project #Software #SoftwareDevelopment

Как делать полезные заметки (How to take smart notes, Zettelkasten) - III

Я продолжаю рассказ про книгу о Zettelkasten, о которой я говорил в постах 1 и 2. И тут речь про первые три шага к успешному письму, которых по мнению автора целых 6 штук:
- Раздельные и взаимосвязанные задачи
- Читайте для понимания
- Делайте полезные заметки
- Развивайте идеи
- Делитесь своими инсайтами
- Заведите себе полезную привычку

Часть 3 - Шесть шагов к успешному письму

9. Раздельные и взаимосвязанные задачи
Тут речь о том, что многозадачность это миф и что эффективность работы в таком режиме сильно ниже эффективности сфокусированной работы над одной задачей. Но сейчас люди редко когда могут сфокусировать внимание надолго на одной теме - мешают отвлекающие факторы и неорганизованный рабочий процесс. А с этим может помочь ящик для заметок, который не только обеспечивает структуру работы, но и заставляет пользователя сознательно переключать внимание между задачами записи заметок.
Автор говорит, что никакой план не поможет нам хорошо писать и его тезис звучит так: "не строй планов, стань экспертом". Автор много говорит про науку и научные работы и делиться своим видением основной идеи науки: "обрести знания и сделать это достоянием общественности". Собственно начинать подготовку к написанию надо с обретения знаний.
Другой тезис посвящен освобождению от лишнего причем в своей памяти (особенно кратковременной), которая не резиновая. Для подтверждения действенности совета приводится эффект Зейгарник, когда незаконченные задачи, как правило, занимают кратковременную память до тех пор, пока не будут выполнены. Но если их записывать, то мозг не делает различий между сделанной и отложенной задачей:) И последний совет звучит так "сократите количество решений". Так мы сможем экономить свои волевые ресурсы и избегать "истощения эго", а значит нам будет проще выполнить работу. Собственно, налаженная система уменьшает степени свободы и сокращает вариативность и количесто решений.

10. Читайте для понимания
Крутые советы для эффективного чтения
- Читайте с ручкой в руке - тут основная мысль в том, чтобы не просто скопировать текст, а в осмысленном диалоге с читаемыми текстами. Я сам часто пишу прямо на полях, оставляю ссылки на другие идеи, а иногда и todo записи:) Конечно, в контексте Zettelkasten это все автор называет предварительным шагом перед созданием постоянной заметки, что попадет в ящик.
- Мыслите шире - суть в том, чтобы постараться избежать "предвзятости подтверждения" и рассмотрения широкого набора гипотез. В методе с ящиком мы идем от интересных идей и заметок, а дальше собираем из них текст. Это позволяет меньше страдать от предвзятости подтверждения, чем в случае старта с решения о гипотезе или проблеме, под которую мы хотим подобрать факты и написать текст:) Отдельно автор говорит про важность поиска фактов, что противоречат нашей гипотезе.
- Найдите суть - тут автор рассказывает про критическое мышление (про это можно почитать отдельную книгу)
- Учитесь читать - тут важно не просто прочитать, но и попробовать переформулировать прочитанное и увидеть лакуны в понимании
- Учитесь, читая - автор говорит про настоящее обучение, что помогает улучшить понимание мира, а не пройти тест (интересно, что меня всегда интересовало именно настоящее обучение начиная с детства). Обучение требует усилий и размышление и создание заметок отлично подходят для обучения.

11. Делайте полезные заметки
Здесь идет речь про создание заметок по одной за раз, про размышление вне рамок и наоборот про функцию заметок как некоторой чексуммы смысла того, что мы прочитали. Дальше про вопросы к самим себе, а почему весь прочитанный текст уложился в такие маленькие репрезентации в виде нескольких заметок и почему именно на те темы, что там оказались. Как заметки работают в качестве внешней памяти и помогают связывать разные контексты между собой (тут возможна кросс-линковка разных источников на интересующую нас тему). Ну и напоследок, а как добавлять постоянные заметки в сам ящик:)

#SelfDevelopment #Writing #Brain #Processes #SystemThinking #Thinking

Kubecon Chicago - November 6-9

На днях в Чикаго проходил Kubecon, который закончился только вчера. Я конечно же не мог посетить конференцию лично, но планировал посмотреть трансляции и даже купил виртуальный билетик. Я даже букал себе время в календаре под это дело, но ничего не помогло
- время старта выступления было в 18 по Мск
- на начало ноября у меня выпали хлопоты по переезду
- и в среду я заболел
В итоге, я так ни одно выступление в прямом эфире не посмотрел, но если получиться, то гляну записи в выходные. Хотя по фидбеку от друга, который был там лично, уровень докладов слабее, чем на условном Highload++. В итоге, если я найду интересные выступления, то я о них напишу в этот канал:)

#Conference #SRE #Devops #DistributedSystem

CNCF Platforms White Paper - I

Ну и в продолжение поста про Kubecon я решил рассказать про whitepaper от CNCF на тему платформ. Документ состоит из 7 пунктов

1. Why platforms?
Собственно документ начинается со списка преимуществ платформ и того, какие проблемы они решают:
- уменьшают когнитивную нагрузку на продуктовые команды
- улучшают надежность и устойчивость продуктов, развернутых поверх платформ
- ускоряют разработку и доставку продуктов за счет переиспользования платформенных инструментов
- уменьшают риски: безопасности, регуляторные, функциональных багов
- помогают использовать эффективно сервисы и мощности публичных облаков

2. What is a platform
Здесь дается определение платформы в виде коллекции возможностей, что определены и представлены в соотоветствии с потребностями пользователей платформы. Здесь важно, что все эти возможности интегрированы вместе и предоставляют возможность выполнять типичные сценарии пользователей платформы. Критически важно, что не все возможности платформенные команды должны реализовывать сами (их могут предоставлять облачные провайдеры или внутренние команды в организации). Так как эти платформе направлены на внутренних разработчиков, то их называют internal developer platform. Дальше авторы отдельно разбирают уровни зрелости платформ
Platform maturity
- продуктовые разработчики могут получать возможности платформы on-demand и сразу использовать их для запуска своих приложений
- продуктовые разработчики могут получать пространство для сервисов и сразу использовать их для запуска пайплайнов и задач для хранения артефактов, конфигурации и сбора телеметрии
- администраторы стороннего софта могут получать свои зависимости по требованию, например, баззы данных, а дальше использовать их в своих решениях
- продуктовые разработчики могут получать полное окружение с темплейтами вместе с run-time и development-time сервисами для специфичных сценарием (Web, ML, ...)
- продуктовые разработчики и менеджеры могут наблюдать за функциональностью, производительностью и костами развернутых сервисов через стандартные инструменты и дашборды

3. Attributes of successful platforms
В этом пункте авторы рассказывают про свойства платформ, которые
- platform as a product - к созданию платформ надо подходит как к созданию продукта
- user experience - надо ориентироваться на опыт разработчиков (DexEx, про него я недавно разбирал white paper)
- documentation and onboarding - здесь приводится пример того что могут предлагать платформы "the platform could offer a reusable supply chain workflow for building, scanning, testing, deploying, and observing a web application on Kubernetes. Such a workflow could be offered with an initial project template and documentation, a bundle often described as a golden path"
- self-service - возможность самостоятельно использовать сервисы
- reduced cognitive load for users - платформа должна уменьшать нагрузку
- optional and composable - продукты должны иметь возможность использовать нужные части платформ, а нехватающие части закрывать самостоятельно
- secure by default - безопасность должна быть встроена в платформы по умолчанию

4. Attributes of successful platform teams
Платформенные команды отвечают за следующие зоны
- исследование требований пользователей и создание роадмапа фичей
- маркетинг, евангелирование и адвокатство ценностей, которые предлагает платформы
- управление и разработка интерфейсов для использования и изучение возможностей и сервисов, включая портал, API, документацию, шаблоны и CI инструменты
Самое важное в том, что платформенные команды должны изучать потребности платформенных пользователей и дальше информировать и постоянно улучшать возможности и интерфейсы, что предоставляют платформы. Для этого можно использовать стандартные продуктовые инструменты, например, описанные в книге Мартина Кагана "Inspired", про которую я писал раньше.

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

#Kubernetes #SRE #DistributedSystems #PlatformEngineering #SoftwareDevelopment #Software #ProductManagement

Пятница с кабанчиком:)

Вечером в среду пятницу,
После обеда,
Сон для усталых, хмурых людей!
Мы приглашаем
Тех, кто отчаен
В дикие джунгли скорей!

Или то вот с чем стоит читать "Designing Data-Intensive Applications" по вечерам в пятницу:) Хотя я его уже пару раз читал, поэтому под это вино почитаю что-нибудь другое на тему проектирования распределенных систем:)

#Joke

Architects, anti-patterns, and organizational fuckery

Интересная статья полугодичной давности про архитекторов и инженеров. Я только сегодня дочитал ее до конца и согласен со многими тезисами, например
- что это вопрос ответственности за свои решения (архитектор, который принимает решения, а реализацию оставляет команде - это антипаттерн)
- что проектирование - это один из основных скиллов разработчиков
- что лучшие "архитекторы" вырастают внутри из инженеров
- что лучшие архитекторы - это staff+ инженеры, которые практикуют разработку и могут проектировать
- что это скорее роль, а не должность
- что если это должность, то слишком велика вероятность потери навыков инженеров, так как велик соблазн начать "делать архитектуру" и отринуть прошлое инженера в плане написания кода, ревью и траблшутинга - ведь, зарплата архиетктора такова, что этим не рентабельно заниматься ... но это ловушка для карьеры

Есть момент, что в некоторых enterprise компаниях архитекторы бывают полезны, но там они скорее не инженеры, а собиратели решений, которые проектируют интеграцию различных вендорских решений между собой. Но для IT компании - это не то, что нужно:) В итоге, я склоняюсь, что вместо должности архитектор и далее должны быть продолжение должностей разработчика до staff, principal и так далее ... с соответвтующими требованиями к инженерным умениям:)

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

#Management #Architecture #Architect

CNCF Platforms White Paper - II

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

5. Challenges when implementing platforms
Платформы обещают многое, но на пути к реализации есть вызовы, которые надо преодолеть. Авторы выделяют следующие
- платформенные команды должны относиться к своим платформам как продукту и развивать их вместе с пользователями
- платформенные команды должны осторожно выбирать свои приоритеты и изначальные партнерства с командами, отвечающими за приложения
- платформенные команды должны искать поддержки от команды лидеров (условно топ-менеджеров) и показывать влияние на value streams
Вся эта часть крутится вокруг продуктового подхода, где платформа должна развиваться как customer-facing продукт (хоть и dev2dev) и решать проблемы своих пользователей. Отдельно упоминается про важность наличия продакт менеджеров, которые работают с пользователями собирая ожидания, создают роадмап развития платформ и собирают обратную связь от пользователей. Для adoption платформенных решений очень важно выбрать правильные возможности (capabilities) для старта, например, авторы упоминают pipelines, databases, observability, которые являются фундаментальными и нужны почти всем:) Дальше авторы приводят рекомендации о том, как уменьшить нагрузку на платформенные команды за счет
- построения thinnest viable platform поверх услуг провайдеров
- использования open source фреймворков, инструментов и шаблонов и объединение их вместе для предоставления app командам
- убедиться, что платформенные команды укомплектованы достаточно для сложности их домена и количества клиентов

6. How to measure the success of platforms
Здесь авторы приводят категории метрик, по которым можно оценивать успешность работы платформенных команд и их платформ
- User satisfaction and productivity - метрики по пользователям (DAU и retention), NPS пользователей, метрики продуктивности (например, фреймворк SPACE, про который я уже рассказывал)
- Organizational efficiency - здесь можно оценить скорость предоставления возможностей (например, provisioning базы данных), создание полностью нового сервиса (от репозитория, сборки и деплоя и появления на production), или времени, что требуется новому пользователю, чтобы сделать первые изменения в коде продукта
- Product and feature delivery - здесь идет речь про DORA метрики: deployment frequency, lead time for changes, time to restore services after failure, change failure rate (подробнее можно почитать в книге "Accelerate", про которую я уже рассказывал). Основная цель платформенных команд в том, чтобы выровнять IT возможности и value streams компании. В итоге, успех платформ измеряется успехом продуктов и приложений организации, команды которой используют эти платформы.

Про возможности платформ можно почитать в последнем посте

#Kubernetes #SRE #DistributedSystems #PlatformEngineering #SoftwareDevelopment #Software #ProductManagement

Disciplined Agile® от PMI

Уже 6 лет я являюсь сертифицированным руководителем проектов по версии PMI (Project Management Institute) и я периодически возвращаюсь к их курсам и обучающим материалам, чтобы продлить свой статус, заработав нужное количество PDU. В этот раз проходя обучение, я наткнулся на много материалов по agile подходам под флагом Disciplined Agile® и мне стало интересно
- что это такое
- откуда появилось
- насколько оно полезно
- и насколько стандартные agile подходы являются недисциплинированными:)

Собственно, начать стоит с того, что это такое и ответ мы можем найти в самом начале страницы с введением в этот вид agile процессов:
Disciplined Agile (DA) is an agnostic, hybrid tool kit that harnesses hundreds of Agile, Lean, and traditional strategies to guide you to the best way of working (WoW) for your team or organization.

Дальше я заинтересовался откуда это появилось и нашел официальную историю появления и развития этого подхода
- В 2012 году Disciplined Agile был создан Scott Ambler и Mark Lines
- В 2019 году PMI приобрело Disciplined Agile
- Дальше PMI активно начало встраивать в свои материалы по управлению проектами agile подходы в форме disciplined agile

Теперь взглянем на интересные моменты DA
- это не фреймворк, а тулкит для создания процессов под себя, авторы называют это Way of Working (сразу вспомнился RUP с его глубоким тюнингом)
- у этого подхода есть 4 отдельных области: mindset (как подавать основы lean и agile в условиях корпорациях), people (роли, ответственность, структура команд), flow (процессы), practices (техники для того, чтобы ваша команда двигалась к цели)
- DA mindset основан на трех китах: принципы (для business agility), promises (соглашения со всеми стейкхолдерами), guidelines (гайды для улучшения WoW)
- дальше DA вписывается в корпорацию, которая конечно же Disciplined Agile Enterprise, в которой бизнес функции называются process blades (для каждого подхода важно придумать свой язык:))
- и вся эта DA enterprise опирается на foundation (mindset, people, agile, lean, serial, WoW)
- за основанием идет DevOps, но не простой а дисциплинированный
- поверх него вводится понятие value streams, а уже сверху громоздится DAE (Disciplined Agile Enterprise)
- дальше авторы вспоминают про свободу выбора и презентуют интересный интерактивный справочник, который позволит кастомизировать WoW
- но для кастомизации и постоянных улучшений авторы вводят понятие guided continuous improvement (GCI), которые разложены на отдельные уровни: personal improvement, team improvement, multi-team improvement, value stream improvement, organizational improvement

В общем, во время изучения базовых основ Disciplined Agile я словил такое ощущение дежавю, что полез изучать историю появления подхода, о которой я написал в начале поста. После этого все стало ясно - PMI надо было добавить себе в портфель менеджерских подходов немного гибкости и они это сделали хоть и довольно топорно:)

#Management #Agile #Project #Leadership #SelfDevelopment #Software #Processes