Книжный клуб - Что обсудим?!

#Life: Всем знакомо — напридумывали задач в Новый год, а к концу января всё забросили? Так пора ломать этот шаблон! 24 декабря в 18:20 по МСКприглашаем вас на онлайн-митап Under Митап. На нём я выступлю с темой: «Пора ломать шаблон: учимся ставить цели на 2026 так, чтобы не забросить их 1 февраля». Я начал использовать эту тактику в конце прошлого года ииии на мне она сработала. Волшебства не будет — будет чёткий подход, немного мотивации и живой пример того, как прошел мой год. А ещё Саша расскажет про IT-автоматизацию: коммиты, пулл-реквесты и CI/CD — как настроить процессы, чтобы они работали на вас. Всё, что нужно знать: 📍Сайт с информацией 📍Регистрация 📍Трансляция будет тут Присоединяйтесь!🌲🌲🌲

#Читаем: Лайфхак — как читать книги и не увидеть «фигу» в итоге Сделаю небольшое отвлечение от обзоров книг и расскажу, как я стал читать эффективнее. Раньше мой метод чтения был примерно таким: - Полностью читал книгу, отмечая интересные мысли. - Если книга стоящая, пытался её пересказать. Если не получалось — бегло перечитывал, уделяя внимание главным моментам. - Снова пытался пересказать. Если выходило — хорошо, если нет — читал только ключевые главы. В итоге в голове что-то оставалось, но далеко не всё. Недавно я начал пробовать методику SQ3R (или SQRRR). Она направлена на глубокое понимание и запоминание текста и состоит из пяти этапов: 📘 1. Просмотр (Skim) Бегло просматриваю книгу: оглавление, заголовки, иллюстрации, схемы. Решаю, стоит ли её читать сейчас, и изучаю структуру. ❓ 2. Вопросы (Question) Превращаю заголовки в вопросы. Спрашиваю себя: что я уже знаю? Что хочу узнать? Как это применю? 📖 3. Чтение (Read) Читаю внимательно, ища ответы на свои вопросы. Делаю заметки, не отвлекаюсь. Читаю блоками по 30 минут с перерывами. 🗣 4. Припоминание (Recall) На следующий день пересказываю материал своими словами — без подглядывания! Можно другу, коллеге или просто записать. 🔄 5. Повторение (Review) Возвращаюсь к материалу несколько раз: - на следующий день - через 3 дня - через неделю Без повторения усваивается лишь 10–30% информации. С повторением — до 90%. Эта система помогает не просто «проглотить» книгу, а действительно её усвоить. Попробуйте — и чтение станет гораздо продуктивнее! А как читаете вы?

#Читаем ГОСТы проектного управления: ГОСТ Р ИСО 21500 — описан список процессов из которых можно составить шаблон проектных работы у себя в команде Всем привет! Продолжаем разбирать ГОСТ по проектному управлению. Если в первой части были общие понятия, то здесь начинается самое интересное — как эти процессы применять на практике. Как применять процессы проектного менеджмента? Главное правило: процессы — это не пошаговая инструкция, а набор инструментов. Их можно и нужно адаптировать под каждый проект. Что важно: 1️⃣ Не все процессы нужны всегда. Выбирайте те, что помогут достичь целей вашего проекта. 2️⃣Процессы повторяются и взаимосвязаны. Например, планирование может идти параллельно с контролем. 3️⃣Учитывайте требования заказчика, спонсора и всех, кто может повлиять на проект. По сути, ГОСТ говорит: «Берите то, что работает, но не забывайте про системный подход». Два взгляда на процессы: управленческий и предметный ГОСТ предлагает сгруппировать процессы двумя способами — как вам удобнее. 1️⃣ Управленческие группы — по этапам проекта: - Инициирование — начинаем проект, назначаем руководителя. - Планирование — детальный план, бюджет, сроки. - Исполнение — делаем работу по плану. - Контроль — следим, всё ли идёт как надо, вносим изменения. - Завершение — закрываем проект, фиксируем опыт. Важный момент: эти группы не идут строго друг за другом. Контроль, например, работает на всех этапах. 2️⃣ Предметные группы — по сферам управления: Интеграция - Заинтересованные лица - Содержание - Ресурсы - Сроки - Стоимость - Риски - Качество - Закупки - Коммуникации Каждая группа содержит конкретные процессы. Например, в «Сроках» — планирование расписания, в «Рисках» — их оценка и управление. Кратко про ключевые процессы Здесь описано 40 процессов — каждый со своими целями, входами и выходами. Приведу только самые яркие: - Разработка устава проекта — официально запускаем проект, назначаем руководителя. - Определение заинтересованных лиц — выявляем всех, кто влияет на проект. - Создание WBS (структуры работ) — разбиваем проект на управляемые части. - Управление рисками — идентифицируем, оцениваем и планируем реакции. - Контроль изменений — чтобы правки не ломали весь проект. -Контроль расписания - Сохранение накопленного опыта. Цель — не наступать на одни и те же грабли в следующих проектах. Что полезного в этом ГОСТе: Дан список процессов, который можно просто взять и составить как конструктор на своем проекте.

