Архитектура Дома Наркомфина вчера и сегодня - Part II (Рубрика #Architecture)

Продолжая первый пост про Дом Наркомфина, здесь я закончу рассказ про оставшуюся часть книги
- Дом Наркомфина. Цветовые решения - цветовые решения в доме сильно отличались от дефолтных и учитывали разную этажность и назначение помещений
- Другие участники строительства Дома. Николай Милютин и Сергей Прохоров - Николай Милютин был наркомом по финансам и главным стейкхолдером при строительстве дома. Без его помощи такой эксперимент бы не состоялся. Сергей Прохоров - был главным инженером стройки, без которого дом бы не удалось построить в нужные сроки, с нужным бюджетом и качеством
- Вторая очередь проекта Дома - у дома предполагалась вторая очередь, но она не случилась
- Довоенная жизнь Дома - до 2 мировой войны дом жил по задуманному плану, но во время войны многие уехали, а потом уже не вернулись. После войны его уже заселили по другому и многие решения переиграли
- "Соцгород" Николая Милютина - авторы рассказывают про вышедшую в 1930 году книгу Милютина «Соцгород», в которой он выдвинул собственную архитектурную концепцию градостроительства в соответствии с марксистской идеологией. В этой книге он обращался к западной практике, а также призывал к деурбанизации, то есть децентрализации городов, что противоречило общепринятой концепции развития городов в СССР. Плюс саму книгу он посвятил вскоре репрессированному коллеге, поэтому книгу запретили спустя год после публикации.
- Аналоги и "двоюродные братья" Дома - здесь авторы приводят примеры других домов, что использовали ячейки Стройкома, в котором когда-то работал Гинзбург. Похожие дома есть в Саратове, Нижнем Новгороде, Екатеринбурге, Ростове-на-Дону и других городах. Редко какие дома настолько ярки как Дом Наркомфина, но в них определенно прослеживается похожая логика и влияние конструктивистов
- Наследие Дома в послевоенной архитектуре - после войны идеи двухэтажных квартир и обобществления быта не особо котировались, но часть домов в 70-е и 80-е годы с похожими идеями было создано
- Послевоенная жизнь и реставрация Дома - к 2000м годам дом постепенно пришел в упадок и появилась идея о его реконструкции, но это потребовало расселения жильцов и выкупа квартир, что шло медленно. Но в 2016-2020 году удалось провести реставрацию этого культого места и теперь Дом Наркомфина - это институциональный и исследовательский проект Музея современного искусства «Гараж».

#Architecture #Design #Culture

Экстремальное программирование: постановка процесса (Extreme Programming Applied: Playing to Win) - Part I

Сегодня я решил вспомнить книгу про экстремальное программирование (XP) из времен старта моей карьеры (на русском она появилась 20 лет назад, а на английском за пару лет до этого). В этой книге авторы разбирают что такое XP и главное, как его применить на практике. Интересно, что большая часть практик XP стала стандартом де-факто и сейчас их даже не надо продавать, так как они считаются некоторым baseline для инженерных практик. Но в начале 2000х XP проиграла маркетинговую войну другим Agile подходам навроде Scrum и его вариаций - инженеры не так красиво пели, как любители поговорить за процессы и ритуалы, поэтому скрам был сильно известнее XP:)

Ну а теперь перейдем к самой книге.

Введение: играть, чтобы выиграть - здесь авторы говорят о том, что софт - это изменчивая сущность и нам надо быть готовым к модификациям нашей системы, а для этого надо учитывать стоимость изменений. И старые подходы (аля waterfall и тяжеловесное планирование, проектирование и т.д.) приводили к тому, что стоимость изменений в процессе создания системы экспоненциально росла, поэтому изменений старались избегать. Но в XP все сделано так, чтобы сгладить стоимость изменений. Именно это авторы и предлагали использовать в качестве главного аргумента.
XP в кратком изложении - здесь авторы рассказывают про ключевые ценности XP и основные принципы, которые раскрываются дальше на страницах книги и объясняется как их практически применять, а также продавать коллегам для внедрения изменений. Основные ценности XP такие
1) Коммуникация (Communication) - работая в стиле XP невозможно избежать общения
2) Простота (Simplicity) - XP всегда предлагает решать проблему самым простым способом
3) Обратная связь (Feedback) - частый и качественный feedback позволит оставаться продукту/проекту на правильной траектории
4) Храбрость (Courage) - для движения с максимальной скоростью нужна храбрость. Плюс надо уметь побеждать sunk cost fallacy

