Как научиться замечать свой рост
Не знаю как вам, а мне всегда трудно было замечать собственный рост. Я регулярно ловлю ощущение топтания на месте и даже какого-то уныния, что «и так не получается, и вот так не получается». Иногда даже накатывает желание сказать «ну и ладно», как знаменитый котенок из старого советского мультфильма.
Означает ли это, что я не расту? Вовсе нет. Просто для того, чтобы заметить свой рост, мне нужно одно из двух:
➡️ Сделать качественный скачок, когда уже трудно будет отпираться
➡️ Сделать осознанные усилия, чтобы этот самый рост заметить
Первое работает хорошо, но часто этот номер проворачивать не получится — для этого нужны какие-то особые условия (крайне челленджовые задачи, новые обязанности, повышение, смена работы и тд). Поэтому качественный скачок работает скорее «редко, но метко».
Проблема в том, что для развития важно сохранять и поддерживать свою мотивацию. А для этого нужна положительная обратная связь. Качественный скачок ее дает в огромном количестве, но из-за редкости на него в этом плане рассчитывать не стоит. И нам остаются лишь осознанные усилия по отслеживанию своего роста.
Для такого регулярного отслеживания я использую рефлексию. Я люблю задавать себе вопросы, подобные следующим:
➡️ В чём я стал лучше за последнее время? (Обычно я люблю взять первый ответ, который приходит в голову, и разобраться в нем)
➡️ Что мне стало даваться гораздо легче, чем раньше?
➡️ Какие задачи за последнее время я сделал очень хорошо и поэтому доволен собой?
➡️ И тому подобные.
Для меня важно задавать себе подобные позитивные вопросы. Из каждого утюга звучат вопросы «улучшайся, делай лучше, рефлексируй что не получилось». Но рефлексировать над успехами не менее важно, потому что они дают чувство уверенности в себе и опору для дальнейшего развития.
Не знаю как вам, а мне всегда трудно было замечать собственный рост. Я регулярно ловлю ощущение топтания на месте и даже какого-то уныния, что «и так не получается, и вот так не получается». Иногда даже накатывает желание сказать «ну и ладно», как знаменитый котенок из старого советского мультфильма.
Означает ли это, что я не расту? Вовсе нет. Просто для того, чтобы заметить свой рост, мне нужно одно из двух:
Первое работает хорошо, но часто этот номер проворачивать не получится — для этого нужны какие-то особые условия (крайне челленджовые задачи, новые обязанности, повышение, смена работы и тд). Поэтому качественный скачок работает скорее «редко, но метко».
Проблема в том, что для развития важно сохранять и поддерживать свою мотивацию. А для этого нужна положительная обратная связь. Качественный скачок ее дает в огромном количестве, но из-за редкости на него в этом плане рассчитывать не стоит. И нам остаются лишь осознанные усилия по отслеживанию своего роста.
Для такого регулярного отслеживания я использую рефлексию. Я люблю задавать себе вопросы, подобные следующим:
Для меня важно задавать себе подобные позитивные вопросы. Из каждого утюга звучат вопросы «улучшайся, делай лучше, рефлексируй что не получилось». Но рефлексировать над успехами не менее важно, потому что они дают чувство уверенности в себе и опору для дальнейшего развития.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍17🔥4❤2
Практикум «ИнфоСушка»: прочитать меньше, применить больше
С глубокого детства система образования вбивает нам в голову, что с любым материалом нужно работать «от корки до корки». Нельзя бросать книгу на середине! И прочитать только две нужные главы тоже нельзя! Если уж взял книгу в руки, то изволь читать от введения до заключения и не пропустить ни буковки.
Даже в школе и университете этот подход имел мало смысла. А уж во взрослом возрасте читать всё от буквы до буквы вообще превращается в способ медленного самоубийства от скуки. В итоге мы страдаем от скучных лекций или продираемся сквозь водянистые книги просто потому, что «уже начали, бросать нельзя».
В итоге получаем грустные картины:
➡️ Тимлид на грани выгорания по вечерам (потому что днём сроки горят) пытается запихнуть в себя книги по менеджменту и архитектуре, хотя голова уже не соображает.
➡️ Senior, который мечтает стать архитектором, месяц за месяцем откладывает книги и статьи по системному дизайну, потому что они набиваются в бэклог быстрее, чем он успевает их читать.
➡️ Продакт-менеджер и маркетолог пытаются разобраться в сложнейшей IT-теме в сжатые сроки, захлёбываясь водой из курсов и статей.
➡️ Вечный студент пишет тонны конспектов по прочитанным книгам и статьям, чтобы больше никогда к ним не возвращаться.
Вместо реального самообразования мы копим интеллектуальный жир. Поглощая тонны информации, мы забиваем головы бесполезными фактами, страдая от того, что не запоминаем ещё больше. А наш мозг заботливо стирает из памяти всё то, что не применяется на практике.
Мне это осознание обошлось дорого и болезненно. Но с тех пор я начал строить конвейер работы с информацией и идеями, который сфокусирован не на бесконечном поглощении материалов, а на их осмыслении и внедрении в рабочую практику.
Именно этим мы занимались на первом потоке моего практикума «ИнфоСушка». Мы ломали старые шаблоны и заменяли их более продуктивными, возвращали себе ответственность за самообучение и учились делать новый опыт явным.
Вот пара реальных ситуаций с первого потока:
➡️ Студент годами боролся с режимом сна. Ранее он мучил профильную книгу целый месяц, прочитал 50 страниц и бросил. На практикуме он за полчаса дошёл до 90-й страницы, полностью скипнул водянистые истории автора, нашёл главу «Как остановить внутреннюю болтовню», забрал чек-лист и ушёл внедрять. Результат — чистая практика за 30 минут.
➡️ Студент, изучающий английский, долго находился на плато B1, пытаясь учить «всё сразу». На практикуме он сузил цель до конкретной боли — нехватки IT-лексики для созвонов, настроил работу с LLM и занимается 18 дней подряд без единого пропуска и с удовольствием, потому что видит смысл в каждом действии.
➡️ Студентка пошла на офлайн-лекцию, на середине поняла, что спикеры льют воду, встала и ушла, сэкономив четыре часа, а затем оформила возврат за ненужную подписку на курс, забрав оттуда только один точечный навык.
Практикум — это не лекции вида «посмотрел и забыл», а сложная аналитическая работа, из-за которой первое время будут возникать сопротивление и желание бросить. Мы будем учиться ставить цели на чтение, безжалостно отбрасывать воду, бороться с FOMO и внедрять прочитанное в свою жизнь, превращая интеллектуальный жир в мышцы личного опыта.
Что вас ждёт внутри практикума «ИнфоСушка»
➡️ Записи уроков. Все материалы доступны сразу, проходить их можно в комфортном темпе.
➡️ Практические задания с проверкой. Каждый блок содержит задания для отработки.
➡️ Закрытый чат поддержки. Общий чат практикума, где можно сдать домашку, задать вопрос или поделиться инсайтом.
➡️ Q&A-сессии. По мере накопления вопросов я провожу живые сессии вопросов и ответов.
➡️ Дополнительные материалы. База уроков постепенно пополняется ответами на запросы студентов и новыми интересными техниками.
➡️ Доступ навсегда. Вы получаете бессрочный доступ к чату, материалам и Q&A-сессиям.
Цена практикума: 9900р.
Если вы готовы перестать копить закладки и хотите научиться превращать информацию в реальные инструменты для жизни, я жду вас в практикуме «ИнфоСушка».
📎 Присоединиться можно по ссылке.
С глубокого детства система образования вбивает нам в голову, что с любым материалом нужно работать «от корки до корки». Нельзя бросать книгу на середине! И прочитать только две нужные главы тоже нельзя! Если уж взял книгу в руки, то изволь читать от введения до заключения и не пропустить ни буковки.
Даже в школе и университете этот подход имел мало смысла. А уж во взрослом возрасте читать всё от буквы до буквы вообще превращается в способ медленного самоубийства от скуки. В итоге мы страдаем от скучных лекций или продираемся сквозь водянистые книги просто потому, что «уже начали, бросать нельзя».
В итоге получаем грустные картины:
Вместо реального самообразования мы копим интеллектуальный жир. Поглощая тонны информации, мы забиваем головы бесполезными фактами, страдая от того, что не запоминаем ещё больше. А наш мозг заботливо стирает из памяти всё то, что не применяется на практике.
Мне это осознание обошлось дорого и болезненно. Но с тех пор я начал строить конвейер работы с информацией и идеями, который сфокусирован не на бесконечном поглощении материалов, а на их осмыслении и внедрении в рабочую практику.
Именно этим мы занимались на первом потоке моего практикума «ИнфоСушка». Мы ломали старые шаблоны и заменяли их более продуктивными, возвращали себе ответственность за самообучение и учились делать новый опыт явным.
Вот пара реальных ситуаций с первого потока:
Практикум — это не лекции вида «посмотрел и забыл», а сложная аналитическая работа, из-за которой первое время будут возникать сопротивление и желание бросить. Мы будем учиться ставить цели на чтение, безжалостно отбрасывать воду, бороться с FOMO и внедрять прочитанное в свою жизнь, превращая интеллектуальный жир в мышцы личного опыта.
Что вас ждёт внутри практикума «ИнфоСушка»
Цена практикума: 9900р.
Если вы готовы перестать копить закладки и хотите научиться превращать информацию в реальные инструменты для жизни, я жду вас в практикуме «ИнфоСушка».
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥10⚡2👍1💯1🤝1
«Волкодав», Мария Семёнова
Я вообще люблю всякую добротную фэнтезятину. Но действительно крутые произведения и циклы встречаются нечасто.
Мой эталон (по впечатлениям от чтения) — цикл «Страж» Алексея Пехова. И этот цикл задрал мне планочку настолько высоко, что я долгое время не мог найти что-то хотя бы подобное по эмоциям и интересности чтения.
Когда я в прошлый раз размышлял: «А чего бы такого почитать?», то внезапно вспомнил, что мой друг Серёга уже несколько раз рекомендовал мне «Волкодава». «Почему бы и нет?» — подумал я и купил книгу.
В итоге я просто провалился в неё с головой. Я традиционно читаю перед сном (недолго, минут 10, просто как ритуал) — и впервые за долгое время я вечером прямо предвкушал момент, когда уже смогу пойти почитать. Также я читал по дороге в метро, на отдыхе и даже в бессонную ночь.
«Волкодав» — это качественное, очень интересное и увлекательное фэнтези со славянским вайбом. Первая книга превосходна! Надеюсь, что весь цикл будет настолько же хорош.
Я вообще люблю всякую добротную фэнтезятину. Но действительно крутые произведения и циклы встречаются нечасто.
Мой эталон (по впечатлениям от чтения) — цикл «Страж» Алексея Пехова. И этот цикл задрал мне планочку настолько высоко, что я долгое время не мог найти что-то хотя бы подобное по эмоциям и интересности чтения.
Когда я в прошлый раз размышлял: «А чего бы такого почитать?», то внезапно вспомнил, что мой друг Серёга уже несколько раз рекомендовал мне «Волкодава». «Почему бы и нет?» — подумал я и купил книгу.
В итоге я просто провалился в неё с головой. Я традиционно читаю перед сном (недолго, минут 10, просто как ритуал) — и впервые за долгое время я вечером прямо предвкушал момент, когда уже смогу пойти почитать. Также я читал по дороге в метро, на отдыхе и даже в бессонную ночь.
«Волкодав» — это качественное, очень интересное и увлекательное фэнтези со славянским вайбом. Первая книга превосходна! Надеюсь, что весь цикл будет настолько же хорош.
1🔥15👍5🤝3⚡1💯1
Как закончить спор, в котором оба правы
Недавно двое моих коллег крепко зарубились по поводу одного API-контракта. Позиция каждого была понятна, и оба хотели сделать хорошо, только договориться в деталях не могли. А я просто сидел и наблюдал — до определённого момента.
Конфликты и споры внутри команды — это нормально и естественно. Как писал Ленсиони в книге «5 пороков команды», если в команде нет конфликтов, то с высокой долей вероятности всем вообще всё равно, что происходит (что намного хуже самих конфликтов).
Проблемы начинаются, только если конфликт:
➡️ затягивается;
➡️ переходит на личности;
➡️ начинает затрагивать всё больше и больше участников.
В такой ситуации конфликту нужна третья сторона — фасилитатор. Это человек относительно беспристрастный, который сможет рассудить участников и вывести их на конструктивный диалог. В командах фасилитатором чаще всего выступает руководитель (он не идеально беспристрастен, зато обладает контекстом и заинтересован в решении конфликта).
В нашей ситуации таким фасилитатором выступил я. В какой-то момент я осознал, что ребята начинают ходить по кругу и ни одна сторона не хочет уступать другой. Я понял, что они уже за деревьями не видят леса: желание «пропихнуть своё решение» заставило их забыть, что мы все работаем в одной команде и делаем одно дело.
Всё, что я сделал, — это прервал их перепалку и напомнил им несколько простых вещей:
➡️ я уважаю мнение каждого из них как профессионала;
➡️ каждый из них по-своему прав, и его предложение — хорошее;
➡️ оба они движимы желанием сделать хорошо (и поэтому спорят);
➡️ мы все — одна команда и делаем одно дело, поэтому нужно найти решение, которое будет лучше для команды.
Удивительно, но после этого спор (длившийся уже почти час) сошёл на нет, и буквально за 10 минут ребята договорились.
Когда члены команды конструктивно спорят, это хорошо. Но иногда им нужно немного помочь принять финальное решение, потому что в пылу спора они могут излишне увлекаться своими идеями и забывать про общую картину.
Недавно двое моих коллег крепко зарубились по поводу одного API-контракта. Позиция каждого была понятна, и оба хотели сделать хорошо, только договориться в деталях не могли. А я просто сидел и наблюдал — до определённого момента.
Конфликты и споры внутри команды — это нормально и естественно. Как писал Ленсиони в книге «5 пороков команды», если в команде нет конфликтов, то с высокой долей вероятности всем вообще всё равно, что происходит (что намного хуже самих конфликтов).
Проблемы начинаются, только если конфликт:
В такой ситуации конфликту нужна третья сторона — фасилитатор. Это человек относительно беспристрастный, который сможет рассудить участников и вывести их на конструктивный диалог. В командах фасилитатором чаще всего выступает руководитель (он не идеально беспристрастен, зато обладает контекстом и заинтересован в решении конфликта).
В нашей ситуации таким фасилитатором выступил я. В какой-то момент я осознал, что ребята начинают ходить по кругу и ни одна сторона не хочет уступать другой. Я понял, что они уже за деревьями не видят леса: желание «пропихнуть своё решение» заставило их забыть, что мы все работаем в одной команде и делаем одно дело.
Всё, что я сделал, — это прервал их перепалку и напомнил им несколько простых вещей:
Удивительно, но после этого спор (длившийся уже почти час) сошёл на нет, и буквально за 10 минут ребята договорились.
Когда члены команды конструктивно спорят, это хорошо. Но иногда им нужно немного помочь принять финальное решение, потому что в пылу спора они могут излишне увлекаться своими идеями и забывать про общую картину.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍11❤7🔥3⚡1💯1
Как принимать решения, о которых не придётся жалеть
В управлении часто (на самом деле практически никогда) нет решений, которые были бы однозначно хорошими и без побочек. Это только в программировании логика детерминирована и конкретна, в жизни же всё намного сложнее.
Иногда из-за всех побочек решение принять может быть непросто. Настолько непросто, что я временами откровенно залипаю между двумя-тремя альтернативами как Буриданов осёл, будучи не в состоянии выбрать. В таких ситуациях нужны простые и относительно универсальные принципы, которые помогут сделать выбор.
Один из таких принципов – золотое правило нравственности. Звучит оно следующим образом:
Любые решения руководителя касаются других людей. Всегда, без исключений. В трудных ситуациях золотое правило нравственности заставляет не только подумать о преимуществах и недостатках – оно также подталкивает к тому, чтобы посмотреть на ситуацию глазами тех людей, которых принимаемое решение затронет (включает эмпатию).
Не всегда эти решения будут хорошими, правильными или приятными (а скорее даже наоборот). Но по своему опыту могу сказать, что решения, принятые через призму золотого правила нравственности, – это решения, о которых мне ни разу не пришлось сожалеть.
В управлении часто (на самом деле практически никогда) нет решений, которые были бы однозначно хорошими и без побочек. Это только в программировании логика детерминирована и конкретна, в жизни же всё намного сложнее.
Иногда из-за всех побочек решение принять может быть непросто. Настолько непросто, что я временами откровенно залипаю между двумя-тремя альтернативами как Буриданов осёл, будучи не в состоянии выбрать. В таких ситуациях нужны простые и относительно универсальные принципы, которые помогут сделать выбор.
Один из таких принципов – золотое правило нравственности. Звучит оно следующим образом:
(Не) поступай по отношению к другим так, как ты (не) хотел бы, чтобы они поступали по отношению к тебе.
Любые решения руководителя касаются других людей. Всегда, без исключений. В трудных ситуациях золотое правило нравственности заставляет не только подумать о преимуществах и недостатках – оно также подталкивает к тому, чтобы посмотреть на ситуацию глазами тех людей, которых принимаемое решение затронет (включает эмпатию).
Не всегда эти решения будут хорошими, правильными или приятными (а скорее даже наоборот). Но по своему опыту могу сказать, что решения, принятые через призму золотого правила нравственности, – это решения, о которых мне ни разу не пришлось сожалеть.
1❤15👍4🔥1💯1
Не знаю как вы, а я уже начинаю планировать программу конф на осень. Расслабленный летний период заканчивается и начинается предновогодний движ!
Первая конфа, куда я точно пойду — Avito.Tech.Conf, которая пройдёт 26 сентября в Москве. Это конфа для нас, лидов, управляющих всяким-разным сложным, будь то команды или распределённые системы.
В программе конфы:
➡️ доклады
➡️ воркшопы
➡️ мастермайнды
➡️ менторские консультации
➡️ интерактивные зоны
➡️ афтепати 🔥
Программа получилась интересная, посмотреть её можно тут.
📎 Регистируйтесь на конфу по ссылке и до встречи!
Первая конфа, куда я точно пойду — Avito.Tech.Conf, которая пройдёт 26 сентября в Москве. Это конфа для нас, лидов, управляющих всяким-разным сложным, будь то команды или распределённые системы.
В программе конфы:
Программа получилась интересная, посмотреть её можно тут.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍4🔥2💯1
Engineering Leadership The Hard Parts by Juan Pablo Buriticá, James Turnbul
Название этой книги заставило меня улыбнуться, потому что я искренне сомневаюсь, что в работе руководителя есть «easy parts». В работе руководителя очень много трудностей – кризисы, дедлайны, разгребание бардаков (в некоторых случаях оставленных предыдущим руководителем). И во всём этом нужно сохранять спокойствие и человечность.
На чужих успехах мы мало чему учимся. А вот чужие неудачи и набитые шишки могут дать интересный взгляд на вещи и новые инструменты. Поскольку я не могу припомнить ни одного «простого» проекта в своей практике, я решил почитать эту книгу и впитать опыт коллег.
⭐️ О чём книга
Основная тема книги – работа руководителя в условиях хаоса и как с ним справляться, не превращаясь в феникса. Книга содержит инструменты и рекомендации для успешного управления в сложных обстоятельствах.
В книге раскрываются следующие темы:
➡️ Как выглядит хаос и в чём заключается роль руководителя в хаосе
➡️ Как подстраиваться в своей роли под хаотично меняющиеся условия
➡️ Как строить команды, которые проходят через хаос и выживают
➡️ Как налаживать разработку и поставку в условиях хаоса
➡️ Как выстраивать техническую стратегию и принципы, устойчивые к хаосу
⭐️ 3 идеи из книги
🟡 Хаос – это не только стресс и боль, но ещё и кузница сильнейших профессионалов. Можно годами управлять даже очень большой, но статичной структурой и ничему толком не научиться. Буквально один год в хаосе может дать больше, чем пять лет обычной работы.
🟡 Главный риск в хаосе – это не ошибка, а бездействие. В хаотичном окружении бывает довольно трудно направлять команду, потому что всё вокруг постоянно меняется. Но если у команды вообще нет никаких целей, то любые потрясения будут бить по ней ещё сильнее. Поэтому лучше иметь хоть какие-то цели и адаптировать их под обстоятельства.
🟡 Команды выгорают не от тяжёлой работы, а от бессмысленности происходящего. Люди могут выдерживать сложные, нагруженные недели и овертаймы, если понимают, ради чего они стараются. Если смысла в работе нет, то команда скатится в постоянное тушение пожаров и выгорание.
⭐️ Мои впечатления
Книга оказалась удивительно простой и жизненной. Узнавать себя в ней я начал прямо с первых страниц, где описываются признаки организации в хаосе (мне кажется, я там бинго собрал).
Во многом книга показалась мне больше эмоциональной и поддерживающей. Было ощущение, что авторы через всю книгу несут простую мысль: «Работать в хаосе сложно». Они заставляют читателя это признать и отталкиваться от этого, подбирая свои действия.
Это очень мудрая мысль. Работа в хаосе пожирает силы и буквально вынимает душу. Бравады и молодецкого задора хватит на некоторое время, но всему рано или поздно приходит конец. Поэтому работать в условиях хаоса нужно с полным осознанием того, что это очень сложно и далеко не бесплатно.
Инструменты, предлагаемые авторами, очень просты и применимы даже в обычных условиях: нормальная постановка целей, процесс принятия решений, практики канбана и так далее. Однако в хаосе все эти простые и правильные вещи становятся в разы важнее, потому что они помогают немного навести порядок.
Книгу рекомендую к прочтению. Мне было полезно.
Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.
➡ А для тех, кто хочет читать с большей пользой, у меня есть статья с описанием моего процесса чтения и упражнениями.
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Название этой книги заставило меня улыбнуться, потому что я искренне сомневаюсь, что в работе руководителя есть «easy parts». В работе руководителя очень много трудностей – кризисы, дедлайны, разгребание бардаков (в некоторых случаях оставленных предыдущим руководителем). И во всём этом нужно сохранять спокойствие и человечность.
На чужих успехах мы мало чему учимся. А вот чужие неудачи и набитые шишки могут дать интересный взгляд на вещи и новые инструменты. Поскольку я не могу припомнить ни одного «простого» проекта в своей практике, я решил почитать эту книгу и впитать опыт коллег.
Основная тема книги – работа руководителя в условиях хаоса и как с ним справляться, не превращаясь в феникса. Книга содержит инструменты и рекомендации для успешного управления в сложных обстоятельствах.
В книге раскрываются следующие темы:
Книга оказалась удивительно простой и жизненной. Узнавать себя в ней я начал прямо с первых страниц, где описываются признаки организации в хаосе (мне кажется, я там бинго собрал).
Во многом книга показалась мне больше эмоциональной и поддерживающей. Было ощущение, что авторы через всю книгу несут простую мысль: «Работать в хаосе сложно». Они заставляют читателя это признать и отталкиваться от этого, подбирая свои действия.
Это очень мудрая мысль. Работа в хаосе пожирает силы и буквально вынимает душу. Бравады и молодецкого задора хватит на некоторое время, но всему рано или поздно приходит конец. Поэтому работать в условиях хаоса нужно с полным осознанием того, что это очень сложно и далеко не бесплатно.
Инструменты, предлагаемые авторами, очень просты и применимы даже в обычных условиях: нормальная постановка целей, процесс принятия решений, практики канбана и так далее. Однако в хаосе все эти простые и правильные вещи становятся в разы важнее, потому что они помогают немного навести порядок.
Книгу рекомендую к прочтению. Мне было полезно.
Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥10👍4❤1
Как не втягиваться в чужую истерику
Есть такой тип людей, которые стараются добиваться результата повышением голоса и топаньем ножкой.
Раньше я довольно легко вовлекался в подобные эмоциональные конфликты. Если разговор переходил на повышенные тона и непечатные выражения — я включался и «давал бой».
Проблема этого подхода заключалась в его ресурсоёмкости. После такого «боя» приходится успокаиваться и восстанавливаться, из-за чего пропадает впустую много времени, которое могло бы быть потрачено на продуктивную работу.
⭐️ Альтернатива от Эпиктета
Кардинально другой взгляд на взрослых людей, которые впадают в эмоции и начинают истерить, дал мне Эпиктет.
По мнению стоиков, человек должен жить в согласии с природой. Природа наделила человека разумом, поэтому жить в согласии с природой означает пользоваться своим разумом по назначению.
Неумение пользоваться своим разумом Эпиктет рассматривает не как моральный порок, а скорее как дефект и несчастье. По его мнению, на такого человека нельзя злиться — ему нужно сочувствовать и сопереживать. Эпиктет считал, что неумение пользоваться своим разумом сродни неизлечимой болезни.
⭐️ Может, мне его по голове ещё погладить?
Идея сочувствия орущему человеку кажется чуждой, не так ли? Обычно мне в такой ситуации скорее хочется откусить собеседнику голову, а не посопереживать.
Нет, такое поведение ненормально. Но сочувствие и сопереживание меняют наше восприятие происходящего, а не самого собеседника. Подход Эпиктета позволил мне понять, что я действительно могу быть причиной недовольства собеседника, но способ выражения этого недовольства — не моя ответственность. И это понимание снижает желание «дать сдачи».
Человеку в истерике сложнее нормально рассуждать и воспринимать логику. Поэтому сначала нужно вывести разговор из эмоций и только потом продолжить обсуждение.
На практике вывод из эмоций бывает разным:
➡️ Кому-то хватает простого напоминания о предмете разговора.
➡️ Другим достаточно показать, что разговор переходит в эмоциональное русло.
➡️ А с кем-то приходится откровенно разорвать коммуникацию.
Сочувствовать истерящему человеку вовсе не означает необходимость терпеть его поступки или позволять собой манипулировать. Сочувствовать — значит осознавать, что человек не способен сейчас к нормальному диалогу. Это сочувствие нужно не истерящему человеку, а нам самим, чтобы сохранить свободу выбора собственной реакции.
А если это его единственный способ коммуникации, то зачем с таким человеком взаимодействовать вообще?
А я человек гневливый (с) Джейсон Стэтхем, «Гнев человеческий»
Есть такой тип людей, которые стараются добиваться результата повышением голоса и топаньем ножкой.
Раньше я довольно легко вовлекался в подобные эмоциональные конфликты. Если разговор переходил на повышенные тона и непечатные выражения — я включался и «давал бой».
Проблема этого подхода заключалась в его ресурсоёмкости. После такого «боя» приходится успокаиваться и восстанавливаться, из-за чего пропадает впустую много времени, которое могло бы быть потрачено на продуктивную работу.
Кардинально другой взгляд на взрослых людей, которые впадают в эмоции и начинают истерить, дал мне Эпиктет.
По мнению стоиков, человек должен жить в согласии с природой. Природа наделила человека разумом, поэтому жить в согласии с природой означает пользоваться своим разумом по назначению.
Неумение пользоваться своим разумом Эпиктет рассматривает не как моральный порок, а скорее как дефект и несчастье. По его мнению, на такого человека нельзя злиться — ему нужно сочувствовать и сопереживать. Эпиктет считал, что неумение пользоваться своим разумом сродни неизлечимой болезни.
Идея сочувствия орущему человеку кажется чуждой, не так ли? Обычно мне в такой ситуации скорее хочется откусить собеседнику голову, а не посопереживать.
Нет, такое поведение ненормально. Но сочувствие и сопереживание меняют наше восприятие происходящего, а не самого собеседника. Подход Эпиктета позволил мне понять, что я действительно могу быть причиной недовольства собеседника, но способ выражения этого недовольства — не моя ответственность. И это понимание снижает желание «дать сдачи».
Человеку в истерике сложнее нормально рассуждать и воспринимать логику. Поэтому сначала нужно вывести разговор из эмоций и только потом продолжить обсуждение.
На практике вывод из эмоций бывает разным:
Сочувствовать истерящему человеку вовсе не означает необходимость терпеть его поступки или позволять собой манипулировать. Сочувствовать — значит осознавать, что человек не способен сейчас к нормальному диалогу. Это сочувствие нужно не истерящему человеку, а нам самим, чтобы сохранить свободу выбора собственной реакции.
А если это его единственный способ коммуникации, то зачем с таким человеком взаимодействовать вообще?
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍18⚡5🔥5🤝2
Я управляю гневом или гнев управляет мной?
Чужая истерика — не повод самому впадать в эмоции и втягиваться в неё (об этом мы говорили в предыдущем посте). Спокойствие и ясный ум важны для руководителя, который хочет конструктивно договариваться с людьми и принимать качественные решения.
Но из этого легко сделать вывод о том, что хороший руководитель всегда спокоен как танк и не повышает голос. А это уже не совсем правда.
Несколько месяцев назад я столкнулся с человеком, который блокировал мне важный процесс. Я несколько раз пытался с ним договориться спокойно: приводил аргументы, отрабатывал его возражения, предлагал альтернативы и пути решения. Не работало. Человек как будто поймал «синдром вахтёрши» и наглухо блокировал мою работу, занимая позицию «будет либо по-моему, либо никак».
В какой-то момент я понял, что мои полномочия — всё, и откровенно на него наорал. И тогда процесс внезапно задвигался.
⭐️ Гнев гневу рознь
Я не сорвался на этого человека, вовсе нет. Я выбрал гнев осознанно, потому что исчерпал все остальные методы воздействия. Хотя внешне я мог выглядеть разгневанным, внутренне я был абсолютно спокоен и контролировал себя.
Но этот случай заставил меня разделить проявление эмоций на два типа:
➡️ Я сорвался и потерял контроль
➡️ Я осознанно решил продемонстрировать человеку гнев, будучи спокойным
Внешне обе эти ситуации выглядят одинаково, но внутри это совершенно разные процессы.
⭐️ Гнев — это тоже инструмент
Иногда мягкая коммуникация становится неэффективной. Человек может:
➡️ Не воспринимать меня всерьёз
➡️ Игнорировать последствия своих решений
➡️ Привыкнуть к тому, что за его поведение ему ничего не будет
➡️ И многое другое
Эмоциональная эскалация в таком случае становится способом показать человеку, что всё серьёзно. Но важно понимать, что это инструмент крайнего случая, когда все остальные (нормальные и здоровые) инструменты просто исчерпали себя. И также важно понимать, что у гнева есть цена — человек затаил на меня обиду. Процесс я сдвинул, но отношения ухудшил.
После этого случая у меня исчезло убеждение «руководителю нельзя злиться». Теперь для меня важен вопрос: «Я управляю гневом или гнев управляет мной?» Самоконтроль в моей картине мира — это не необходимость всегда выглядеть спокойным, а умение осознанно выбирать свою реакцию и принимать её последствия.
Чужая истерика — не повод самому впадать в эмоции и втягиваться в неё (об этом мы говорили в предыдущем посте). Спокойствие и ясный ум важны для руководителя, который хочет конструктивно договариваться с людьми и принимать качественные решения.
Но из этого легко сделать вывод о том, что хороший руководитель всегда спокоен как танк и не повышает голос. А это уже не совсем правда.
Несколько месяцев назад я столкнулся с человеком, который блокировал мне важный процесс. Я несколько раз пытался с ним договориться спокойно: приводил аргументы, отрабатывал его возражения, предлагал альтернативы и пути решения. Не работало. Человек как будто поймал «синдром вахтёрши» и наглухо блокировал мою работу, занимая позицию «будет либо по-моему, либо никак».
В какой-то момент я понял, что мои полномочия — всё, и откровенно на него наорал. И тогда процесс внезапно задвигался.
Я не сорвался на этого человека, вовсе нет. Я выбрал гнев осознанно, потому что исчерпал все остальные методы воздействия. Хотя внешне я мог выглядеть разгневанным, внутренне я был абсолютно спокоен и контролировал себя.
Но этот случай заставил меня разделить проявление эмоций на два типа:
Внешне обе эти ситуации выглядят одинаково, но внутри это совершенно разные процессы.
Иногда мягкая коммуникация становится неэффективной. Человек может:
Эмоциональная эскалация в таком случае становится способом показать человеку, что всё серьёзно. Но важно понимать, что это инструмент крайнего случая, когда все остальные (нормальные и здоровые) инструменты просто исчерпали себя. И также важно понимать, что у гнева есть цена — человек затаил на меня обиду. Процесс я сдвинул, но отношения ухудшил.
После этого случая у меня исчезло убеждение «руководителю нельзя злиться». Теперь для меня важен вопрос: «Я управляю гневом или гнев управляет мной?» Самоконтроль в моей картине мира — это не необходимость всегда выглядеть спокойным, а умение осознанно выбирать свою реакцию и принимать её последствия.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥15👍6❤2⚡1🤔1
Team Topologies, 2nd edition by Matthew Skelton, Manuel Pais
Строить подразделения, которые не тормозят, — задача со звёздочкой (в чём я успел убедиться на собственном опыте, собирая отдел буквально «на ходу» на одной из работ). Поэтому любые ментальные модели, которые помогут грамотно подойти к этому вопросу, очень полезны руководителю любого уровня.
Про Team Topologies я ранее слышал неоднократно и даже читал краткое описание концепции (из которой понял, что интуитивно применял этот подход к построению команд и раньше). Но скоро передо мной снова встанет задача проектирования и развития крупного юнита в управлении, поэтому я решил погрузиться в идею глубже.
⭐️ О чём книга
Название книги довольно говорящее — она посвящена топологиям инженерных команд, которые работают на поток поставки ценности и не тормозят разработку.
В книге раскрываются следующие темы:
➡️ В чём проблема с традиционными структурами команд
➡️ Почему так важен закон Конвея и что такое обратный манёвр Конвея
➡️ 4 фундаментальные топологии команд
➡️ Модели взаимодействия команд между собой
➡️ Эволюция оргструктуры под потребности бизнеса
⭐️ 3 идеи из книги
🟡 Думать, что архитектуру можно долго поддерживать в отрыве от структуры команд, — фундаментальная ошибка. Разрыв между архитектурой и структурой команд будет виден на всех уровнях разработки. Я думаю, на этом месте скупую слезу пустят те, кто работает с «отделом корпоративной архитектуры».
🟡 Один из ключевых факторов эффективности команд — неблокирующие зависимости. Например, очень сложно эффективно поставлять фичи, если их тестирует отдел QA, который находится чёрт его знает где и имеет свои процессы/приоритеты/взгляд на вещи. Или другая, более частая проблема — неправильно разделённые зоны ответственности, где одна команда вынуждена ждать другую (иногда месяцами). Проблема не в самом наличии зависимостей, а в зависимостях, которые регулярно блокируют поток работы одной команды решениями другой.
🟡 Платформенные команды нужны для того, чтобы расчистить путь продуктовым командам и снять с них лишнюю когнитивную нагрузку. Хорошая платформа убирает много трения в процессе разработки и релиза. К сожалению, не все платформы это понимают и навязывают свою «философию», что приводит к аккуратному избеганию их возможностей разработчиками.
⭐️ Мои впечатления
Впечатления у меня остались немного смешанные. С одной стороны, идеи из книги мне понравились, и в них много здравого смысла. Разделение на типы команд, определение типов коммуникаций, применение обратного манёвра Конвея — ценные и полезные штуки, которые я успел проверить на практике.
С другой стороны, книга показалась мне удивительно водянистой. Сложилось ощущение, что её ключевые идеи можно было уложить в страниц 20–30, но для издательства нужно было нарастить объём. Поэтому треть книги занимают бесполезные case studies, а сами главы изобилуют историями, восхваляющими Team Topologies.
Главная ценность Team Topologies для меня не в четырёх типах команд, а в самом способе смотреть на организацию: архитектуру систем, границы ответственности и взаимодействия между командами нужно проектировать как одно целое.
Руководителю, который проектирует отдел из нескольких команд, идеи из этой книги стоит знать обязательно. Но для ознакомления с ними вполне достаточно будет прочитать несколько статей или саммари книги. Саму книгу целиком стоит читать, только если хочется разобраться в аргументации и деталях взаимодействий.
Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.
➡ А для тех, кто хочет читать с большей пользой, у меня есть практикум «ИнфоСушка», в котором мы полностью меняем подход к чтению и делаем его эффективным.
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Строить подразделения, которые не тормозят, — задача со звёздочкой (в чём я успел убедиться на собственном опыте, собирая отдел буквально «на ходу» на одной из работ). Поэтому любые ментальные модели, которые помогут грамотно подойти к этому вопросу, очень полезны руководителю любого уровня.
Про Team Topologies я ранее слышал неоднократно и даже читал краткое описание концепции (из которой понял, что интуитивно применял этот подход к построению команд и раньше). Но скоро передо мной снова встанет задача проектирования и развития крупного юнита в управлении, поэтому я решил погрузиться в идею глубже.
Название книги довольно говорящее — она посвящена топологиям инженерных команд, которые работают на поток поставки ценности и не тормозят разработку.
В книге раскрываются следующие темы:
Впечатления у меня остались немного смешанные. С одной стороны, идеи из книги мне понравились, и в них много здравого смысла. Разделение на типы команд, определение типов коммуникаций, применение обратного манёвра Конвея — ценные и полезные штуки, которые я успел проверить на практике.
С другой стороны, книга показалась мне удивительно водянистой. Сложилось ощущение, что её ключевые идеи можно было уложить в страниц 20–30, но для издательства нужно было нарастить объём. Поэтому треть книги занимают бесполезные case studies, а сами главы изобилуют историями, восхваляющими Team Topologies.
Главная ценность Team Topologies для меня не в четырёх типах команд, а в самом способе смотреть на организацию: архитектуру систем, границы ответственности и взаимодействия между командами нужно проектировать как одно целое.
Руководителю, который проектирует отдел из нескольких команд, идеи из этой книги стоит знать обязательно. Но для ознакомления с ними вполне достаточно будет прочитать несколько статей или саммари книги. Саму книгу целиком стоит читать, только если хочется разобраться в аргументации и деталях взаимодействий.
Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4👍2🔥1🤔1
Теперь нас трое
Как говорится в старой шутке, когда у человека рождается сын, он становится отцом, а когда рождается дочь — он становится папулей.
Почти две недели назад я стал папулей.
Дома нас теперь трое. Буквально две недели назад этого маленького человека ещё не было в моей жизни, а теперь я не могу представить, что её когда-то не было. Привычный мир меняется и перестраивается — в доме появилась куча детских приспособлений, кот обижается на недостаток внимания, а мой богатый опыт бессонниц наконец-то пригодился😂
А ещё родительство буквально за две недели успело дать мне пачку новых знаний:
➡️ По интонации детского плача можно относительно легко понять, что именно не так.
➡️ Бодики на молниях гораздо удобнее бодиков на кнопках.
➡️ В позе «тигр на ветке» очень удобно носить мою маленькую львицу.
Никакой мудрой концовки не будет, просто хочу поделиться радостью❤️ А на фотке — Алиса и я в футболке «молодой папа», подаренной друзьями.
Как говорится в старой шутке, когда у человека рождается сын, он становится отцом, а когда рождается дочь — он становится папулей.
Почти две недели назад я стал папулей.
Дома нас теперь трое. Буквально две недели назад этого маленького человека ещё не было в моей жизни, а теперь я не могу представить, что её когда-то не было. Привычный мир меняется и перестраивается — в доме появилась куча детских приспособлений, кот обижается на недостаток внимания, а мой богатый опыт бессонниц наконец-то пригодился
А ещё родительство буквально за две недели успело дать мне пачку новых знаний:
Никакой мудрой концовки не будет, просто хочу поделиться радостью
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤99🔥39👍22⚡2
Как LinkedIn построил AI Code Review на всю компанию
Последнее время читаю столько хороших технических материалов, что даже подумываю возродить ТехноФитнес — в основной блог они просто не влезают. Сегодня хочу поделиться шикарной статьёй о том, как в LinkedIn построили AI Code Review.
С распространением AI-агентов разработчики начинают писать больше кода, и bottleneck постепенно переезжает в Code Review. В LinkedIn это стало видно по росту P90 времени до первого человеческого ревью. А масштаб там огромный: больше 10к активных репозиториев и десятки тысяч PR в неделю.
Для меня как для руководителя разработки эта тема особенно важна. Если ускорить написание кода, но не масштабировать контроль качества, то либо появится огромная очередь из изменений, либо требования к ревью начнут деградировать (все же делали LGTM на 5к строк, да?). А дальше кодовая база довольно быстро поедет куда-то не туда.
Инженеры из LinkedIn поэтому построили собственную multi-agent систему AI Code Review. Сейчас она делает 79к ревью в неделю примерно по 40к PR, а её рекомендации принимаются разработчиками в 63,9% случаев.
⭐️ Интересные идеи
➡️ Мультиагентное ревью. Главная проблема AI Code Review — не найти максимум замечаний, а не заспамить разработчика мусором. Поэтому несколько независимых агентов параллельно ревьюят PR, а оркестратор объединяет и перепроверяет результаты. Совпадение между моделями повышает confidence. Цена — больше токенов, вычислений и latency.
➡️ Контекст кодовой базы важен. Хороший AI Reviewer должен знать не только язык, но и конкретную систему. В LinkedIn для этого используют трёхуровневую систему правил: глобальные, репозиторные и use-case-specific. Отсюда неприятный вывод: качество AI Review напрямую упирается в качество формализованных знаний о системе (пиши доки, бл&ть!).
➡️ AI Reviewer – это отдельная инженерная система. У него есть SLA, observability, staged rollout и eval перед изменениями. Ревью стартует примерно через 90 секунд, большинство проверок заканчивается меньше чем за 10 минут. Лайки под комментариями авторы считают vanity metric. Вместо этого они проверяют, внёс ли разработчик рекомендацию в merged code. На выборке из 5230 комментариев в 90,1% случаев удалось уверенно определить результат. При этом acceptance rate для logic errors достигает 80%, а для concurrency bugs в их выборке вообще был 100%.
➡️ Feedback loop из продовых инцидентов. LinkedIn хочет анализировать SEV0/SEV1-инциденты и автоматически превращать найденные failure patterns в новые правила Code Review. Получается замкнутый цикл: сломали прод → разобрали причину → научили reviewer ловить похожую ошибку до мержа.
Статья хорошо подтверждает моё ощущение: в AI-first разработке Code Review превращается из ботика-комментатора в полноценный платформенный инструмент. И без такого слоя масштабировать AI-разработку нормально не получится.
Приятного чтения!
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Последнее время читаю столько хороших технических материалов, что даже подумываю возродить ТехноФитнес — в основной блог они просто не влезают. Сегодня хочу поделиться шикарной статьёй о том, как в LinkedIn построили AI Code Review.
С распространением AI-агентов разработчики начинают писать больше кода, и bottleneck постепенно переезжает в Code Review. В LinkedIn это стало видно по росту P90 времени до первого человеческого ревью. А масштаб там огромный: больше 10к активных репозиториев и десятки тысяч PR в неделю.
Для меня как для руководителя разработки эта тема особенно важна. Если ускорить написание кода, но не масштабировать контроль качества, то либо появится огромная очередь из изменений, либо требования к ревью начнут деградировать (все же делали LGTM на 5к строк, да?). А дальше кодовая база довольно быстро поедет куда-то не туда.
Инженеры из LinkedIn поэтому построили собственную multi-agent систему AI Code Review. Сейчас она делает 79к ревью в неделю примерно по 40к PR, а её рекомендации принимаются разработчиками в 63,9% случаев.
Статья хорошо подтверждает моё ощущение: в AI-first разработке Code Review превращается из ботика-комментатора в полноценный платформенный инструмент. И без такого слоя масштабировать AI-разработку нормально не получится.
Приятного чтения!
Please open Telegram to view this post
VIEW IN TELEGRAM
Linkedin
High-Signal AI Code Review That Adapts to Your Codebase at Scale
2👍9🔥6❤5🤝1
Результаты четвёртого месяца обучения на курсе «Руководитель отдела»
Четвёртый (и последний) месяц обучения на курсе Стратоплана «Руководитель отдела» пролетел ещё быстрее и незаметнее, чем все предыдущие. Отчасти так получилось, потому что он немножечко короче всех остальных и занятий было меньше.
Этот месяц был практически полностью посвящён финансам. Мы прошли следующие темы:
➡️ Кадровый резерв, защита от bus-фактора и выращивание себе замены
➡️ Реализация стратегии бизнеса
➡️ Системный people-менеджмент для больших структур
➡️ Модуль по конфликтам и конструктивной конфронтации
В конце курса уже чувствовалась накопленная усталость от обучения – оно было действительно интенсивным. Тем не менее, темы последних занятий были для меня настолько важны, что я отработал их по полной программе.
Особенно ценным для меня оказалось занятие по реализации стратегии. В жизни я многократно сталкивался с тем, что бизнес свои хотелки и мечты называет «стратегией», но реализовать эту «стратегию» невозможно физически. В модуле мы разбирали подобные кейсы и на практике рассматривали, что с ними делать.
Также важным оказалось занятие по системному people-менеджменту. С ростом структуры 1-1 как инструмент начинает работать хуже – в отделе из 20 человек с каждым раз в две недели по часу уже трудновато разговаривать. Мы разбирали, как строить человеческую систему и процессы, в которых людям будет хорошо и комфортно работать, а бизнес будет получать достойный результат.
Обучение было очень крутым, но мне теперь нужно немного передохнуть и собрать в кучу всё то, чему удалось научиться. Скоро я получу сертификат и напишу пост с общими впечатлениями от обучения. Оставайтесь на связи😉
Четвёртый (и последний) месяц обучения на курсе Стратоплана «Руководитель отдела» пролетел ещё быстрее и незаметнее, чем все предыдущие. Отчасти так получилось, потому что он немножечко короче всех остальных и занятий было меньше.
Этот месяц был практически полностью посвящён финансам. Мы прошли следующие темы:
В конце курса уже чувствовалась накопленная усталость от обучения – оно было действительно интенсивным. Тем не менее, темы последних занятий были для меня настолько важны, что я отработал их по полной программе.
Особенно ценным для меня оказалось занятие по реализации стратегии. В жизни я многократно сталкивался с тем, что бизнес свои хотелки и мечты называет «стратегией», но реализовать эту «стратегию» невозможно физически. В модуле мы разбирали подобные кейсы и на практике рассматривали, что с ними делать.
Также важным оказалось занятие по системному people-менеджменту. С ростом структуры 1-1 как инструмент начинает работать хуже – в отделе из 20 человек с каждым раз в две недели по часу уже трудновато разговаривать. Мы разбирали, как строить человеческую систему и процессы, в которых людям будет хорошо и комфортно работать, а бизнес будет получать достойный результат.
Обучение было очень крутым, но мне теперь нужно немного передохнуть и собрать в кучу всё то, чему удалось научиться. Скоро я получу сертификат и напишу пост с общими впечатлениями от обучения. Оставайтесь на связи
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥21❤11👍9⚡1💯1
Почему быстрые команды не делают организацию быстрой
Один из самых важных показателей команды – это скорость её поставки. Об оптимизации этого параметра все вокруг говорят уже давным-давно (да я и сам целый цикл постов про расшитие бутылочных горлышек написал). Все стараются улучшать качество процессов, CI/CD, развивать своих инженеров.
Но иногда можно заметить забавный парадокс: в подразделении несколько команд, которые прекрасно и быстро работают, но общая поставка всё равно еле ползёт.
⭐️ Как же так получается?
Каждая команда контролирует только свой поток работы: свой бэклог задач, спринты, релизы и так далее. При смещении фокуса внимания на уровень хотя бы нескольких команд появляется много дополнительных факторов:
➡️ Одной команде нужно дождаться API от другой команды, у которой другие приоритеты
➡️ Загруженный архитектор становится боттлнеком
➡️ Изменения одной команды затрагивают ещё три других, и решение требует кучи согласований
➡️ Закончились свободные стенды для тестирования (или он вообще один)
➡️ И множество иных причин
В итоге в lead time появляется колоссальное количество ожидания, которое никак не разруливается на уровне одной команды.
⭐️ Граф зависимостей
По сути, отношения и зависимости между командами выстраиваются в такой же граф зависимостей, какой вы можете найти у себя в коде. И этот граф точно так же может быть плотным или разреженным, однонаправленным или двунаправленным, аккуратным или запутанным до уровня современного искусства.
И в этом графе нужно очень хорошо разбираться, потому что производительность подразделения определяется не только скоростью самих команд, но и тем, как они связаны и взаимодействуют между собой. Можно ускорить одну команду на 50% и не получить общего ускорения, потому что она на каждые два дня работы будет неделю ждать смежников.
Если большинство изменений регулярно пересекает границы команд, возможно, неправильно проведены сами границы.
У меня есть прекрасная история, которая иллюстрирует эту проблему: мы делали фичу совместно с соседним отделом. Фича казалась небольшой, но её невозможно было поставить по частям, независимо. Мы собрались, окнули архитектуру и приступили к работе.
Наша часть была готова через неделю. А релиз фичи состоялся через полтора месяца, потому что у смежников полезли проблемы: то API забыли описать, то руки тестировщиков заняты чем-то другим, то ещё что-то. В итоге получилось, что общий результат был плачевным, хотя моя часть была сделана быстро.
Главная проблема была не в том, что смежники работали плохо, а в том, что результат одной команды в принципе не имел ценности без результата другой.
⭐️ Где проблемы, Лебовски?
Если большинство фич регулярно требует участия нескольких команд и создаёт ожидание, то проблема скорости может быть уже не внутри команд, а в границах ответственности и архитектуре.
Поэтому нужно анализировать:
➡️ Где регулярно возникают простои
➡️ Какие команды блокируют друг друга и как часто
➡️ Какие зависимости становятся бутылочным горлышком
➡️ Не нужно ли поменять архитектуру (и оргструктуру заодно)
Производительность подразделения зависит не только от высокой производительности каждой команды в отдельности, но и от того, насколько они не мешают друг другу поставлять ценность (кстати, похожую модель хорошо разбирает книга Team Topologies).
Быстрые команды не обязательно делают организацию быстрой. Иногда главная оптимизация — не ускорить команды, а убрать лишние зависимости между ними.
Один из самых важных показателей команды – это скорость её поставки. Об оптимизации этого параметра все вокруг говорят уже давным-давно (да я и сам целый цикл постов про расшитие бутылочных горлышек написал). Все стараются улучшать качество процессов, CI/CD, развивать своих инженеров.
Но иногда можно заметить забавный парадокс: в подразделении несколько команд, которые прекрасно и быстро работают, но общая поставка всё равно еле ползёт.
Каждая команда контролирует только свой поток работы: свой бэклог задач, спринты, релизы и так далее. При смещении фокуса внимания на уровень хотя бы нескольких команд появляется много дополнительных факторов:
В итоге в lead time появляется колоссальное количество ожидания, которое никак не разруливается на уровне одной команды.
По сути, отношения и зависимости между командами выстраиваются в такой же граф зависимостей, какой вы можете найти у себя в коде. И этот граф точно так же может быть плотным или разреженным, однонаправленным или двунаправленным, аккуратным или запутанным до уровня современного искусства.
И в этом графе нужно очень хорошо разбираться, потому что производительность подразделения определяется не только скоростью самих команд, но и тем, как они связаны и взаимодействуют между собой. Можно ускорить одну команду на 50% и не получить общего ускорения, потому что она на каждые два дня работы будет неделю ждать смежников.
Если большинство изменений регулярно пересекает границы команд, возможно, неправильно проведены сами границы.
У меня есть прекрасная история, которая иллюстрирует эту проблему: мы делали фичу совместно с соседним отделом. Фича казалась небольшой, но её невозможно было поставить по частям, независимо. Мы собрались, окнули архитектуру и приступили к работе.
Наша часть была готова через неделю. А релиз фичи состоялся через полтора месяца, потому что у смежников полезли проблемы: то API забыли описать, то руки тестировщиков заняты чем-то другим, то ещё что-то. В итоге получилось, что общий результат был плачевным, хотя моя часть была сделана быстро.
Главная проблема была не в том, что смежники работали плохо, а в том, что результат одной команды в принципе не имел ценности без результата другой.
Если большинство фич регулярно требует участия нескольких команд и создаёт ожидание, то проблема скорости может быть уже не внутри команд, а в границах ответственности и архитектуре.
Поэтому нужно анализировать:
Производительность подразделения зависит не только от высокой производительности каждой команды в отдельности, но и от того, насколько они не мешают друг другу поставлять ценность (кстати, похожую модель хорошо разбирает книга Team Topologies).
Быстрые команды не обязательно делают организацию быстрой. Иногда главная оптимизация — не ускорить команды, а убрать лишние зависимости между ними.
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤6👍5🔥4⚡1💯1
PostgreSQL: архитектура и тюнинг SQL-запросов
Погрузись в архитектуру и прокачай оптимизацию запросов одной из самых популярных open source СУБД – PostgreSQL.
🌐 В программе курса:
🤩 Разберём, как работают СУБД вообще и PostgreSQL в частности: что такое MVCC, ACID, WAL, LRU, PPC/TPC и другие фундаментальные понятия архитектуры баз данных
🤩 Получишь теорию и практику EXPLAIN и EXPLAIN ANALYZE на разных типа запросов: без индексов, с индексами, index only, нормализованные и документ-ориентированные данные и json-поля, изменение параметров сессии/конфигурации для ускорения запросов
🤩 Изучишь архитектуру хранения данных в PostgreSQL, типы и особенности индексов, а также полезные советы и трюки оптимизации БД
🤩 Получишь свой собственный выделенный облачный PostgreSQL-сервер (8 vCPU, 12G RAM, 100G NVMe) – предоставляется БЕСПЛАТНО на время обучения + готовый e-commerce датасет TPC-H (миллион пользователей, несколько миллионов заказов на десятки гигабайт)
🗓 Старт курса: 3 сентября. 5 недель обучения.
Изучить программу и записаться можно здесь.
🤩 Кто мы: R&D-центр Devhands, автор курса Николай Ихалайнен, эксперт по СУБД (ex-Percona), со-основатель MyDB, энтузиаст открытого ПО.
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzquuHE37
Погрузись в архитектуру и прокачай оптимизацию запросов одной из самых популярных open source СУБД – PostgreSQL.
Изучить программу и записаться можно здесь.
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzquuHE37
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5🔥2🤝1
An Elegant Puzzle by Will Larson
Блог Уилла Ларсона я почитываю довольно давно. Мне нравится его стиль письма и идеи, которые он высказывает о руководстве техническими подразделениями (и периодически я у него что-то утаскиваю в работу).
Я прекрасно знал, что он написал несколько книг, но при этом не читал ни одной из них. И недавно я решил исправить эту ситуацию, прочитав самую популярную из его книг – «An Elegant Puzzle», о которой я слышал много хорошего от уважаемых людей. Мне всегда интересно посмотреть на управление с новой стороны, а мнение Уилла Ларсона я уважаю, так что книга обещала стать очень интересной.
⭐️ О чём книга
Уилл Ларсон рассматривает менеджмент (и в частности инженерный менеджмент) как элегантный пазл, в котором нужно аккуратно подбирать нужные кусочки и вставлять их на место. Его книга – это серия таких кусочков, которые читатель может «вставить» в свои проекты.
В книге раскрываются следующие темы:
➡️ Взгляд на организационный дизайн и инструменты для его построения
➡️ Набор инструментов для разных случаев жизни руководителя
➡️ Подходы к изменению и адаптации своего стиля управления в зависимости от обстоятельств
➡️ Культура и способы её взращивания
⭐️ 3 идеи из книги
🟡 Исправление ситуации в команде – процесс медленный. Команда, которая захлёбывается под потоком задач и грудой технического долга, не сможет стать сверхпроизводительной за месяц. Проблемы команды обладают инерцией: найм, техдолг, процессы и ожидания меняются с разной скоростью, поэтому управленческое решение и наблюдаемый результат разделены месяцами. Руководитель должен запастись терпением и упорно вести команду к лучшей жизни (попутно защищая от попыток разломать всё, что он сделал).
🟡 Хороший процесс не компенсирует неправильный состав команды. По сути, поставить правильного человека на правильное место – одна из главных задач руководителя. Например, если вы соберёте команду полностью из джунов и дадите им правильные архитектурные процессы, то на выходе всё равно получится big ball of mud, потому состав команды не соответствует задаче.
🟡 Стратегия – это один из хороших способов выравнивания нескольких команд. Стратегия даёт конкретное направление для того, чтобы преодолеть ограничения выбранной цели, а также даёт общий взгляд на то, чем мы все тут занимаемся. Ларсон регулярно делает отсылки к книге Румельта «Хорошая стратегия, плохая стратегия» (только делает это менее абстрактно и показывает, как её применять на практике). Если команды не выравнивать, то получится лебедь, рак, щука и ситуация из предыдущего поста.
⭐️ Мои впечатления
Книга действительно оставила ощущение пазла. С одной стороны, она составлена из постов из блога Ларсона (может, и я когда-нибудь так же сделаю, кто знает…). С другой стороны, все эти кусочки складываются в удивительно целостную картинку того, как заниматься инженерным менеджментом. При этом каждый кусочек самодостаточен, и его можно применять независимо от других, что делает книгу фактически настольным справочником.
Читать книгу легко и интересно. В словах Уилла Ларсона сквозит огромный опыт, и есть ощущение, что каждый совет из книги он действительно прожил сам (что тоже большая редкость в современном чтиве). При этом книга скорее будет полезна руководителям среднего звена и выше, а не тимлидам – проблемы в ней рассматриваются более верхнеуровневые.
Если ищете последовательный учебник менеджмента, то вам эта книга скорее не подойдёт. А если уже управляете несколькими командами и хотите расширить набор моделей и инструментов, очень подойдёт.
Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.
➡ А для тех, кто хочет читать с большей пользой, у меня есть практикум «ИнфоСушка», в котором мы полностью меняем подход к чтению и делаем его эффективным.
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Блог Уилла Ларсона я почитываю довольно давно. Мне нравится его стиль письма и идеи, которые он высказывает о руководстве техническими подразделениями (и периодически я у него что-то утаскиваю в работу).
Я прекрасно знал, что он написал несколько книг, но при этом не читал ни одной из них. И недавно я решил исправить эту ситуацию, прочитав самую популярную из его книг – «An Elegant Puzzle», о которой я слышал много хорошего от уважаемых людей. Мне всегда интересно посмотреть на управление с новой стороны, а мнение Уилла Ларсона я уважаю, так что книга обещала стать очень интересной.
Уилл Ларсон рассматривает менеджмент (и в частности инженерный менеджмент) как элегантный пазл, в котором нужно аккуратно подбирать нужные кусочки и вставлять их на место. Его книга – это серия таких кусочков, которые читатель может «вставить» в свои проекты.
В книге раскрываются следующие темы:
Книга действительно оставила ощущение пазла. С одной стороны, она составлена из постов из блога Ларсона (может, и я когда-нибудь так же сделаю, кто знает…). С другой стороны, все эти кусочки складываются в удивительно целостную картинку того, как заниматься инженерным менеджментом. При этом каждый кусочек самодостаточен, и его можно применять независимо от других, что делает книгу фактически настольным справочником.
Читать книгу легко и интересно. В словах Уилла Ларсона сквозит огромный опыт, и есть ощущение, что каждый совет из книги он действительно прожил сам (что тоже большая редкость в современном чтиве). При этом книга скорее будет полезна руководителям среднего звена и выше, а не тимлидам – проблемы в ней рассматриваются более верхнеуровневые.
Если ищете последовательный учебник менеджмента, то вам эта книга скорее не подойдёт. А если уже управляете несколькими командами и хотите расширить набор моделей и инструментов, очень подойдёт.
Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤6👍3🔥2⚡1🤔1
AI меняет не только скорость разработки, но и то, как устроена работа команды. На TeamLead Сибирь этому отвели самый большой трек — 11 докладов о реальных внедрениях.
Кроме AI есть доклады про найм, процессы и управление изменениями. А практику собрали в отдельном зале мастер-классов, где можно разобрать свою рабочую задачу с ведущим.
Конференция идет 10–11 сентября в Новосибирске и онлайн, в программе больше 30 докладов. Участникам дают промокоды на проживание и дорогу.
👉 Программа и билеты
Темы AI-трека:
➡️ как считать эффект от ИИ и вести внедрение как управляемый эксперимент
➡️ почему AI дает эффект на пилотах, а через полгода результат исчезает
➡️ как 2-3 человека с ИИ-агентами делают целый продукт
➡️ что делает за вас кодинг-агент и как строить harness на открытых моделях
Кроме AI есть доклады про найм, процессы и управление изменениями. А практику собрали в отдельном зале мастер-классов, где можно разобрать свою рабочую задачу с ведущим.
Конференция идет 10–11 сентября в Новосибирске и онлайн, в программе больше 30 докладов. Участникам дают промокоды на проживание и дорогу.
👉 Программа и билеты
2❤2🤝2👍1
Дочь против игрового перфекционизма
Я всегда немного недолюбливал игры с открытым миром. Мне всегда хочется выполнить все сайд-квесты, посетить все точки на карте (горите в аду, вопросики на Скеллиге) и собрать все коллекции. Но обычно игра надоедает мне гораздо раньше, чем я успеваю всё это сделать. Например, по этой причине я не прошёл Baldur's Gate 3 — к третьему акту я уже просто задолбался в неё играть.
Но сейчас возможность поиграть выпадает мне примерно раз в две недели на пару часиков. И когда я беру в руки геймпад, то осознаю: бегать по сайд-квестам не очень хорошая идея. Поэтому я начинаю бодро гонять по основному сюжету, выполняя только те сторонние активности, которые находятся по дороге.
И внезапно удовольствия от игры стало намного больше. Выполнение всех побочек обычно приводило к тому, что на любом боссе возникал вопрос, кто тут ещё босс на самом деле. А теперь основные сюжетные задания и челленджат нормально, и награда за них не ощущается как насмешка над игроком.
Получается, дочь уже вылечила меня от перфекционизма хотя бы в играх: когда я перестал пытаться пройти всё, играть стало интереснее.
В общем, приятно я вчера в Dying Light 2 погонял, рекомендую. А сегодня болею за Team Spirit🔥
// А вы из какого лагеря?
🌚 — пока на карте остался хоть один вопросик, я не успокоюсь
👻 — побочки подождут, мне пора спасать мир
Я всегда немного недолюбливал игры с открытым миром. Мне всегда хочется выполнить все сайд-квесты, посетить все точки на карте (горите в аду, вопросики на Скеллиге) и собрать все коллекции. Но обычно игра надоедает мне гораздо раньше, чем я успеваю всё это сделать. Например, по этой причине я не прошёл Baldur's Gate 3 — к третьему акту я уже просто задолбался в неё играть.
Но сейчас возможность поиграть выпадает мне примерно раз в две недели на пару часиков. И когда я беру в руки геймпад, то осознаю: бегать по сайд-квестам не очень хорошая идея. Поэтому я начинаю бодро гонять по основному сюжету, выполняя только те сторонние активности, которые находятся по дороге.
И внезапно удовольствия от игры стало намного больше. Выполнение всех побочек обычно приводило к тому, что на любом боссе возникал вопрос, кто тут ещё босс на самом деле. А теперь основные сюжетные задания и челленджат нормально, и награда за них не ощущается как насмешка над игроком.
Получается, дочь уже вылечила меня от перфекционизма хотя бы в играх: когда я перестал пытаться пройти всё, играть стало интереснее.
В общем, приятно я вчера в Dying Light 2 погонял, рекомендую. А сегодня болею за Team Spirit
// А вы из какого лагеря?
🌚 — пока на карте остался хоть один вопросик, я не успокоюсь
👻 — побочки подождут, мне пора спасать мир
Please open Telegram to view this post
VIEW IN TELEGRAM
2🌚10❤8👻5⚡1👍1💯1