#Читаем ГОСТы проектного управления: ГОСТ Р ИСО 21500 — Руководство по проектному менеджменту Капец, даже у меня мозг ломается от того, как написаны ГОСТы. 😂 ГОСТ Р ИСО 21500–2014 — это российская версия международного руководства (даже схемы внутри ГОСТа на английском языке с расшифровкой) по проектному менеджменту. Сейчас я опишу ключевые идеи из первых разделов (пп. 1–3.12), которые задают фундамент. Ключевые понятия, которые стоит запомнить: ▫️ Проект — это уникальный набор процессов с началом и концом, нацеленный на создание конкретного результата. Каждый проект уникален! ▫️ Проектный менеджмент — это применение методов, инструментов и процессов для достижения целей проекта. ▫️ Стратегия и проекты — проекты рождаются из возможностей, которые выявляются в рамках стратегии организации. Их цель — создание преимуществ для бизнеса. ▫️ Внешняя среда — на проект влияет множество факторов: экономика, законы, технологии, культура внутри организации. Учесть их — задача номер один. ▫️ Заинтересованные лица — это все, кто влияет на проект или подвержен его влиянию: заказчик, команда, поставщики, регулирующие органы и даже общество. ▫️ Жизненный цикл — проект делится на фазы, каждая со своими целями и результатами. Управление должно быть адаптировано под каждую фазу. ▫️ Ограничения — сроки, бюджет, ресурсы, качество, риски. Они взаимосвязаны: изменение одного влияет на другие. Три типа процессов проектного менеджмента (п. 3.12): Стандарт выделяет три ключевых типа процессов, которые взаимодействуют в течение жизненного цикла: ▫️ Процессы проектного менеджмента — уникальны для управления проектами. Они определяют, как должны управляться работы. ▫️ Процессы создания продукта — не уникальны для проектов. Они отвечают за что — за определение требований и создание конкретного продукта, услуги или результата. ▫️ Поддерживающие процессы — также не уникальны. Они обеспечивают логистику, финансы, учёт, безопасность — всё, что помогает основным процессам. Процессы также можно группировать по: ▫️Управленческим группам (инициирование, планирование, исполнение, контроль, завершение) ▫️Предметным группам (интеграция, сроки, стоимость, риски, качество, коммуникации и др.) Их комбинируют и применяют гибко, в зависимости от специфики проекта. Главный вывод из первых глав: Управление проектами — это не просто «сделать задачу», а системная деятельность, которая начинается со стратегии, учитывает окружение, вовлекает людей и балансирует между ограничениями. Без чёткого понимания основ легко упустить из виду важные детали. Мой личный вывод: Пока для меня никакой особой пользы нет, кроме напоминания о том, что надо вести таблицу рисков и помнить о том, что ЕСЛИ организация начинает проект, то этот проект — ступенька для определённой ЦЕЛИ! Читаем дальше.

