The Joy of Building Large Scale Systems • Suhail Patel • YOW! 2023

Это очень интересное выступление Suhail Patel, Senior Staff Engineer at Monzo. Оно посвящено тому, как поменялись latency numbers (смотри "Latency Numbers Every Programmer Should Know") и производительность в общем за последние годы. Важно, что эти изменения напрямую влияют на проектирование и эксплуатацию масштабных и нагруженных систем. Автор очень подробно идет по куче тем и
- Рассказывает про работу b-tree+ в базах данных (интересно, что он не говорит про LSM и SSTables)
- Показывает как поменялась скорость дисков: HDD (200 mbps), SDD (550 mbps), NVMe (3000 mbps)
- Упоминает про изменения в CPU (да закон Мура уже не про рост мощности одного ядра, а про увеличение количества ядер) + появление ARM процессоров, что выдают больше мощности на стоимость по сравнению с x86-64
- Говорит про рост пропускной способности сети (c 1Gbps до десятков Gbps) и появление кастомных чипов типа TPU от Google (tensor processor unit)
- Вспоминает давнишние предсказания о том, что несмотря на увеличение мощности компьютеров software всегда найдет куда утилизировать эти мощности (обычно в дополнительные уровни абстракций поверх уровня железа)
- Разбирает подход с работой вида thread per core (сравнение shared everything arch vs shared nothing arch на уровне процессора, его ядер и доступа к памяти), тут же рассказ про выделение одного ядра на работу с сетью и как это помогает с tail latency, про Seastar, что используется в Scylla (конкурент Cassandra, но только на C++, а не Java), про io_uring, который заехал и в libuv
- Рекламирует Rust как инструмент для системного программирования и показывает как его легко использовать с Python (пример с парсингом дат в промышленном масштабе)
- Рассказывает про новые трюки с garbace collection, начиная с Java 17, дальше про eBPF (я рассказывал про интересную документалку об этом проекте)
- Говорит про простое ускорение работы с парсингом JSON, оптимизацию загрузки весов с llama и подобные вещи при помощи понимания низкоуровневых концепций
И заканчивает на высокой ноте, призывая лучше разбираться с тем, как работет железо под нашим софтом

Many of the systems (apps, services, databases, caches, queues) that we build/rely on are grounded on quite poor assumptions for the hardware of today

Software can keep pace, but there’s some work needed to yield huge results, power new kinds of systems and reduce compute costs

#Software #Architecture #DistributedSystems #SystemEngineering #SystemDesign #Engineering #Devops #SRE

Разверните ваш корабль (Turn the Ship Around!)

Прочитал за пару дней эту интересную книгу, посвященную лидерству. Вся книга представляет собой историю капитанства Дэвида Марке, который рассказывает про свой подход, с помощью которого он превратил подводную лодку Santa Fe из худшей в лучшую всего за несколько лет. Дэвид описывает свой подход как переход от модели "leader - followers" к модели "leader - leaders". Для этого он выделяет три ключевые темы
- Control - принятие решений и контроль за их реализацией Дэвид предлагает передавать на тот уровень, где эффективнее всего это можно сделать. Чем-то это напоминает OKR (objectives and key results), в котором сверху приходят цели, а на местах люди уже придумывают как их достигнуть и какие ключевые результаты удастся получить. В итоге, у Дэвида в модели лидерства капитан не является человеком, который рассказывает что сделать и принимает за всех решения. У него офицеры и старшины могут принимать решения в своей зоне ответственности и нести за них ответственность (понятно, что несмотря на это за все происходящее на подводной лодке все равно accountable капитан)
- Competency - передача принятия решений и контроля без наличия нужных компетенций - это выстрел себе в ногу. Поэтому другой основой подхода Дэвида является повышение уровня компетенций команды. Его подход к инцидентам и работе с ними напоминает подходы SRE (site reliability engineers) и конкретно postmortems. Интересно, что Дэвид переключает команду с режима избегания ошибок на достижение операционного совершенства (operational excellence). Это фокусирует людей на непрерывном улучшении и обучении в процессе работы, вместо попыток просто "не облажаться"
- Clarity - в модели "leader - leaders" очень важно, чтобы люди, принимающие решения на местах, понимали общую цель организации. Часто в бизнесе при этом говорят про vision, mission, strategy и так далее. В книге Дэвид описывает как это выглядело для сотрудников на подводной лодке:)