Дальше авторы вспоминают про основные практики, которых всего 12 штук, но в дальше в самой книге они делят их на шесть стартовых и остальные, что надо внедрять во вторую очередь, поэтому я тут начну с первых 6
1) Игра в планирование - здесь авторы рассказывают про планирование и оценку трудозатрат. Фактически, предлагается следующая частотность Release planning (quaterly) -> Iteration planning (2 weeks) -> Standup meetings (everyday). Авторы отмечают важность оценивания трудозатрат для того, чтобы дискутировать с заказчиком на уровне приоритетов задач и стоимости их реализации. Это похоже на общепринятую сейчас практику
2) Частые релизы (Small releases) - частотность релизов и их небольшой размер очень хорошо укладываются в lean практики и позволяют инкрементально получать ценность. А с точки зрения инженерии это позволяет поддерживать нужный темп и не слишком рисковать во время каждого релиза - подробнее рекомендую почитать книгу "Accelerate" (см. мой пост) и про DORA метрики. Это уже стандарт де-факто
3) Тестирование - фактически, авторы рассказывают про TDD и объясняют зачем нам нужны тесты в сложных системах. Это уже стандарт де-факто.
4) Парное программирование - тут речь про работу в паре за одним компьютером при реализации одной задачи. Эта практика так и не стала общепринятой, но вместо нее принято делать design review до реализации задачи, а также code review уже после ее реализации
5) Рефакторинг - здесь авторы вспоминают Мартина Фаулера и его классическую книгу "Рефакторинг", а сам подход сейчас является стандартом де-факто в индустрии
6) Continuous integration - авторы продают важность интеграции проекта и прогона тестов как можно чаще, например, несколько раз в день. С тех пор тулинг вокруг CI сильно улучшился и мы собираем приложения и гоняем тесты на каждый коммит. Плюс теперь принято использовать TBD (trunk based development), который доводит идею continuous integration до логического финала

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

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

Экстремальное программирование: постановка процесса - Part II (Extreme Programming Applied: Playing to Win)

Этот пост заканчивает разбор книги из начала 2000х, рассказ про которую я начал в предыдущем посте. Здесь я планировал рассказать про шесть оставшихся практик второй очереди, а также дать материалы для дальнейшего изучения. Ну поехали
1) Простой дизайн (Simple Design) - здесь суть в том, чтобы не делать большую архитектуру перед стартом проекта, а проектировать по мере поступления новой информации и требований. Звучит хорошо, но у неопытных ребят это превращается в big ball of mud. В итоге, тут до сих пор есть вопросики о том, а как же правильно проектировать комплексные системы
2) Коллективное владение кодом (Collective code ownership) - коллективное владение кодом внутри команд является стандартом де-факто, а вот контрибьютинг в код соседних команд до сих пор не так тривиален - есть такое направление как innersourcing, про которое упоминают при желании уменьшить ожидания и зависимости от других команд. Основная суть как раз в том, чтобы не ждать соседнюю команду, а самому набацать им кода и влить через процедуру merge request. На этом пути есть ряд организаионно-технических проблем, но bigtech компании как-то справляются с ними:)
3) Приемочные тесты (Acceptance tessting) - суть в том, чтобы фиксировать ожидания заказчика и писать приемочные тесты, которые выступают как фиксация критериев приема задач со стороны заказчика. Сейчас этот подход чуток расширился до критериев готовности по задачам (definition of done), которые должны быть выполнены прежде, чем элемент бэклога (пользовательская история) будет считаться завершенным.
4) Стандарты кодирования (Coding standards) - авторы говорили про стандарты кодирования, которые сейчас автоматизируются на уровне linters. Но если пойти чуть дальше, то стандарты помогают и на уровне использования общих библиотек или стандартизации подходов к проектированию API
5) Метафора системы (metaphor) - интересная концепция про использование метафор внутри системы и общего языка для общения технарей и бизнес-заказчиков. Лет через 5 после выпуска этой книги вышла книга "Domain-Driven Design: Tackling Complexity in the Heart of Software", в которой Эрик Эванс представил концепцию DDD и ввел термин ubiquitous language
6) Сорокочасовая рабочая неделя (40-hour week) - здесь авторы говорят про отсутствие переработок и нормальный work/life balance. Интересно, что уже тогда эта тема была важна и вошла в набор принципов.

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