#Читаем ГОСТы проектного управления: ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом». Первый ГОСТ прочитан, в целом там по пунктам перечислены этапы реализация проекта. Вот главные мысли: 1. Управление проектом — это система процессов. ИНИЦИАЦИЯ → ПЛАНИРОВАНИЕ → ИСПОЛНЕНИЕ → КОНТРОЛЬ → ЗАВЕРШЕНИЕ 2. Четыре ключевые роли. В любом проекте должны быть ясно определены: Заказчик— владелец результата. Руководитель проекта— отвечает за результат. Куратор— обеспечивает ресурсы и поддержку «сверху». Команда проекта— те, кто делает. 3. План — это не «хотелки», а договоренность. Главный вывод этапа планирования —утвержденный базовый план(по срокам, бюджету, содержанию). Это не просто график, а точка отсчета для всех решений и оценок. 4. Планировать нужно ВСЁ. Не только сроки и бюджет. Стандарт требует отдельного планирования для: Содержания(что и для кого делаем?). Рисков(что может пойти не так и что делать?). Коммуникаций(кто, что, когда и в какой форме должен знать?). Изменений(как вносить правки, чтобы не погрузиться в хаос?). 5. Контроль Цель контроля — не отчитаться, а понять причины отклонений от плана и сформировать корректирующие и предупреждающие действия. Без этого управление превращается в наблюдение за катастрофой. 6. Документы Утверждать до использования, вовремя обновлять, хранить актуальные версии в нужном месте, обеспечивать конфиденциальность. Устаревший документ на столе — источник ошибок. Резюме: Этот ГОСТ — напоминание, что успешный проект строится на дисциплине, ясности и предсказуемости, а не на экспромнте и "вдруг прокатит"

#Книга месяца - Читаем ГОСТы Решил почитать регламенты по проектному управлению. Если получится надыбть PM book 7, тоже прочитаю. И конечно поделюсь с вами инсайтами 🔥 Список: ГОСТ Р 54869-2011 — Проектный менеджмент. Требования к управлению проектом ГОСТ Р ИСО 21500-2014 — Руководство по проектному менеджменту (основные принципы и процессы) ГОСТ Р 58305-2018 — Система менеджмента проектной деятельности ГОСТ Р 54870-2011 — Проектный менеджмент. Требования к управлению программами ГОСТ Р 54871-2011 — Проектный менеджмент. Требования к управлению портфелями проектов ГОСТ Р 56715.5-2015 — Проектный менеджмент. Системы менеджмента проектной деятельности. Термины и определения

#Читаем «Проект «Феникс»: Как DevOps устраняет хаос и ускоряет развитие компании»: итоговый обзор 🔥 Эта книга — яркий представитель одного из моих любимых жанров — бизнес-роман. Читается так же легко, как художественная литература, но при этом содержит массу полезных практических мыслей. Основа сюжета навеяна «Целью» Голдратта: здесь тоже есть главный герой-руководитель, которому в решении рабочих проблем помогает внешний «гуру». Описанные события очень напоминают мою прошлую работу — полный бардак, неразбериха и невозможность (или нежелание) высшего руководства наладить процессы в компании. От книги у меня остались положительные эмоции, но также возникли некоторые вопросы. Самый главный вопрос: вся книга описывает 3 месяца из жизни компании. За этот срок в IT-отделе перевернули все процессы и получили рекордный рост за квартал. Не кажется ли это дичью? С учетом того, что в книге не раз упоминается, что компания огромная и ее акции то ли уже котируются на Уолл-стрит, то ли готовятся к IPO. Что такое 3 месяца? Да ничего! Поэтому либо это фантастика, либо идеи были настолько очевидными, что не хватало всего лишь РЕАЛЬНОГО руководителя и ПИНКА высшему руководству для действий. Мне кажется, главный герой просто оказался в нужном месте в нужное время, но без его опыта, характера и помощи ментора ничего бы не вышло — это факт. Ладно, давайте теперь о полезном, а его здесь много. В компании должен быть лидер, который наладит взаимодействие между отделами. Этот человек должен мыслить в масштабах всей компании и понимать существующие процессы, например, связь между IT-разработкой и бизнес-процессами. Важно в реальном времени видеть, на какой стадии находится проект и каковы сроки его окончания. Главная задача — постоянно работать над системой, выявляя и устраняя ее недостатки. А именно — постоянно искать узкие места (бутылочные горлышки): нашли, устранили, пошли искать следующие. В итоге мы приходим к тому, что называется ПРОЦЕССОМ — не как к жесткому своду правил, а как к живому механизму, главная цель которого — обеспечивать бесперебойный поток ценности от разработки к клиенту и постоянно улучшаться за счет обратной связи. На примере нашей команды: мы сейчас пытаемся по максимуму все автоматизировать, так как команда у нас небольшая, и любой сверхнагруз создает те самые «бутылочные горлышки», а автоматизация помогает их устранять. Мы типизируем проекты, чтобы для каждого был готовый шаблон. Улучшаем CI/CD, подключаем ИИ к ревью — чтобы разработчики не тратили на это время и могли сосредоточиться на новой функциональности, а клиент получал новые фичи быстрее и экономил бюджет. Настраиваем автосборки и оповещения. Далее планируем внедрить процессы по управлению качеством. Потом будем смотреть на эффективность и думать над улучшениями — и так по кругу. В итоге шаг за шагом наши процессы будут улучшаться, а время работы — сокращаться. Это и есть принцип DevOps. Рекомендую к прочтению всем, даже тем, кто не связан с IT.