Из интересного отмечу, что подход к лидерству Дэвида хорошо сработал в рамках военно-морского флота и многие его наработки стали через несколько лет стандартом де-факто (а где-то и де-юре). Плюс многие офицеры с лодки Santa Fe дальше успешно служили на флоте и получали повышения, так как впитали эту модель лидерства и несли ее дальше.

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

#Management #Leadership #SelfDevelopment #Psychology #ForParents #SystemThinking #ProjectManagement

Programmer’s Apprentice Season 2: Future Directions in AI-assisted Coding • Erik Meijer • YOW! 2023

Интересное выступление про будущее разработки, в котором Erik Meijer, Director of Engineering at Facebook, делает утверждение, что мы - последнее поколение, что будет писать код руками:) И это не печалит автора доклада, скорее он рад и вдохновлен этой возможностью. Для начала автор вспоминает про то, как развивались языки программирования и про 5th generation, а потом как он ушел в создание языков программирования, а в районе 2017 года на фоне развития neural networks перешел в AI (вовремя переобулся). Дальше он говорит про
- Non-monothonic logic (как ранний подход к AI)
- Virtuous cycle между железом и программным обеспечением (отсылка к закону Мура)
- Vicious cycle между бизнесом и программным обеспечением, где сложность бизнеса приводит к усложнению софта (что может съедать весь прирост от virtuous cycle). Для этого обычно разрабатываются software engineering tools. Но автор предлагает заменить software + software engineering tools на AI:)
- Дальше автор рассказывает про whitepaper 2021 года "AI in Software Engineering at Facebook", где он выступал в качестве соавтора. Где авторы говорили про: code search using natural language, но это не очень понравилось пользователям. Дальше автор говорит про code recommendations, automated bug fixes. Для 2021 года это была крутая статья, но в 2022 году с приходом к власти LLMs она мгновенно устарела и автор показывает как эти сценарии легко выполняются с chatGPT
- Дальше автор переходит к описанию того, как можно автоматизировать самих себя:
-- AI-powerd typing (copilot)
-- AI-powered search (chatGPT)
-- AI-powered "workflows" (autoGPT)
- И дальше Eric показывает как это может выглядеть для написания программ в виде взаимодействия агентов: testrun agent, bugfix agent, refactor agent. Плюс дальше идет prompt engineering
- Дальше автор иронизирует над фреймворком React для фронта, а дальше рассказывает про новый React, который приведен в whitepaper "ReAct: Synergizing Reasoning and Acting in Language Models" и дальше автор вспоминает свою whitepaper из 20 века "Client-side Web Scripting with HaskellScript"
- Ну и под конец автор рассказывает про видение LLM как scripting client
- Финальным слайдом идет утверждение, что llm-based software is very powerful, but error-prone, brittle, insecure, hard to write, impossible to debug, expensive, privacy sensitive
- И это все стоит поправить для того, чтобы перейти в новый светлый мир (где код писать будут LLMs), а для этого надо еще будет поработать инженерам:)

#Management #Software #SoftwareDevelopment #LLM #AI #ML #Engineering #SystemEngineering #Architecture

Java Weekend Offer @ Tinkoff

Мы в Тинькофф периодически проводим мероприятия, на которых устроиться на работу к нам можно за выходные. Очередное такое мероприятие пройдет в эти выходные (3-4 февраля) и 17-18 февраля. В рамках таких мероприятий обычно несколько команд приносят свои вакансии и преимущественно проводят интервью. В этот раз там есть ребята из моего юнита, что развивают Маркетинговую платформу. Эта платформа представляет из себя набор продуктов, с помощью которых мы связываемся с клиентами по множеству маркетинговых каналов. Каждый клиент банка — наш пользователь. Платформа работает по сценариям, которые создают контент-менеджеры. Она совершает более 100 млн действий ежедневно: рассылает пользователям пуш-уведомления и СМС, начисляет бонусы, запускает многоходовые маркетинговые акции и геймификацию.