P.S.
Если этот обзор понравился, то рекомендую почитать книги
- Modern software engineering - это недавняя книга Дейва Фарли, про которую я уже писал. В этой книге Дейв рассказывает примерно про эти же практики, но в приложении к текущему уровню индустрии
- Accelerate - это книга 2017 года от Nicole Forsgreen, Jez Humble и Gene Kim, про которую я уже писал. В этой книге авторы рассказывают результаты DevOps Reports за 5 лет и показывают как инженерные практики помогают бизнесу двигаться быстрее
- Tidy First?: A Personal Exercise in Empirical Software Design (Чистый дизайн. Практика эмпирического проектирования ПО) - недавняя книга Кента Бека, создателя eXtreme Programming, про которую я уже рассказывал. В этой книге Кент подробнее ракрывает суть принципа Simple Design:)
- A philosophy of software design - книга Джона Остерхута, создателя алгоритма консенсуса Raft, про которую я уже рассказывал. В этой книге Джон круто раскрывает про свой подход к дизайну софта и важности инженерных практик

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

Super Pumped: The Battle for Uber (Битва за Uber) (Рубрика #Management)

Прочитал очередную книгу во время отпуска - на этот раз про историю Uber. Эта компания продемонстрировала силу подрывных инноваций, буквально разрушив стандартный мир таксистов и диспетчеров и построив на осколках новый красивый и удобный мир для пассажиров. Этой революцией руководил Трэвис Каланик, который ценил результаты превыше всего и игнорировал законы, выкручивая руки властям. Эта книга читается как боевик и рассказывает историю удивительно детально, так как Майк Айзек был штатным журналистом в New York Times и писал о технологических компаниях и очень много про Uber, который гремел в 2010х. Пока я читал книгу, то ловил себя на мысли, что это почти готовый сценарий - оказалось, что так думал не только я, но и ребята из Showtime, которые в 2022 году выпустили одноименный сериал. Пересказывать все перипетии книги мне кажется лишним, но вот посмотреть на список ценностей, который сформулировал Тревис, мне кажется интересным. Это позволяет сравнить Uber с другими технологическими гигантами (у Тревиса было 14 принципов как и у Amazon изначально, подробнее про Amazon и его культуру можно почитать в книге "Working Backwards", про которую я рассказывал раньше)

1) Always be hustlin’ (Get more done with less, working longer, harder, and smarter, not just two out of three)
2) Be an owner, not a renter (Revolutions are won by true believers)
3) Big bold bets (Take risks and plant seeds that are five to ten years out)
4) Celebrate cities (Everything we do is to make cities better)
5) Customer obsession (Start with what is best for the customer)
6) Inside out (Find the gap between popular perception and reality)
7) Let builders build (People must be empowered to build things)
8) Make magic (Seek breakthroughs that will stand the test of time.)
9) Meritocracy and toe-stepping (The best idea always wins. Don’t sacrifice truth for social cohesion and don’t hesitate to challenge the boss)
10) Optimistic leadership (Be inspiring)
11) Principled confrontation (Sometimes the world and institutions need to change in order for the future to be ushered in)
12) Superpumped (Ryan Graves’s original Twitter proclamation after Kalanick replaced him as CEO; the world is a puzzle to be solved with enthusiasm)
13) Champion’s mind-set (Put everything you have on the field to overcome adversity and get Uber over the finish line)
14) Be yourself (Each of us should be authentic)

А после низвержения Каланика в 2017 году принципы переписали и их осталось всего 8 (подробнее можно почитать в статье 2017 года).