#Читаем «Как DevOps устраняет хаос и ускоряет развитие компании»: Я дочитал книгу. Полный восторг! Сейчас перескажу вам самую суть книги без комментариев, а отдельным постом опишу свои мысли по всей книге, потому что именно она достойна глубокого анализа и обсуждения. В книге автор говорит о трех принципах — «Три пути». Первый путь касается хода работы слева направо: от разработчиков к клиенту. Чтобы максимизировать скорость этого потока, необходимо: - Придерживаться небольших партий и интервалов в работе. - Никогда не передавать дефекты далее по процессу. - Постоянно оптимизировать систему в глобальном смысле. Второй путь касается постоянной и быстрой обратной связи. Это движение справа налево по всем этапам потока создания ценности, которое приводит к тому, что мы можем предотвратить повторное появление проблем и наладить их более быстрое обнаружение и устранение. Таким образом, мы создаем качество с самых истоков, накапливая и применяя знания именно там, где они нужны. Третий путь касается создания культуры, которая укрепляет две вещи: - Постоянные эксперименты, требующие готовности рисковать и учиться как на ошибках, так и на успехах. - Понимание того, что повторение и практика лежат в основе мастерства. «Что со всем этим делать?» — спросите вы. Я рекомендую проанализировать свои процессы, прислушаться к автору, и вы поймете, что, вероятно, у вас те же проблемы, что описаны в книге (а выше как раз приведены решения).

#Читаем «Как DevOps устраняет хаос и ускоряет развитие компании» Хочу оставить классную цитату здесь: "Лучшие команды добиваются лучших результатов, когда постоянно повторяют одни и теже процессы. Повторение создаем привычки, а привычки обеспечивают мастерство в любом деле". Как я согласен с этой фразой. Системно позовляет убрать героизм и ночные работы, когда процессы становятся автоматическими происходит снижение когнитивной нагрузки на мозг сотрудников, повторение позволяет оттачивать процессы и находить в них ошибки для устранения. Всем это в итоге приводит к масштабируемости процессов.

#Читаем «Как DevOps устраняет хаос и ускоряет развитие компании» — и опять системная работа. Я кое-что понял про себя. Я классно справляюсь с задачами, когда мне понятны правила игры, и плохо, когда есть неопределённость и объём информации столько, что мне сложно внутри головы её расфасовать и отсортировать. Как раз для таких случаев есть графики, таблицы и другие способы систематизации информации. Прочитал ещё 63 страницы пользы. Чтобы укротить хаос, надо: - Понимать ход работы — где мы находимся? - Сделать время ожидания видимым, чтобы ты знал, в каких местах происходят затыки и где теряется время. - Постоянно давить на систему с целью избавиться от тех недостатков, которые в ней есть. Это простые прописные истины, но у многих ли так сделано? Далее — просто несколько умных цитат из книги: - «Улучшение ежедневной работы даже важнее, чем выполнение её». - «Стандартизация и документирование работы, чтобы её могло выполнить несколько человек». - «Повторение рождает привычки, а привычки — основа мастерства». - «Если ресурс используется на пятьдесят процентов, время ожидания равняется 50/50 или единице. Если ресурс используется на девяносто процентов, время ожидания — 90/10 или в девять раз дольше». - «Как нам управиться со всеми срочными делами? Эти задачи увеличивают скорость работы? Они увеличивают операционную стабильность или сокращают время для поиска причин сбоев и восстановления после них? Если нет — они не срочные». Читаем дальше )

Народ, напишите пжл книги в коментах по упарвлению проектами, надо переосмыслить подход...