Для того, чтобы дойти до фит-интервью с командами (и выбрать вакансию маркетинговой платформы) надо пройти 3 секции интервью
- Языковая секция, где будет обсуждаться платформа, фреймворки, с которыми вы работали, и теоретические вопросы, а также будет ревью кода
- Алгоритмы и структуры данных, где будет пара алгоритмических задач, чтобы оценить навык написания кода (эти навыки можно тренировать на leetcode, который и я использую, чтобы поддерживать себя в форме)
- System Design (для уровня senior), где надо будет спроектировать распределенную систему (вот мой пост про это интервью)

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

#SoftwareDevelopment #Software #Vacancy #Engineering

Профсообщества в больших компаниях

Появилась запись встречи канала "безвотэтоговсего" про профессиональные сообщества в Росбанке, где я дискутировал на прошлой неделе. Во встрече помимо меня участвовали следующие замечательные люди:
- Сергей Щербинин, автор канала "безвотэтоговсего" и организатор встречи
- Паша Соломин, лидер разработки и сопровождения СБОЛ
- Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых сервисов Росбанка
- Макс Морозов, СЕО Астон

В дискуссии мы обсуждали много вопросов и вот несколько из них
- Как и зачем корпорации строят профсообщества и как они измеряют их эффективность?
- Как выстраивать лидеронезависимые сообщества?
- Как вовлекать в них людей, пробуждая интерес, а не выставляя ненужные KPI?

Если суммировать мою точку зрения на основе опыта Тинькофф, то у нас проффсообщества логично называются профессиями и выстроены примерно так
- У профессий есть свои лидеры, что исполняют эту роль, совмещая с участием в продуктах/проектах
- Професии являются точкой синхронизации людей, объединенных вокруг чего-то общего: профессии (продакт менеджер, системный аналитик, qa-инженер, разработчик), языка разработки в случае разработчиков(golang, kotlin/java/.net, etc), функции (архитектура, процессы разработки) и так далее
- У каждой профессии есть ее лидеры, которые ее развивают как во всей организации, так и внутри крупных подразделений
- Лидеры профессий помогают определять ожидания от специалистов, которые входят в определенную профессию - это так называемые матрицы компетенций
- Лидеры профессий участвуют в рассмотрении заявок на повышение, что идут через наш процесс Т-Рост, про который я рассказывал в своей статье
- Лидеры профессий помогают улучшать найм сотрудников в рамках своей профессии (это наши стримы найма, например я когда-то курировал и рассказывал про system design и troubleshooting)
- В рамках профессии вырабатываются стандарты и часто реализовывается общий инструментарий, который помогает всем в рамках профессии быть эффективным
- Также лидеры профессий часто ведут публичную деятельность по освещению своей профессии как внутри, так и снаружи компании (aka devrel)

Для меня концепция профессии звучит классно и позитивно, но возникает вопрос а почему не выделить это в отдельную должность?
Ответ в том, что при выделении сотрудников на fulltime мы получаем сломанную ситуацию, когда крутой представитель профессии постепенно теряет
- Экспертизу в ней, так как перестает работать руками
- Связь с землей и уходит в абстракции, так как перестает работать руками
В итоге, лидер профессии вынужден сидеть на двух стульях.

Но тогда возникает вопрос, а зачем ему это делать?
Ответ в том, что это улучшает карму сотрудника и повышает вероятность успешного повышения в рамках процесса Т-Рост, причем для высоких грейдов это становится необходимым, но недостаточным критерием:)

#Management #Leadership #Engineering #Staff #Software #Devrel

Leetcode - прогресс за первый месяц

Я уже рассказывал как купил себе Premium подписку на LeetCode на день рождения (3 января ) и парочку курсов оттуда ("Data Structures and Algorithms" и "System Design for Interviews and Beyond"). А теперь пришло время отчитаться за этот месяц:
- Оказалось, что руки забыли примерно одинаково как писать на всех языках, поэтому я решил вспоминать Python для алгоритмических задач
- После того, как я вспомнил синтаксис python и чуток набил руку, то easy задачки я стал решать где-то за 5-10 минут, а вот задачки уровня medium идут у меня с переменным успехом (и пока они скорее побеждают)
- У нас в компании есть чатик любителей leetcode, которые решают Daily Challenge вместе и обсуждают задачки - я туда тоже записался, но отрешал только около половины ежедневных задачек
- Зато SQL у меня как будто не забывался - тут в среднем easy задачки идут за пару минут, medium обычно минут 5 и даже hard задачки решаются относительно просто (правда, сегодня ночью решал порядка часа последнюю hard задачку из набора "Advanced SQL 50")

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

