Как оптимизация может ухудшить поставку
Когда инженер только становится тимлидом, у него есть чёткая цель: заставить всё вокруг работать максимально эффективно. Чаще всего это происходит из-за желания закрепиться в новой роли, но и технический бэкграунд даёт о себе знать — привычка всё оптимизировать никуда не делась.
Поэтому загружать команду на 100% кажется максимально эффективным и правильным решением. Если мы за это платим – пусть работает. Желание всё оптимизировать кажется экономически оправданным. В результате юный тимлид частенько начинает заниматься локальными оптимизациями, забывая о картине в целом.
⭐️ К чему приводит локальная загрузка
Но производственный процесс — не инженерная система. Локальная оптимизация в коде может привести только к ускорению его выполнения. А вот оптимизация какой-либо точки производственного процесса может, наоборот, ухудшить общую производительность команды.
Так происходит потому, что в реальных системах есть так называемые «бутылочные горлышки» — узкие места, которые по сути определяют пропускную способность всей системы. Любые локальные оптимизации в других местах приведут лишь к тому, что перед бутылочным горлышком начнёт скапливаться всё больше и больше работы, вызывая снижение производительности всей системы.
⭐️ Что будет, если загрузить команду на 100%
Термин «бутылочное горлышко» ввёл Элияху Голдратт в своей теории ограничений. Впервые его можно встретить в книге «Цель» (см. мой обзор), которую я настоятельно рекомендую всем тимлидам.
Расскажу случай из своей практики. В одной из команд мы в какой-то момент озаботились наращиванием поставки. Естественно, первая же мысль была ошибочной — «нам нужно оптимизировать время работы программистов». Путём различных манипуляций с процессами мы снизили затраты времени разработчиков, в результате чего они действительно начали закрывать больше задач. Круто же?
Не круто. К своему неприятному удивлению мы обнаружили, что поставка команды стала хуже. Тогда мы сделали то, с чего следовало начать — проанализировали свой рабочий процесс.
Оказалось, что бутылочным горлышком нашей системы были вовсе не программисты, а QA. Их было меньше, система была сложной, и ребята просто не успевали тестировать всё то, что к ним поступало. А когда мы оптимизировали процесс разработки и стали закрывать больше задач, QA совсем приуныли. Из-за роста нагрузки и обязательств они начали работать в спешке и менее качественно, больше уставать и пропускать баги. В результате мы получили снижение и поставки команды, и качества системы.
⭐️ Производительность системы определяется бутылочным горлышком
В незавершённом продукте нет ценности. Код программиста бесполезен до тех пор, пока не окажется в проде и не начнёт приносить пользу клиентам. Но до этого он должен быть отревьюен, протестирован и, собственно, выкачан.
Если бутылочное горлышко системы находится не в скорости разработки, нет смысла её оптимизировать. Разработчики просто перегрузят узкое место и будут ворчать, что постоянно приходится решать конфликты в ветках.
Парадоксально, но в нашей ситуации первым правильным решением было перестать копать. И да, это означало уменьшение количества производимого кода. Поскольку ограничение системы заключалось не в скорости разработки, мы отказались от идеи «запихнуть в работу как можно больше фич» и стали отталкиваться от загрузки QA.
От этого решения выиграли все. QA выдохнули и смогли спокойно делать свою работу. У разработчиков появилось время на технический долг и изучение новых областей (например, фронты начали периодически брать задачи по бэку и наоборот). Система стабилизировалась, и всё вернулось на круги своя.
Однако изначальную проблему мы не решили. Скорость поставки осталась прежней. Но об этом я расскажу в следующем посте. :)
// Если сталкивались с ситуациями ухудшения производительности из-за локальных оптимизаций — пишите в комментах. И не забывайте про💛 !
Когда инженер только становится тимлидом, у него есть чёткая цель: заставить всё вокруг работать максимально эффективно. Чаще всего это происходит из-за желания закрепиться в новой роли, но и технический бэкграунд даёт о себе знать — привычка всё оптимизировать никуда не делась.
Поэтому загружать команду на 100% кажется максимально эффективным и правильным решением. Если мы за это платим – пусть работает. Желание всё оптимизировать кажется экономически оправданным. В результате юный тимлид частенько начинает заниматься локальными оптимизациями, забывая о картине в целом.
Но производственный процесс — не инженерная система. Локальная оптимизация в коде может привести только к ускорению его выполнения. А вот оптимизация какой-либо точки производственного процесса может, наоборот, ухудшить общую производительность команды.
Так происходит потому, что в реальных системах есть так называемые «бутылочные горлышки» — узкие места, которые по сути определяют пропускную способность всей системы. Любые локальные оптимизации в других местах приведут лишь к тому, что перед бутылочным горлышком начнёт скапливаться всё больше и больше работы, вызывая снижение производительности всей системы.
Термин «бутылочное горлышко» ввёл Элияху Голдратт в своей теории ограничений. Впервые его можно встретить в книге «Цель» (см. мой обзор), которую я настоятельно рекомендую всем тимлидам.
Расскажу случай из своей практики. В одной из команд мы в какой-то момент озаботились наращиванием поставки. Естественно, первая же мысль была ошибочной — «нам нужно оптимизировать время работы программистов». Путём различных манипуляций с процессами мы снизили затраты времени разработчиков, в результате чего они действительно начали закрывать больше задач. Круто же?
Не круто. К своему неприятному удивлению мы обнаружили, что поставка команды стала хуже. Тогда мы сделали то, с чего следовало начать — проанализировали свой рабочий процесс.
Оказалось, что бутылочным горлышком нашей системы были вовсе не программисты, а QA. Их было меньше, система была сложной, и ребята просто не успевали тестировать всё то, что к ним поступало. А когда мы оптимизировали процесс разработки и стали закрывать больше задач, QA совсем приуныли. Из-за роста нагрузки и обязательств они начали работать в спешке и менее качественно, больше уставать и пропускать баги. В результате мы получили снижение и поставки команды, и качества системы.
В незавершённом продукте нет ценности. Код программиста бесполезен до тех пор, пока не окажется в проде и не начнёт приносить пользу клиентам. Но до этого он должен быть отревьюен, протестирован и, собственно, выкачан.
Если бутылочное горлышко системы находится не в скорости разработки, нет смысла её оптимизировать. Разработчики просто перегрузят узкое место и будут ворчать, что постоянно приходится решать конфликты в ветках.
Парадоксально, но в нашей ситуации первым правильным решением было перестать копать. И да, это означало уменьшение количества производимого кода. Поскольку ограничение системы заключалось не в скорости разработки, мы отказались от идеи «запихнуть в работу как можно больше фич» и стали отталкиваться от загрузки QA.
От этого решения выиграли все. QA выдохнули и смогли спокойно делать свою работу. У разработчиков появилось время на технический долг и изучение новых областей (например, фронты начали периодически брать задачи по бэку и наоборот). Система стабилизировалась, и всё вернулось на круги своя.
Однако изначальную проблему мы не решили. Скорость поставки осталась прежней. Но об этом я расскажу в следующем посте. :)
// Если сталкивались с ситуациями ухудшения производительности из-за локальных оптимизаций — пишите в комментах. И не забывайте про
Please open Telegram to view this post
VIEW IN TELEGRAM
Патрик Ленсиони «5 пороков команды»
Некоторые книги стоит перечитывать раз в несколько лет. К таким я отношу, например, все труды Нассима Талеба. Но не все книги обязаны быть настолько же сложными, чтобы приносить пользу.
Первый раз «5 пороков команды» я читал где-то пять лет назад. Я тогда уже больше года управлял своей первой командой и в целом неплохо справлялся. Книга мне понравилась, но не зажгла, оставив послевкусие типа: «С тезисами согласен, звучит хорошо».
Но недавно, на обучении для руководителей, я вновь коснулся модели Ленсиони. И на этот раз она показалась мне гораздо более глубокой, чем на первый взгляд. Поэтому я взял первоисточник и приступил к чтению.
⭐️ О чём книга
Книга посвящена пяти основным порокам, которые мешают группе людей стать командой. К ним относятся: взаимное недоверие, уход от конфликта, безответственность, нетребовательность и безразличие к результату. Также в книге показано, как эти пороки мешают команде работать эффективно.
В книге раскрываются следующие темы:
➡️ Как каждый из пороков негативно влияет на команду?
➡️ Как исправлять эти пороки?
➡️ Какие упражнения могут сблизить и сплотить команду?
⭐️ 3 идеи из книги
🟡 Члены команды должны рассматривать коллективные результаты как счёт в футбольном матче. В хорошей команде выигрывают или проигрывают все одновременно. Если в команде возможны ситуации, где кто-то выигрывает, а другие нет, то это не команда, а группа.
🟡 Не соглашайся, но выполняй. Иногда обсуждения проблем и попытки прийти к единому мнению могут парализовать работу команды. В таких случаях самая эффективная стратегия — не согласиться с решением, но подчиниться ему, будто согласен. Решения команды должны быть выше конкретного человека.
🟡 Ссора и спор — это две разные вещи. Спор (конструктивный) является нормальной частью работы и направлен на то, чтобы улучшить конечный результат команды. Ссора же — это конфликт, который вредит доверию и командному духу, никак не помогая двигаться к цели.
⭐️ Мои впечатления
В этот раз книга Ленсиони произвела на меня гораздо большее впечатление. Я думаю, что сказывается прожитый опыт — многие ситуации, которые автор описывает в книге, были мне уже знакомы (местами прямо флешбеки возникали).
Модель Ленсиони неидеальна, как и любая другая модель. Но это не лишает её полезности. Особенно мне понравилось рассматривать, как пороки взаимосвязаны и один порождает другой. Например, из недоверия вытекает безответственность и нетребовательность, которые, в свою очередь, порождают уход от конфликта и безразличие к результату.
Конечно, связи там чуть сложнее, но ключевая мысль — любой порок команды создаёт усиливающую петлю обратной связи для других пороков. Фактически, можно получить каскадный эффект: возникновение одного порока создаёт второй, который создаёт третий, который…
Я бы рекомендовал прочитать эту книгу тимлидам, у которых уже есть некоторый опыт. Новичкам она вряд ли будет полезна — идеи могут показаться классными, но слишком уж абстрактными. Лично я понял эту книгу гораздо лучше, когда набрался всякого-разного (не всегда приятного) опыта.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Некоторые книги стоит перечитывать раз в несколько лет. К таким я отношу, например, все труды Нассима Талеба. Но не все книги обязаны быть настолько же сложными, чтобы приносить пользу.
Первый раз «5 пороков команды» я читал где-то пять лет назад. Я тогда уже больше года управлял своей первой командой и в целом неплохо справлялся. Книга мне понравилась, но не зажгла, оставив послевкусие типа: «С тезисами согласен, звучит хорошо».
Но недавно, на обучении для руководителей, я вновь коснулся модели Ленсиони. И на этот раз она показалась мне гораздо более глубокой, чем на первый взгляд. Поэтому я взял первоисточник и приступил к чтению.
Книга посвящена пяти основным порокам, которые мешают группе людей стать командой. К ним относятся: взаимное недоверие, уход от конфликта, безответственность, нетребовательность и безразличие к результату. Также в книге показано, как эти пороки мешают команде работать эффективно.
В книге раскрываются следующие темы:
В этот раз книга Ленсиони произвела на меня гораздо большее впечатление. Я думаю, что сказывается прожитый опыт — многие ситуации, которые автор описывает в книге, были мне уже знакомы (местами прямо флешбеки возникали).
Модель Ленсиони неидеальна, как и любая другая модель. Но это не лишает её полезности. Особенно мне понравилось рассматривать, как пороки взаимосвязаны и один порождает другой. Например, из недоверия вытекает безответственность и нетребовательность, которые, в свою очередь, порождают уход от конфликта и безразличие к результату.
Конечно, связи там чуть сложнее, но ключевая мысль — любой порок команды создаёт усиливающую петлю обратной связи для других пороков. Фактически, можно получить каскадный эффект: возникновение одного порока создаёт второй, который создаёт третий, который…
Я бы рекомендовал прочитать эту книгу тимлидам, у которых уже есть некоторый опыт. Новичкам она вряд ли будет полезна — идеи могут показаться классными, но слишком уж абстрактными. Лично я понял эту книгу гораздо лучше, когда набрался всякого-разного (не всегда приятного) опыта.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
Цикл постов про самообучение
Формат обучения в школе и институте — это верный способ привить человеку отвращение к самой мысли о том, чтобы учиться чему-то новому. Я довольно долго искал свои принципы эффективного самообразования, потому что в IT невозможно бесконечно ехать на старых знаниях.
Очередной мой цикл постов был посвящён тем принципам обучения и самообразования, которыми я руководствуюсь каждый день. Поэтому если что-то пропустили — самое время наверстать. И для удобства я собрал все ссылки по порядку в один пост. Но читать посты можно в любом порядке — они самодостаточны.
⭐️ Посты
➡️ Зачем мне это знать? – о волшебном вопросе, который значительно бустит эффективность обучения.
➡️ Хочешь научиться? Пиши. – о подходе, который позволяет осмыслять информацию, а не просто потреблять её.
➡️ Читать легко, а думать — больно — о том, что наиболее ценно в процессе самообразования.
➡️ Сколько книжек по боксу нужно прочитать, чтобы побить Майка Тайсона? – о ценности тестирования новых идей на практике.
➡️ Как тестировать идеи и при чём тут Голлум – о процессе тестирования новых идей.
➡️ Сколько нужно знать, чтобы делать? – о том, в какой момент нужно переходить от теории к практике.
➡️ Зачем так заморачиваться с обучением? – личная рефлексия о том, чего ради я так усложняю себе жизнь.
Приятного чтения!
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Формат обучения в школе и институте — это верный способ привить человеку отвращение к самой мысли о том, чтобы учиться чему-то новому. Я довольно долго искал свои принципы эффективного самообразования, потому что в IT невозможно бесконечно ехать на старых знаниях.
Очередной мой цикл постов был посвящён тем принципам обучения и самообразования, которыми я руководствуюсь каждый день. Поэтому если что-то пропустили — самое время наверстать. И для удобства я собрал все ссылки по порядку в один пост. Но читать посты можно в любом порядке — они самодостаточны.
Приятного чтения!
Please open Telegram to view this post
VIEW IN TELEGRAM
Как я искал, что тормозит поставку команды
Итак, локальная оптимизация привела нас в парадоксальную ситуацию: программисты стали делать больше, а поставка команды снизилась. Чаще всего это случается, когда изменения не учитывают бутылочное горлышко системы. Но мы не сразу поняли, в чём проблема.
В предыдущем посте я рассказал о том, что такое бутылочные горлышки и как производительность моей команды ухудшилась из-за увеличения скорости разработки. В конечном счёте нам пришлось откатить изменения и снизить количество задач, производимых программистами. Бутылочным горлышком оказался ресурс тестировщиков, а не скорость написания кода.
⭐️ С чего начать поиск бутылочных горлышек
Я забежал вперёд и раскрыл спойлер — что оказалось бутылочным горлышком в нашем случае. Но ведь это не вся история. Нам пришлось потратить время и усилия на поиск узкого места.
Итак, наш процесс стабилизировался благодаря снижению поставки задач от разработки в тестирование. Но изначальная проблема осталась, ведь нам так и не удалось повысить производительность команды. Поэтому мы решили начать с анализа текущих процессов команды.
Для начала я пошёл и покопался, что может указывать на бутылочное горлышко в системе. В книге «Цель» Голдратт приводит следующий признак: перед бутылочным горлышком всегда скапливается работа. Выглядеть это может по-разному: какой-то этап процесса оказывается переполнен задачами или же задачи на нём выполняются очень долго. Так или иначе, при визуализации процесса на той же канбан-доске бутылочное горлышко обычно легко увидеть.
⭐️ Действительно ли это бутылочное горлышко?
В нашем случае всё оказалось просто до боли: на этапе Ready for QA было огромное количество задач, которое в основном увеличивалось. В среднем там висело по 10 задач с периодическими увеличениями до 15.
Но скопления работы недостаточно для того, чтобы назначить какой-то этап бутылочным горлышком. Поэтому мы решили применить дополнительные инструменты анализа, чтобы повысить свою уверенность:
➡️ Посмотрели на некотором периоде времени (несколько недель), как у нас меняется состояние колонки Ready for QA и cycle time для этого статуса. Мы увидели, что cycle time самый большой на всём жизненном цикле задачи, а задач в Ready for QA приходит больше, чем уходит.
➡️ Провели ретроспективы, посвящённые трудностям в поставке за последние несколько недель. Тестировщики жаловались на нагрузку, программисты жаловались, что задачи висят в тестировании и их не получается смержить, из-за чего приходится править конфликты.
➡️ На дейликах часто звучали фразы вида: «Протестируйте, пожалуйста, эту задачу в приоритете, она мне нужна для следующей задачи».Как видите, сразу несколько признаков указывали на то, что бутылочным горлышком является тестирование. Поэтому наша локальная оптимизация скорости разработки сделала всей системе только хуже — тестирование просто не могло переварить увеличившийся поток задач.
⭐️ Главная ошибка при поиске бутылочных горлышек
На мой взгляд, главная ошибка — принимать первую же гипотезу как истину и бросаться её чинить.
Обжёгшись на молоке, я решил перестраховаться и набрать достаточно доказательств того, что бутылочное горлышко находится именно в тестировании. Поэтому немного затянул процесс. Однако предыдущий неудачный опыт научил меня тому, что лучше перебдеть, чем недобдеть и опять сделать команде плохо.
В некоторых процессах бывают статусы с долгим cycle time, но это не делает их бутылочным горлышком. Например, одна из моих команд работала по Scrum, и самый долгий cycle time был у статуса Ready for release. Делает ли это частоту релизов бутылочным горлышком команды? Конечно, нет. Поэтому важно внимательно и всесторонне изучить свои гипотезы, прежде чем что-либо менять.
Итак, нам удалось найти и провалидировать бутылочное горлышко команды. Теперь мы были готовы к тому, чтобы ускорять поставку. Об этом — в следующем посте.
// Сталкивались ли вы с бутылочными горлышками в разработке? Делитесь в комментариях, интересен чужой опыт. А также ставьте💛 , если тема заходит.
Итак, локальная оптимизация привела нас в парадоксальную ситуацию: программисты стали делать больше, а поставка команды снизилась. Чаще всего это случается, когда изменения не учитывают бутылочное горлышко системы. Но мы не сразу поняли, в чём проблема.
В предыдущем посте я рассказал о том, что такое бутылочные горлышки и как производительность моей команды ухудшилась из-за увеличения скорости разработки. В конечном счёте нам пришлось откатить изменения и снизить количество задач, производимых программистами. Бутылочным горлышком оказался ресурс тестировщиков, а не скорость написания кода.
Я забежал вперёд и раскрыл спойлер — что оказалось бутылочным горлышком в нашем случае. Но ведь это не вся история. Нам пришлось потратить время и усилия на поиск узкого места.
Итак, наш процесс стабилизировался благодаря снижению поставки задач от разработки в тестирование. Но изначальная проблема осталась, ведь нам так и не удалось повысить производительность команды. Поэтому мы решили начать с анализа текущих процессов команды.
Для начала я пошёл и покопался, что может указывать на бутылочное горлышко в системе. В книге «Цель» Голдратт приводит следующий признак: перед бутылочным горлышком всегда скапливается работа. Выглядеть это может по-разному: какой-то этап процесса оказывается переполнен задачами или же задачи на нём выполняются очень долго. Так или иначе, при визуализации процесса на той же канбан-доске бутылочное горлышко обычно легко увидеть.
В нашем случае всё оказалось просто до боли: на этапе Ready for QA было огромное количество задач, которое в основном увеличивалось. В среднем там висело по 10 задач с периодическими увеличениями до 15.
Но скопления работы недостаточно для того, чтобы назначить какой-то этап бутылочным горлышком. Поэтому мы решили применить дополнительные инструменты анализа, чтобы повысить свою уверенность:
На мой взгляд, главная ошибка — принимать первую же гипотезу как истину и бросаться её чинить.
Обжёгшись на молоке, я решил перестраховаться и набрать достаточно доказательств того, что бутылочное горлышко находится именно в тестировании. Поэтому немного затянул процесс. Однако предыдущий неудачный опыт научил меня тому, что лучше перебдеть, чем недобдеть и опять сделать команде плохо.
В некоторых процессах бывают статусы с долгим cycle time, но это не делает их бутылочным горлышком. Например, одна из моих команд работала по Scrum, и самый долгий cycle time был у статуса Ready for release. Делает ли это частоту релизов бутылочным горлышком команды? Конечно, нет. Поэтому важно внимательно и всесторонне изучить свои гипотезы, прежде чем что-либо менять.
Итак, нам удалось найти и провалидировать бутылочное горлышко команды. Теперь мы были готовы к тому, чтобы ускорять поставку. Об этом — в следующем посте.
// Сталкивались ли вы с бутылочными горлышками в разработке? Делитесь в комментариях, интересен чужой опыт. А также ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Как ускорить поставку без дополнительных людей
Итак, моей команде потребовалось ускорить поставку. Увеличив производительность разработки, мы чуть не довели своих QA до выгорания. Поэтому мы сделали шаг назад и начали анализировать весь процесс поставки, чтобы найти затык.
Предыдущий пост закончился на том, что мы нашли “бутылочное горлышко” своего процесса поставки. Им оказалось тестирование — команда не могла поставлять больше, чем QA в состоянии переварить. Мы тщательно проверили эту гипотезу и убедились, что она верна.
Конечно же, первым делом я запросил дополнительных тестировщиков в команду. Начальство ответило в стиле ДимАнатолича: “Денег нет, но вы там держитесь. И поставку ускорьте.” Что поделать — пришлось выкручиваться.
⭐️ Выкручиваемся как можем
Первым делом я вернулся к книге “Цель” Голдратта, которая и дала мне понимание бутылочных горлышек. Вопрос был следующий: как ускоряться без дополнительных ресурсов? И я нашёл ответ — строить систему вокруг бутылочного горлышка, подчинить ему весь производственный процесс. Для этого можно сделать следующие вещи:
➡️ Перестать перегружать бутылочное горлышко работой (всё равно больше не сделает).
➡️ Ускорить прохождение работы через бутылочное горлышко (повысить КПД).
➡️ Убрать лишнюю работу с бутылочного горлышка (вдруг оно делает что-то бесполезное).
➡️ Увеличить ресурсы бутылочного горлышка (то, с чего я пытался начать).
В нашем случае подчинение поставки бутылочному горлышку значило, что тестирование становится центральным компонентом системы. И вся система должна быть построена вокруг него. Увеличение ресурсов нам было недоступно (по крайней мере сейчас), поэтому мы стали применять остальные пункты выше.
⭐️ Первые шаги
Первым делом мы перестали перегружать тестировщиков фичами. К счастью, мне даже не пришлось продавать это стейкхолдерам — их интересовала только конечная поставка по результатам спринта, а её объём определялся ресурсом тестирования. Ребята выдохнули, и мы стали думать над фундаментальным вопросом: как нам ускорить тестирование за счёт более свободных ресурсов разработки?
У нас уже была автоматизация, но самих тестов было не слишком много. У тестировщиков постоянно не хватало на них времени. Параллельно мы примерно прикинули, сколько задач возвращается из тестирования на доработку, и поняли, что повышение качества входа может сильно нас ускорить.
Поэтому мы решили вложиться одновременно в автоматизацию и улучшение требований. Список идей выглядел примерно так:
➡️ Изменили DoR: задача считается готовой к разработке, только если в ней описаны тест-кейсы. Для описания тест-кейсов подключается тестирование.
➡️ Изменили DoD: задача считается выполненной, только если разработчик написал автотесты, покрывающие описанные в требованиях кейсы.
➡️ Завели задачи на написание автотестов. Эти задачи выполнялись как техдолг.
Эти перемены учитывали все заинтересованные стороны. Гипотетический путь выглядел примерно так:
➡️ Описанные тест-кейсы упрощали работу программиста, которому не приходилось придумывать их на ходу.
➡️ Написание автотестов снижало количество багов на входе в тестирование.
➡️ Поскольку автотесты сохраняются, количество багов в целом должно уменьшаться.
➡️ Ресурс тестировщиков тратится на написание тест-кейсов, но это окупается за счёт ускорения тестирования.
➡️ Написание автотестов программистами постепенно повысит общее покрытие приложения и дополнительно снизит количество багов.
⭐️ Что получилось в итоге
Гипотезы сработали отлично. Пару спринтов мы привыкали, но обратная связь от ребят была потрясающей. Программисты радовались, что задачи реже возвращаются на доработку, тестировщики радовались, что в задачах меньше багов и растёт покрытие тестами, я радовался ускорению поставки. При этом спокойны были и стейкхолдеры: все при деле, фичи делаются — всё прекрасно.
Мы добились ускорения поставки на 30%, и этот показатель продолжал расти. Бонусом мы получили постепенное снижение багов на проде практически до нуля. Но впереди были новые челленджи, о которых я расскажу в следующем посте :)
// Ставь💛 в поддержку своих тестировщиков!
Итак, моей команде потребовалось ускорить поставку. Увеличив производительность разработки, мы чуть не довели своих QA до выгорания. Поэтому мы сделали шаг назад и начали анализировать весь процесс поставки, чтобы найти затык.
Предыдущий пост закончился на том, что мы нашли “бутылочное горлышко” своего процесса поставки. Им оказалось тестирование — команда не могла поставлять больше, чем QA в состоянии переварить. Мы тщательно проверили эту гипотезу и убедились, что она верна.
Конечно же, первым делом я запросил дополнительных тестировщиков в команду. Начальство ответило в стиле ДимАнатолича: “Денег нет, но вы там держитесь. И поставку ускорьте.” Что поделать — пришлось выкручиваться.
Первым делом я вернулся к книге “Цель” Голдратта, которая и дала мне понимание бутылочных горлышек. Вопрос был следующий: как ускоряться без дополнительных ресурсов? И я нашёл ответ — строить систему вокруг бутылочного горлышка, подчинить ему весь производственный процесс. Для этого можно сделать следующие вещи:
В нашем случае подчинение поставки бутылочному горлышку значило, что тестирование становится центральным компонентом системы. И вся система должна быть построена вокруг него. Увеличение ресурсов нам было недоступно (по крайней мере сейчас), поэтому мы стали применять остальные пункты выше.
Первым делом мы перестали перегружать тестировщиков фичами. К счастью, мне даже не пришлось продавать это стейкхолдерам — их интересовала только конечная поставка по результатам спринта, а её объём определялся ресурсом тестирования. Ребята выдохнули, и мы стали думать над фундаментальным вопросом: как нам ускорить тестирование за счёт более свободных ресурсов разработки?
У нас уже была автоматизация, но самих тестов было не слишком много. У тестировщиков постоянно не хватало на них времени. Параллельно мы примерно прикинули, сколько задач возвращается из тестирования на доработку, и поняли, что повышение качества входа может сильно нас ускорить.
Поэтому мы решили вложиться одновременно в автоматизацию и улучшение требований. Список идей выглядел примерно так:
Эти перемены учитывали все заинтересованные стороны. Гипотетический путь выглядел примерно так:
Гипотезы сработали отлично. Пару спринтов мы привыкали, но обратная связь от ребят была потрясающей. Программисты радовались, что задачи реже возвращаются на доработку, тестировщики радовались, что в задачах меньше багов и растёт покрытие тестами, я радовался ускорению поставки. При этом спокойны были и стейкхолдеры: все при деле, фичи делаются — всё прекрасно.
Мы добились ускорения поставки на 30%, и этот показатель продолжал расти. Бонусом мы получили постепенное снижение багов на проде практически до нуля. Но впереди были новые челленджи, о которых я расскажу в следующем посте :)
// Ставь
Please open Telegram to view this post
VIEW IN TELEGRAM
Тейва Харшани «100 ошибок Go и как их избежать»
Давайте немного отдохнём от менеджмента, софтов и вот этого вот всего — с хардкорным кодом! Как-никак, я до сих пор каждый день пишу код. Последние полтора года я программирую на Golang, и мне очень нравится этот язык.
Конечно же, базовые книжки я прочитал ещё на стадии изучения языка. Но с тех пор как-то руки не доходили почитать что-то конкретно про Go — я больше читал про архитектуру, распределённые системы и базы данных. И тут произошло неожиданно приятное событие: ко мне пришли ребята из издательского дома «Питер» и предложили сделать обзор на обновлённое издание книги «100 ошибок Go».
Конечно, я не мог отказаться от обзора очередной интересной книги. Тем более что «100 ошибок Go» — книга не для новичков. Но обо всём по порядку.
⭐️ О чём книга
Как следует из названия, книга посвящена разбору 100 примеров ошибок и неэффективной работы в языке Golang. Глобально ошибки разбиты на смысловые разделы: организация кода, обработка ошибок, конкурентность и так далее.
Что можно узнать из книги:
➡️ Как грамотно использовать интерфейсы
➡️ Как выстрелить себе в ногу, перепутав длину и ёмкость среза
➡️ Чем всё-таки отличается конкурентность от параллелизма
➡️ Как создать race condition с помощью оператора append
➡️ И многое другое :)
⭐️ 3 идеи из книги
В Go интерфейс создаётся на уровне клиента. Это непривычно для программистов типа меня, которые обычно определяют интерфейс как абстракцию доступа. Проблема в том, что интерфейсы в Go реализуются неявно, и поэтому код не должен навязывать абстракцию своим клиентам.
Называть пакеты в Go нужно ещё тщательнее, чем переменные. Именование пакета должно быть кратким, ёмким и отражать его возможности. Пакеты похожи на namespace из C#, и одновременно не являются ими. Знали бы вы, сколько мы времени на код-ревью тратим, придумывая нейминг пакетов…
Обработка ошибки должна быть выполнена ровно один раз. Знаю-знаю, всегда есть соблазн сделать что-то и передать ошибку дальше, но это не идиоматично. Если код обработал ошибку, то она не должна «лететь» дальше. Является ли дополнительное логирование обработкой — решайте самостоятельно :)
⭐️ Мои впечатления
Книга мне очень понравилась. Она далеко не такая простая и примитивная, как базовые руководства по Go, и посвящена разным хитрым нюансам языка. Некоторые ошибки довольно очевидны, если внимательно пройти A Tour of Go, но многие другие дали мне достаточно интересной пищи для размышлений.
Большой плюс книги — куча интерактивных примеров кода, которые можно запихнуть в Go Playground и поэкспериментировать (я провёл несколько весьма интересных экспериментов с конкурентностью). При этом код написан очень ясно, лаконично и снабжён комментариями, поэтому читать его легко и приятно.
Отдельный плюс — перевод книги. Он достаточно хорош: в процессе чтения я не спотыкался на словах и не ловил ступор. Технические книги в целом переводить непросто, и переводчики «100 ошибок Go» хорошо справились со своей задачей.
Если вы только начинаете изучать Go — скорее всего, книга вам покажется тяжеловатой. Но более опытным ребятам она, по моему мнению, зайдёт очень хорошо.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Давайте немного отдохнём от менеджмента, софтов и вот этого вот всего — с хардкорным кодом! Как-никак, я до сих пор каждый день пишу код. Последние полтора года я программирую на Golang, и мне очень нравится этот язык.
Конечно же, базовые книжки я прочитал ещё на стадии изучения языка. Но с тех пор как-то руки не доходили почитать что-то конкретно про Go — я больше читал про архитектуру, распределённые системы и базы данных. И тут произошло неожиданно приятное событие: ко мне пришли ребята из издательского дома «Питер» и предложили сделать обзор на обновлённое издание книги «100 ошибок Go».
Конечно, я не мог отказаться от обзора очередной интересной книги. Тем более что «100 ошибок Go» — книга не для новичков. Но обо всём по порядку.
Как следует из названия, книга посвящена разбору 100 примеров ошибок и неэффективной работы в языке Golang. Глобально ошибки разбиты на смысловые разделы: организация кода, обработка ошибок, конкурентность и так далее.
Что можно узнать из книги:
В Go интерфейс создаётся на уровне клиента. Это непривычно для программистов типа меня, которые обычно определяют интерфейс как абстракцию доступа. Проблема в том, что интерфейсы в Go реализуются неявно, и поэтому код не должен навязывать абстракцию своим клиентам.
Называть пакеты в Go нужно ещё тщательнее, чем переменные. Именование пакета должно быть кратким, ёмким и отражать его возможности. Пакеты похожи на namespace из C#, и одновременно не являются ими. Знали бы вы, сколько мы времени на код-ревью тратим, придумывая нейминг пакетов…
Обработка ошибки должна быть выполнена ровно один раз. Знаю-знаю, всегда есть соблазн сделать что-то и передать ошибку дальше, но это не идиоматично. Если код обработал ошибку, то она не должна «лететь» дальше. Является ли дополнительное логирование обработкой — решайте самостоятельно :)
Книга мне очень понравилась. Она далеко не такая простая и примитивная, как базовые руководства по Go, и посвящена разным хитрым нюансам языка. Некоторые ошибки довольно очевидны, если внимательно пройти A Tour of Go, но многие другие дали мне достаточно интересной пищи для размышлений.
Большой плюс книги — куча интерактивных примеров кода, которые можно запихнуть в Go Playground и поэкспериментировать (я провёл несколько весьма интересных экспериментов с конкурентностью). При этом код написан очень ясно, лаконично и снабжён комментариями, поэтому читать его легко и приятно.
Отдельный плюс — перевод книги. Он достаточно хорош: в процессе чтения я не спотыкался на словах и не ловил ступор. Технические книги в целом переводить непросто, и переводчики «100 ошибок Go» хорошо справились со своей задачей.
Если вы только начинаете изучать Go — скорее всего, книга вам покажется тяжеловатой. Но более опытным ребятам она, по моему мнению, зайдёт очень хорошо.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
Плавающие бутылочные горлышки
В процессе ускорения поставки командой мы обнаружили бутылочное горлышко в тестировании. В предыдущем посте я рассказал, как мы его “расшили”.
Хотелось бы мне сказать, что это был счастливый конец истории и после этого все зажили счастливо, но это было бы не совсем правдой. Мы и правда добились значительного ускорения поставки и снижения количества багов, но появились новые трудности.
⭐️ Прилетело откуда не ждали
Тестирование перестало захлёбываться от нагрузки, разработка пилит тесты — кажется, что всё прекрасно. Но теперь перестал справляться другой элемент системы. Угадаете, какой?
Требования от бизнеса. Ускорение поставки привело к тому, что мы действительно стали делать больше фич. Поэтому нам потребовалось больше задач со стороны бизнеса, к чему наш продакт оказался не готов. Он привык работать в определённом темпе и уделять нам определённый объём внимания (он работал с несколькими командами), поэтому рост производительности создал ему внезапные проблемы. Он за нас был, конечно, рад — но не от всего сердца.
А теперь добавьте к этой возросшей производительности мой принцип “не делать бессмысленную хрень” и поставьте себя на место продакта. Ему понадобилось некоторое время на адаптацию, а мы в это время с довольными лицами переделали кучу техдолга в продукте и докрутили автоматизацию.
⭐️ Главный вывод о бутылочных горлышках
Но сама ситуация меня немного напрягла. Мы исправили проблемы в одном месте — и сразу же получили новые проблемы в другом. Я вернулся к книге “Цель” и стал читать про бутылочные горлышки.
Герои книги тоже неоднократно сталкивались с такой проблемой. Каждый раз, когда они “расшивали” бутылочное горлышко, в системе неизбежно возникало новое. Это приводит нас к следующему выводу:
➡️ Бутылочное горлышко в системе есть всегда.
Вывод настолько очевиден, что аж бесит. И в этом весь Голдратт — он стремился сделать всё настолько очевидным, чтобы мог понять кто угодно.
Из этого вывода следует, что в системе всегда будет ограничивающий элемент. И он может перемещаться по системе. Любые изменения в системе могут вызвать перемещение бутылочного горлышка в другое место. К примеру, “расшивая” одно бутылочное горлышко, мы автоматически создаём другое.
В нашей ситуации мы “расшили” тестирование — и быстро упёрлись в поставку требований от бизнеса. Но другое решение могло создать и другие бутылочные горлышки. Например, если бы мне дали ещё парочку тестировщиков, то бутылочным горлышком могла бы стать разработка — программисты просто не успевали бы делать задачи с той скоростью, с которой их тестируют.
⭐️ Подводя итог
Из всей этой ситуации я вынес для себя несколько уроков:
➡️ Хочешь ускорить систему — найди бутылочное горлышко и строй процессы вокруг него.
➡️ Бутылочное горлышко в системе есть всегда.
➡️ Если бутылочное горлышко перестало быть бутылочным горлышком, значит, оно переместилось в другое место.
➡️ Любые изменения в системе могут вызвать перемещение текущего бутылочного горлышка в новое место.
Это был интересный путь, и он меня многому научил. С тех пор я всегда стараюсь сначала посмотреть на процесс верхнеуровнево, чтобы определить его потенциальные узкие места — чаще всего в них и скрываются точки оптимизации.
На этом я заканчиваю небольшой цикл про бутылочные горлышки. Спасибо за ваши лайки, комментарии и вопросы — они были для меня очень ценны. Мне настолько понравилось писать этот цикл, что аж доклад захотелось сделать (но этому препятствует бутылочное горлышко в виде моего времени).
// И не забывайте нажать волшебный💛
В процессе ускорения поставки командой мы обнаружили бутылочное горлышко в тестировании. В предыдущем посте я рассказал, как мы его “расшили”.
Хотелось бы мне сказать, что это был счастливый конец истории и после этого все зажили счастливо, но это было бы не совсем правдой. Мы и правда добились значительного ускорения поставки и снижения количества багов, но появились новые трудности.
Тестирование перестало захлёбываться от нагрузки, разработка пилит тесты — кажется, что всё прекрасно. Но теперь перестал справляться другой элемент системы. Угадаете, какой?
Требования от бизнеса. Ускорение поставки привело к тому, что мы действительно стали делать больше фич. Поэтому нам потребовалось больше задач со стороны бизнеса, к чему наш продакт оказался не готов. Он привык работать в определённом темпе и уделять нам определённый объём внимания (он работал с несколькими командами), поэтому рост производительности создал ему внезапные проблемы. Он за нас был, конечно, рад — но не от всего сердца.
А теперь добавьте к этой возросшей производительности мой принцип “не делать бессмысленную хрень” и поставьте себя на место продакта. Ему понадобилось некоторое время на адаптацию, а мы в это время с довольными лицами переделали кучу техдолга в продукте и докрутили автоматизацию.
Но сама ситуация меня немного напрягла. Мы исправили проблемы в одном месте — и сразу же получили новые проблемы в другом. Я вернулся к книге “Цель” и стал читать про бутылочные горлышки.
Герои книги тоже неоднократно сталкивались с такой проблемой. Каждый раз, когда они “расшивали” бутылочное горлышко, в системе неизбежно возникало новое. Это приводит нас к следующему выводу:
Вывод настолько очевиден, что аж бесит. И в этом весь Голдратт — он стремился сделать всё настолько очевидным, чтобы мог понять кто угодно.
Из этого вывода следует, что в системе всегда будет ограничивающий элемент. И он может перемещаться по системе. Любые изменения в системе могут вызвать перемещение бутылочного горлышка в другое место. К примеру, “расшивая” одно бутылочное горлышко, мы автоматически создаём другое.
В нашей ситуации мы “расшили” тестирование — и быстро упёрлись в поставку требований от бизнеса. Но другое решение могло создать и другие бутылочные горлышки. Например, если бы мне дали ещё парочку тестировщиков, то бутылочным горлышком могла бы стать разработка — программисты просто не успевали бы делать задачи с той скоростью, с которой их тестируют.
Из всей этой ситуации я вынес для себя несколько уроков:
Это был интересный путь, и он меня многому научил. С тех пор я всегда стараюсь сначала посмотреть на процесс верхнеуровнево, чтобы определить его потенциальные узкие места — чаще всего в них и скрываются точки оптимизации.
На этом я заканчиваю небольшой цикл про бутылочные горлышки. Спасибо за ваши лайки, комментарии и вопросы — они были для меня очень ценны. Мне настолько понравилось писать этот цикл, что аж доклад захотелось сделать (но этому препятствует бутылочное горлышко в виде моего времени).
// И не забывайте нажать волшебный
Please open Telegram to view this post
VIEW IN TELEGRAM
Почему цели по SMART не работают
Недавно на обучении для руководителей я проходил модуль по постановке целей. Мы разбирали современные фреймворки и методологии и, конечно же, начали с популярного SMART.
Я всегда относился к нему (как и к прочим аббревиатурам) скептически, потому что мнемоники частенько «натягивают сову на глобус» ради красоты (привет, ACID). Но сама идея SMART мне нравилась. И вот на обучении мне порекомендовали статью, которая коротко и ясно объясняет, как именно нужно ставить цели по SMART, чтобы они действительно работали.
⭐️ Интересные идеи
➡️ Основная проблема — зацикливание на том, что хорошая цель должна обладать всеми пятью признаками SMART. Но во многих случаях это просто нереально. Попытки полностью применить SMART приводят либо к очень странным целям, либо к отказу от него.
➡️ Чем выше уровень менеджмента, тем более абстрактными становятся цели и тем сложнее применять SMART. Излишняя конкретизация лишает цель преимуществ абстрактности (этот принцип реализован в OKR — абстрактная цель, конкретные результаты).
➡️ Основная проблема SMART — слишком много разных трактовок. Руководителей сбивает с толку разнородная информация из книг, журналов, статей и так далее. Изначальная идея обычно намного шире, чем альтернативные версии других авторов.
Приятного чтения!
// Ставь💛 , если применяешь SMART в делах
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Недавно на обучении для руководителей я проходил модуль по постановке целей. Мы разбирали современные фреймворки и методологии и, конечно же, начали с популярного SMART.
Я всегда относился к нему (как и к прочим аббревиатурам) скептически, потому что мнемоники частенько «натягивают сову на глобус» ради красоты (привет, ACID). Но сама идея SMART мне нравилась. И вот на обучении мне порекомендовали статью, которая коротко и ясно объясняет, как именно нужно ставить цели по SMART, чтобы они действительно работали.
Приятного чтения!
// Ставь
Please open Telegram to view this post
VIEW IN TELEGRAM
RapidBI
Why SMART Objectives don’t work
It’s easy to say Why SMART Objectives don’t work when we have been using variants that often confuse people & more restrictive than was initially proposed
Радислав Гандапас, «Камасутра для оратора»
В этом году у меня довольно бурно идёт работа с публичными выступлениями: доклады (наконец-то) начали попадать в программы конференций, выступаю я относительно регулярно, плюс наложилось внутреннее обучение по выступлениям. Тема для меня всё-таки относительно новая, поэтому я постоянно ищу любые советы и идеи, как сделать свои доклады лучше.
Конечно же, я не мог пройти мимо книги одного из самых известных спикеров России — Радислава Гандапаса. Этот человек зарабатывает на жизнь публичными выступлениями, поэтому его опыт в этой области я считаю ценным и интересным.
⭐️ О чём книга
Книга посвящена основам публичных выступлений. Автор задаётся целью научить читателя не просто выступать публично, но ещё и получать от этого удовольствие (прекрасный посыл, я считаю).
В книге раскрываются следующие темы:
➡️ Как работать с волнением перед выступлением?
➡️ Как подготовить хорошее выступление?
➡️ Как устанавливать контакт с аудиторией и вовлекать её?
➡️ Как отвечать на каверзные вопросы?
⭐️ 3 идеи из книги
➡️ При анализе прошедшего выступления сосредоточьтесь на том, что у вас получилось хорошо. Поиск ошибок закрепляет мнение о себе как о слабом спикере. Нужно найти свои фирменные сильные стороны и использовать их.
➡️ Блестящий финал получается, если последние фразы выступления перекликаются с первыми и таким образом замыкают круг. Подтверждаю на своём опыте как слушателя: от таких выступлений всегда остаются приятные впечатления.
➡️ Не выступайте перед людьми, а разговаривайте с ними. Скучные лекторы-всезнайки всем ещё в университете оскомину набили.
⭐️ Мои впечатления
Начну с хорошего. В книге я встретил несколько действительно интересных и необычных идей, которые можно применить на практике. Например, поиск своих сильных сторон как спикера при пост-анализе выступления — я почему-то обычно только ошибки ищу. Также я утащил некоторые идеи по взаимодействию с аудиторией и поддержанию вовлечённости.
Но вау-эффекта книга не произвела. Довольно много воды и бахвальства, а вторая половина вообще состоит из многословных вопросов и ответов. Плюс некоторые метафоры Гандапаса показались мне, кхм, излишне яркими.
В целом книжка достойна того, чтобы начинающие спикеры просмотрели её и взяли себе на вооружение некоторые идеи. Да и опытные докладчики могут найти себе парочку нововведений. Но хорошее обучение по публичным выступлениям и большое количество практики она, конечно, не заменит.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
В этом году у меня довольно бурно идёт работа с публичными выступлениями: доклады (наконец-то) начали попадать в программы конференций, выступаю я относительно регулярно, плюс наложилось внутреннее обучение по выступлениям. Тема для меня всё-таки относительно новая, поэтому я постоянно ищу любые советы и идеи, как сделать свои доклады лучше.
Конечно же, я не мог пройти мимо книги одного из самых известных спикеров России — Радислава Гандапаса. Этот человек зарабатывает на жизнь публичными выступлениями, поэтому его опыт в этой области я считаю ценным и интересным.
Книга посвящена основам публичных выступлений. Автор задаётся целью научить читателя не просто выступать публично, но ещё и получать от этого удовольствие (прекрасный посыл, я считаю).
В книге раскрываются следующие темы:
Начну с хорошего. В книге я встретил несколько действительно интересных и необычных идей, которые можно применить на практике. Например, поиск своих сильных сторон как спикера при пост-анализе выступления — я почему-то обычно только ошибки ищу. Также я утащил некоторые идеи по взаимодействию с аудиторией и поддержанию вовлечённости.
Но вау-эффекта книга не произвела. Довольно много воды и бахвальства, а вторая половина вообще состоит из многословных вопросов и ответов. Плюс некоторые метафоры Гандапаса показались мне, кхм, излишне яркими.
В целом книжка достойна того, чтобы начинающие спикеры просмотрели её и взяли себе на вооружение некоторые идеи. Да и опытные докладчики могут найти себе парочку нововведений. Но хорошее обучение по публичным выступлениям и большое количество практики она, конечно, не заменит.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
Всем привет!
Сегодня выступил на CodeFest с докладом «Лидерство в трудные времена». Спасибо всем пришедшим за ваши прекрасные вопросы и тёплые отзывы❤️ 🥹
Ещё пообщался с кучей классных людей, а с Сашей Брызгаловой даже сфоткался🙃
Завтра приглашаю всех присутствующих на квартирник «Менеджер-стоик: античные практики современного управления». Будет очень интересная дискуссия с участием менеджера и философа-стоика. Есть возможность качественно поспорить😉
Все записи опубликую в канале по готовности, так что если пропустили эту чудную конференцию — не беда. До встречи завтра💛
Сегодня выступил на CodeFest с докладом «Лидерство в трудные времена». Спасибо всем пришедшим за ваши прекрасные вопросы и тёплые отзывы
Ещё пообщался с кучей классных людей, а с Сашей Брызгаловой даже сфоткался
Завтра приглашаю всех присутствующих на квартирник «Менеджер-стоик: античные практики современного управления». Будет очень интересная дискуссия с участием менеджера и философа-стоика. Есть возможность качественно поспорить
Все записи опубликую в канале по готовности, так что если пропустили эту чудную конференцию — не беда. До встречи завтра
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Вкладываться в переносимые навыки
Итак, вы решили развиваться. Вы твёрдо намерены качать свои знания и навыки, чтобы стать в чём-то настоящей крутышкой. С чего вы начнёте?
Сейчас как никогда просто стало раскачиваться в любом направлении. Во всех сферах есть адекватная литература, тренажёры, менторы и многое другое. И эта доступность порождает новую проблему — проблему выбора.
⭐️ Почему так сложно формировать план самообразования?
Хорошо, когда роадмап прост и понятен. Есть точка А, точка Б, между ними — путь из конкретных навыков с понятными алгоритмами развития. Но на практике чаще всего бывает чуть иначе. Точка Б не очень конкретная, навыки и критерии их развития непонятны, путь к цели не просматривается.
Ситуация становится вдвойне сложной, когда навыки уже на хорошем уровне, и становится трудно развивать их дальше. С одной стороны, ковыряться в глубоких деталях текущих навыков может быть просто невыгодно по затратам сил. С другой стороны, альтернативные направления тоже вызывают вопросы. Что же делать?
⭐️ Переносимость знаний и навыков
Таким вопросом когда-то задавался и я. Я всю жизнь страдал жгучим любопытством. Иногда кажется, что мне интересно вообще ВСЁ. Но с ростом моего островка знаний ширилось и осознание океана неизвестности, поэтому выбор совершать приходилось.
В книге Скотта Адамса «Теория везения» (дурацкий перевод, не отражающий сути) я нашёл идею, помогающую выходить из таких дилемм. Адамс рекомендует для самообразования и развития выбирать наиболее универсальные, переносимые области знаний. Под переносимостью он понимает возможность применять это знание в различных сферах жизни.
Возьмём, например, переговоры. Они нас окружают не только на работе — в переговорной ситуации можно оказаться даже в отпуске, торгуясь с продавцом сувениров за магнитики. Широта применения этого навыка делает вложения в него очень выгодными.
А теперь давайте рассмотрим знания какого-нибудь специфического фреймворка. Эти знания применимы только в одной конкретной области — программировании с использованием этого фреймворка. Его границы не выходят за рамки работы (а иногда даже за рамки одной компании или команды).
⭐️ Давайте без крайностей
Из написанного выше можно сделать поспешный вывод о том, что узкопрофильные знания не нужны. И это будет ошибкой — нужны, ещё как. Просто важно понимать область их применения и необходимую глубину этих знаний. Например, язык программирования стоит изучать глубже, чем фреймворки и библиотеки. Но полностью посвящать всё своё обучение узкопрофильному, специализированному знанию тоже невыгодно — инвестировать время и силы нужно с максимальной отдачей.
Подход Скотта Адамса скорее подталкивает к тому, на что направить свои силы и время в долгосрочной перспективе. Если вам нужны конкретные знания и навыки для достижения какой-то цели — отлично. Но если такой цели нет, а расти хочется — имеет смысл вкладываться в универсальные вещи, которые могут пригодиться во многих жизненных ситуациях.
// Поделитесь своими удачными инвестициями в навыки в комментариях. Давайте обогатим арсенал друг друга. Например, я считаю крайне удачной инвестицией развитие навыков критического анализа информации.
Итак, вы решили развиваться. Вы твёрдо намерены качать свои знания и навыки, чтобы стать в чём-то настоящей крутышкой. С чего вы начнёте?
Сейчас как никогда просто стало раскачиваться в любом направлении. Во всех сферах есть адекватная литература, тренажёры, менторы и многое другое. И эта доступность порождает новую проблему — проблему выбора.
Хорошо, когда роадмап прост и понятен. Есть точка А, точка Б, между ними — путь из конкретных навыков с понятными алгоритмами развития. Но на практике чаще всего бывает чуть иначе. Точка Б не очень конкретная, навыки и критерии их развития непонятны, путь к цели не просматривается.
Ситуация становится вдвойне сложной, когда навыки уже на хорошем уровне, и становится трудно развивать их дальше. С одной стороны, ковыряться в глубоких деталях текущих навыков может быть просто невыгодно по затратам сил. С другой стороны, альтернативные направления тоже вызывают вопросы. Что же делать?
Таким вопросом когда-то задавался и я. Я всю жизнь страдал жгучим любопытством. Иногда кажется, что мне интересно вообще ВСЁ. Но с ростом моего островка знаний ширилось и осознание океана неизвестности, поэтому выбор совершать приходилось.
В книге Скотта Адамса «Теория везения» (дурацкий перевод, не отражающий сути) я нашёл идею, помогающую выходить из таких дилемм. Адамс рекомендует для самообразования и развития выбирать наиболее универсальные, переносимые области знаний. Под переносимостью он понимает возможность применять это знание в различных сферах жизни.
Возьмём, например, переговоры. Они нас окружают не только на работе — в переговорной ситуации можно оказаться даже в отпуске, торгуясь с продавцом сувениров за магнитики. Широта применения этого навыка делает вложения в него очень выгодными.
А теперь давайте рассмотрим знания какого-нибудь специфического фреймворка. Эти знания применимы только в одной конкретной области — программировании с использованием этого фреймворка. Его границы не выходят за рамки работы (а иногда даже за рамки одной компании или команды).
Из написанного выше можно сделать поспешный вывод о том, что узкопрофильные знания не нужны. И это будет ошибкой — нужны, ещё как. Просто важно понимать область их применения и необходимую глубину этих знаний. Например, язык программирования стоит изучать глубже, чем фреймворки и библиотеки. Но полностью посвящать всё своё обучение узкопрофильному, специализированному знанию тоже невыгодно — инвестировать время и силы нужно с максимальной отдачей.
Подход Скотта Адамса скорее подталкивает к тому, на что направить свои силы и время в долгосрочной перспективе. Если вам нужны конкретные знания и навыки для достижения какой-то цели — отлично. Но если такой цели нет, а расти хочется — имеет смысл вкладываться в универсальные вещи, которые могут пригодиться во многих жизненных ситуациях.
// Поделитесь своими удачными инвестициями в навыки в комментариях. Давайте обогатим арсенал друг друга. Например, я считаю крайне удачной инвестицией развитие навыков критического анализа информации.
Please open Telegram to view this post
VIEW IN TELEGRAM
Рустам Агамалиев, «Наука нечтения»
Как минимум пять человек поймали меня на CodeFest с вопросами о том, как я читаю. Пришла пора раскрыть завесу тайны!
Первое, с чего я начинал свой рассказ, — я не придумал ничего нового. Я просто понял, что не умею читать, и нашёл способ этому научиться.
Так уж сложились обстоятельства, что мой учитель недавно взял и опубликовал книгу о том, как нужно эффективно читать (или, точнее, не-читать) книги. И, конечно же, я её про-не-читал буквально через пару недель после публикации.
⭐️ О чём книга
Книга посвящена методу не-чтения. Суть его заключается в том, что внимательный и требовательный читатель гораздо больше не читает, чем читает. Метод направлен на то, чтобы извлекать суть из книг, получая ответы на свои вопросы без пустой траты времени и сил.
В книге раскрываются следующие темы:
➡️ Чем настоящее чтение отличается от того, которому нас учили в школе?
➡️ Почему так важно готовиться к чтению и как это делать?
➡️ Как превратить развлекательное чтение в образовательное?
➡️ Техники, которые помогают качественнее читать и осмыслять прочитанное
➡️ Бонус-глава о том, как читать художественную литературу
⭐️ 3 идеи из книги
🟡 Результат чтения гораздо важнее количества прочитанных книг. Число просмотренных страниц не имеет никакого значения само по себе; важны только изменения, которые произошли в жизни после чтения и осмысления прочитанного.
🟡 Не-чтение основывается на избирательности. В первую очередь читатель должен понять, какую цель он хочет достичь и какие источники ему в этом помогут. Его задача — совсем не потребление новой информации и не удовлетворение эго циферкой прочитанных книг. Экономия сил и времени достигается за счёт осознанного выбора: что нужно читать, а что можно пропустить.
🟡 Для реальных изменений в жизни просто читать книги недостаточно. Нужно ещё обдумывать идеи, экспериментировать с ними, находить им место в своей жизни и личной системе знаний. Тогда и только тогда новая информация будет усваиваться, запоминаться и влиять на жизнь читателя.
⭐️ Мои впечатления
Не буду юлить — я всё-таки изрядно предвзят и к автору, и к книге. В своё время обучение у Рустама в корне изменило мой подход к чтению и самообразованию. И хотя у меня сейчас не всегда хватает времени и сил на написание заметок по прочитанному, я глубоко осознаю и ощущаю важность осмысления и применения новой информации.
Книга показывает альтернативный взгляд на чтение и выводит из привычной модели «читаем от корки до корки, а потом пересказываем прочитанное», которую нам отчаянно вбивали в головы с первого класса. Автор предлагает другой подход к чтению — через осознанность, продуманную подготовку и глубокую работу с полученными в результате чтения идеями.
Я руководствуюсь изложенными в книге принципами каждый день, при чтении любого материала. Конечно, мне ещё далеко до уровня Рустама, но применение даже части инструментов (при условии понимания общей системы) сильно улучшило качество моего чтения.
Рекомендую однозначно, даже если вы не читаете книги. Вы совсем иначе взглянете на все окружающие тексты.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Как минимум пять человек поймали меня на CodeFest с вопросами о том, как я читаю. Пришла пора раскрыть завесу тайны!
Первое, с чего я начинал свой рассказ, — я не придумал ничего нового. Я просто понял, что не умею читать, и нашёл способ этому научиться.
Так уж сложились обстоятельства, что мой учитель недавно взял и опубликовал книгу о том, как нужно эффективно читать (или, точнее, не-читать) книги. И, конечно же, я её про-не-читал буквально через пару недель после публикации.
Книга посвящена методу не-чтения. Суть его заключается в том, что внимательный и требовательный читатель гораздо больше не читает, чем читает. Метод направлен на то, чтобы извлекать суть из книг, получая ответы на свои вопросы без пустой траты времени и сил.
В книге раскрываются следующие темы:
Не буду юлить — я всё-таки изрядно предвзят и к автору, и к книге. В своё время обучение у Рустама в корне изменило мой подход к чтению и самообразованию. И хотя у меня сейчас не всегда хватает времени и сил на написание заметок по прочитанному, я глубоко осознаю и ощущаю важность осмысления и применения новой информации.
Книга показывает альтернативный взгляд на чтение и выводит из привычной модели «читаем от корки до корки, а потом пересказываем прочитанное», которую нам отчаянно вбивали в головы с первого класса. Автор предлагает другой подход к чтению — через осознанность, продуманную подготовку и глубокую работу с полученными в результате чтения идеями.
Я руководствуюсь изложенными в книге принципами каждый день, при чтении любого материала. Конечно, мне ещё далеко до уровня Рустама, но применение даже части инструментов (при условии понимания общей системы) сильно улучшило качество моего чтения.
Рекомендую однозначно, даже если вы не читаете книги. Вы совсем иначе взглянете на все окружающие тексты.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
«Фичи катятся» про генеративный ИИ и мультиагентные схемы
На эти выходные я принёс вам глубокий, рассудительный подкаст от моего дружочка-пирожочка Глеба Михеева про генеративный ИИ. Глупо отрицать, что AI сильно повлияет на наши жизни и что мы находимся в самом разгаре трансформации множества рабочих и бизнес-процессов.
Смотреть такие подкасты особенно важно на фоне непрекращающихся воплей о том, что нас всех заменит ИИ. Вместо того чтобы поддаваться панике, гораздо продуктивнее будет изучить тему и разобраться в вопросе поглубже. А здесь — полтора часа годноты от людей, которые хорошо понимают, что происходит в мире AI.
⭐ Интересные идеи
➡ Интеллект — это не просто обработка информации, а способность двигаться к цели, адаптироваться, учиться и взаимодействовать. ИИ становится «интеллектуальным» лишь тогда, когда способен на самостоятельные решения и рефлексию ошибок.
➡ Мультиагентные системы — это архитектура будущего. Каждый агент автономен, но действует с другими ради общей цели. Примеры: логистика, умные дома, марсоходы. Такая структура позволяет масштабировать системы, сохраняя управляемость и адаптивность.
➡ Успешный ИИ-проект начинается не с кода, а с правильной постановки задачи. Главная компетенция — умение формулировать, что именно нужно, а не умение писать нейросети. Именно это открывает ИИ для бизнеса и неинженеров.
➡ В основе сбалансированных агентных систем лежит теория игр. Правильно настроенные правила взаимодействия (как в аукционе второй цены) позволяют достигать эффективного равновесия между интересами. Без этого — хаос, переоптимизация, карго-культ.
Альтернативные площадки с подкастом:
🟡 ВК
🟡 RuTube
🟡 Spotify
🟡 Apple Podcasts
🟡 Яндекс.Музыка
Приятного просмотра!
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
На эти выходные я принёс вам глубокий, рассудительный подкаст от моего дружочка-пирожочка Глеба Михеева про генеративный ИИ. Глупо отрицать, что AI сильно повлияет на наши жизни и что мы находимся в самом разгаре трансформации множества рабочих и бизнес-процессов.
Смотреть такие подкасты особенно важно на фоне непрекращающихся воплей о том, что нас всех заменит ИИ. Вместо того чтобы поддаваться панике, гораздо продуктивнее будет изучить тему и разобраться в вопросе поглубже. А здесь — полтора часа годноты от людей, которые хорошо понимают, что происходит в мире AI.
Альтернативные площадки с подкастом:
Приятного просмотра!
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Как мы пришли к мультиагентным системам // Дмитрий Бугайченко и Глеб Михеев
Дима Бугайченко — CDS B2C в Сбере. Мы познакомились в Минске, где выступали на митапе по рекомендательным системам. Мне понравился его доклад, а после, на афтерпати, несколько часов обсуждали машинное обучение и мультиагентные системы. Тогда я подумал: “Блин…
Помоги людям заметить свои достижения
Другие люди не обязаны замечать наши достижения. Они не обязаны нас хвалить и вообще обращать внимание на то, что мы что-то сделали.
Звучит сурово, не так ли? Но это правда. Люди не умеют читать мысли и в первую очередь думают о себе (что совершенно нормально). Более того, мы живём в чудовищном потоке информации, который вызывает настолько сильную перегрузку, что мы о себе периодически забываем. Поэтому иногда бывает сложно заметить, что же там такого классного сделали другие.
⭐️ Говорить о своих достижениях — нормально
Меня с детства учили: «Не хвастайся, хвастаться нехорошо, хвастунов никто не любит». Так-то оно так, только под определение «хвастовство» в моём информационном поле попадали и вполне здравые сообщения о своих достижениях.
Некорректное определение хвастовства в голове может создать такую ситуацию, в которой человек из стыда быть осуждённым будет умалчивать о своей значимой работе. Это наносит вред как ему самому (никто не догадается), так и окружающим (он мог сделать что-то действительно хорошее и полезное).
⭐️ Говорить о своих достижениях — это помощь другим
Давайте посмотрим на это с другой стороны. Вот сидит ваш руководитель. У него куча работы, огромный поток информации и широкая зона ответственности. Вероятно, его ум постоянно загружен.
Представляете, насколько такому человеку трудно заметить чьи-то достижения? Для этого нужно выделить время и внимание в постоянной гонке за результатами и проанализировать деятельность человека, чтобы выделить в ней нечто значимое. Мало кто станет регулярно и сознательно этим заниматься.
Но при этом руководителю важно знать, как у вас вообще дела (я надеюсь). Так вот, сообщая о своих достижениях, вы облегчаете руководителю его работу — ему придётся меньше напрягаться для понимания ситуации. Аналогично с коллегами: если вы сделали что-то классное, что может быть полезно другим, то рассказать им об этом вовсе не является хвастовством. Это акт заботы о других людях.
⭐️ Но это же бахвальство!
Грань тонка. Может быть очень сложно понять, где простой рассказ о своих достижениях и результатах переходит в хвастовство.
Я для себя выделил одно простое правило: слушай свою совесть. Она может иногда излишне меня сдерживать, но убережёт от совсем уж откровенных ошибок. Например, совесть не даст мне приукрасить или исказить результаты, излишне себя превозносить и перенасыщать рассказ эмоциональными подробностями.
Простая констатация фактов и своих чувств не является бахвальством. Приведу личный пример: я выступил с докладом на CodeFest, и он получил рейтинг 4,87 из 5, чем я очень горжусь и доволен. В этом предложении — только факты и мои чувства. Но стоит добавить щепотку «я порвал аудиторию» и «люди рукоплескали стоя», как вполне здравая коммуникация превращается в акт хвастовства.
Не стесняйтесь говорить о своих результатах и достижениях. Это делает вашу жизнь и жизни окружающих проще и приятнее.
// Без ложной скромности прошу поставить💛 , если пост понравился.
Другие люди не обязаны замечать наши достижения. Они не обязаны нас хвалить и вообще обращать внимание на то, что мы что-то сделали.
Звучит сурово, не так ли? Но это правда. Люди не умеют читать мысли и в первую очередь думают о себе (что совершенно нормально). Более того, мы живём в чудовищном потоке информации, который вызывает настолько сильную перегрузку, что мы о себе периодически забываем. Поэтому иногда бывает сложно заметить, что же там такого классного сделали другие.
Меня с детства учили: «Не хвастайся, хвастаться нехорошо, хвастунов никто не любит». Так-то оно так, только под определение «хвастовство» в моём информационном поле попадали и вполне здравые сообщения о своих достижениях.
Некорректное определение хвастовства в голове может создать такую ситуацию, в которой человек из стыда быть осуждённым будет умалчивать о своей значимой работе. Это наносит вред как ему самому (никто не догадается), так и окружающим (он мог сделать что-то действительно хорошее и полезное).
Давайте посмотрим на это с другой стороны. Вот сидит ваш руководитель. У него куча работы, огромный поток информации и широкая зона ответственности. Вероятно, его ум постоянно загружен.
Представляете, насколько такому человеку трудно заметить чьи-то достижения? Для этого нужно выделить время и внимание в постоянной гонке за результатами и проанализировать деятельность человека, чтобы выделить в ней нечто значимое. Мало кто станет регулярно и сознательно этим заниматься.
Но при этом руководителю важно знать, как у вас вообще дела (я надеюсь). Так вот, сообщая о своих достижениях, вы облегчаете руководителю его работу — ему придётся меньше напрягаться для понимания ситуации. Аналогично с коллегами: если вы сделали что-то классное, что может быть полезно другим, то рассказать им об этом вовсе не является хвастовством. Это акт заботы о других людях.
Грань тонка. Может быть очень сложно понять, где простой рассказ о своих достижениях и результатах переходит в хвастовство.
Я для себя выделил одно простое правило: слушай свою совесть. Она может иногда излишне меня сдерживать, но убережёт от совсем уж откровенных ошибок. Например, совесть не даст мне приукрасить или исказить результаты, излишне себя превозносить и перенасыщать рассказ эмоциональными подробностями.
Простая констатация фактов и своих чувств не является бахвальством. Приведу личный пример: я выступил с докладом на CodeFest, и он получил рейтинг 4,87 из 5, чем я очень горжусь и доволен. В этом предложении — только факты и мои чувства. Но стоит добавить щепотку «я порвал аудиторию» и «люди рукоплескали стоя», как вполне здравая коммуникация превращается в акт хвастовства.
Не стесняйтесь говорить о своих результатах и достижениях. Это делает вашу жизнь и жизни окружающих проще и приятнее.
// Без ложной скромности прошу поставить
Please open Telegram to view this post
VIEW IN TELEGRAM
Честный взгляд на IT изнутри
За 5 лет руководства я понял одну простую истину: IT-менеджмент — штука сложная. Задачи могут быть похожи друг на друга, но чаще всего это только кажется. Каждую старую задачу приходится решать в новом контексте, с новыми людьми и новыми продуктами, поэтому старые методики не всегда работают.
Всё вдвойне усложняется тем, что хорошей и полезной информации по руководству не так много. Да, есть базовые книжки, но они чаще всего написаны в стиле философии. А диванная философия имеет свойство рассыпаться при первом контакте с реальностью.
Поэтому сегодня я хочу порекомендовать вам канал «Кем я хочу стать, когда вырасту». В нём директор по консалтингу крупной IT-компании рассказывает о работе руководителя и развитии продуктов и продактов.
Вот несколько интересных постов, с которых стоит начать знакомство:
➡️ Тимлид-старожил — главное зло в команде — про классическую ошибку: «поставим тимлидом того, кто дольше всех работает».
➡️ Инсайт, кому на самом деле нужен ваш продукт — про то, как нужно думать о продукте, чтобы на нём зарабатывать.
➡️ Саббатикал в IT — саботаж? — о длительном отдыхе.
➡️ Скука — главный киллер любой карьеры — о тихом убийце производительности и мотивации членов команды.
Автор пишет посты из своего 10-летнего опыта в роли лида и руководителя, избегая диванной философии. Только реальный опыт, только хардкор.
Подписывайтесь на канал, чтобы погрузиться в реальный мир IT без розовых очков.
Реклама. ИП Миронова Надежда Олеговна ИНН 772985604739 erid:2Vtzqxjmy1F
За 5 лет руководства я понял одну простую истину: IT-менеджмент — штука сложная. Задачи могут быть похожи друг на друга, но чаще всего это только кажется. Каждую старую задачу приходится решать в новом контексте, с новыми людьми и новыми продуктами, поэтому старые методики не всегда работают.
Всё вдвойне усложняется тем, что хорошей и полезной информации по руководству не так много. Да, есть базовые книжки, но они чаще всего написаны в стиле философии. А диванная философия имеет свойство рассыпаться при первом контакте с реальностью.
Поэтому сегодня я хочу порекомендовать вам канал «Кем я хочу стать, когда вырасту». В нём директор по консалтингу крупной IT-компании рассказывает о работе руководителя и развитии продуктов и продактов.
Вот несколько интересных постов, с которых стоит начать знакомство:
Автор пишет посты из своего 10-летнего опыта в роли лида и руководителя, избегая диванной философии. Только реальный опыт, только хардкор.
Подписывайтесь на канал, чтобы погрузиться в реальный мир IT без розовых очков.
Реклама. ИП Миронова Надежда Олеговна ИНН 772985604739 erid:2Vtzqxjmy1F
Please open Telegram to view this post
VIEW IN TELEGRAM
Хочешь отдохнуть? Тащи себя из дома!
Отдых — это тоже работа. Но чаще всего мы занимаемся бурной имитацией отдыха с последующей бурной имитацией работы на неделе, потому что силы не восстановились.
Отдыхать нас никто не учил, поэтому снова берём свою судьбу в свои лапки и начинаем её менять. Впереди — длинные, как такса, выходные — самое время попрактиковаться в восстановлении своих батареек. И начать нужно с переключения в режим отдыха.
⭐️ Как включить режим отдыха?
Одна из простейших, но крайне эффективных техник введения себя в состояние отдыха — вытащить себя из атмосферы, в которой обычно происходят какие-то рабочие процессы. Если учесть, что многие из нас сидят на удалёнке или гибриде, то можно предположить, что дом превращается во второй офис.
Вы когда-нибудь пробовали отдыхать в офисе? Как вам, нормально отдыхается, сил полно потом?
Лично я не могу полноценно отдохнуть и расслабиться дома, особенно когда целый день из него работал. Мне нужна хоть какая-то смена обстановки, потому что дома я на автомате продолжаю прокручивать в голове рабочие мысли. Поэтому иногда я просто иду в парк и туплю там часок-другой: смотрю на уточек, трогаю траву, кайфую от запаха дубов.
Всё это сверху поливается проблемой гибрида. Когда я возвращаюсь домой из офиса, то кажется, что я вернулся с работы на работу. Неприятненько. Жизнь в таком режиме выматывает.
Поэтому для переключения себя в режим отдыха нужно сделать одну простую вещь — свалить куда подальше от источников работы. В идеале ещё и смартфон дома оставить, но это для совсем уж постигших дзен (в чьё число ваш покорный слуга не входит). Простая смена обстановки и отсутствие возможности что-либо поковырять в работе поможет вам легче переключиться в расслабленность и восстановление.
Гораздо проще не думать о работе, когда под рукой нет такого соблазнительного ноутбука с рабочими чатиками и открытой IDE/консолью/JIRA/что у вас там. Нет смысла испытывать свою силу воли на фоне усталости. Лучше помочь себе избавиться от отвлекающих факторов хотя бы на какое-то время.
Сам себя не отдохнёшь — никто тебя не отдохнёт.
// Ставь💛 во имя отдыха
Отдых — это тоже работа. Но чаще всего мы занимаемся бурной имитацией отдыха с последующей бурной имитацией работы на неделе, потому что силы не восстановились.
Отдыхать нас никто не учил, поэтому снова берём свою судьбу в свои лапки и начинаем её менять. Впереди — длинные, как такса, выходные — самое время попрактиковаться в восстановлении своих батареек. И начать нужно с переключения в режим отдыха.
Одна из простейших, но крайне эффективных техник введения себя в состояние отдыха — вытащить себя из атмосферы, в которой обычно происходят какие-то рабочие процессы. Если учесть, что многие из нас сидят на удалёнке или гибриде, то можно предположить, что дом превращается во второй офис.
Вы когда-нибудь пробовали отдыхать в офисе? Как вам, нормально отдыхается, сил полно потом?
Лично я не могу полноценно отдохнуть и расслабиться дома, особенно когда целый день из него работал. Мне нужна хоть какая-то смена обстановки, потому что дома я на автомате продолжаю прокручивать в голове рабочие мысли. Поэтому иногда я просто иду в парк и туплю там часок-другой: смотрю на уточек, трогаю траву, кайфую от запаха дубов.
Всё это сверху поливается проблемой гибрида. Когда я возвращаюсь домой из офиса, то кажется, что я вернулся с работы на работу. Неприятненько. Жизнь в таком режиме выматывает.
Поэтому для переключения себя в режим отдыха нужно сделать одну простую вещь — свалить куда подальше от источников работы. В идеале ещё и смартфон дома оставить, но это для совсем уж постигших дзен (в чьё число ваш покорный слуга не входит). Простая смена обстановки и отсутствие возможности что-либо поковырять в работе поможет вам легче переключиться в расслабленность и восстановление.
Гораздо проще не думать о работе, когда под рукой нет такого соблазнительного ноутбука с рабочими чатиками и открытой IDE/консолью/JIRA/что у вас там. Нет смысла испытывать свою силу воли на фоне усталости. Лучше помочь себе избавиться от отвлекающих факторов хотя бы на какое-то время.
Сам себя не отдохнёшь — никто тебя не отдохнёт.
// Ставь
Please open Telegram to view this post
VIEW IN TELEGRAM
Патрик Ленсиони, «Идеальный командный игрок»
Хорошую команду невозможно сколотить из людей, которые не умеют работать в команде. Эта идея кажется очевидной. Но можете ли вы сходу ответить, какие именно качества делают человека командным игроком?
В поисках ответа на этот вопрос я и взял книгу Патрика Ленсиони «Идеальный командный игрок». Ранее я читал другую его книгу — «Пять пороков команды», и она мне понравилась своей структурностью и интересным форматом, а также дала много пищи для размышлений.
«Идеальный командный игрок» тоже написана в жанре бизнес-романа с пояснительными теоретическими главами в конце. Сначала читаешь историю, а потом допниками дополняешь понимание — очень удобно.
⭐️ О чём книга
Книга продолжает историю одного из героев «Пяти пороков команды», который решил выйти из IT и пойти управлять строительным бизнесом. Он внезапно оказывается в ситуации вида «пан или пропал» и понимает, что затащить два огромных проекта можно только командной работой…
В книге раскрываются следующие темы:
➡️ Какими тремя качествами обладает идеальный командный игрок?
➡️ Как распознать, что сотруднику не хватает одного из качеств?
➡️ Как помочь людям становиться идеальными игроками?
➡️ Как сочетать эту модель с пятью пороками команды?
⭐️ 3 идеи из книги
🟡 Три ключевых качества командного игрока: скромность, жажда деятельности, чуткость. Скромность означает умение не перетягивать одеяло внимания на себя (а вовсе не умалчивание достижений), жажда деятельности говорит сама за себя, а чуткость — это эмоциональный интеллект и навыки коммуникации.
🟡 Если не увольнять ослов, то начнут уходить те, кто ослами не являются. Ослами герои книги называют людей, далёких от командной работы. В примере Ленсиони рассказывает о том, как люди уходили из-за скилловой, но крайне неприятной в общении менеджера проектов.
🟡 Люди могут делать что-то не со зла. Например, хорошие специалисты могут быть излишне резкими в общении только потому, что не понимают, как это выглядит со стороны и воспринимается другими людьми. Задача команды — помочь им развить нужные навыки.
⭐️ Мои впечатления
Модель Ленсиони мне показалась достаточно простой и гибкой. Она настолько проста, что кажется обыкновенным здравым смыслом. И тут мне сразу же вспоминается Годратт, который говорил, что самые правильные вещи в конечном счёте кажутся просто здравым смыслом.
Сама книга хорошо и наглядно показывает, как выглядит работа с человеком, у которого недостаёт одного из трёх качеств. Это не означает, что у всех сотрудников все эти качества должны быть «вкачаны» на максимум — мы люди, у каждого будут свои перекосы. Но полное отсутствие любого из них может быть разрушительным.
Книга небольшая и приятно читается (я прочитал её в самолёте, пока летел домой с CodeFest). Художественная составляющая проста и наглядна, а автор и не планировал писать «Войну и мир». Некоторые сценки из книги даже вызывали у меня флешбеки.
Рекомендую к прочтению, если у вас уже есть опыт руководства. Идеи Ленсиони хороши сами по себе, но гораздо лучше ложатся на набитые граблями шишки.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Хорошую команду невозможно сколотить из людей, которые не умеют работать в команде. Эта идея кажется очевидной. Но можете ли вы сходу ответить, какие именно качества делают человека командным игроком?
В поисках ответа на этот вопрос я и взял книгу Патрика Ленсиони «Идеальный командный игрок». Ранее я читал другую его книгу — «Пять пороков команды», и она мне понравилась своей структурностью и интересным форматом, а также дала много пищи для размышлений.
«Идеальный командный игрок» тоже написана в жанре бизнес-романа с пояснительными теоретическими главами в конце. Сначала читаешь историю, а потом допниками дополняешь понимание — очень удобно.
Книга продолжает историю одного из героев «Пяти пороков команды», который решил выйти из IT и пойти управлять строительным бизнесом. Он внезапно оказывается в ситуации вида «пан или пропал» и понимает, что затащить два огромных проекта можно только командной работой…
В книге раскрываются следующие темы:
Модель Ленсиони мне показалась достаточно простой и гибкой. Она настолько проста, что кажется обыкновенным здравым смыслом. И тут мне сразу же вспоминается Годратт, который говорил, что самые правильные вещи в конечном счёте кажутся просто здравым смыслом.
Сама книга хорошо и наглядно показывает, как выглядит работа с человеком, у которого недостаёт одного из трёх качеств. Это не означает, что у всех сотрудников все эти качества должны быть «вкачаны» на максимум — мы люди, у каждого будут свои перекосы. Но полное отсутствие любого из них может быть разрушительным.
Книга небольшая и приятно читается (я прочитал её в самолёте, пока летел домой с CodeFest). Художественная составляющая проста и наглядна, а автор и не планировал писать «Войну и мир». Некоторые сценки из книги даже вызывали у меня флешбеки.
Рекомендую к прочтению, если у вас уже есть опыт руководства. Идеи Ленсиони хороши сами по себе, но гораздо лучше ложатся на набитые граблями шишки.
Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
«Проект крутой, но я ухожу». 5 причин, почему IT-специалисты увольняются
Статья на тему, которая болит у каждого руководителя — о текучке. Люди периодически меняют работу, и это нормально. Ненормально — когда люди покидают компанию слишком часто, проработав в ней всего пару месяцев.
В первую очередь статья меня заинтересовала тем, что исследует причины увольнений именно на российском рынке. Это делает её достаточно прикладной и применимой в наших реалиях.
⭐️ Интересные идеи
➡️ Двумя топовыми факторами ухода по-прежнему остаются отсутствие роста зарплаты и рабочий стресс.
➡️ Плохие рабочие условия могут вызывать серьёзный стресс. Это касается как работы в офисе (шум, запахи, транспортная доступность), так и удалёнки (или её отсутствия).
➡️ Стресс может возникать из-за борьбы с системой: странный софт, бюрократия, устаревшие инструменты работы.
➡️ Перегрузка и постоянно “горящие” сроки — один из ключевых факторов увольнений. Многие IT-компании работают на износ, люди находятся в постоянном стрессе и ожидаемо выгорают, что часто приводит к увольнениям.
➡️ Неожиданный фактор ухода — слабый онбординг. Человек приходит в компанию и оказывается предоставлен сам себе. С него спрашивают результаты, но не дают помощи и отмахиваются. Новичок чувствует себя некомфортно и решает сменить место работы.
Приятного чтения!
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖
📝 @ulshinblog
Статья на тему, которая болит у каждого руководителя — о текучке. Люди периодически меняют работу, и это нормально. Ненормально — когда люди покидают компанию слишком часто, проработав в ней всего пару месяцев.
В первую очередь статья меня заинтересовала тем, что исследует причины увольнений именно на российском рынке. Это делает её достаточно прикладной и применимой в наших реалиях.
Приятного чтения!
Please open Telegram to view this post
VIEW IN TELEGRAM
Tproger
«Проект крутой, но я ухожу». 5 причин, почему IT-специалисты увольняются
Разобрали 5 основных причин, почему айтишники уходят даже из топовых компаний. Реальные кейсы, аналитика, исследования. Рассказываем, как не попасть в такую ситуацию и что делать, если вы всё-таки в неё попали.
Лучшая тактика работы с лоуперформерами
Лучшая тактика работы с лоуперформерами — гнать их сразу при выявлении. Гуманнее всего будте уволить быстро. Чем раньше вы это поймёте, тем меньше сойдёте с ума.
Большинство людей любит быть хорошими и нравиться другим людям. Это приятно — все тебя принимают, все тебе улыбаются. Вот только руководство людьми включает в себя принятие непопулярных решений, которые зачастую идут вразрез с концепцией «быть хорошим для всех».
Менеджеры, которые пытаются спасти всех — не добрые, а трусливые. Их пугает перспектива конфликта, и они прикрываются гуманизмом.
⭐️ Ху из лоуперформер
Думаю, что мне стоит объяснить, кого конкретно я называю лоуперформерами. Для меня лоуперформер — это человек, который сознательно и систематически не исполняет свои рабочие обязанности с надлежащим качеством. Проще говоря, это человек, который работает ровно настолько, чтобы его не уволили, и ещё поменьше.
В это определение не попадают:
➡️ Люди, которые работали нормально, но просто устали или даже выгорели.
➡️ Люди, у которых что-то случилось, и они не в состоянии нормально работать.
➡️ Люди, которые чего-то не умеют.
⭐️ Нужно же давать людям шанс!
Шанс нужно давать вышеперечисленным категориям. Если человек нормально работал, а потом перестал — нужно с ним как минимум поговорить, а, возможно, даже помочь выйти из этого состояния.
Но хотите ли вы давать шанс людям, которые откровенно не справляются со своей работой? Которые делают задачи как попало? Которые стараются поработать поменьше?
А готовы ли вы к тому, что другие члены вашей команды уволятся из-за того, что один человек позволяет себе вообще не работать и руководитель ничего с этим не делает?
Лоуперформер — это бич команды. Мало того что он сам не работает, он ещё и подрывает моральный дух коллектива. Представьте ситуацию: вы работаете как обычно, а рядом человек откровенно пинает болт. Будет ли вам комфортно? Думаю, что вряд ли.
Также такой человек наносит вред руководителю. Он стягивает на себя драгоценные силы и внимание, которые руководитель мог потратить на полезную работу с командой и улучшение процессов. Вместо продуктивной деятельности лиду приходится ломать голову над тем, как быть с этим человеком.
⭐️ Люди не меняются
Я многократно работал с лоуперформерами. И могу сказать только одно: на моей памяти ещё не произошло ни одного случая, когда лоуперформер исправлялся. Люди, которые начали хуже работать по каким-то причинам, чаще всего возвращались в колею вместе с устранением этих причин. Но лентяи и раздолбаи выдавали максимум пару недель нормальной работы, после чего всё возвращалось на круги своя.
Мы — взрослые люди. И мы работаем с другими взрослыми людьми, даже если они себя таковыми не считают. Не надо спасать того, кто не тонет. Дайте ему плыть дальше. Только не в вашей команде. А его место пусть займёт другой человек, который будет приносить пользу себе и команде.
// Приходилось ли вам нянчиться с лоуперформерами? Или сразу увольняли и дело с концом?
Лучшая тактика работы с лоуперформерами — гнать их сразу при выявлении. Гуманнее всего будте уволить быстро. Чем раньше вы это поймёте, тем меньше сойдёте с ума.
Большинство людей любит быть хорошими и нравиться другим людям. Это приятно — все тебя принимают, все тебе улыбаются. Вот только руководство людьми включает в себя принятие непопулярных решений, которые зачастую идут вразрез с концепцией «быть хорошим для всех».
Менеджеры, которые пытаются спасти всех — не добрые, а трусливые. Их пугает перспектива конфликта, и они прикрываются гуманизмом.
Думаю, что мне стоит объяснить, кого конкретно я называю лоуперформерами. Для меня лоуперформер — это человек, который сознательно и систематически не исполняет свои рабочие обязанности с надлежащим качеством. Проще говоря, это человек, который работает ровно настолько, чтобы его не уволили, и ещё поменьше.
В это определение не попадают:
Шанс нужно давать вышеперечисленным категориям. Если человек нормально работал, а потом перестал — нужно с ним как минимум поговорить, а, возможно, даже помочь выйти из этого состояния.
Но хотите ли вы давать шанс людям, которые откровенно не справляются со своей работой? Которые делают задачи как попало? Которые стараются поработать поменьше?
А готовы ли вы к тому, что другие члены вашей команды уволятся из-за того, что один человек позволяет себе вообще не работать и руководитель ничего с этим не делает?
Лоуперформер — это бич команды. Мало того что он сам не работает, он ещё и подрывает моральный дух коллектива. Представьте ситуацию: вы работаете как обычно, а рядом человек откровенно пинает болт. Будет ли вам комфортно? Думаю, что вряд ли.
Также такой человек наносит вред руководителю. Он стягивает на себя драгоценные силы и внимание, которые руководитель мог потратить на полезную работу с командой и улучшение процессов. Вместо продуктивной деятельности лиду приходится ломать голову над тем, как быть с этим человеком.
Я многократно работал с лоуперформерами. И могу сказать только одно: на моей памяти ещё не произошло ни одного случая, когда лоуперформер исправлялся. Люди, которые начали хуже работать по каким-то причинам, чаще всего возвращались в колею вместе с устранением этих причин. Но лентяи и раздолбаи выдавали максимум пару недель нормальной работы, после чего всё возвращалось на круги своя.
Мы — взрослые люди. И мы работаем с другими взрослыми людьми, даже если они себя таковыми не считают. Не надо спасать того, кто не тонет. Дайте ему плыть дальше. Только не в вашей команде. А его место пусть займёт другой человек, который будет приносить пользу себе и команде.
// Приходилось ли вам нянчиться с лоуперформерами? Или сразу увольняли и дело с концом?
Please open Telegram to view this post
VIEW IN TELEGRAM