#Читаем «Как DevOps устраняет хаос и ускоряет развитие компании»: господи, как это похоже на то, с чем я работал на госслужбе. Как и в книге Голлдрата, у главного героя есть ментор, который задает вопросы и ставит задачу найти ответы самостоятельно. Вопросы были такие: 1.Что такое работа? 2.Какие виды работ есть? По факту, со 115-й страницы до 200-й главный герой искал ответ и нашел: 1.Бизнес-проекты 2.Внутренние проекты 3.Изменения 4.Внеплановая работа («горящая») Четвертый пункт — самый важный. Потому что незапланированная работа съедает запланированный бюджет, и задача состоит в том, чтобы научиться этим управлять. И как я себя узнал в этой книге! Когда ты подходишь к начальству и говоришь: «нам надо стабилизировать ситуацию, а для этого нужно остановить процессы», — в ответ мне только пальцем у виска крутили. И вот в книге ментор и главный герой предлагают ТУ ЖЕ САМУЮ ИДЕЮ. А идея проста: если заморозить всю работу, кроме «горящей», то объем работы будет уменьшаться, сроки — улучшаться. А если не разобраться с завалом и снова дать нагрузку, то все вернется на круги своя. И поэтому сейчас герой тестирует подход — «заморозка» всех проектов на 2 недели, пока не разберутся с самым главным проектом на производстве, а там сделают дальнейшие выводы. Читаем дальше, очень интересно ) Сталкивались ли вы с тем, что незапланированная работа съедала все ресурсы?

#Читаем «Как DevOps устраняет хаос и ускоряет развитие компании»: проблема «незаменимого человека» В больших романах не всегда есть время на выжимку идей, но одна проблема красной нитью проходит через все 115 страниц. И это проблема «незаменимого человека». В компании есть программист по имени Брент. Он — местный супер-сеньор, который один-единственный знает всю систему огромной компании. И, как вы думаете, что происходит? У компании постоянные краши, и все, естественно, бегут к Бренту. А он при этом должен тащить ещё и главный проект — «Феникс». Знакомая ситуация? Не кажется ли вам, что такой сотрудник — это самое узкое «бутылочное горлышко» в системе? Интересно, как герои будут решать эту проблему...

Пришло мое золото)

#Читаем: «Как DevOps устраняет хаос и ускоряет развитие компании» По дороге в Екатеринбург и обратно во Владимир прочитал уже около 100 страниц этой книги. Сначала мне показалось, что эта книга чем-то похожа на «Цель» Элияху Голдрата, но сейчас кажется, что это почти что копия. Кстати, в главе 7 даже есть отсылка к этой книге! Но почему автора зовут не Элияху, а Элайя М. Голдрат? Интересно, почему имена разные? Оказывается, Элайя — это имя для неформального общения в Америке. На данном этапе в жизни героя, как и в книге Голдрата, появился ментор. Он сравнивает IT с производственным циклом, рассказывает о «бутылочном горлышке» и предлагает найти ответ на вопрос, что же такое «работа». Ну, блин, прям копия Голдрата! Посмотрим, что будет дальше, но на самом деле становится только интереснее.

#Читаем: "Как DevOps устраняет хаос и ускоряет развитие компании" Так как еду в поезде, экспресс-отзыв по первым 5 главам. Книга супер!🔥🔥🔥 Начало очень похоже на книгу Эллияху Голдрата. Героя повысили и кинули в пекло проблем. У героя системное мышление и естественно он начинает наводить порядок. Сколько ещё нужно примеров, чтобы начать всем работать системно!?)

#Книга месяца - "Как DevOps устраняет хаос и ускоряет развитие компании" Джин Ким, Кевин Бер, Джордж Спаффорд" Месяц смотрел на эту книгу на полке в офисе, собрался с духом и взял в руки, очень приятно удивлен, что написана в моем любом стиле - бизнес роман, а это в корне меняет дело. Я даже отложил книгу по цифровизации производства (ее в следующем месяце)!!!

#Читаем: «Менеджмент на основе данных» Дочитал книгу. Резюме такое: «Руководителям нужно помнить о 4 уровнях логики при принятии решений». Из этой мысли вытекает, что для принятия грамотного решения нужны данные. Их нужно правильно собрать, обработать и на их основе построить гипотезы, которые затем следует проверить. Только после этого принимается непосредственное решение. Этот подход и называется управлением на основе данных. Но здесь важно не забывать, что математика работает только с большой группой людей. То есть вы не сможете практически применить ваши выводы к отдельному человеку, поскольку поведение людей непредсказуемо — от болезни родственников до четвёртой фазы луны. Поэтому идеальный подход — это математика плюс понимание особенностей конкретного человека при принятии окончательных решений. Книгу советую к прочтению! 🔥