P.S.
Купленные курсы я пока не прошел (и даже особо не начинал), но планирую в феврале их заботать. Особенно интересно будет изучить system design курс.

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Code of Leadership - Episode ? - Антихрупкость в IT от Саши Бындю

Я подумал, что в рамках моего подкаста было бы интересно не просто звать гостей и обсуждать их любимые книги. Круто иногда звать и самих авторов книг и обсуждать их творчество вместе с ними. Именно такую серию мы запишем с Сашей Бындю на следующей неделе по книге "Антихрупкость в IT". Договориться получилось достаточно легко
- Мы с Сашей уже были знакомы где-то с 2019 года, когда он выступал на ArchDays 2019 года с докладом про Inner source (я в ПК этой конференции с самого начала)
- Саша с большим интересом делится своим подходом к антихрупкости (он рассказывал про это на Codefest 2023)
- Я недавно прочитал его книгу и уже рассказл про нее раньше
- Когда я предложил Саше прийти в гости, то он легко согласился, а также написал небольшой ответ на мой обзор
- Когда мы обсуждали план на выпуск, то поняли, что интересно будет поговорить про "карты гипотез", продуктовый и проектный подход, работу в модели заказчик/исполнитель или внутри организации, архитектурные вопросы и так далее

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

#Management #Software #Architecture #Processes #Project #ProductManagement #Engineering #Processes #Consulting

Тренды геймификации - эфир South HUB

Меня достаточно часто зовут пообщаться и что-то пообсуждать. И я особенно люблю, когда я могу прийти не сам, а посоветовать кого-то более релевантного из моих коллег. И с этим эфиром на South Hub про геймификацию так и получилось - я порекомендовал позвать моего коллегу, Вадима Гончарова, который руководит разработкой игр и спецпроектов. Кстати, Вадим недавно на YaTalks рассказывал про то, как ребята делали игру "Ряд наград". Кстати, отдел Вадима теперь входит в управление разработки соцплатформ, про чью вакансию SRE лида я писал недавно.

В эфире будут участвовать
- Кирилл Буртный - СТО Х5 Tech, модератор дискуссии и январский соведущий канала South Hub.
- Вадим Гончаров, руководитель разработки спецпроектов и игр в Тинькофф.
- Антон Лямин, руководитель продукта опыта покупателей Авито.
- Олег Афанасьев, CPO RuStore | VK.

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

#Software #GameDesign #Engineering

GraphQL: The Documentary

Полтора года назад я посмотрел эту документалку в рамках изучения whitepaper "Continuous Deployment of Mobile Software at Fb (Showcase)", на которую я написал краткое саммари в своем блоге. Если кратко суммировать, то где-то до 2012 компания, что создала GraphQL шла в сторону веба в мобилке, но стало ясно, что HTML5 в мобиле тогда не работал. Дальше они решили переобуться на нативную разработку и стало ясно, что старые APIшки не очень помогают в разработке нативных приложений. Дальше вместо проектирования API ребята изобрели свой способ через выставление query language прямо в потребителей и назвали это GraphQL. Несмотря на мое отношение к GraphQL рекомендую глянуть эту документалку и понять откуда растут ноги у этого подхода.

Кстати, я уже рассказывал про другие документалки
- How A Small Team of Developers Created React at Facebook | React.js: The Documentary
- Ruby on Rails: The Documentary
- Inside Envoy: The Proxy for the Future [OFFICIAL FILM]
- eBPF Documentary: eBPF’s Creation Story – Unlocking The Kernel
- AlphaGo - The Movie
- Kubernetes: The Documentary

#Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

Алгоритмы: построение и анализ (Introduction to Algorithms)

