Лично я очень люблю учиться. Меня приводит в дикий восторг изучение чего-то новенького и увязывание этого с тем, что я уже знаю. Я настолько люблю учиться, что постоянно учусь учиться и ищу новые методы, как сделать этот процесс эффективнее.
Поэтому сегодня у меня в обзоре — прекраснейшая книжка Дэна Уиллингема "Учись как профи".
Книга в основном предназначена для студентов, которым предстоит усваивать много материала по разным предметам, а затем сдавать контрольные работы, экзамены, практику и прочие стандартные для высшего образования задачи.
В книге раскрываются следующие темы:
Как бы я хотел, чтобы эта книга попала ко мне в руки во времена университетской скамьи! Конечно, многие из этих вещей я хорошо прочувствовал на собственном опыте (ещё в школе домашка занимала от силы полчаса, потому что на уроках я разбирался в материале вместо написания огромных конспектов). Однако эта книга может стать настоящим сокровищем для школьников старших классов и студентов.
Уиллингем акцентирует внимание на том, что для запоминания материала лучше всего в нём хорошенько разобраться. Конечно, мнемотехники могут помочь в экстренных случаях (когда экзамен завтра), однако более эффективно — учиться вовремя и не доводить до такого.
Для взрослого человека книга несёт меньшую ценность, потому что нам не так часто нужно сдавать экзамены. Однако даже нам приходится периодически проходить различные тестирования на обучающих курсах, да и собеседования по программированию часто напоминают университетский экзамен с оценкой за формальные "галочки". Поэтому, на мой взгляд, в этой книге найдёт пользу каждый человек, которому приходится по работе изучать что-то новое.
Читали книгу? Как вам?
Никита Ульшин про IT | #обзор_книги #soft_skills #обучение
Please open Telegram to view this post
VIEW IN TELEGRAM
Уроки орнитологии: менеджер-сорока
Продолжаем уроки увлекательной орнитологии. С чайка-менеджерами мы уже разобрались в предыдущих постах, однако есть ещё один тип птичек среди управленцев. Это сорока-менеджеры.
Что мы знаем о сороках? Они хватают всё блестящее и тащат к себе. Точно так же поступают и некоторые управленцы. Нашёл какую-то интересную идею/методологию/подход? Надо срочно её затащить в команду и нанести всем вокруг непоправимую пользу!
🔄 Кто виноват
Причины такого поведения могут быть разными. Одни менеджеры просто горят желанием добиться успеха и хотят сделать всё как можно лучше. Другие страдают от перфекционизма и синдрома самозванца. А однажды я своими глазами видел человека, который считал себя самым умным и всеми силами стремился это доказать.
Сам по себе подход постоянного обучения и поиск точек роста — это замечательно. Однако в абсолют всё возводят только ситхи, а люди вообще больше любят стабильность и предсказуемость. Поэтому изменения нужно внедрять постепенно, создавая команде умеренный дискомфорт. Работать в условиях, где всё меняется по сто раз в день, морально тяжело. Особенно в IT-сфере, где специалистам нужно иметь возможность спокойно и сосредоточенно выполнять свои задачи. Просто представьте себе работу, где у руководителя каждый день "гениальная новая идея, которую нужно срочно внедрить".
Если постоянно внедрять нововведения без явных причин, команда будет пребывать в растерянности. У людей сложится ощущение, что рабочие процессы сырые и их нужно постоянно исправлять, докручивать, улучшать. А дальше они легко могут перенести этот вывод на себя и свою работу: "команда работает плохо, меня уволят, ааааа".
🔄 Что делать
Затаскивание блестяшек в команду — не самая страшная "болезнь" на уровне тимлида, однако с ростом уровня последствия такого поведения гарантированно будут усиливаться. Вот как можно с этим бороться:
🟡 Начать с "5 нахрена". Сосредоточьтесь на решаемой проблеме, а именно — действительно ли эта проблема мешает жить и стоит ли её решать. Иначе, в погоне за блестяшками, можно не заметить "проблемный рояль" в комнате.
🟡 Обсуждать новые идеи с командой и собирать обратную связь. Люди могут как отвергнуть идею, так и предложить неожиданные варианты её адаптации под командные процессы. Такие идеи внедрять гораздо легче.
🟡 Применять модели управления изменениями (например, ADKAR) для более плавного внедрения новшеств. Даже если вы уже приняли решение о внедрении — стоит сделать это мягко и аккуратно, не врываясь "с ноги" в рабочие процессы.
Сорока-менеджмент — это не плохо. Это признак того, что человек развивается в роли руководителя и ищет новые подходы к решению своих задач. Просто этот процесс нужно немного обуздать, и всё пойдёт как по маслу.
Сталкивались ли вы в своей работе с менеджерами-сороками?
Никита Ульшин про IT | #management #change_management
Продолжаем уроки увлекательной орнитологии. С чайка-менеджерами мы уже разобрались в предыдущих постах, однако есть ещё один тип птичек среди управленцев. Это сорока-менеджеры.
Что мы знаем о сороках? Они хватают всё блестящее и тащат к себе. Точно так же поступают и некоторые управленцы. Нашёл какую-то интересную идею/методологию/подход? Надо срочно её затащить в команду и нанести всем вокруг непоправимую пользу!
Причины такого поведения могут быть разными. Одни менеджеры просто горят желанием добиться успеха и хотят сделать всё как можно лучше. Другие страдают от перфекционизма и синдрома самозванца. А однажды я своими глазами видел человека, который считал себя самым умным и всеми силами стремился это доказать.
Сам по себе подход постоянного обучения и поиск точек роста — это замечательно. Однако в абсолют всё возводят только ситхи, а люди вообще больше любят стабильность и предсказуемость. Поэтому изменения нужно внедрять постепенно, создавая команде умеренный дискомфорт. Работать в условиях, где всё меняется по сто раз в день, морально тяжело. Особенно в IT-сфере, где специалистам нужно иметь возможность спокойно и сосредоточенно выполнять свои задачи. Просто представьте себе работу, где у руководителя каждый день "гениальная новая идея, которую нужно срочно внедрить".
Если постоянно внедрять нововведения без явных причин, команда будет пребывать в растерянности. У людей сложится ощущение, что рабочие процессы сырые и их нужно постоянно исправлять, докручивать, улучшать. А дальше они легко могут перенести этот вывод на себя и свою работу: "команда работает плохо, меня уволят, ааааа".
Затаскивание блестяшек в команду — не самая страшная "болезнь" на уровне тимлида, однако с ростом уровня последствия такого поведения гарантированно будут усиливаться. Вот как можно с этим бороться:
Сорока-менеджмент — это не плохо. Это признак того, что человек развивается в роли руководителя и ищет новые подходы к решению своих задач. Просто этот процесс нужно немного обуздать, и всё пойдёт как по маслу.
Сталкивались ли вы в своей работе с менеджерами-сороками?
Никита Ульшин про IT | #management #change_management
Please open Telegram to view this post
VIEW IN TELEGRAM
🔗 Ссылку опубликую перед эфиром
Невесел тимлид.
Ван он ван не любил проводить,
Команда ушла.
Я регулярно общаюсь с коллегами по цеху на разные интересные темы, и частенько в ходе таких разговоров рождаются крутые идеи и инсайты. А ещё эти разговоры приносят мне море удовольствия.
Недавно я понял, что хочу вынести хотя бы часть таких разговоров во внешний мир, чтобы другие люди тоже могли послушать и утащить себе ценные идеи. Поэтому я решил запустить новый проект - эфиры с крутыми ребятами из IT и не только на разные темы. Говорить будем про управление разработкой, людьми и собой.
Проект я решил назвать "1-1", потому что каждый такой эфир будет по сути встречей 1-1 с гостем на конкретную тему. Не спрашивайте, как я буду выкручиваться, если гостей будет несколько - сам не знаю
Первый эфир будет посвящён проведению полезных встреч 1-1 с сотрудниками. Моим гостем будет Даша Корчуганова, руководитель команды разработки Газпромбанк Бизнес-Онлайн. Даша более 7-ми лет пишет фронтенд с любовью
Мы обсудим следующие темы:
Приходите, будет интересно и познавательно!
Никита Ульшин про IT| #onetoone #podcast
Please open Telegram to view this post
VIEW IN TELEGRAM
Это не то, что я хотел
Вряд ли для кого-то будет новостью, что люди видят мир по-разному. Однако, начиная делегировать, это утверждение начинаешь воспринимать совершенно по-другому.
Я в своё время очень быстро выяснил, что сколько есть в мире людей — столько же существует способов решить одну и ту же задачу. Особенно острым это ощущение было, когда в результате работы человека получалось вовсе не то, что я себе представлял.
Что делать в такой ситуации? Человек работал, старался. Сказать ему, что он сделал что-то не то, — это обесценивание его труда. Более того, это было бы перекладыванием ответственности с себя на исполнителя. Цитируя одного футболиста: мои ожидания — это мои проблемы.
✅ Делегирование ≠ снятие ответственности
Делегируя задачу, я передаю ответственность за её исполнение другому человеку, но ответственность за результат остаётся на мне. Всё, что должен сделать исполнитель, — это выполнить задачу так, как ему сказали. Так вот, если он сделал "не то, что было нужно", то это ошибка руководителя, который недостаточно ясно и конкретно объяснил, "что было нужно".
Моя ответственность как заказчика заключается в том, чтобы дать исполнителю максимально чёткие и понятные критерии выполнения задачи. В agile это называется definition of done (DoD) — критерии того, что задача считается завершённой. Исполнитель должен понимать, по каким признакам я буду судить о том, выполнена задача или нет. В противном случае открывается широкий простор для манипуляций и прокрастинации с обеих сторон.
✅ Как формулировать DoD?
Для формулирования критериев приёмки задачи достаточно задать себе простой вопрос: "Как я пойму, что эта задача готова?" Затем просто запишите всё, что придёт в голову, и уберите лишнее. Постарайтесь, чтобы записи были максимально конкретными и наблюдаемыми со стороны. "Результат должен удовлетворять моё чувство прекрасного" — так себе критерий, потому что исполнителю будет сложно в него попасть.
Конечно, какие-то детали можно и нужно опускать. Не стоит в красках описывать каждую мелочь. В некоторых случаях DoD может быть даже расплывчатым (например, для R&D-задач я почти всегда ставил довольно абстрактный DoD). Однако тут важно понимать уровень самостоятельности и ответственности исполнителя. Для опытного Senior-специалиста задача с не самыми конкретными критериями может быть вполне приемлемой, а для джуна — смерти подобной.
✅ DoD - это забота о себе и сотрудниках
Поначалу составление критериев приёмки задачи может показаться делом сложным, нудным и муторным. Заниматься этим лениво, и хотелось бы, чтобы люди сами обо всём догадывались. Только вот проблема в том, что телепатов не существует (привет, Нео). Если делать ставку на то, что люди сами всё поймут, то рано или поздно они критически не поймут, и это приведёт к беде.
Посмотрите на этот процесс с другой стороны. Руководитель, который ставит чёткие и понятные критерии выполнения задачи, в первую очередь заботится о своих сотрудниках. Исполнителям будет гораздо комфортнее выполнять конкретные, хорошо проработанные задачи с зафиксированным ожидаемым результатом, чем "пойди туда — не знаю куда, принеси то — не знаю что". Соответственно, у людей от такого подхода заметно снижается стресс и повышается продуктивность (привет, обезьянка Тима Урбана). Да и себе вы заметно упростите жизнь, потому что результат выполнения задачи будет проще оценивать.
В общем, позаботьтесь о своих исполнителях и сформулируйте для задач ожидаемый результат. Люди вам только спасибо скажут.
Никита Ульшин про IT | #management #agile
Вряд ли для кого-то будет новостью, что люди видят мир по-разному. Однако, начиная делегировать, это утверждение начинаешь воспринимать совершенно по-другому.
Я в своё время очень быстро выяснил, что сколько есть в мире людей — столько же существует способов решить одну и ту же задачу. Особенно острым это ощущение было, когда в результате работы человека получалось вовсе не то, что я себе представлял.
Что делать в такой ситуации? Человек работал, старался. Сказать ему, что он сделал что-то не то, — это обесценивание его труда. Более того, это было бы перекладыванием ответственности с себя на исполнителя. Цитируя одного футболиста: мои ожидания — это мои проблемы.
Делегируя задачу, я передаю ответственность за её исполнение другому человеку, но ответственность за результат остаётся на мне. Всё, что должен сделать исполнитель, — это выполнить задачу так, как ему сказали. Так вот, если он сделал "не то, что было нужно", то это ошибка руководителя, который недостаточно ясно и конкретно объяснил, "что было нужно".
Моя ответственность как заказчика заключается в том, чтобы дать исполнителю максимально чёткие и понятные критерии выполнения задачи. В agile это называется definition of done (DoD) — критерии того, что задача считается завершённой. Исполнитель должен понимать, по каким признакам я буду судить о том, выполнена задача или нет. В противном случае открывается широкий простор для манипуляций и прокрастинации с обеих сторон.
Для формулирования критериев приёмки задачи достаточно задать себе простой вопрос: "Как я пойму, что эта задача готова?" Затем просто запишите всё, что придёт в голову, и уберите лишнее. Постарайтесь, чтобы записи были максимально конкретными и наблюдаемыми со стороны. "Результат должен удовлетворять моё чувство прекрасного" — так себе критерий, потому что исполнителю будет сложно в него попасть.
Конечно, какие-то детали можно и нужно опускать. Не стоит в красках описывать каждую мелочь. В некоторых случаях DoD может быть даже расплывчатым (например, для R&D-задач я почти всегда ставил довольно абстрактный DoD). Однако тут важно понимать уровень самостоятельности и ответственности исполнителя. Для опытного Senior-специалиста задача с не самыми конкретными критериями может быть вполне приемлемой, а для джуна — смерти подобной.
Поначалу составление критериев приёмки задачи может показаться делом сложным, нудным и муторным. Заниматься этим лениво, и хотелось бы, чтобы люди сами обо всём догадывались. Только вот проблема в том, что телепатов не существует (привет, Нео). Если делать ставку на то, что люди сами всё поймут, то рано или поздно они критически не поймут, и это приведёт к беде.
Посмотрите на этот процесс с другой стороны. Руководитель, который ставит чёткие и понятные критерии выполнения задачи, в первую очередь заботится о своих сотрудниках. Исполнителям будет гораздо комфортнее выполнять конкретные, хорошо проработанные задачи с зафиксированным ожидаемым результатом, чем "пойди туда — не знаю куда, принеси то — не знаю что". Соответственно, у людей от такого подхода заметно снижается стресс и повышается продуктивность (привет, обезьянка Тима Урбана). Да и себе вы заметно упростите жизнь, потому что результат выполнения задачи будет проще оценивать.
В общем, позаботьтесь о своих исполнителях и сформулируйте для задач ожидаемый результат. Люди вам только спасибо скажут.
Никита Ульшин про IT | #management #agile
Please open Telegram to view this post
VIEW IN TELEGRAM
Невесел тимлид.
Ван он ван не любил проводить,
Команда ушла.
Что делают успешные тимлиды на встречах 1-1? Как эти встречи помогают не только команде, но и самому руководителю? В пилотном выпуске моего подкаста мы вместе с Дашей Корчугановой обсудили всё, что нужно знать о встречах 1-1: зачем они нужны, как их проводить, и когда лучше отказаться от регулярных 1-1.
Даша - руководитель команды разработки Газпромбанк Бизнес-Онлайн. Более 7-ми лет пишет фронтенд с любовью
О чём мы поговорили:
Лично меня очень зацепила тема того, как давать корректирующую обратную связь на 1-1. Тема интересная настолько, что в будущем я бы хотел посвятить ей отдельный выпуск.
Запись уже доступна по ссылкам ниже. Слушайте, делитесь впечатлениями и рассказывайте, как вы проводите свои 1-1. Также я буду очень благодарен за любые пожелания и обратную связь как по форме, так и по содержанию проекта.
Никита Ульшин про IT | #onetoone_podcast
Please open Telegram to view this post
VIEW IN TELEGRAM
После прочтения книги Кэла Ньюпорта «В работу с головой» я заинтересовался темой скуки. Ньюпорт многократно упоминал, что мозгу нужна разгрузка для переваривания информации (поэтому озарения приходят в дУше). Я решил покопать эту тему чуть поглубже и взял почитать книгу Мануш Зомороди «Разреши себе скучать».
Книга целиком и полностью посвящена теме скуки, которой так мало осталось в современном мире. Основная задача книги — помочь читателю отвоевать хоть какое-то пространство для «просто поскучать» в бесконечном окружении уведомлений, мерцаний и цифровых искушений.
В книге раскрываются следующие темы:
Также каждая глава книги заканчивается вызовом — упражнением, которое позволяет немного уменьшить давление технологий и информационного потока на наше внимание.
Книжка неплохая, но на мой вкус довольно водянистая. Очень много историй «great success». Однако ценные мысли в ней однозначно есть.
Сама тема цифровой и информационной гигиены очень сложная и актуальная. В последние несколько лет я стараюсь содержать в чистоте своё информационное пространство, и это невероятно тяжёлый труд. Постоянно появляются какие-то поглотители внимания и возмутители спокойствия.
Справляться мне помогает осознанность: я понимаю, что что-то идёт не так, и начинаю анализировать причины. Чаще всего этот процесс заканчивается очередной масштабной чисткой источников информации, закладок, тудушек, списков книг и прочих свалок.
Я считаю, что эту книжку стоит прочитать всем, кто страдает от цифровой зависимости и не представляет своей жизни без смартфона в руках. Возможно, книга не даст всех ответов, но хотя бы заставит задуматься в нужную сторону. Также предложенные упражнения — неплохой способ «потыкать палочкой» свою цифровую зависимость и посмотреть, что из этого получится.
Сильно вчитываться не рекомендую — воды многовато. Но пару идей подхватить вполне можно.
Читали книгу? Как вам?
Никита Ульшин про IT | #обзор_книги
Please open Telegram to view this post
VIEW IN TELEGRAM
Как убедиться, что вас поняли правильно?
В предыдущем посте я писал о том, что такое Definition Of Done (DoD) и как его можно применять в делегировании. Однако мы рассмотрели только одну сторону вопроса — как самому сформулировать ожидания.
Но не стоит забывать, что на другой стороне DoD находится человек, и ему ничто человеческое не чуждо. Он вполне может не до конца понять написанное или понять его неправильно в силу своих внутренних установок.
Эти моменты важно прояснить до того, как специалист возьмется за задачу. Иначе велика вероятность, что результат получится не таким, как ожидалось. В лучшем случае потребуется некоторое количество правок, в худшем — задачу придется основательно переделывать (да, даже при составленном DoD). В любом случае это приведет к лишним затратам времени и сил на коммуникацию и доработки. А ведь именно этого мы пытаемся избежать с помощью DoD.
И здесь возникает важный вопрос: хорошо, я сформулировал DoD, но как убедиться, что меня поняли правильно?
✅ Техника обратного резюмирования
Один из самых простых, надежных и эффективных способов проверить, что человек всё понял, — это попросить его пересказать суть задачи своими словами. Этот прием называется "техника обратного резюмирования".
Суть её крайне проста. Чтобы пересказать задачу, человеку придется:
➡️ Вспомнить ключевые факты.
➡️ Выстроить между ними причинно-следственные связи.
➡️ Добавить щепотку себя — рассказать, как он собирается выполнять задачу.
➡️ Сформулировать это всё словами и представить в логичном виде.
Проще говоря, человеку придется напрячься и тщательно обдумать, что именно он услышал, что понял и как намерен действовать.
В ходе пересказа сразу становятся видны несостыковки. Человек может запинаться, задавать уточняющие вопросы, говорить путано или даже совсем не то, что вы имели в виду. И это нормально — в этом и заключается вся суть техники обратного резюмирования: выявить трудности в понимании.
✅ "Но людей же это бесит!"
Одно из распространенных опасений, которое я часто слышу, когда рассказываю об этой технике: "Собеседник будет раздражаться. Он подумает, что я считаю его тупым и неспособным понять, раз так досконально разжёвываю задачу".
Такое действительно может случиться. Всё зависит от вашей подачи. Если подойти к человеку с вопросами типа: "Понял? Ну-ка расскажи, что ты понял", — он, скорее всего, почувствует раздражение.
Поэтому важно донести свои намерения. Остановитесь на секунду и подумайте: зачем вы хотите уточнить? Скорее всего, вы просто хотите убедиться, что правильно донесли свои мысли до собеседника, чтобы потом не пришлось ничего переделывать.
Именно это и нужно объяснить. Например, можно сказать: "Я хочу убедиться, что смог нормально объяснить тебе задачу/проблему. Расскажи, пожалуйста, как ты понял сказанное мной, чтобы мы убедились, что одинаково всё понимаем и я справился с объяснением."
Таким образом, вы берёте на себя ответственность за качество передачи информации и мягко настраиваете собеседника на то, чтобы он дал вам обратную связь в виде пересказа.
Попробуйте использовать технику обратного резюмирования при постановке следующей задачи. Вы удивитесь, сколько времени и сил она сэкономит.
А как вы проверяете, что задачи поняты правильно? Применяете ли технику обратного резюмирования? Делитесь в комментариях!
Никита Ульшин про IT | #management #delegation
В предыдущем посте я писал о том, что такое Definition Of Done (DoD) и как его можно применять в делегировании. Однако мы рассмотрели только одну сторону вопроса — как самому сформулировать ожидания.
Но не стоит забывать, что на другой стороне DoD находится человек, и ему ничто человеческое не чуждо. Он вполне может не до конца понять написанное или понять его неправильно в силу своих внутренних установок.
Эти моменты важно прояснить до того, как специалист возьмется за задачу. Иначе велика вероятность, что результат получится не таким, как ожидалось. В лучшем случае потребуется некоторое количество правок, в худшем — задачу придется основательно переделывать (да, даже при составленном DoD). В любом случае это приведет к лишним затратам времени и сил на коммуникацию и доработки. А ведь именно этого мы пытаемся избежать с помощью DoD.
И здесь возникает важный вопрос: хорошо, я сформулировал DoD, но как убедиться, что меня поняли правильно?
Один из самых простых, надежных и эффективных способов проверить, что человек всё понял, — это попросить его пересказать суть задачи своими словами. Этот прием называется "техника обратного резюмирования".
Суть её крайне проста. Чтобы пересказать задачу, человеку придется:
Проще говоря, человеку придется напрячься и тщательно обдумать, что именно он услышал, что понял и как намерен действовать.
В ходе пересказа сразу становятся видны несостыковки. Человек может запинаться, задавать уточняющие вопросы, говорить путано или даже совсем не то, что вы имели в виду. И это нормально — в этом и заключается вся суть техники обратного резюмирования: выявить трудности в понимании.
Одно из распространенных опасений, которое я часто слышу, когда рассказываю об этой технике: "Собеседник будет раздражаться. Он подумает, что я считаю его тупым и неспособным понять, раз так досконально разжёвываю задачу".
Такое действительно может случиться. Всё зависит от вашей подачи. Если подойти к человеку с вопросами типа: "Понял? Ну-ка расскажи, что ты понял", — он, скорее всего, почувствует раздражение.
Поэтому важно донести свои намерения. Остановитесь на секунду и подумайте: зачем вы хотите уточнить? Скорее всего, вы просто хотите убедиться, что правильно донесли свои мысли до собеседника, чтобы потом не пришлось ничего переделывать.
Именно это и нужно объяснить. Например, можно сказать: "Я хочу убедиться, что смог нормально объяснить тебе задачу/проблему. Расскажи, пожалуйста, как ты понял сказанное мной, чтобы мы убедились, что одинаково всё понимаем и я справился с объяснением."
Таким образом, вы берёте на себя ответственность за качество передачи информации и мягко настраиваете собеседника на то, чтобы он дал вам обратную связь в виде пересказа.
Попробуйте использовать технику обратного резюмирования при постановке следующей задачи. Вы удивитесь, сколько времени и сил она сэкономит.
А как вы проверяете, что задачи поняты правильно? Применяете ли технику обратного резюмирования? Делитесь в комментариях!
Никита Ульшин про IT | #management #delegation
Please open Telegram to view this post
VIEW IN TELEGRAM
Встречаемся на TeamLeadConf
Конференции я люблю. Это и новые идеи, и новые знакомста, и отличные доклады.
Завтра и послезавтра буду на TeamLeadConf. Уже составил список докладов, которые хочу послушать и список людей, которых хочу увидеть. Предполагаю, что буду там с утра до вечера, так что можно меня поймать и помучать вопросами за кофе :)
До встречи!🕺
Конференции я люблю. Это и новые идеи, и новые знакомста, и отличные доклады.
Завтра и послезавтра буду на TeamLeadConf. Уже составил список докладов, которые хочу послушать и список людей, которых хочу увидеть. Предполагаю, что буду там с утра до вечера, так что можно меня поймать и помучать вопросами за кофе :)
До встречи!
Please open Telegram to view this post
VIEW IN TELEGRAM
📚 Алексей Пименов, "Канбан Метод. Базовая практика"
У меня сложилась довольно интересная ситуация: я давно работаю "по канбану" (позже объясню, почему кавычки), но никогда глубоко в него не вникал. Все мои знания о методе были обрывочными, поэтому я решил систематизировать их. Руководитель порекомендовал мне прочитать книгу Алексея Пименова "Канбан Метод", что я и сделал.
⭐️ О чём книга
Книга посвящена практическому применению Канбан-метода. Она адресована руководителям производственных процессов (в принципе, любых), которые отвечают за производительность команды, подразделения, цеха — чего угодно.
Сам Алексей направляет свою книгу в первую очередь на специалистов в сфере умственного труда, где результаты работы сложно "пощупать". Это требует визуализации процесса, чтобы сделать его понятным и прозрачным.
В книге раскрываются следующие темы:
➡️ Почему так сложно управлять нематериальным производством?
➡️ В чём заключаются основные принципы и практики Канбан-метода?
➡️ Как начать использовать Канбан в своей работе?
➡️ Как выстроить системную работу с помощью Канбана?
➡️ Как анализировать и улучшать Канбан-системы?
⭐️ 3 главных вывода из книги
🟡 Строить систему вокруг работы, а не вокруг людей. Управление производственным процессом — это управление самой работой, а не попытка максимально загрузить каждого сотрудника (об этом ещё Элияху Голдратт писал в "Цели").
🟡 Не нужно изобретать процесс с нуля. Начинайте с того, что уже есть, и сделайте это явным с помощью визуализации, каденций и других практик.
🟡 Главный фокус — стабильная поставка клиентской ценности. Вся система строится вокруг предоставления ценности заказчику. Всё остальное — второстепенно. Задача производственного процесса — дать клиенту то, за что он платит.
⭐️ Мои впечатления
Мне очень понравилась книга Алексея. Она отлично структурирована и написана простым, понятным языком. Автор последовательно проводит читателя через все ключевые этапы: от осознания проблемы до внедрения и поддержки решения.
Книга изобилует примерами из практики, что делает её ещё более полезной. Особенно меня заинтересовали графики анализа незавершённой работы в разделе об улучшении Канбан-систем. Однако каждый раздел богат на примеры, которые объясняют идеи автора. Что особенно приятно — примеры живые, "настоящие", а не вымышленные и искусственные.
По сути, книга даёт отличный верхнеуровневый обзор Канбан-метода. Конечно, некоторые темы раскрыты поверхностно (например, управление изменениями), но это логично. Во-первых, книга изначально не ставит целью углубляться в каждую тему. Во-вторых, если рассматривать все аспекты Канбана подробно, это превратилось бы в Большую Советскую Энциклопедию.
Лично мне не хватило ссылок на дополнительные материалы, чтобы глубже изучить отдельные части Канбан-метода. Это не критично, но всегда интересно знать, на чём автор основывал своё творчество. Любителям "копнуть глубже", как я, придётся самим отправляться в интернет и искать исследования, книги и опыт компаний.
Книга получилась очень полезной, и я рекомендую её всем, кто так или иначе управляет производственными процессами. Принципы Канбана будут актуальны даже для тех, кто работает по Scrum, LeSS, Waterfall или вообще в условиях хаоса.
Читали книгу? Как вам?
Никита Ульшин про IT | #обзор_книги
У меня сложилась довольно интересная ситуация: я давно работаю "по канбану" (позже объясню, почему кавычки), но никогда глубоко в него не вникал. Все мои знания о методе были обрывочными, поэтому я решил систематизировать их. Руководитель порекомендовал мне прочитать книгу Алексея Пименова "Канбан Метод", что я и сделал.
Книга посвящена практическому применению Канбан-метода. Она адресована руководителям производственных процессов (в принципе, любых), которые отвечают за производительность команды, подразделения, цеха — чего угодно.
Сам Алексей направляет свою книгу в первую очередь на специалистов в сфере умственного труда, где результаты работы сложно "пощупать". Это требует визуализации процесса, чтобы сделать его понятным и прозрачным.
В книге раскрываются следующие темы:
Мне очень понравилась книга Алексея. Она отлично структурирована и написана простым, понятным языком. Автор последовательно проводит читателя через все ключевые этапы: от осознания проблемы до внедрения и поддержки решения.
Книга изобилует примерами из практики, что делает её ещё более полезной. Особенно меня заинтересовали графики анализа незавершённой работы в разделе об улучшении Канбан-систем. Однако каждый раздел богат на примеры, которые объясняют идеи автора. Что особенно приятно — примеры живые, "настоящие", а не вымышленные и искусственные.
По сути, книга даёт отличный верхнеуровневый обзор Канбан-метода. Конечно, некоторые темы раскрыты поверхностно (например, управление изменениями), но это логично. Во-первых, книга изначально не ставит целью углубляться в каждую тему. Во-вторых, если рассматривать все аспекты Канбана подробно, это превратилось бы в Большую Советскую Энциклопедию.
Лично мне не хватило ссылок на дополнительные материалы, чтобы глубже изучить отдельные части Канбан-метода. Это не критично, но всегда интересно знать, на чём автор основывал своё творчество. Любителям "копнуть глубже", как я, придётся самим отправляться в интернет и искать исследования, книги и опыт компаний.
Книга получилась очень полезной, и я рекомендую её всем, кто так или иначе управляет производственными процессами. Принципы Канбана будут актуальны даже для тех, кто работает по Scrum, LeSS, Waterfall или вообще в условиях хаоса.
Читали книгу? Как вам?
Никита Ульшин про IT | #обзор_книги
Please open Telegram to view this post
VIEW IN TELEGRAM
Развитие сотрудников через неопределённость
Продолжаем развивать тему Definition Of Done (DoD) как рабочего инструмента тимлида. В предыдущих постах я писал о том, что DoD — важная штука для делегирования и прозрачной постановки задач сотрудникам. Однако DoD может быть не только инструментом для постановки задач, но и способом развивать членов команды.
✅ Уровень DoD и опыт сотрудников
Для начала давайте подумаем: всем ли членам команды нужен DoD с одинаково детальным уровнем проработки? Ответ очевиден: конечно, нет.
🟡 Стажёры требуют максимально разжёванного и детального DoD, вплоть до пошаговой инструкции.
🟡 Джуны уже лучше понимают проект, но всё ещё нуждаются в наставничестве и подробных пояснениях.
🟡 Мидлы способны работать с умеренной неопределённостью. Они замечают нестыковки и "туман войны" в задачах.
🟡 Сеньёры справляются с задачами высокого уровня неопределённости, включая R&D без чётких инструкций.
🟡 Крутые сеньёры могут сами написать DoD.
Очевидно, что уровень неопределённости задачи напрямую зависит от уровня специалиста. Чем опытнее сотрудник, тем менее подробные инструкции ему нужны и тем сложнее задачи он может решать.
✅ Что, если сознательно повысить уровень неопределённости?
Исходя из вышесказанного, напрашивается интересный эксперимент: а что будет, если преднамеренно давать специалистам задачи, в которых уровень неопределённости выше, чем они привыкли?
Я проводил такой эксперимент в своих командах, и результаты оказались действительно крутыми. Но у этой практики есть свои нюансы (о них ниже).
Начнём с хорошего. Люди начинают расти значительно быстрее. Работая над задачами с "белыми пятнами", они учатся внимательнее анализировать свою работу. Например, задумываются о том, как текущая фича встраивается в общий продукт или какие неожиданные тестовые сценарии могут появиться. Это прокачивает не только навыки выполнения задач, но и общее понимание продукта и процесса.
Теперь о нюансах.
➡️ Не делайте так постоянно
Работа с задачами, полными неопределённости, — это выход из зоны комфорта. А значит, сотрудник испытывает стресс. Периодические вызовы полезны и способствуют росту, но если делать это постоянно, то в лучшем случае вы получите нелестную обратную связь, а в худшем — столкнётесь с выгоранием и потерей доверия.
➡️ Открыто обсуждайте изменения
Прежде чем давать сотруднику менее проработанные задачи, обсудите это с ним. Возможно, человек сейчас хочет заниматься чем-то другим (например, наставничеством для стажёров). Если он не готов брать на себя дополнительные сложности, предложите вернуться к этой идее позже.
Важно дать сотруднику право отказаться, а не навязывать новый подход в одностороннем порядке.
➡️ Не бросайте людей в воду
Некоторых из нас в детстве учили плавать, бросая в середину озера. Но с сотрудниками так поступать нельзя. Если вы договорились, что человек берёт задачу с высоким уровнем неопределённости, обеспечьте ему поддержку. Он должен понимать, что в любой момент может обратиться к вам за помощью, получить разъяснения и советы.
✅ Почему это важно
Внедрять такую технику для развития сотрудников может быть непросто, но результаты того стоят. Вы не только ускорите их профессиональный рост, но и укрепите доверие в команде. И однажды, на вопрос сотрудника: "А как сделать эту задачу?" — вы сможете с гордостью ответить: "Ты мне скажи."
А вы пробовали давать своим сотрудникам задачи с повышенной неопределённостью? Какие результаты это дало?
Никита Ульшин про IT | #management #delegation #team_development
Продолжаем развивать тему Definition Of Done (DoD) как рабочего инструмента тимлида. В предыдущих постах я писал о том, что DoD — важная штука для делегирования и прозрачной постановки задач сотрудникам. Однако DoD может быть не только инструментом для постановки задач, но и способом развивать членов команды.
Для начала давайте подумаем: всем ли членам команды нужен DoD с одинаково детальным уровнем проработки? Ответ очевиден: конечно, нет.
Очевидно, что уровень неопределённости задачи напрямую зависит от уровня специалиста. Чем опытнее сотрудник, тем менее подробные инструкции ему нужны и тем сложнее задачи он может решать.
Исходя из вышесказанного, напрашивается интересный эксперимент: а что будет, если преднамеренно давать специалистам задачи, в которых уровень неопределённости выше, чем они привыкли?
Я проводил такой эксперимент в своих командах, и результаты оказались действительно крутыми. Но у этой практики есть свои нюансы (о них ниже).
Начнём с хорошего. Люди начинают расти значительно быстрее. Работая над задачами с "белыми пятнами", они учатся внимательнее анализировать свою работу. Например, задумываются о том, как текущая фича встраивается в общий продукт или какие неожиданные тестовые сценарии могут появиться. Это прокачивает не только навыки выполнения задач, но и общее понимание продукта и процесса.
Теперь о нюансах.
Работа с задачами, полными неопределённости, — это выход из зоны комфорта. А значит, сотрудник испытывает стресс. Периодические вызовы полезны и способствуют росту, но если делать это постоянно, то в лучшем случае вы получите нелестную обратную связь, а в худшем — столкнётесь с выгоранием и потерей доверия.
Прежде чем давать сотруднику менее проработанные задачи, обсудите это с ним. Возможно, человек сейчас хочет заниматься чем-то другим (например, наставничеством для стажёров). Если он не готов брать на себя дополнительные сложности, предложите вернуться к этой идее позже.
Важно дать сотруднику право отказаться, а не навязывать новый подход в одностороннем порядке.
Некоторых из нас в детстве учили плавать, бросая в середину озера. Но с сотрудниками так поступать нельзя. Если вы договорились, что человек берёт задачу с высоким уровнем неопределённости, обеспечьте ему поддержку. Он должен понимать, что в любой момент может обратиться к вам за помощью, получить разъяснения и советы.
Внедрять такую технику для развития сотрудников может быть непросто, но результаты того стоят. Вы не только ускорите их профессиональный рост, но и укрепите доверие в команде. И однажды, на вопрос сотрудника: "А как сделать эту задачу?" — вы сможете с гордостью ответить: "Ты мне скажи."
А вы пробовали давать своим сотрудникам задачи с повышенной неопределённостью? Какие результаты это дало?
Никита Ульшин про IT | #management #delegation #team_development
Please open Telegram to view this post
VIEW IN TELEGRAM
🔗 Эфир в Telegram
Есть в жизни каждого тимлида два стула: на одном техничка сложная, на другом менеджмент запарный. Пробема в том, что выбрать один из них на этой роли невозможно. Каждый день нужно совершать трудный выбор: посвятить своё время управлению команде или техническим задачам.
В новом эпизоде моего подкаста "1-1" мы с моим гостем, Антоном Непша, поговорим о том, как балансировать между кодом и управлением, не жертвуя качеством ни в одном из направлений. Антон - лидер компетенции frontend-разработки в Сбере, разрабатывает web-версию СберБанк Онлайн, развивает внутренее фронтенд-сообщество, организовывает митапы, выступает на конференциях и ведёт интересный канал.
Мы раскроем следующие вопросы:
Приходите на эфир, чтобы позадавать вопросы. Запись будет через несколько дней. До встречи!
Никита Ульшин про IT | #live
Please open Telegram to view this post
VIEW IN TELEGRAM
За время ведения канала я написал уже довольно много обзоров книг (и не собираюсь останавливаться). Для удобства я решил собрать все обзоры в один пост, который буду регулярно пополнять. Ссылка на него также будет в закреплённом сообщении, чтобы вы в любой момент могли найти интересующую вас книгу.
1. Designing Data-Intensive Applications by Martin Kleppmann
2. Кэрол Дуэк, "Гибкое сознание"
3. Сэм Ньюмен, "Создание микросервисов"
4. Understanding Message Brokers by Jakub Corab
5. Сергей Поварнин, "Искусство спора"
6. Титус Винтерс, Том Маншрек, Хайрам Райт, "Делай как в Google"
7. Сергей Поварнин, "Как читать книги"
8. Ронни Митра, Иракли Надареишвили, "Микросервисы. От архитектуры до релиза"
9. Зонке Аренс, "Как делать полезные заметки"
10. Тьяго Форте "Второй мозг"
11. Сэм Ньюмен, "От монолита к микросервисам"
12. Грег Хорин, "Управление проектами с нуля"
13. Джеймс Стэньер, "Карьера Software Engineering Manager"
14. Дэниел Гоулман, "Эмоциональный интеллект"
15. Кэл Ньюпорт, "В работу с головой"
16. Маршалл Розенберг, "Ненасильственное общение"
17. Дэн Уиллингем "Учись как профи. 14 супернавыков, чтобы освоить все, что хочешь"
18. Михалис Цукалос, "Golang для профи"
19. Джон Боднер, "Go. Идиомы и паттерны проектирования"
20. Тейва Харшани «100 ошибок Go и как их избежать»
21. Сергей Виноградов, "Логика. Учебник для средней школы"
22. Георгий Челпанов, "Учебник логики"
23. Александр Ивин, "Искусство мыслить правильно"
24. Мануш Зомороди, "Разреши себе скучать"
25. Алексей Пименов, "Канбан Метод. Базовая практика"
26. Рэй Далио, "Принципы"
27. Кэл Ньюпорт "Хватит мечтать, займись делом."
28. Массимо Пильюччи "Как быть стоиком: Античная философия и современная жизнь"
29. Брайан Моран, Майкл Леннингтон "12 недель в году"
30. Марина Перескокова "Мама, я тимлид! Практические советы по руководству IT-командой"
31. Зиг Зиглар "Цели. Как пользоваться жизнь на всю катушку"
32. Элияху Голдратт "Цель. Процесс непрерывного совершенствования"
33. Энни Дьюк "Принцип ставок"
34. The Poker Mindset by Matthew Hilger, Ian Taylor
35. Райан Холидей "Эго - это враг"
36. Камиль Фурнье "От разработчика до руководителя"
37. Ларри Кинг «Как разговаривать с кем угодно, когда угодно, где угодно»
38. Кейт Феррацци, «Никогда не ешьте в одиночку и другие правила нетворкинга»
39. Максим Батырев, «45 татуировок менеджера»
40. Кристофер Хэдфилд, «Руководство астронавта по жизни на Земле. Чему научили меня 4000 часов на орбите»
41. Райан Холидей «Препятствие как путь»
42. Йонге Мингьюр Ринпоче, «Будда, мозг и нейрофизиология счастья. Как изменить жизнь к лучшему»
43. Элияху Голдратт, «Цель-2. Дело не в везении»
44. Ричард Румельт, «Хорошая стратегия, плохая стратегия»
45. Сьюзен Фаулер, «Почему они не работают? Новый взгляд на мотивацию сотрудников»
46. Дэниел Пинк «Драйв. Что на самом деле нас мотивирует»
47. Михай Чиксентмихайи «Поток. Психология оптимального переживания»
48. Патрик Ленсиони «5 пороков команды»
49. Радислав Гандапас, «Камасутра для оратора»
50. Рустам Агамалиев, «Наука нечтения»
51. Патрик Ленсиони, «Идеальный командный игрок»
52. Роберт Чалдини, «Психология влияния»
53. Маркос Васкес, «Стоики побеждают. Ментальные тренировки для преодоления жизненных трудностей»
1. Терри Пратчетт, “Кот без прикрас”
2. Лю Цысинь, “Задача трёх тел”
3. Терри Пратчетт и Нил Гейман, "Благие знамения"
4. Алексей Пехов, цикл "Страж"
5. Виктор Пелевин "Чапаев и Пустота"
Никита Ульшин про IT | #обзор_книги
Please open Telegram to view this post
VIEW IN TELEGRAM
📚 Рэй Далио, "Принципы"
Мне всегда интересно узнать принципы, которыми руководствуются другие люди. Именно их я стараюсь понять в личном общении (и даже в переписке). Для меня принципы — это правила жизни, которые человек выбирает самостоятельно, осознанно и которыми руководствуется в принятии повседневных решений.
При всей неоднозначности персоны Рэя Далио было бы просто глупо отрицать, что этот человек добился успеха в некоторых областях жизни и у него есть чему поучиться. Поэтому я взял его книгу "Принципы" в надежде найти для себя что-то полезное.
⭐️ О чём книга
Структурно книга разделена на три большие части.
Первая часть посвящена автобиографии Рэя Далио и его воспоминаниям. Он рассказывает, как стал тем, кем стал, и какой путь в жизни прошёл.
Вторая часть посвящена его жизненным принципам. Здесь автор перечисляет пять основных принципов, которыми руководствуется. Каждый принцип раскрывается примерами и пояснениями.
Третья часть (самая большая, почти 50% книги) содержит принципы работы Далио. Она дополнительно разбита на три блока: правильная корпоративная культура, правильные люди, создание и совершенствование механизма. В этой части содержатся принципы и советы по организации работы.
В книге раскрываются следующие темы:
➡️ Биография Рэя Далио
➡️ Как принимать реальность и работать с ней?
➡️ Как и зачем сохранять непредубеждённость?
➡️ Что такое корпоративная культура и как она влияет на работу организации?
➡️ Работа с людьми: найм, развитие, увольнения
➡️ Развитие организации и устранение проблем
⭐️ Три вывода из книги
🟡 Любая сложность или ошибка — это головоломка, за решение которой полагается награда в виде понимания какого-то принципа устройства мира и возможности не совершать такую же ошибку повторно.
🟡 Люди действуют на основе своих принципов и убеждений, поэтому каждое действие человека содержит информацию о нём. Наблюдение за действиями (а не словами) людей может многое о них рассказать.
🟡 Тяни за каждую подозрительную ниточку и доверяй своей интуиции. Если кажется, что где-то что-то идёт не так, лучше пойти и перепроверить. Мелкие неприятности могут быть предвестниками серьёзных проблем.
⭐️ Мои впечатления
Я подошёл к книге с завышенными ожиданиями, потому что её нахваливали все вокруг. Скажу честно — я скорее разочарован.
Первые 25% книги посвящены самолюбованию и пересказу биографии в выгодном для автора свете. Далио пытается выставить себя человеком, который получил всё, опираясь исключительно на свои принципы. Но при этом он не раскрывает некоторые важные детали своей биографии (например, каким образом Bridgewater получил в управление активы пенсионных фондов).
Вся оставшаяся часть книги по большей части представляет собой довольно "водянистые" success stories по поводу тех или иных принципов. Читая эти главы, нужно помнить, что всё написанное — это конкретный опыт конкретного человека.
Многие из его принципов — это скорее советы, причём не все из них практичны и полезны. Это нормально: все люди разные, и даже сам Далио где-то в книге упоминает, что его идеи — не панацея от всех бед.
Тем не менее, книга содержит много хороших и полезных идей, которые я себе утащил и глубоко обдумал в своих заметках. От многих из этих мыслей явно веет стоицизмом.
Мне также понравилось, что все идеи и мысли Далио довольно прикладные. В книге нет увещеваний на тему "мир во всём мире" и "любовь ко всему живому и неживому". Далио — довольно циничный практик, и это ощущается в тексте. По-своему это полезно: читателю не приходится ломать голову над абстракциями.
⭐️ Вывод
Ознакомиться с книгой в целом будет полезно. Я бы рекомендовал следующий формат чтения: первую часть пропустить полностью, из второй и третьей читать только идеи без описания ситуаций их применения, но обдумать место для каждой из идей в своей жизни.
В более продвинутом варианте я бы рекомендовал сначала почитать что-то из современного стоицизма (например, того же Массимо Пильюччи), а уже после этого ознакомиться с "Принципами" Далио. Вот это точно будет интересный опыт! :)
Читали книгу? Как вам?
Никита Ульшин про IT | #обзор_книги
Мне всегда интересно узнать принципы, которыми руководствуются другие люди. Именно их я стараюсь понять в личном общении (и даже в переписке). Для меня принципы — это правила жизни, которые человек выбирает самостоятельно, осознанно и которыми руководствуется в принятии повседневных решений.
При всей неоднозначности персоны Рэя Далио было бы просто глупо отрицать, что этот человек добился успеха в некоторых областях жизни и у него есть чему поучиться. Поэтому я взял его книгу "Принципы" в надежде найти для себя что-то полезное.
Структурно книга разделена на три большие части.
Первая часть посвящена автобиографии Рэя Далио и его воспоминаниям. Он рассказывает, как стал тем, кем стал, и какой путь в жизни прошёл.
Вторая часть посвящена его жизненным принципам. Здесь автор перечисляет пять основных принципов, которыми руководствуется. Каждый принцип раскрывается примерами и пояснениями.
Третья часть (самая большая, почти 50% книги) содержит принципы работы Далио. Она дополнительно разбита на три блока: правильная корпоративная культура, правильные люди, создание и совершенствование механизма. В этой части содержатся принципы и советы по организации работы.
В книге раскрываются следующие темы:
Я подошёл к книге с завышенными ожиданиями, потому что её нахваливали все вокруг. Скажу честно — я скорее разочарован.
Первые 25% книги посвящены самолюбованию и пересказу биографии в выгодном для автора свете. Далио пытается выставить себя человеком, который получил всё, опираясь исключительно на свои принципы. Но при этом он не раскрывает некоторые важные детали своей биографии (например, каким образом Bridgewater получил в управление активы пенсионных фондов).
Вся оставшаяся часть книги по большей части представляет собой довольно "водянистые" success stories по поводу тех или иных принципов. Читая эти главы, нужно помнить, что всё написанное — это конкретный опыт конкретного человека.
Многие из его принципов — это скорее советы, причём не все из них практичны и полезны. Это нормально: все люди разные, и даже сам Далио где-то в книге упоминает, что его идеи — не панацея от всех бед.
Тем не менее, книга содержит много хороших и полезных идей, которые я себе утащил и глубоко обдумал в своих заметках. От многих из этих мыслей явно веет стоицизмом.
Мне также понравилось, что все идеи и мысли Далио довольно прикладные. В книге нет увещеваний на тему "мир во всём мире" и "любовь ко всему живому и неживому". Далио — довольно циничный практик, и это ощущается в тексте. По-своему это полезно: читателю не приходится ломать голову над абстракциями.
Ознакомиться с книгой в целом будет полезно. Я бы рекомендовал следующий формат чтения: первую часть пропустить полностью, из второй и третьей читать только идеи без описания ситуаций их применения, но обдумать место для каждой из идей в своей жизни.
В более продвинутом варианте я бы рекомендовал сначала почитать что-то из современного стоицизма (например, того же Массимо Пильюччи), а уже после этого ознакомиться с "Принципами" Далио. Вот это точно будет интересный опыт! :)
Читали книгу? Как вам?
Никита Ульшин про IT | #обзор_книги
Please open Telegram to view this post
VIEW IN TELEGRAM
Ухудшаются ли технические навыки тимлида? Как поддерживать баланс между техничкой и менеджментом? В новом выпуске подкаста "1-1" мы с Антоном Непшей обсудили, как тимлиду не разорваться между работой технаря и менеджера, а найти золотую середину.
Антон - лидер компетенции frontend-разработки в Сбере, разрабатывает web-версию СберБанк Онлайн, развивает внутренее фронтенд-сообщество, организовывает митапы, выступает на конференциях и ведёт интересный канал.
О чём мы поговорили:
Мне интереснее всего было обсуждать тему страха перед ухудшением или полной потерей технических навыков. Мой опыт показывает, что чаще всего страх вызывает не само ухудшение, а непонимание, что именно может ухудшиться и что с этим можно делать (и нужно ли делать).
Запись уже доступна по ссылкам ниже. Слушайте, делитесь впечатлениями и рассказывайте, как вы боретесь с ухудшением технических навыков в роли руководителя.
Никита Ульшин про IT | #onetoone_podcast
Please open Telegram to view this post
VIEW IN TELEGRAM
Про надёжность
Надёжность в бигтехе - это сложно. Огромные инфраструктуры, базы данных в несколько петабайт, сотни тысяч инстанстов. И за всё это отвечают обычные люди.
Я всегда очень уважал инфраструктурных инженеров. Работа программиста - это в среднем написание кода и доведение его до рабочего состояния. А девопс живёт в такой рабочей среде, где постоянно что-то ломается или отваливается. При этом мало гасить возникающие пожары, нужно ещё и развивать это всё.
Сегодня у меня экспериментальная рубрика #добрый_пиар и я хочу порекомендовать вам канал Андрея Синицына. Андрей занимается эксплуатацией огромных IT-инфраструктур и очень интересно об этом пишет. Да и не только об этом, Андрей вообще очень интересно пишет и у него приятный слог.
Рекомендую обратить внимание на следующие посты:
➡ Про метастабильное состояние отказа - интересный пост про нахождение системы между работоспособным и неработоспособным состоянием
➡ Про внутренности "пяти девяток"
➡ Как регулярно писать тексты для канала - под этим постом мы развели любопытную дискуссию
➡ И даже мемасики на инженерные темы есть
В общем, подписывайтесь, читайте и не стесняйтесь задавать вопросы - Андрей всем и всегда отвечает в комментариях под своими постами.
Никита Ульшин про IT | #добрый_пиар
Надёжность в бигтехе - это сложно. Огромные инфраструктуры, базы данных в несколько петабайт, сотни тысяч инстанстов. И за всё это отвечают обычные люди.
Я всегда очень уважал инфраструктурных инженеров. Работа программиста - это в среднем написание кода и доведение его до рабочего состояния. А девопс живёт в такой рабочей среде, где постоянно что-то ломается или отваливается. При этом мало гасить возникающие пожары, нужно ещё и развивать это всё.
Сегодня у меня экспериментальная рубрика #добрый_пиар и я хочу порекомендовать вам канал Андрея Синицына. Андрей занимается эксплуатацией огромных IT-инфраструктур и очень интересно об этом пишет. Да и не только об этом, Андрей вообще очень интересно пишет и у него приятный слог.
Рекомендую обратить внимание на следующие посты:
В общем, подписывайтесь, читайте и не стесняйтесь задавать вопросы - Андрей всем и всегда отвечает в комментариях под своими постами.
Никита Ульшин про IT | #добрый_пиар
Please open Telegram to view this post
VIEW IN TELEGRAM
И так понятно
Вы когда-нибудь сталкивались с ситуацией, когда вроде бы всё объяснил, а собеседник понял вообще другое? Это классическая проблема коммуникации: между тем, что я подумал, и тем, что понял собеседник, часто возникает разрыв.
В одном из предыдущих постов я писал, что мало передать человеку информацию - нужно ещё и убедиться, что он правильно понял. В качестве инструмента я предложил рассмотреть технику обратного резюмирования, когда собеседник пересказывает информацию своими словами.
⭐️ Почему люди понимают не то, что я сказал?
Однако вопрос, почему происходит такая деформация информации, остался открытым. Внести ясность поможет 4-уровневая модель коммуникации из людьми. Суть её заключается в том, что любая передача информации делится на несколько этапов:
🟡 То, что я подумал.
🟡 То, что я сказал.
🟡 То, что собеседник услышал.
🟡 То, что собеседник понял.
На каждом из этих этапов происходит искажение информации.
➡️ Подумал одно, сказал другое (искажение между мыслью и словом).
➡️ Собеседник слушал невнимательно и/или выдрал часть мысли из контекста (искажение между словом и восприятием).
➡️ Собеседник всё понял по-своему (искажение между восприятием и мыслью).
Я легко могу вспомнить ситуации, где я попадал в ловушку от каждого из этих преобразований. Но самые сильные деформации происходят, когда я не могу чётко сформулировать мысль, а собеседник меня вообще не слушает.
Наглядно искажения информации можно увидеть в детской игре "испорченный телефон", где прохождение единицы информации через несколько таких циклов преображает её до неузнаваемости. Я даже мемчик приложил для наглядности.
⭐️ Как снизить искажения информации?
Из всего вышесказанного можно сделать вывод, что возможностей для искажения информации очень много. Поэтому существует такое же множество техник для улучшения информационного обмена между людьми. Приведу несколько примеров:
➡️ Учиться чётко формулировать мысли. На помощь придут логика и риторика.
➡️ Отслеживать непонимание и недопонимание, задавать уточняющие вопросы.
➡️ Просить собеседника пересказать услышанное своими словами.
➡️ Самому пересказывать сказанное собеседником с просьбой проверить, правильно ли вы всё поняли.
Главное, о чём нужно помнить - информация искажается очень легко. Между тем, что я подумал и что мой собеседник понял может оказаться настоящая пропасть. Так что не стоит рассчитывать на то, что "и так понятно". Помните, каждое слово проходит через несколько преобразований. Учитесь строить мосты через эту пропасть — и ваши коммуникации станут гораздо эффективнее.
Никита Ульшин про IT | #management #communication
Вы когда-нибудь сталкивались с ситуацией, когда вроде бы всё объяснил, а собеседник понял вообще другое? Это классическая проблема коммуникации: между тем, что я подумал, и тем, что понял собеседник, часто возникает разрыв.
В одном из предыдущих постов я писал, что мало передать человеку информацию - нужно ещё и убедиться, что он правильно понял. В качестве инструмента я предложил рассмотреть технику обратного резюмирования, когда собеседник пересказывает информацию своими словами.
Однако вопрос, почему происходит такая деформация информации, остался открытым. Внести ясность поможет 4-уровневая модель коммуникации из людьми. Суть её заключается в том, что любая передача информации делится на несколько этапов:
На каждом из этих этапов происходит искажение информации.
Я легко могу вспомнить ситуации, где я попадал в ловушку от каждого из этих преобразований. Но самые сильные деформации происходят, когда я не могу чётко сформулировать мысль, а собеседник меня вообще не слушает.
Наглядно искажения информации можно увидеть в детской игре "испорченный телефон", где прохождение единицы информации через несколько таких циклов преображает её до неузнаваемости. Я даже мемчик приложил для наглядности.
Из всего вышесказанного можно сделать вывод, что возможностей для искажения информации очень много. Поэтому существует такое же множество техник для улучшения информационного обмена между людьми. Приведу несколько примеров:
Главное, о чём нужно помнить - информация искажается очень легко. Между тем, что я подумал и что мой собеседник понял может оказаться настоящая пропасть. Так что не стоит рассчитывать на то, что "и так понятно". Помните, каждое слово проходит через несколько преобразований. Учитесь строить мосты через эту пропасть — и ваши коммуникации станут гораздо эффективнее.
Никита Ульшин про IT | #management #communication
Please open Telegram to view this post
VIEW IN TELEGRAM
Встречаемся на Frontend Night by Sber
Коллеги из Сбера пригласили меня выступить с докладом Frontend Night в понедельник 16 декабря.
Я буду участником стрима "Soft-Skills и процессы" и расскажу о менторстве с точки зрения руководителя команды. Мы поговорим о том, как менторство может помогать команде профессионально расти и решать всё более сложные задачи и о том, как тимлид может внедрить и поддерживать процесс менторства в своей команде.
Тема для меня очень актуальная, потому что я активно занимаюсь менторством последние несколько лет и накопил много интересного опыта на эту тему. Теперь мне хочется поделиться опытом с коллегами и показать им, что менторство - это классно, полезно и совсем не сложно.
Рядом со мной в стриме будут такие титаны публичных выступлений, как Миша Трифонов и Глеб Михеев с крутейшими докладами про servant leader и кросс-командные коммуникации. А после докладов ожидается after-party с фуршетом и играми.
Приходите, будет интересно и познавательно! А если вдруг не получится - позже будут записи.
Где и когда:
16 декабря (понедельник), 17:00.
Офлайн: Москва, IRRI loft, м. Павелецкая, Дербеневская набережная, 7, стр. 31.
Онлайн: будет трансляция.
Участие бесплатно, но нужна регистрация. Зарегистрироваться и посмотреть программу можно здесь.
Коллеги из Сбера пригласили меня выступить с докладом Frontend Night в понедельник 16 декабря.
Я буду участником стрима "Soft-Skills и процессы" и расскажу о менторстве с точки зрения руководителя команды. Мы поговорим о том, как менторство может помогать команде профессионально расти и решать всё более сложные задачи и о том, как тимлид может внедрить и поддерживать процесс менторства в своей команде.
Тема для меня очень актуальная, потому что я активно занимаюсь менторством последние несколько лет и накопил много интересного опыта на эту тему. Теперь мне хочется поделиться опытом с коллегами и показать им, что менторство - это классно, полезно и совсем не сложно.
Рядом со мной в стриме будут такие титаны публичных выступлений, как Миша Трифонов и Глеб Михеев с крутейшими докладами про servant leader и кросс-командные коммуникации. А после докладов ожидается after-party с фуршетом и играми.
Приходите, будет интересно и познавательно! А если вдруг не получится - позже будут записи.
Где и когда:
16 декабря (понедельник), 17:00.
Офлайн: Москва, IRRI loft, м. Павелецкая, Дербеневская набережная, 7, стр. 31.
Онлайн: будет трансляция.
Участие бесплатно, но нужна регистрация. Зарегистрироваться и посмотреть программу можно здесь.
Кэл Ньюпорт "Хватит мечтать, займись делом. Почему хорошо работать важнее, чем искать хорошую работу."
Книги Кэла Ньюпорта мне нравятся своей прямотой. Он честно высказывает своё мнение и делится своим опытом, хотя его тексты иногда звучат резковато. Однако лично мне каждая его книга даёт много пищи для размышлений.
Ранее я уже писал обзор на его прекрасную книгу "В работу с головой" о важности глубокого погружения в работу. "Хватит мечтать, займись делом" я взял, чтобы познакомиться со взглядом Ньюпорта на работу мечты и то, как её найти в жизни. Вопрос для меня актуальный, потому что я много лет страдал от синдрома самозванца. Иногда я чувствовал себя как Буриданов осёл, будучи не в силах сделать выбор.
⭐ О чём книга
Книга рассказывает о двух подходах к работе: подходе мечтателя и подходе мастера. Подход мечтателя (крайне популярный) звучит так: найди работу мечты, и тебе не придётся работать ни дня в жизни (неправильно понятый Конфуций в гробу вертится).
Ньюпорт убедительно показывает, почему, по его мнению, этот подход нежизнеспособен. В качестве альтернативы он предлагает рассмотреть подход мастера, который заключается в том, чтобы наращивать свои навыки и благодаря этому получать всё более привлекательную работу.
В книге раскрываются следующие темы:
➡ Почему гнаться за работой мечты — это путь в никуда.
➡ Что такое карьерный капитал и как его наращивать.
➡ Как обменивать карьерный капитал на работу мечты.
➡ Способы постоянного наращивания профессионализма.
➡ Влияние личной миссии на карьеру.
⭐ 3 вывода из книги
🟡 Если гнаться за мечтой, можно легко оказаться в тупике и попасть в ловушку вечного разочарования, потому что мир не идеален. К тому же погоня за мечтой подпитывает эго.
🟡 Главное — это профессиональное мастерство. Работа мечты встречается редко, и за неё нужно заплатить карьерным капиталом. Меня эта идея вдохновила настолько, что я прямо в процессе чтения написал пост на эту тему.
🟡 Чем бы вы ни занимались, подходите к работе как истинный мастер: везде ищите возможности для роста и обучения. Станьте работником, которого невозможно не заметить.
⭐ Мои впечатления
Основная идея книги довольно проста: вместо стремления к лучшей работе стремись лучше работать — остальное приложится. Звучит просто, однако на практике такой подход требует дисциплины, усердия, терпения и открытости.
Ньюпорт довольно детально (при этом без лишней воды) разбирает как подход мечтателя, так и подход мастера, показывая преимущества и недостатки каждого. При этом он не подаёт подход мастера как лекарство от всех болезней и серебряную пулю. Он честно показывает, что этот путь труден и подойдёт не всем, но потенциальная награда за него очень высока.
Мне нравится концепция рыночных отношений, которую Ньюпорт закладывает в подход мастера. Хочешь работу мечты — будь готов заплатить за неё ценными профессиональными навыками и знаниями. Это звучит как честная сделка.
Конечно, порой бывает, что недостаточно квалифицированные люди занимают какие-то крутые позиции. Но счастливы ли они там? Вряд ли. Здесь будет уместно вспомнить книгу "Поток", в которой говорится, что для получения счастья и удовольствия от работы нужен баланс сложности задач и профессиональных навыков. Если задачи слишком сложные, человек будет находиться в постоянном стрессе, и ни о какой радости от работы не может быть и речи.
На мой вопрос книга ответила полностью. Как минимум, я убедился, что нахожусь на правильном пути и правильно смотрю на мир (или попал под confirmation bias :)). А ещё я обогатил понимание своих принципов работы идеями, которые почерпнул из книги.
Если вы периодически испытываете неудовлетворённость от своей деятельности, будь то работа, хобби или свой проект, я очень рекомендую прочитать эту книгу. Она небольшая, но пищи для размышлений даёт предостаточно.
Никита Ульшин про IT | #обзор_книги
Книги Кэла Ньюпорта мне нравятся своей прямотой. Он честно высказывает своё мнение и делится своим опытом, хотя его тексты иногда звучат резковато. Однако лично мне каждая его книга даёт много пищи для размышлений.
Ранее я уже писал обзор на его прекрасную книгу "В работу с головой" о важности глубокого погружения в работу. "Хватит мечтать, займись делом" я взял, чтобы познакомиться со взглядом Ньюпорта на работу мечты и то, как её найти в жизни. Вопрос для меня актуальный, потому что я много лет страдал от синдрома самозванца. Иногда я чувствовал себя как Буриданов осёл, будучи не в силах сделать выбор.
Книга рассказывает о двух подходах к работе: подходе мечтателя и подходе мастера. Подход мечтателя (крайне популярный) звучит так: найди работу мечты, и тебе не придётся работать ни дня в жизни (неправильно понятый Конфуций в гробу вертится).
Ньюпорт убедительно показывает, почему, по его мнению, этот подход нежизнеспособен. В качестве альтернативы он предлагает рассмотреть подход мастера, который заключается в том, чтобы наращивать свои навыки и благодаря этому получать всё более привлекательную работу.
В книге раскрываются следующие темы:
Основная идея книги довольно проста: вместо стремления к лучшей работе стремись лучше работать — остальное приложится. Звучит просто, однако на практике такой подход требует дисциплины, усердия, терпения и открытости.
Ньюпорт довольно детально (при этом без лишней воды) разбирает как подход мечтателя, так и подход мастера, показывая преимущества и недостатки каждого. При этом он не подаёт подход мастера как лекарство от всех болезней и серебряную пулю. Он честно показывает, что этот путь труден и подойдёт не всем, но потенциальная награда за него очень высока.
Мне нравится концепция рыночных отношений, которую Ньюпорт закладывает в подход мастера. Хочешь работу мечты — будь готов заплатить за неё ценными профессиональными навыками и знаниями. Это звучит как честная сделка.
Конечно, порой бывает, что недостаточно квалифицированные люди занимают какие-то крутые позиции. Но счастливы ли они там? Вряд ли. Здесь будет уместно вспомнить книгу "Поток", в которой говорится, что для получения счастья и удовольствия от работы нужен баланс сложности задач и профессиональных навыков. Если задачи слишком сложные, человек будет находиться в постоянном стрессе, и ни о какой радости от работы не может быть и речи.
На мой вопрос книга ответила полностью. Как минимум, я убедился, что нахожусь на правильном пути и правильно смотрю на мир (или попал под confirmation bias :)). А ещё я обогатил понимание своих принципов работы идеями, которые почерпнул из книги.
Если вы периодически испытываете неудовлетворённость от своей деятельности, будь то работа, хобби или свой проект, я очень рекомендую прочитать эту книгу. Она небольшая, но пищи для размышлений даёт предостаточно.
Никита Ульшин про IT | #обзор_книги
Please open Telegram to view this post
VIEW IN TELEGRAM
Командная работа над ошибками
В любой, даже самой простой системе, всегда есть пространство для ошибок. Ошибки случаются — и это просто факт, который нужно принять.
Сложнее всего относиться к ошибкам как к урокам, из которых можно сделать выводы. Когда я учился в школе, ошибки воспринимались как нечто порицаемое и наказуемое (но только со стороны ученика; поймать учителя на ошибке было делом рискованным). Это привело к тому, что я вырос со страхом ошибок. Как выяснилось со временем, моя проблема не уникальна: огромное количество моих друзей и знакомых тоже от неё страдают.
В командной работе ошибки случаются ещё чаще, чем в личной. Это происходит просто из-за сложности системы. Чем больше в системе элементов, тем выше вероятность, что что-то выйдет из строя (привет магистратуре по микроэлектронике). Точно так же и в человеческих системах: вероятность ошибки растёт с увеличением количества коммуникаций (здесь уместно вспомнить мой недавний пост про искажения информации).
⭐️ Никто не совершает ошибки специально
В этом году я усвоил для себя один крайне важный принцип: никто не совершает ошибки специально. Ошибка происходит, когда мы делаем нечто, не обладая знаниями или информацией о последствиях (то есть почти всегда). Зачастую мы даже не осознаём, что ошибаемся, пока не совершим какое-то действие.
Сразу оговорюсь, что если человек совершает "ошибку" преднамеренно, с полным пониманием ситуации, то это уже не ошибка, а саботаж.
Правильный подход к ошибке — проанализировать ситуацию, сделать выводы и двигаться дальше. Если в команде кто-то ошибся, нужно понять, где скрыто проблемное место, и постараться его устранить. Тогда ошибка принесёт всем пользу.
Две альтернативные стратегии могут показаться кому-то более привычными, но они наносят команде исключительно вред. Я говорю о наказании за ошибку и об игнорировании ошибок. Конечно, некоторые категории ошибок влекут за собой наказания. Однако эти категории и их последствия должны быть известны заранее, иначе процесс работы превращается в минное поле. Игнорирование же ошибок может привести к проблемам, которые уже невозможно будет игнорировать (попробуйте поигнорировать боль в зубах, например).
⭐️ Как работать над ошибками?
Для работы над ошибками лучше всего подходит написание и обсуждение post mortem. Изначально этим термином называлось вскрытие тела с целью установления причины смерти. В нашем случае вскрывать нужно ситуацию, чтобы установить причину её возникновения.
Строгой формы написания post mortem нет. Однако можно начать с ответов на несколько базовых вопросов:
➡️ "Что, где и когда произошло?" — ситуация в реальном мире.
➡️ "Какие последствия вызвало произошедшее?" — конкретные последствия.
➡️ "По какой причине возникла ошибка?" — причина (причины) произошедшего.
➡️ "Что мы сделали хорошо?" — какие действия команды положительно повлияли на устранение последствий.
➡️ "Что можно улучшить?" — чего не хватило в процессе работы.
➡️ "Какие шаги мы предпримем дальше?" — что конкретно сделаем, чтобы проблема не повторилась.
Post mortem крайне важно писать без оценок, фиксируя только объективные факты. Единственный оценочный вопрос — о том, что команда сделала хорошо.
После написания post mortem команде стоит обсудить его и, при необходимости, дополнить. На пункты из последнего вопроса нужно поставить задачи, назначить ответственных, а сам результат обсуждения сохранить на будущее.
Post mortem — прекрасный инструмент анализа ошибок. Он позволяет найти недочёты в процессах и сделать жизнь команды приятнее.
Никита Ульшин про IT | #management #post_mortem
В любой, даже самой простой системе, всегда есть пространство для ошибок. Ошибки случаются — и это просто факт, который нужно принять.
Сложнее всего относиться к ошибкам как к урокам, из которых можно сделать выводы. Когда я учился в школе, ошибки воспринимались как нечто порицаемое и наказуемое (но только со стороны ученика; поймать учителя на ошибке было делом рискованным). Это привело к тому, что я вырос со страхом ошибок. Как выяснилось со временем, моя проблема не уникальна: огромное количество моих друзей и знакомых тоже от неё страдают.
В командной работе ошибки случаются ещё чаще, чем в личной. Это происходит просто из-за сложности системы. Чем больше в системе элементов, тем выше вероятность, что что-то выйдет из строя (привет магистратуре по микроэлектронике). Точно так же и в человеческих системах: вероятность ошибки растёт с увеличением количества коммуникаций (здесь уместно вспомнить мой недавний пост про искажения информации).
В этом году я усвоил для себя один крайне важный принцип: никто не совершает ошибки специально. Ошибка происходит, когда мы делаем нечто, не обладая знаниями или информацией о последствиях (то есть почти всегда). Зачастую мы даже не осознаём, что ошибаемся, пока не совершим какое-то действие.
Сразу оговорюсь, что если человек совершает "ошибку" преднамеренно, с полным пониманием ситуации, то это уже не ошибка, а саботаж.
Правильный подход к ошибке — проанализировать ситуацию, сделать выводы и двигаться дальше. Если в команде кто-то ошибся, нужно понять, где скрыто проблемное место, и постараться его устранить. Тогда ошибка принесёт всем пользу.
Две альтернативные стратегии могут показаться кому-то более привычными, но они наносят команде исключительно вред. Я говорю о наказании за ошибку и об игнорировании ошибок. Конечно, некоторые категории ошибок влекут за собой наказания. Однако эти категории и их последствия должны быть известны заранее, иначе процесс работы превращается в минное поле. Игнорирование же ошибок может привести к проблемам, которые уже невозможно будет игнорировать (попробуйте поигнорировать боль в зубах, например).
Для работы над ошибками лучше всего подходит написание и обсуждение post mortem. Изначально этим термином называлось вскрытие тела с целью установления причины смерти. В нашем случае вскрывать нужно ситуацию, чтобы установить причину её возникновения.
Строгой формы написания post mortem нет. Однако можно начать с ответов на несколько базовых вопросов:
Post mortem крайне важно писать без оценок, фиксируя только объективные факты. Единственный оценочный вопрос — о том, что команда сделала хорошо.
После написания post mortem команде стоит обсудить его и, при необходимости, дополнить. На пункты из последнего вопроса нужно поставить задачи, назначить ответственных, а сам результат обсуждения сохранить на будущее.
Post mortem — прекрасный инструмент анализа ошибок. Он позволяет найти недочёты в процессах и сделать жизнь команды приятнее.
Никита Ульшин про IT | #management #post_mortem
Please open Telegram to view this post
VIEW IN TELEGRAM
Дополнительные материалы к докладу "Менторство как драйвер профессионального роста команды"
Скорее всего, прямо сейчас я выступаю с докладом на Frontend Night by Sber (или отвечаю на вопросы). В этом посте я собрал полезные ссылки и материалы, которые я использовал при подготовке доклада.
📕 Презентация
📎 Исследования, которые я использовал в докладе
🟡 Case Study: Workforce Analytics at Sun - оригинал исследования от Gartner, paywall
🟡 Sun Mentoring: 1996- 2009 - white paper о менторстве в Sun
🟡 CNBC|SurveyMonkey Workplace Happiness Index - исследование удовлетворённости работой от CNBC/SurveyMonkey
🟡 Nine in 10 workers who have a career mentor say they are happy in their jobs - анализ и выводы из этого исследования
🟡 Менторство в IT: 73% опытных специалистов становятся наставниками - исследование менторства от Хабр.Карьера
📎 Дополнительные материалы
🟡 Statistics on Mentorship: The Latest Research on Employee Development - сводка из нескольких исследований по менторству, довольно занимательные выводы
🟡 Seven Keys To Creating A High-Impact Mentoring Program - статья о том, как выстроить рабочее менторство, достаточно простая и понятная
🟡 How To Know If You'll Be A Great Mentor - отличный короткий гайдлайн по характеристикам крутых менторов. Пригодится руководителям для анализа потенциальных менторов.
🟡 Defining the Ideal Qualities of Mentorship: A Qualitative Analysis of the Characteristics of Outstanding Mentors - исследование качеств выдающихся менторов (я не изучал, лежит на будущее)
Спасибо всем, кто слушал доклад и задавал вопросы💛 Запись выложу, как только она будет доступна.
Никита Ульшин про IT | #публичные_выступления #доп_материалы
Скорее всего, прямо сейчас я выступаю с докладом на Frontend Night by Sber (или отвечаю на вопросы). В этом посте я собрал полезные ссылки и материалы, которые я использовал при подготовке доклада.
📕 Презентация
Спасибо всем, кто слушал доклад и задавал вопросы
Никита Ульшин про IT | #публичные_выступления #доп_материалы
Please open Telegram to view this post
VIEW IN TELEGRAM