Если же говорить про книгу в общем, то она мне понравилась. Тревис в ней конечно описан как говнюк, но именно такой человек, который не бежит от драки, и требовался для запуска маховика двухсторонней платформы пассажиры <=> водители. В то время чиновники и стандартные компании такси горой стояли за статус кво, поэтому Тревис срезал углы и добивался результата, но в какой-то момент он перешел черту и начал вредить своей компании. Инвесторам удалось свергнуть его, подготовив целую тайную операцию. Даже уйти красиво ему не дали, слив поминутно всю информацию о свержении Майку Айзеку, который в тот же день все опубликовал в газете:)

Автор завершает книгу предостережением относительно харизматичных основателей технологических компаний навроде Тревиса Каланика (Uber), Адама Неймана (WeWork), Элизабет Холмс (Theranos) или Сэма Бенкман-Фрида (FTX). Эти лидеры умеют продавать видение будущего инвесторам так, что на них находит затмение относительно самой идеи или ее реализации, когда основатель проповедует иезуитское "Цель оправдывает средство".

#Management #Leadership #Bigtech #Processes #BusinessStory

How we use GenAI in SRE (Рубрика #SRE)

Я периодически почитываю статьи Google на тему "Distributed Systems and Parallel Computing" на их сайте research.google. Именно там я нашел статью "How we use GenAI in SRE" с абстрактом вида

Службы Google работают на крупнейшей в мире сети компьютеров. Инженеры по надежности сайтов (SRE) следят за тем, чтобы весь стек был в порядке: центры обработки данных были безопасными, хорошо подготовленными; у нас были резервные механизмы и целостность данных; чтобы убедиться, что мы правильно проектируем наш стек, используя правильные компромиссы в области хранения, репликации и программного обеспечения. Генеративный ИИ — отличный инструмент, который сделает нас сверхэффективными: имея доступ к инструментам для создания наших самых сложных конфигураций, для классификации рисков и событий, для управления большими массивами машин с помощью агентов или для дешевой автоматизации сложных рабочих процессов. В этом докладе будет рассмотрен путь, который SRE начал много лет назад, чтобы стать по-настоящему дисциплиной AI-First, и последние достижения в области инструментов, практик и рабочих процессов.

Эта статья оказалась не статьей, а простенькой презентацией от 20 апреля 2024 года (сама презентация доступна здесь). Из этой презентации можно вытащить не так много нового

1) Тезис про то, как SRE связан с работой AI систем

SRE is crucial component to operate at scale AI systems that are trustworthy, safe and efficient

2) Как SRE помогает AI
- Дизайн распределенных систем - системы, у которых основа завязана на AI, тоже должны хорошо масштабироваться и быть надежными
- Ускорить деплой - новые железные компоненты (GPU, TPU, ...) должны поступать в датацентры и эффективно шедулиться
- Trust & safety - результаты работы систем, основывающихся на AI моделях, должны быть выровнены относительно человеческих стандартов
- Эксплуатация и автоматизация - тренировка моделей и пайлайны для fine-tuning, релизов, откатов и так далее (вообще это можно называть MLOps)

3) Как AI помогает SRE
- Генеративный AI для документации и постмортемов - сохранение документации чистой и актуальной, создание изначальных постмортемов (видимо, рыба с автозаполнением части инфы)
- Автоматизация workflow - агентские процессы служат как workflow runners и выполняют часть функций на проде
- Оценка риска - еще до возникновения инцидента модели могут детектировать проблемы и исправлять часть из них
- Эффективность ресурсов - начиная с температур в датацентрам и до размещения сервисов по доступным машинкам ML модели помогают проду быть более здоровым и эффективным

В итоге, это доклад на хайповую тему, но вот содержание не уходит дальше рассказов о том, что SRE в Google теперь на AI-стероидах и применяется к AI системам:))

#SRE #Management #ML #AI #Processes #SystemDesign #DistributedSystems