Я купил этот кирпич за авторством Кормена, Лейзерсона и Ривеста еще в 2002 году, когда думал, что смогу стать мастером в алгоритмах. Это было еще первое издание книги с белой обложкой и тогда соавторов было еще трое. Мне тогда нравилось изучать эту книгу, но на первых курсах университета у меня еще не было личного компьютера, поэтому приходилось писать псевдокод на листочке и дебажить в голове. Такая схема работы не слишком помогала в изучении computer science, но основы вроде бы я тогда уловил (заодно понял, что в этой области я звезд с неба не хватаю:) иначе бы и в голове мог все это отрешивать без компа).

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

Прошло много лет и теперь можно вернуться к книге, а алгозадачи решать не в голове, а на leetcode:)

Структура книги достаточно логичная и состоит из следующих частей
1) Математические основы анализа алгоритмов - скорость роста функций (нотация O(n)), рекурентные соотношения, множества, комбинаторика и вероятность
2) Сортировка и порядковые статистики - сортировка с помощью кучи, quick sort, медианы и порядковые статистики
3) Структуры данных - стеки, очереди, связанные списки, хеш-таблицы, деревья
4) Методы построения и анализа алгоритмов - динамическое программирование, жадные алгоритмы
5) Более сложные структуры данных - b-tree, биномиальные кучи, фиобаначчиевы кучи, системы непересекающихся множеств
6) Алгоритмы на графах - поиск в ширину и глубину, минимальные покрывающие деревья, кратчайшие пути, максимальный поток
7) Дополнительные главы - матрицы, быстрое преобразование Фурье, NP-полнота и многое другое

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

#Software #Algorithm #Engineering #SelfDevelopment

The Most Powerful Software Development Process Is The Easiest • Dave Farley • GOTO 2024

Это короткое видео Дэйва Фарли посвящено дизайну идеального процесса разработки софта. Интересно, что сам Дейв - тертый калач, который в давние времена написал книгу Continuous Delivery (я про нее рассказывал), а недавно - "Modern Software Engineering: Doing What Works to Build Better Software Faster", которая стоит у меня на полке и ждет своего часа. В этом видео Дэйв предлагает отринуть текущие практики и попробовать придумать процесс разработки софта from the first principle. В конце он предлагает модель идеального процесса, как видится ему. Интересно, что этот процесс позволяет размышлять не просто про идеал, а про вашу конкретную ситуацию и понять что не так с вашим процессом или вспоминая Льва Толстого понять в чем ваше несчастье:)

Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по своему

Ну а теперь кратко про мысли Дэйва
- Фиксирует цели разработки софта как решение проблем других при помощи софта. Для этого надо:
-- Понять проблему - отсюда появляются requirements
-- Решить проблему - тут мы пока пишем код, но некоторые говорят, что скоро будет писать только промпты
-- Проверить, что она решена - отсюда появляются тесты
- Так как мир вокруг изменчив, то нам надо уметь меняться - меняются требования и нам надо уметь делать изменения - отсюда появляется желание двигаться вперед маленькими шагами
- Нам надо понимать, что мы двигаемся в нужную сторону, поэтому нам надо верифицировать результаты и разрабатывать софт инкрементально
- Одновременно нам нужно, чтобы наша система работала с первой версии и на протяжении всех инкрементальных изменений - она же решает задачи пользователей, как мы определились в самом начале (а для этого она должна быть up & running)

Дальше автор показывает процесс:
- Смутное желание от бизнеса
- User story, где важно выразить потребности пользователя, а не конкретное решение
- Тут же важно привести примеры (из которых можно сделать test cases)
- А дальше уже идет design & implement часть, которую автор описывает подробнее
-- Про commit stage, упоминая continuous integration - на этой фазе проверяется техническая корректность изменений
-- Про acceptance stage - на этой стадии идут проверки, а можно ли релизить это изменение: acceptance test, security, performance, etc

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

P.S.
В общем, в этом видео нет ничего нового, но оно краткое, понятное и дает хорошую базовую модель процессов разработки.

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE

Become an Effective Software Engineering Manager • James Stanier & Gergely Orosz • GOTO 2023

Интересное интервью с James Stanier, автором книги "Become an Effective Software Engineering Manager" и отдельно расшифровка.