Как я решаю сложные задачи или Как от решений в уме я пришел к письменной культуре (Рубрика #SelfDevelopment)

За свои 38 лет я прошел большой путь в этом вопросе. В детстве мне многое давалось легко, еще до школы я начал играть в шахматы, а в первом классе уже побеждал отца. Так я оказался в шахматной секции ДЮСШ, куда я ходил до конца седьмого класса. Там я научился отличию тактики от стратегии, расчету вариантов, а также позиционной игре (тут, кстати, были самые большие проблемы). Шахматы очень структурировали мое мышление и дали следующие перки
- Оценка позиции и проработка стратегии
- Учет конкретных деталей текущей позиции и расчет вариантов
- Умение взглянуть на позицию с позиции оппонента, задача которого не дать тебе реализовать свой план
И все бы хорошо, но я был слишком самоуверенным и ленивым - так я пришел к выводу, что все задачи мне стоит решать в голове. В школе это приводило к тому, что я часто вместо решения уравнения просто писал сразу ответ, при решении стереометрических задач представлял их в голове и тоже писал ответ:) Базовые задачки по физике я решал примерно также. Это привело к тому, что к старшим классам я не мог решать действительно сложные олимпиадные задачи, так как навыка записывать промежуточные шаги у меня не было. В десятом классе я начал учиться в ЗФТШ (заочной физико-технической школе при МФТИ). Это обучение навело меня на мысль, что надо что-то менять. За последние два класса школы я научился писать свои решения ручкой в тетради, а не оставлять в голове - это помогло мне поступить в МФТИ, где я уже строчил лекции и семинары на потоке:)
На третьем курсе университета я начал работать и я продолжать много писать и размышлять о решаемых задачах, но по-настоящему парадигма сдвинулась только тогда, когда я стал руководить людьми. Тогда я понял, что важно не просто описать решение задачи, целевой процесс или нашу стратегию развития приложения, а важно сделать так, чтобы твои коллеги это поняли:) Я начал тренировать эти навыки, но расцвели они уже после прихода в Т-Банк (тогда еще в Тинькофф). Здесь у меня команда и зона ответственности росла быстро и неотвратимо. В какой-то момент я понял, что без выстроенной письменной культуры я быстро закончусь и начал ее практиковать еще активнее - я писал RFC, ADR, планы развития, инструкции, делал автоматизации на базе wiki и макро-репортов:) Суть была в том, чтобы построить систему, в которой информация не замыкается на одном человеке, а доступна всем заинтересованным. Где-то в 2018 году я начал выступать на конференциях и завел блог на Medium, а в 2022 году - в telegram. Сейчас я здесь и пытаюсь по вечерам и выходным писать книгу, которая будет состоять из компиляции моих постов, выстроенных в нужном порядке. Идет это туговато, но если бы у меня не было письменных артефактов из прошлого, то это было бы попросту невозможно:)

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

#SelfDevelopment #Writing #Leadership #Management

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

В издательстве Питер очередная распродажа с 12 по 18 августа со скидками в 40%. Для получения этой скидки надо использовать промокод "Лето" при оформлении заказа.

В прошлую расродажу я купил себе 5 книг и одну из них уже прочитал
- Data mesh в действии - тема очень интересна в контексте ухода от стандартного DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale" и поэтому решил почитать другую книгу:)
- Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:) Хотя я эти базовые алгоритмы уже много раз изучал в разных вариациях, но решил, что книга из серии "Грокаем ..." сможет мне объяснить эти алгоритмы еще доступнее:)
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад. Решил посмотреть что авторы добавили по прошествии времени
- Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:)
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT и GPT-4, я ее уже прочел и даже рассказывал в отдельном посте.

#Sales

ЦЕХ 4 - Урок #15 "Превращение рукописи в издание. Эксперт — Светлана Мотылькова" (Рубрика #Writing)

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