Интересные моменты
- The real stories behind the book - каждая глава начинается с истории, которая легко позволяет представить себя на месте главного персонажа (пример с менеджером команды, что не поставялет нужный результат). Эти части написаны по мотивам реальных историй:)
- Journey to become an engineering manager - про треки развития внутри разработки, а также как легко расти естественно вместе с компанией на растущем рынке:)
- Prescriptions vs tools: Why this book is different - в этой книге нет описания как нужно поступать в каждой конкретной ситуации. Вместо этого тут описываются ситуации и возможное поведение в их рамках. А дальше читатели уже сами могут решать как им поступать:) Ну кроме гигиенических правил бытия менеджером, что идут в начале книги
- Getting into management: How to make it happen - тут обсуждается как можно дорасти до engineering manager в рамках растущей компании ... и как сейчас это сложно сделать в текущем контексте, где часть компаний скорее не растут, а сжимаются. Плюс тут обсуждается как сделать так, чтобы попытка стать менеджером была безопасной (чтобы можно было вернуться на роль individual contributor, если роль менеджера не подошла)
- Trends in engineering management - история про удаленную работу, про волны сокращений в tech компаниях, а также как часть engineering managers могут возвращаться в разработку по причинам уменьшения штата. Ну и про увольнения
- Must-have tools in management - тут ребята говорят про делегирование/контроль, а также про стоицизм
- Book recommendations - рассказ про другие книги - "Effective Remote Work" и "The Software Engineer's Guidebook", где первая книга гостя, а вторая - интервьюера.

#Management #Leadership #Software #Engineering #SoftwareDevelopment #Career

Канбан Метод. Базовая практика

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

- его изобрели на "Тойоте"
- в нем есть доски и стикеры
- там ограничивают количество незавршенной работы

И дальше идет отстройка от старого канбана к новому, который придумал David J Anderson и превратил это в Kanban Univerysity (с курсами и сертификациями). Оставим в стороне сам подход к выбору уже используемого слова, а дальше объяснению всем, что это слово теперь значит что-то другое на совести David J Anderson. А рассмотрим саму книгу, которая состоит из четырех разделов.

1. Нематериальное производство
В этой части дается краткая отсылка к истории, когда производство было материальным и можно было видеть как материалы и незаконченное производство двигается по стадиям процесса (как в "Тойота"). А вот в условной разработке мы это движение уже не видим и нам нужно делать приседания для визуализации (откуда и растут ногу у знаменитых досок с тикетами)

2. Введение в Канбан Метод
Здесь все начинается с разбора принципов управления изменениями
- Начните с того, что есть сейчас (если задуматься над фразой, то сложно начать с чего-то другого)
- Договоритесь об эволюционном развитии (нет революциям и да постепенным улучшениям)
- Поощряйте проявление лидерства на всех уровнях
Дальше автор переходит к рассмотрению принципов поставки ценности
- Начиная с определения, что такое сервис поставки ценности
- Продолжая развитием правил для улушения показателей
- Отмечая важность понимания и фокуса на ожиданиях заказчика
- Говоря про важность управления работой, а не людьми
Завершает автор разбором базовых практик
- Визуализация
- WIP лимиты
- Управление потоком
- Явные правила
- Использование петель обратной связи
- Совместное развитие на основе моделей и научного подхода

3. Начиннаем использовать канбан
Здесь автор рассказывает про то, как изучать и улучшать процессы на практике, а точнее про
- Метрики производственного процеса
- Жизненные циклы
- Классы обслуживания
- Как строить канбан систему: про обязательства в такой системе, ее составные части, как дизайнить тикеты и саму доску.
Отдельно разбирается STATIK (System Thinking Approach To Introducing Kanban)

4. Улучшение канбан-системы
В этом разделе предполагается, что у нас уже есть канбан-система и мы дальше начинаем ее файн-тюнить, используя
- Накопительную диаграмму потока (cumulative flow diagram)
- Работу с узкими звеньями (как их выявить и что с ними делать)
- Работу с ресурсами непостоянной доступности (что это такое и как с ними быть)
- Что делать с вариативностью и как использовать теорию вероятности и массового обслуживаня (очень интересна часть про работу с рисками)
- Отдельно разбираются типы встреч и их ритмичность в канбан системе

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

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

Про улучшение процессов разработки софта я тоже как-то уже рассказывал и про kanban я там говорил по книге "Making Work Visible", на которую я как-то написал краткое саммари.

#Processes #Management #Leadership #Software #Kanban