Основные мысли, которые я вынес из этого урока следующие
1) При работе с издательством надо будет заключить авторский договор - бывают договоры на отчуждение прав и лицензицонные договоры - отличие как при продаже квартиры vs сдачи ее в аренду
2) Лицензионные договоры популярнее и они тоже бывают двух типов: с исключительными правами или неисключительными - неисключительный лицензионный договор позволяет автору заключать такие договоры одновременно с несколькими издательствами
3) Состав договора должен включать следующее: дата и срок действия, преамбула, предмет договора, гарантии авторства и какие права автор передает издательству. Важно подробно перечислить все права, которые автор передает издательству
4) Вознаграждения авторам бывают разные - авансовые для состоявшихся авторов в зачет royalty или только роялти без аванса
5) Условия договора можно обсуждать, задавать уточняющие вопросы и предлагать изменения, которые кажутся ему важными
6) Жизненный цикл рукописи в издательстве достаточно сложен - все направлено на то, чтобы получить на выходе качественный продукт
7) В процессе работы над книгой, автор взаимодействует с литературным редактором, научным редактором, корректором, дизайнером и арт-директором.
8) У автора нет права финального решения по названию книги, обложке, тезисам и всему остальному - надо рассчитывать на профессионализм вышеуказанных специалистов, которые не будут стрелять себе в ногу, ухудшая книгу
9) Количество всяких деталей, которые определяют качество книги, зашкаливает - поэтому издательство не зря берет свой процент за издание книги (ну или вам надо брать риски на себя, организовывать все эти процессы и самому пожинать плоды самиздата)

По итогам этого урока я понял, что мне точно надо работать с издательством - я не чувствую в себе желание заморачиваться со всеми этими вещами, но хочу получить на выходе действительно крутую книгу, которую приятно держать в руках, удобно читать, не зазорно подарить:) Судя по этому курсу ЦЕХ, МИФ в этом плане соответствует моим ожиданиям от издательства:) Мне нравится профессионализм экспертов, ведущих курс, а также работающих в МИФ практикующими редакторами, маркетологами, ...

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

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Розыгрыш билетов на IT Picnic 17 августа

17 августа в Москве в парке Коломенское пройдет большой ИТ-Пикник, про который я рассказывал раньше. У меня есть 3 билета для читателей моего канала. Чтобы определить кому достанутся билеты, я решил устроить небольшой конкурс - напишите в комментариях темы, которые вы хотели бы, чтобы я разобрал здесь отдельными постами или в видео на Youtube. Авторы самых интересных предложений получат билеты - первых два победителя я определю по количеству лайков под комментариями, а третьим получателем билета будет тот, предложение которого мне понравится больше всего:) Получателей билетов я определю завтра в 16.00 и в личку пришлю им pdf'ки с билетами.

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

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

#Conference #Software #SoftwareArchitecture #SRE

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (Как управлять интеллектуалами: я нерды & гики) - Part I (Рубрика #Management)

Я прочитал эту книгу Майкла Лоппа (Michael Lopp) на английском 5 лет назад, к тому моменту она была уже не первой свежести - пережила 3 переиздания и последнее было в 2016 году. Книга тогда мне понравилась - авторский стиль отличался легкостью и юмором и местами достаточно точно бил в цель. В 2020 году у Майкла появилась книга "The Art of Leadership", которая зашла мне еще больше (я про нее уже рассказывал). А потом прошло время и издательство "Питер" перевело книгу "Managing Humans" под названием "Как управлять интеллектуалами". Я поржал с названия и добавил его в свой виртуальный список книг, которые попали под каток вандалов-переводчиков.

Сейчас при написании своей книги про Engineering management я вспомнил произведение Майкла и решил вспомнить что в нем было хорошего и рассказать об этом вам.

Книга состоит из трех частей:
1. The Management Quiver - здесь автор использует для набора скиллов менеджера метафору стрел и колчана для них. Суть в том, что менеджмент почти всегда подразумевает решение проблем. И ваши навыки являются такими стрелами, которые позволят поразить цель и решить проблему. Одновременно, вы можете пополнять свой колчан, учась у ваших руководителей и коллег.
2. The Process is the Product - лажают все, но именно процессы помогают предотвратить проблемы и катастрофы. Процессы направлены на то, чтобы придать структуру работе и исключить действия, что совершаются наобум. Процессы создают некоторую напряженность между теми, кто создает и теми, кто оценивает. Это легко приводит к бюрократии, бессмысленным совещаниям, конфликтным ситуациям. И автор тут предлагает способы как увернуться от всего этого как Нео от пуль в Матрице
3. Versions of You - здесь автор рассказывает на пальцах о мышлении гиков и о том, как успешно научиться с разными людьми, где каждый человек - это другая версия вас:) А финальные главы этой части посвящены тому, как подготовиться к следующей работе и мирно уйти с текущей.

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

#Management #Software #Engineering #SoftwareDevelopment #Processes #Leadership