Никита Ульшин про IT @ulshinblog Channel on Telegram

Никита Ульшин про IT

@ulshinblog


Программист и тимлид, более 10 лет в IT. Пишу про программирование, архитектуру, менеджмент и книжки.

По всем вопросам: @NikitaUlshin

Никита Ульшин про IT (Russian)

Вы любите программирование, архитектуру, менеджмент и книги? Тогда канал Никиты Ульшина, известного программиста и тимлида с более чем 10-летним опытом в IT индустрии, именно для вас! Здесь вы найдете полезные статьи и рекомендации по указанным темам, а также многое другое.

На канале "Никита Ульшин про IT" вы сможете узнать о последних трендах в мире программирования, изучить новые подходы к архитектуре программных решений, улучшить навыки в управлении проектами и получить рекомендации по интересным книгам из области IT.

Не упустите возможность быть в курсе самых актуальных событий в IT от профессионала своего дела! Присоединяйтесь к каналу уже сегодня и не забудьте задать ваши вопросы Никите Ульшину по контакту @NikitaUlshin.

Никита Ульшин про IT

20 Nov, 07:30


🎙️ 1-1 с Дашей Корчугановой. Встречи 1-1, которые работают

Невесел тимлид.
Ван он ван не любил проводить,
Команда ушла.


Что делают успешные тимлиды на встречах 1-1? Как эти встречи помогают не только команде, но и самому руководителю? В пилотном выпуске моего подкаста мы вместе с Дашей Корчугановой обсудили всё, что нужно знать о встречах 1-1: зачем они нужны, как их проводить, и когда лучше отказаться от регулярных 1-1.

Даша - руководитель команды разработки Газпромбанк Бизнес-Онлайн. Более 7-ми лет пишет фронтенд с любовью ❤️

О чём мы поговорили:
➡️ Зачем вообще нужно проводить 1-1?
➡️ Как регулярные 1-1 влияют на членов команды и команду в целом?
➡️ О чём говорить на 1-1, чтобы они не превращались в пустую формальность?
➡️ Что делать, если 1-1 провести надо, а сил нет?
➡️ Как перестать беспокоиться и начать проводить встречи 1-1 со своей командой?

Лично меня очень зацепила тема того, как давать корректирующую обратную связь на 1-1. Тема интересная настолько, что в будущем я бы хотел посвятить ей отдельный выпуск.

Запись уже доступна по ссылкам ниже. Слушайте, делитесь впечатлениями и рассказывайте, как вы проводите свои 1-1. Также я буду очень благодарен за любые пожелания и обратную связь как по форме, так и по содержанию проекта.

👀 YouTube
📹 Rutube
🎙 Аудио
🎵 Яндекс.Музыка

Никита Ульшин про IT | #oneonone #podcast

Никита Ульшин про IT

18 Nov, 07:30


Это не то, что я хотел

Вряд ли для кого-то будет новостью, что люди видят мир по-разному. Однако, начиная делегировать, это утверждение начинаешь воспринимать совершенно по-другому.

Я в своё время очень быстро выяснил, что сколько есть в мире людей — столько же существует способов решить одну и ту же задачу. Особенно острым это ощущение было, когда в результате работы человека получалось вовсе не то, что я себе представлял.

Что делать в такой ситуации? Человек работал, старался. Сказать ему, что он сделал что-то не то, — это обесценивание его труда. Более того, это было бы перекладыванием ответственности с себя на исполнителя. Цитируя одного футболиста: мои ожидания — это мои проблемы.

Делегирование ≠ снятие ответственности

Делегируя задачу, я передаю ответственность за её исполнение другому человеку, но ответственность за результат остаётся на мне. Всё, что должен сделать исполнитель, — это выполнить задачу так, как ему сказали. Так вот, если он сделал "не то, что было нужно", то это ошибка руководителя, который недостаточно ясно и конкретно объяснил, "что было нужно".

Моя ответственность как заказчика заключается в том, чтобы дать исполнителю максимально чёткие и понятные критерии выполнения задачи. В agile это называется definition of done (DoD) — критерии того, что задача считается завершённой. Исполнитель должен понимать, по каким признакам я буду судить о том, выполнена задача или нет. В противном случае открывается широкий простор для манипуляций и прокрастинации с обеих сторон.

Как формулировать DoD?

Для формулирования критериев приёмки задачи достаточно задать себе простой вопрос: "Как я пойму, что эта задача готова?" Затем просто запишите всё, что придёт в голову, и уберите лишнее. Постарайтесь, чтобы записи были максимально конкретными и наблюдаемыми со стороны. "Результат должен удовлетворять моё чувство прекрасного" — так себе критерий, потому что исполнителю будет сложно в него попасть.

Конечно, какие-то детали можно и нужно опускать. Не стоит в красках описывать каждую мелочь. В некоторых случаях DoD может быть даже расплывчатым (например, для R&D-задач я почти всегда ставил довольно абстрактный DoD). Однако тут важно понимать уровень самостоятельности и ответственности исполнителя. Для опытного Senior-специалиста задача с не самыми конкретными критериями может быть вполне приемлемой, а для джуна — смерти подобной.

DoD - это забота о себе и сотрудниках

Поначалу составление критериев приёмки задачи может показаться делом сложным, нудным и муторным. Заниматься этим лениво, и хотелось бы, чтобы люди сами обо всём догадывались. Только вот проблема в том, что телепатов не существует (привет, Нео). Если делать ставку на то, что люди сами всё поймут, то рано или поздно они критически не поймут, и это приведёт к беде.

Посмотрите на этот процесс с другой стороны. Руководитель, который ставит чёткие и понятные критерии выполнения задачи, в первую очередь заботится о своих сотрудниках. Исполнителям будет гораздо комфортнее выполнять конкретные, хорошо проработанные задачи с зафиксированным ожидаемым результатом, чем "пойди туда — не знаю куда, принеси то — не знаю что". Соответственно, у людей от такого подхода заметно снижается стресс и повышается продуктивность (привет, обезьянка Тима Урбана). Да и себе вы заметно упростите жизнь, потому что результат выполнения задачи будет проще оценивать.

В общем, позаботьтесь о своих исполнителях и сформулируйте для задач ожидаемый результат. Люди вам только спасибо скажут.

Никита Ульшин про IT | #management #agile

Никита Ульшин про IT

15 Nov, 06:01


Делаем крутой онбординг одной левой

Я обожаю делать жизнь своего окружения счастливее, и оно отвечает мне тем же. Меня зовут Женя и это гостевой пост от автора канала Счастливый тимлид.

Одной из моих сильный сторон я считаю умение проектировать эффективные процессы. А среди этих процессов у меня особенно хорошо получается делать классный онбординг. И на примере моего опыта хочу поделиться с вами секретиками, которые легко внедрить и сразу получить результат.

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

Первым делом пришлось протюнить этап выдачи компьютера и доступов. Я прописал регламенты, по которым фронтендерам выдавали конкретную модель ноутбука в комплекте с настроенными учетными записями ко всем нужным контурам. На этом этапе закрыли момент, когда человек выходит на работу и после подписания документов чего-то ждет и не может ничего делать. Нечего ждать, вперед знакомиться!

После знакомства с HR кандидат, точнее уже новый сотрудник, попадал ко мне на вводную встречу. На ней мы еще раз знакомились, поздравляли друг друга с возможностью поработать вместе и я вручал ему ссылки на онбординг и подготовленные для него задачи.

Да, важно не в моменте придумывать что бы такого дать новичку, а заранее, за пару недель уже начать выискивать в беклоге простые мелкие, но важные задачи. На них новичок сможет не только познакомиться с кодом, и пройти весь путь от передвигания задачи в таск-трекере до деплоя на прод, но и сразу же почувствовать себя ценным для команды. Еще и на ретро можно будет его похвалить и поздравить с первым релизом.

У меня, кстати, рекорд по выводу фичи новичком от выхода его на работу, до деплоя на продакшен — четыре дня!

Чтобы новичок оперативно и вдумчиво прошел все этапы квеста, стоит поиграть с ним в игру: «Почини наш онбординг». Правила следующие: он должен пройти по каждому пункту и проверить что пункт имеет смысл, выполним, а ожидаемый результат соответствует действительности. А если что-то не так, то ему обязательно нужно этот пунктик исправить. За каждую найденную неточность или проблему стоит неистово новичка благодарить. Так и ему весело и приятно, и онбординг после каждого новичка становится всё более полным и актуальным. Я называю это «вечнозеленый онбординг». Надеюсь когда-то этот подход назовут в мою честь.

И финально. Никак нашему новичку не справиться без бадди! Обязательно назначаем нашему новичку друга дня, лучше каждый день нового, чтобы за неделю он смог познакомится со всей командой. Пусть обращается к нему по всем вопросам. Главное не забыть снять с этого сотрудника часть задач, чтобы он не агрился, что его отвлекают, а наоборот, со всем своим обаянием и душевной добротой делился ценными знаниями.

Вот вроде и всё. Внедряйте советы в свои онбординги, и приходите в мой канал за новыми постами. Там, кстати, Никита свой пост про онбординг опубликовал.

© Счастливый тимлид

Никита Ульшин про IT

14 Nov, 07:30


Закулисье IT: честный взгляд изнутри на управление продуктами, проектами и командами

Менеджмент продуктов и руководство в IT — сложный процесс, о котором известно не так много. На канале «Кем я хочу стать когда вырасту» автор рассказывает о развитии продуктов, продакт-менеджеров и работе руководителя.

Что стоит прочитать в первую очередь:
• От чего на самом деле зависит успех в IT
• Стоит ли стремиться в руководители на самом деле?
• Почему на рынке так много слабых продуктов

Все посты основаны на личном опыте более 10 лет в роли тимлида и руководителя.

Подписывайтесь на канал, чтобы погрузиться в реальный мир IT без розовых очков.

ИП Миронова Надежда Олеговна, ИНН: 772985604739 erid:2VtzqvcjYxE

Никита Ульшин про IT

13 Nov, 07:30


🎙 1-1 с Дашей Корчугановой. Встречи 1-1, которые работают

🗓 15 ноября в 19:00
🔗 Ссылку опубликую перед эфиром

Невесел тимлид.
Ван он ван не любил проводить,
Команда ушла.


Я регулярно общаюсь с коллегами по цеху на разные интересные темы, и частенько в ходе таких разговоров рождаются крутые идеи и инсайты. А ещё эти разговоры приносят мне море удовольствия.

Недавно я понял, что хочу вынести хотя бы часть таких разговоров во внешний мир, чтобы другие люди тоже могли послушать и утащить себе ценные идеи. Поэтому я решил запустить новый проект - эфиры с крутыми ребятами из IT и не только на разные темы. Говорить будем про управление разработкой, людьми и собой.

Проект я решил назвать "1-1", потому что каждый такой эфир будет по сути встречей 1-1 с гостем на конкретную тему. Не спрашивайте, как я буду выкручиваться, если гостей будет несколько - сам не знаю 🙂 Будет прямая трансляция эфира с возможностью позадавать вопросы и конечно же запись через несколько дней.

Первый эфир будет посвящён проведению полезных встреч 1-1 с сотрудниками. Моим гостем будет Даша Корчуганова, руководитель команды разработки Газпромбанк Бизнес-Онлайн. Даша более 7-ми лет пишет фронтенд с любовью ❤️

Мы обсудим следующие темы:
➡️Зачем нужны 1-1 встречи и как они влияют на мотивацию и продуктивность.
➡️Как правильно структурировать 1-1, чтобы каждый участник ушёл с чётким пониманием своих целей.
➡️Как измерить эффективность 1-1 и понять, что они приносят реальную пользу.
➡️Когда регулярные 1-1 не нужны и можно освободить календарь для других задач.

Приходите, будет интересно и познавательно!

Никита Ульшин про IT| #oneonone #podcast

Никита Ульшин про IT

11 Nov, 07:30


Уроки орнитологии: менеджер-сорока

Продолжаем уроки увлекательной орнитологии. С чайка-менеджерами мы уже разобрались в предыдущих постах, однако есть ещё один тип птичек среди управленцев. Это сорока-менеджеры.

Что мы знаем о сороках? Они хватают всё блестящее и тащат к себе. Точно так же поступают и некоторые управленцы. Нашёл какую-то интересную идею/методологию/подход? Надо срочно её затащить в команду и нанести всем вокруг непоправимую пользу!

🔄 Кто виноват

Причины такого поведения могут быть разными. Одни менеджеры просто горят желанием добиться успеха и хотят сделать всё как можно лучше. Другие страдают от перфекционизма и синдрома самозванца. А однажды я своими глазами видел человека, который считал себя самым умным и всеми силами стремился это доказать.

Сам по себе подход постоянного обучения и поиск точек роста — это замечательно. Однако в абсолют всё возводят только ситхи, а люди вообще больше любят стабильность и предсказуемость. Поэтому изменения нужно внедрять постепенно, создавая команде умеренный дискомфорт. Работать в условиях, где всё меняется по сто раз в день, морально тяжело. Особенно в IT-сфере, где специалистам нужно иметь возможность спокойно и сосредоточенно выполнять свои задачи. Просто представьте себе работу, где у руководителя каждый день "гениальная новая идея, которую нужно срочно внедрить".

Если постоянно внедрять нововведения без явных причин, команда будет пребывать в растерянности. У людей сложится ощущение, что рабочие процессы сырые и их нужно постоянно исправлять, докручивать, улучшать. А дальше они легко могут перенести этот вывод на себя и свою работу: "команда работает плохо, меня уволят, ааааа".

🔄 Что делать

Затаскивание блестяшек в команду — не самая страшная "болезнь" на уровне тимлида, однако с ростом уровня последствия такого поведения гарантированно будут усиливаться. Вот как можно с этим бороться:

🟡Начать с "5 нахрена". Сосредоточьтесь на решаемой проблеме, а именно — действительно ли эта проблема мешает жить и стоит ли её решать. Иначе, в погоне за блестяшками, можно не заметить "проблемный рояль" в комнате.

🟡Обсуждать новые идеи с командой и собирать обратную связь. Люди могут как отвергнуть идею, так и предложить неожиданные варианты её адаптации под командные процессы. Такие идеи внедрять гораздо легче.

🟡Применять модели управления изменениями (например, ADKAR) для более плавного внедрения новшеств. Даже если вы уже приняли решение о внедрении — стоит сделать это мягко и аккуратно, не врываясь "с ноги" в рабочие процессы.

Сорока-менеджмент — это не плохо. Это признак того, что человек развивается в роли руководителя и ищет новые подходы к решению своих задач. Просто этот процесс нужно немного обуздать, и всё пойдёт как по маслу.

Сталкивались ли вы в своей работе с менеджерами-сороками?

Никита Ульшин про IT | #management #change_management

Никита Ульшин про IT

08 Nov, 07:30


🔖 Дэн Уиллингем "Учись как профи. 14 супернавыков, чтобы освоить все, что хочешь"

Лично я очень люблю учиться. Меня приводит в дикий восторг изучение чего-то новенького и увязывание этого с тем, что я уже знаю. Я настолько люблю учиться, что постоянно учусь учиться и ищу новые методы, как сделать этот процесс эффективнее.

Поэтому сегодня у меня в обзоре — прекраснейшая книжка Дэна Уиллингема "Учись как профи".

⭐️ О чём книга

Книга в основном предназначена для студентов, которым предстоит усваивать много материала по разным предметам, а затем сдавать контрольные работы, экзамены, практику и прочие стандартные для высшего образования задачи.

В книге раскрываются следующие темы:
➡️ Как работать на лекциях и практических занятиях, чтобы понимать как можно больше.
➡️ Ведение записей и работа с ними для усвоения материала.
➡️ Самостоятельное обучение по сложным книгам.
➡️ Экзамены: подготовка, сдача, пост-анализ.
➡️ Борьба с прокрастинацией при учёбе.
➡️ Ослабление тревоги перед экзаменами.
➡️ Дополнительно каждая тема рассматривается с точки зрения преподавателя: как облегчить учёбу и понимание своим студентам.

⭐️ 3 вывода из книги

🟡 Для понимания разрозненных элементов материала очень важно устанавливать между ними связи, будь то на лекции или при чтении книги. Полезно даже в своём конспекте рисовать и подписывать связи.

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

🟡Лучшая техника запоминания — это глубокое понимание самого материала и причинно-следственных связей в нём. Если дополнить понимание интересом, запоминание практически гарантировано.

⭐️ Мои впечатления

Как бы я хотел, чтобы эта книга попала ко мне в руки во времена университетской скамьи! Конечно, многие из этих вещей я хорошо прочувствовал на собственном опыте (ещё в школе домашка занимала от силы полчаса, потому что на уроках я разбирался в материале вместо написания огромных конспектов). Однако эта книга может стать настоящим сокровищем для школьников старших классов и студентов.

Уиллингем акцентирует внимание на том, что для запоминания материала лучше всего в нём хорошенько разобраться. Конечно, мнемотехники могут помочь в экстренных случаях (когда экзамен завтра), однако более эффективно — учиться вовремя и не доводить до такого.

Для взрослого человека книга несёт меньшую ценность, потому что нам не так часто нужно сдавать экзамены. Однако даже нам приходится периодически проходить различные тестирования на обучающих курсах, да и собеседования по программированию часто напоминают университетский экзамен с оценкой за формальные "галочки". Поэтому, на мой взгляд, в этой книге найдёт пользу каждый человек, которому приходится по работе изучать что-то новое.

Читали книгу? Как вам?

Никита Ульшин про IT | #обзор_книги #soft_skills #обучение

Никита Ульшин про IT

06 Nov, 07:30


Как перестать беспокоиться и начать делегировать

Тимлид, который пытается тянуть всю работу команды на себе, далеко не уедет. А, вероятнее всего, уедет лишь выгоревшим в отпуск. Именно этим чаще всего заканчивается первый опыт тимлидства.

Это нормально. Представьте вчерашнего технического специалиста, на которого внезапно свалилась огромная куча новых обязанностей: планирование, оценка, мотивация, переговоры. Первое, что обычно хочется делать в такой ситуации, — бегать по кругу и кричать: "Аааааа!"

Делегировать очень сложно. Когда я только начинал учиться делегированию, каждый раз испытывал дикий страх за конечный результат и превращался в микро-менеджера. Получалась довольно неприятная ситуация: вроде бы отдал задачу человеку, а сам его постоянно дёргаю. Нехорошо.

Лично мне на старте было сложнее всего именно отпустить контроль и довериться другому человеку. Постоянно казалось, что он сделает что-то не то или не так. Или сделает не так качественно, как сделал бы я сам. Или ещё что-то.

На самом деле, так оно и есть. Другой человек выполнит задачу по-другому. Результат может быть лучше или хуже, раньше или позже, чем если бы это делал я сам — но он гарантированно будет отличаться. Именно эта неопределённость конечного результата и вызывает страх. Но здесь скрыта большая ошибка: чаще всего даже я сам не знаю, каким получится конечный результат задачи, за которую берусь. Поэтому корень проблемы — в недоверии к другим людям.

Что делать в такой ситуации?
🟡 Честно и открыто сказать команде, что вы учитесь делегировать задачи. Попросите их сразу давать обратную связь: если вы чересчур скатываетесь в микро-менеджмент, лучше узнать об этом как можно раньше.

🟡 Договориться о промежуточных точках контроля результатов. Возможно, вам будет достаточно дейлика, но можно обсудить и дополнительные меры. Главное — прийти к соглашению с исполнителем, чтобы все эти ритуалы не стали для него неожиданностью.

🟡 Попытаться расслабиться и довериться людям. Это самая страшная часть, но стоит приложить усилия, чтобы не вмешиваться в работу и просто посмотреть на конечный результат. Вполне вероятно, что он вас приятно удивит.

🟡 Не забывайте благодарить и хвалить людей за проделанную работу и обратную связь. Это поможет им сохранять мотивацию для дальнейшей самостоятельной работы.

Я в своё время поступил кардинально: сказал команде, что страдаю микро-менеджментом, попросил честной обратной связи и просто дал людям делать свою работу. Поначалу было страшно, но через пару недель я осознал, что мир вокруг не рухнул и, вообще, дела обстоят достаточно неплохо. А члены команды в один голос заявили, что им гораздо больше нравится работать с таким уровнем самостоятельности и доверия.

А как у вас обстоят дела с делегированием? Какими способами вы учились доверять команде и избегать микро-менеджмента?

Никита Ульшин про IT | #management

Никита Ульшин про IT

04 Nov, 07:30


Как говорить о техдолге с бизнесом

Техдолг — это не просто технические задачи, которые можно откладывать до лучших времен. Он охватывает кучу разных проблем: от устаревших библиотек и «спорных» архитектурных решений до сложного в поддержке кода и ручного тестирования. Как результат, техдолг рано или поздно затрагивает не только команду, но и бизнес. И объяснять необходимость работы над ним нужно так, чтобы бизнес видел, как это влияет на его показатели.

🔄 Почему техдолг вообще проблема?

Основные последствия техдолга — замедление разработки и ухудшение клиентского опыта. И пока код свежий, проблема не видна, но с ростом и усложнением проектов техдолг начинает мешать. Задачи делаются дольше, чем хотелось бы, планы меняются из-за необходимости «причесать» старый код или отложить нужные изменения из-за устаревших решений. Это тратит время, а значит, бизнес теряет возможности быстрее выводить продукт на рынок.

И еще один момент — клиентский опыт. Чем больше техдолга, тем больше риска, что пользователи столкнутся с багами. Устранять их можно, но это тоже требует времени, и пока команда вносит правки, бизнес теряет доверие клиентов. Если техдолг мешает команде работать на полную, продукт в конце концов начинает терять в качестве.

🔄 Как перевести техдолг на язык бизнеса?

Чтобы техдолг был понятен бизнесу, его нужно связать с реальными метриками. Например, скорость выхода новой функциональности — это бизнес-показатель, который может сильно страдать из-за устаревших решений. Или рассмотрим покрытие тестами: если тестировщики завалены ручными проверками, автотесты помогут снять нагрузку и быстрее выпускать обновления. Метрики вроде количества багов, загрузки QA-команды и времени на релизы становятся отличным аргументом.

Например, однажды в нашей команде тестирование стало узким местом, и это затормозило весь процесс. Команда быстро делала фичи, но их не удавалось оперативно выпускать. Я договорился с руководством, что разработчики помогут разгрузить тестировщиков автотестами, чтобы ускорить процесс. Результат не заставил себя ждать: критичные сценарии покрыли автотестами, QA стало проще управлять задачами, и скорость релизов выросла. Для бизнеса это стало заметно, потому что мы смогли быстрее доносить улучшения до клиентов.

🔄 Что важно помнить, разговаривая о техдолге

Главное здесь — избегать узкотехнических объяснений и говорить через знакомые метрики. К примеру, обсуждая тестовое покрытие, можно сосредоточиться на экономии времени и увеличении пропускной способности команды. Техдолг — это не просто про код. Это возможность для бизнеса быть гибким и быстрым. Вложение в работу над ним — это вложение в устойчивость и конкурентоспособность команды.

А как вы объясняете важность работы с техдолгом руководству?

Никита Ульшин про IT | #management #tech_debt

Никита Ульшин про IT

02 Nov, 12:01


Как я выжил при Иване Грозном. Гид для путешественников во времени

На одном из моих любимых исторических каналов "Файб" вышла просто невероятная по сложности и интересности работа - "Как я выжил при Иване Грозном".

Команда провела целое исследование быта и особенностей той эпохи, и превратила его в документальный фильм. Вы узнаете, как жили люди 450 лет назад и что ждало бы современного жителя России, попади он в ту эпоху. Также авторы предлагают целый гид о том, как не окончить своё путешествие во времени печальной участью в первый же день.

Всю неделю мы с женой по вечерам после работы по чуть-чуть смотрели этот шедевр. Эх, если бы мне в школе так историю рассказывали, то я бы может и даты получше запоминал...

Приятного просмотра!

Никита Ульшин про IT | #culture #history

Никита Ульшин про IT

01 Nov, 08:01


🔖 Маршалл Розенберг, "Ненасильственное общение"

Огромная часть работы менеджера — это общение. Но общение может быть очень разным и оставлять после себя целый спектр ощущений. Как же выстроить продуктивное и здоровое общение?

На эту тему написано множество книг, что лишь подтверждает её актуальность. Сегодня я расскажу про одну из таких книг — Ненасильственное общение Маршалла Розенберга.

⭐️ О чём книга

Маршалл Розенберг в своей книге предлагает модель ненасильственного общения, которая позволяет выстроить эмпатичное, доброжелательное, основанное на взаимопонимании общение.

В книге раскрываются следующие темы:
➡️ Что такое ненасильственное общение и чем оно отличается от обычного общения.
➡️ Какое общение мешает сопереживанию и эмпатии.
➡️ Наблюдение за другими без оценивания.
➡️ Принятие ответственности за свои чувства, их осознание и выражение.
➡️ Как здоровым образом выражать свои просьбы.
➡️ Эмпатия и её сила в общении.
➡️ Как конструктивно выражать гнев.
➡️ Разрешение конфликтов с применением ННО.

Для меня все эти вопросы были крайне актуальны, и книга дала достаточно хорошие, подробные ответы на них.

⭐️ Топ-3 вывода из книги

🟡 За любым словом, действием или эмоцией человека всегда стоит неудовлетворённая потребность. Переводя разговор на уровень потребностей, мы получаем возможность помочь человеку.

🟡Осуждение, оценки, сравнения и тому подобные вещи мешают установке контакта и сопереживанию между людьми.

🟡Каждый человек сам несёт ответственность за свои чувства, мысли и действия.

⭐️ Мои впечатления

Прочитал я книгу быстро, а вот переваривал несколько месяцев — настолько насыщенной она мне показалась. Я написал по ней около 20 заметок и до сих пор обдумываю некоторые из прочитанных концепций.

Книга очень полезная и практико-применимая, но применять её довольно непросто. Пока читаешь — всё в целом понятно, кажется простым и очевидным. Но на практике сразу же возникают вопросы, сложности, недопонимания. Я начал применять прочитанное в книге практически сразу и постоянно сталкивался с тем, что не понимаю, как правильно поступить в той или иной ситуации. Самый большой эффект дали именно сами попытки применять — я начал задумываться о своих эмоциях, мыслях и потребностях, а через некоторое время смог переносить это на других людей.

Особенно ценными для меня оказались главы про эмпатию, просьбы и проживание гнева. Я получил идеи для улучшения по каждому из этих пунктов — особенно про осознание и проживание гнева (иногда страдаю от раздражительности).

Я очень рекомендую прочитать и попытаться применить эту книгу всем руководителям, потому что навыки ненасильственного общения мне кажутся крайне полезными в ежедневной работе. Лично я проникся техниками ННО и регулярно применяю их в жизни. Получается по-разному, но результаты мне нравятся.

Читали книгу? Как вам?

Никита Ульшин про IT | #обзор_книги #менеджмент #soft_skills

Никита Ульшин про IT

30 Oct, 09:32


Тимлид или чайка-менеджер? Управление без лишнего контроля

Знаете золотое правило инженеров? Работает — не трогай. Оно вполне применимо и для тимлидов: не стоит постоянно дёргать членов команды, если они заняты делом.

Почти у каждого моего знакомого из сферы IT есть история о том, как всё шло хорошо до появления белоснежных перьев на горизонте. Да, я говорю о чайка-менеджменте — управлении в стиле "прилетел, поорал, всё вокруг обгадил, улетел".

К сожалению, эта проблема распространена не только среди новичков. Ей страдают и опытные руководители, которые уже не первый год управляют (а в худшем случае ещё и повышение получили). Чайка-менеджмент обычно вызван страхом отпустить бразды контроля команды. Человеку кажется, что если он расслабится и перестанет всё вокруг контролировать, то работа непременно полетит в тартарары, проект провалится, и всех уволят.

Что уж греха таить, я и сам страдал от чайка-менеджмента в начале своего управленческого пути. Мне казалось, что я делаю благое дело — постоянно нахожусь в курсе всех задач, всё контролирую, всё знаю и лихо жонглирую приоритетами. Спасибо моей дорогой команде, которая честно и откровенно рассказала мне, как же я их задолбал своим микро-контролем.

По моим наблюдениям, чайка-менеджер обычно просыпается внутри руководителя в двух ситуациях:

🔄 Всё хорошо, команда работает: "Ааа, я ничего не делаю, тимлид не нужен, меня уволят!"
🔄 Всё плохо, что-то идёт не так: "Ааа, всё пропало, меня уволят!"

Понятное дело, что шкала не бинарная и включение режима чайки у всех происходит при разном уровне стресса. Проблема в том, что это ни к чему не ведёт. Менеджер-чайка искренне убеждён, что наносит своей команде непоправимую пользу, но это не так. Единственный выгодоприобретатель у такого поведения — сам менеджер, а точнее его чувство безопасности. Но от этого страдает качество работы и жизни всей команды.

Когда у команды всё хорошо, то лучше всего заняться "смазкой" механизма работы — собрать обратную связь, пересмотреть процессы, поработать над планами и целями. Чайка-менеджер выбирает тактику "летать и орать", имитируя бурную деятельность. В итоге командные процессы развиваются слабо или вообще стагнируют, а рано или поздно наступают сложности.

Когда что-то идёт не так, то чаще всего нужно довериться своей команде и просто дать ей исправить ситуацию, расчищая для неё путь. Но чайка-менеджер так не может, поэтому он продолжает "летать и орать", нагнетая обстановку и усиливая стресс. Члены команды нервничают, совершают больше ошибок, устают. В итоге проблемы устраняются дольше, качество работы страдает, а настроение команды падает до нуля.

Я не видел ни одной ситуации, когда чайка-менеджмент принёс хотя бы минимальную пользу. Более того, суета руководителя передаётся и всему коллективу. В итоге получаем низкопроизводительную, уставшую, демотивированную команду.

Что делать?

➡️ Учиться доверять людям и отпускать контроль. Для статус-чека у вас есть дейлики, где люди говорят о своих задачах и блокерах. Если к людям не приставать попусту, то они будут только благодарны.

➡️ Осознать свою роль в команде. Тимлид нужен в первую очередь для организации работы. Вместо постоянного контроля лучше заняться устранением блокеров и бутылочных горлышек команды.

➡️ Развивать доверие и командный дух. Людям должно быть комфортно и безопасно говорить о своих проблемах и затруднениях. Если их голос слышат, а проблемы помогают решить, то они не будут о них умалчивать. Это положительно скажется на всей команде.

➡️ Пользоваться услугами менторов и психотерапевтов, если совсем тревога не отпускает.

Избавиться от чайка-менеджмента непросто, но результат — лёгкость на душе, спокойствие команды, удовольствие от работы — стоит того.

Сталкивались ли вы с чайка-менеджерами в своей жизни? Или, может, сами были чайкой?

Никита Ульшин про IT

Никита Ульшин про IT

28 Oct, 07:45


Как работать с отказами систем в BFF: основные паттерны отказоустойчивости

Появилась запись моего доклада "Как работать с отказами систем в BFF: основные паттерны отказоустойчивости", с которым я выступал на A?.Frontend Day.

В докладе я рассказал про следующие темы:
🔄 Как проекты проходят путь от монолитного API к BFF и каковы плюсы/минусы его внедрения.
🔄 Что может пойти не так в дивном мире распределённых систем? (Спойлер: вообще что угодно.)
🔄 Паттерн Timeout (он же Deadline) и его применение для ограничения времени выполнения запросов.
🔄 Паттерн Retry и его применение для сглаживания разовых/краткосрочных сбоев.
🔄 Паттерн Circuit Breaker и его применение для защиты сбоящего сервиса от перегрузки.
🔄 Плюсы, минусы и особенности каждого паттерна, а также их влияние на UX.
🔄 Примеры реализации вышеперечисленных паттернов на TypeScript.

Дополнительные материалы к докладу доступны по ссылке.

Приятного просмотра!

#публичные_выступления

Никита Ульшин про IT

25 Oct, 08:30


Кэл Ньюпорт "В работу с головой"

Вопрос личной продуктивности всегда казался мне важным. Поэтому я стараюсь изучать всё адекватное, до чего могу дотянуться. Книги Кэла Ньюпорта мне рекомендовали многие, поэтому я и решил его почитать. Спойлер — ни капли не пожалел.

О чём книга

В книге рассказывается о глубокой работе — процессе, когда человек занимается только важными для него задачами и не отвлекается на внешние раздражители. Ньюпорт считает, что самые важные и ценные достижения возможны именно в результате глубокой работы.

По его мнению, глубокая работа настолько значима, что ради неё стоит отбросить всё малозначительное (Ньюпорт называет глубокую работу ключевым навыком XXI века). Фактически он предлагает планировать своё время вокруг состояния максимальной концентрации. Даже отдых, по его мнению, должен быть таким, чтобы способствовать восстановлению для дальнейшей глубокой работы.

В качестве примеров Ньюпорт приводит известных личностей: Карла Густава Юнга, Дональда Кнута, Адама Гранта. Также он много рассказывает о своём опыте глубокой работы и её влиянии на его жизнь и достижения.

Три вывода из книги

➡️ Глубокая работа — это работа в состоянии максимальной концентрации над важными задачами. В процессе глубокой работы растёт мастерство, и создаются значимые результаты.

➡️ Глубокая работа настолько важна, что имеет смысл планировать весь день вокруг неё (особенно учитывая, что много такой работы в день не сделать).

➡️ Основой глубокой работы является навык концентрации, который можно развивать с помощью медитации и глубокой работы. Концентрацию ослабляют отвлечения и развлечения: соцсети, чаты и прочие "залипалки".

Мои впечатления

Книга мне очень понравилась, потому что мой опыт перекликается с тем, о чём говорит Кэл Ньюпорт. Самые сложные и интересные вещи в своей жизни я создавал в состоянии максимальной концентрации, не отвлекаясь на посторонние раздражители. Более того, мне знакомо чувство удовлетворения после сеанса сконцентрированной работы.

Помимо самой концепции и её доказательств, Ньюпорт предлагает несколько способов увеличить количество глубокой работы в жизни. Он идёт от примеров конкретных людей к техникам, что позволяет читателю выбрать подходящие идеи для реализации.

Также Ньюпорт затрагивает тему отдыха. Работа в состоянии высокой концентрации — энергозатратное занятие, поэтому восстановление становится особенно важным.

На выходе из книги складывается цельная картина: появляется понимание того, что такое глубокая работа, как её планировать и интегрировать в свою жизнь. Я ушёл с большим количеством идей и потенциальных экспериментов, а многие из них пробовал реализовать прямо по ходу чтения. Результаты получились очень интересные.

Книгу настоятельно рекомендую всем, кто в конце дня чувствует, что "занимался какой-то ерундой" или "опять ничего не сделал". Мне она помогла вернуть контроль над своим временем.

#обзор_книги

Никита Ульшин про IT

23 Oct, 08:16


Иду в гости к Двум Иванам

Друзья, сегодня небольшой анонс. Два Ивана позвали меня к себе в подкаст гостем. Подкаст ведут Иван Елфимов и Иван Чернов - опытные инженеры из Ostrovok.ru. Ребята обсуждают разные интересные темы из мира IT: от языков программирования до архитектуры распределённых систем.

Мы поговорим о тимлидстве, эффективности и тому подобных интересных вещах. По этому поводу завтра в 13:00 будет трансляция с записи. Иваны уже подготовили для меня несколько каверзных вопросов, а я приглашаю вас зайти на трансляцию и поспрашивать то, что вам будет интересно. Или же оставляйте свои вопросы в комментариях к посту.

Запись конечно же будет :) До встречи!

Никита Ульшин про IT

21 Oct, 08:23


Как бесплатно повысить мотивацию членов команды?

Одна из вещей, с которыми тимлид должен работать, — это мотивация членов команды. Но мотивация — штука сложная, её не получится накачать насосом, как воздушный шарик. Она состоит из множества факторов, и ещё большее количество факторов на неё влияет.

Конечно, базовые факторы мотивации на работе — это достойная оплата труда и комфортные рабочие условия. Если человек откровенно недополучает денег или тратит по два часа каждый день на дорогу до работы в одну сторону, то никакие печеньки на кухне и "дружный коллектив" не помогут. Но давайте предположим, что эти моменты закрыты, и у членов команды всё в целом хорошо. Тогда уже в бой вступают альтернативные факторы мотивации.

Пример — свобода выбора и признание профессионализма. Каждый специалист хочет ощущать, что он на что-то влияет и волен выбирать, а также что его уважают и ценят как профессионала. Можно помочь человеку сформировать эти ощущения как словом (обратная связь на 1:1), так и делом. И давайте к делу.

Идеальные команды с идеально выстроенными процессами существуют только в идеальном вакууме (которого, кстати, тоже в природе не существует). Всегда есть какие-то шероховатости и несостыковки: то процессы за бизнесом не успевают, то техдолг накопился, то людей стало много, и тимлид захлёбывается. В любой команде всегда есть пространство для улучшений.

Почему бы не направить энергию сотрудников в русло этих улучшений? Если на 1:1 спросить у человека, что, по его мнению, можно сделать, чтобы команде жилось легче и приятнее, — он будет только рад поделиться своими идеями.

Здесь кроется первый подвох: если человек из раза в раз делится своими идеями, но ничего не меняется, то его мотивация будет угасать. Зачем генерировать идеи, если они не находят применения? Творческая энергия угасает, глаза тухнут, всё грустно.

Важно не упустить этот момент и задать следующий вопрос: какие из этих идей человек сам хотел бы реализовать? Обычно в этот момент у сотрудника начинают гореть не только глаза, но и руки "чешутся". Тут уже имеет смысл переходить к постановке конкретных задач, планированию и тому подобным вещам.

Если дать сотруднику возможность свободно выразить свои идеи и внедрить их в жизнь, это даст ему ощущение свободы действий (можно предлагать идеи без опаски) и уважения как профессионала (мои идеи принимают, меня благодарят за их реализацию). Следующие идеи сотрудник будет предлагать с большим энтузиазмом — ещё бы, ведь предыдущие приняли и дали реализовать. Более того, хороший пример заразителен, и члены команды могут начать наперебой предлагать интересные и креативные вещи.

В моей практике были следующие примеры:

- Тестировщица прошла курсы по UX и исправила множество недочётов в продукте.
- Бэкендер залез в автотесты, распараллелил их и ускорил прохождение джоба в три раза.
- Аналитик начал проводить потрясающие ретроспективы для команды.

Самое интересное, что люди занимались этим с радостью и удовольствием. И вдвойне приятно им было получать похвалу и благодарность за результаты проделанной работы. А ещё такие задачи отлично ложатся в постановку целей. Фидбек от ребят тоже был крайне положительным.

Конечно, не всегда всё получается так гладко, и иногда люди просто не хотят делать что-то дополнительно. Это их право, не нужно навязывать работу. Возможно, со временем их замотивирует пример других членов команды (у меня такое было пару раз).

Также не все эксперименты будут удачными. Это тоже не повод расстраиваться, потому что невозможно заранее знать, что получится. На мой взгляд, важно сделать быстрый тест гипотезы и подумать над полученными результатами. Чем больше таких итераций будет сделано, тем выше вероятность получить классный итог.

#management

Никита Ульшин про IT

18 Oct, 08:28


Что делать, если эмоциональный диапазон как у зубочистки? Обзор книги Дэниела Гоулмана "Эмоциональный интеллект"

Эту книгу я прочитал пару месяцев назад и спешу поделиться с вами выводами и инсайтами.

О чём книга

Книга рассказывает о таком понятии, как "эмоциональный интеллект". Вкратце его можно определить как способность понимать и осознавать свои эмоции и эмоции других людей. "Интеллект" мне кажется слишком громким словом в этом контексте, я бы скорее заменил термин автора на "эмоциональную осознанность".

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

Топ-3 вывода из книги

👉 Эмоции — корень всего, что происходит у нас в голове. Эмоции порождают мысли, мысли порождают действия.
👉 По уровню базовой эмоциональной осознанности мы всё ещё пещерные люди. Многие наши автоматические эмоциональные реакции когда-то были залогом выживания, но в современном мире могут сильно мешать жить.
👉 Эмоциональный интеллект можно и нужно развивать. На помощь придут практики осознанности, психотерапия и ведение дневника.

Мои впечатления

Тема эмоционального интеллекта мне, как руководителю, кажется крайне важной. Мы, люди, не роботы. Отбрасывая эмоции в общении с коллегами и подчинёнными, можно совершить кучу грубых ошибок и испортить отношения. Наверняка каждый из нас может вспомнить ситуации, когда его чувства проигнорировали. Как ощущения были?

Эмоциональную осознанность нужно развивать, чтобы не повторять подобных ситуаций самому. Эмпатия к другим начинается с умения понять и принять свои собственные чувства. Если человек болеет, стоит отнестись к нему с пониманием, а не давить на него срочными и горящими задачами.

По содержанию книга, конечно, далека от идеала. Лично мне она показалась довольно однобокой, поверхностной и переполненной "историями успеха", как типичный "бестселлер Амазон". Плюс мне не очень понравилось, что Гоулман в первой же главе аргументирует недоказанной теорией "эмоционального мозга". Но на общую картину это не влияет.

Также меня не покидало ощущение, что Гоулман откровенно пытается хайпануть на сравнении эмоционального интеллекта с IQ — это ещё в названии книги легко заметить. Проблема в том, что сам по себе IQ особо ничего не показывает, что уже многократно было доказано. Поэтому автор, по сути, спекулирует на сравнении своей теории с не самым показательным тестом интеллекта.

В целом книга ничего особенно нового не приносит и является компиляцией других, более серьёзных трудов (список литературы в конце — просто загляденье). Если вы не очень хорошо разбираетесь в том, что такое эмоции и как с ними вообще жить, книжка поможет погрузиться в этот увлекательный мир. В противном случае рекомендую взять что-нибудь посерьёзнее. Пример такой книги — в следующем обзоре.

#обзор_книги #management #психология

Никита Ульшин про IT

16 Oct, 08:30


SQL миграции в Postgres

Так уж вышло, что последние три месяца моя команда пилит runbook по шардированию красивых и толстых Postgres-ов. Мы узнали много всего интересного (в том числе и о себе местами), а в ходе этого приключения нам пришлось перелопатить уйму материалов по шардированию.

Любой более-менее опытный разработчик умеет работать с миграциями базы. Казалось бы, чего там сложного - написал скрипт и поехали (и поломали обратную совместимость). Но на самом деле миграции полны тонкостей и нюансов, которые начинают стрелять в ногу на больших объёмах данных.

Сегодня я хочу поделиться двумя бесподобными статьями про особенности миграций в больших Postgres.

https://habr.com/ru/articles/540500/
https://habr.com/ru/articles/736458/

Первая часть посвящена достаточно простым миграциям, а вторая - более сложным вариантам типа разделения таблицы. Крайне рекомендую к ознакомлению всем работающим с Postgres, почерпнёте для себя много интересного.

Никита Ульшин про IT

14 Oct, 07:36


Простой процесс постоянного роста

Я довольно активно занимаюсь менторингом как внутри компании, так и вне её. И в пятницу ко мне на менторинг пришёл коллега с очень интересным запросом: хочу развиваться в сторону техлида/архитектора.

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

Сосредоточились мы именно на "делать".

Как люди вообще становятся техлидами? Я в своей жизни занимал эту роль несколько раз, и процесс был практически идентичным: мне что-то не нравится, я предлагаю альтернативу, получаю добро на её реализацию и делаю. В какой-то момент оказывается, что я — техлид.

Из своего опыта я вынес, что все результаты появляются благодаря хорошо организованному процессу. В данном случае процесс довольно прост:

1. Найти точки, где что-то можно улучшить.
2. Предложить свои решения этих проблем тимлиду и команде.
3. Получить обратную связь и доработать свои предложения.
4. Реализовать улучшения.
5. GOTO 1

В самом процессе нет ничего сложного, но есть нюанс. Настоящую пользу он приносит, только функционируя постоянно. Да, даже разовые улучшения сделают жизнь команды чуть приятнее и прокачают автора изменений. Но для систематического роста в плане навыков и результатов нужно постоянно искать потенциальные точки роста и стараться их реализовать. Это уже не просто процесс, а по сути майндсет постоянного улучшения (привет, Голдратт).

Конечно, такой процесс — не единственный фактор, влияющий на получение интересных позиций и ролей в команде. Но я считаю его фундаментальным, потому что без умения хорошо работать и приносить пользу команде дальнейший рост специалиста может оказаться вредным для окружающих.

С моим менти мы решили проделать следующее упражнение:

1. Составить список того, что, на его взгляд, можно улучшить в команде.
2. Для каждой проблемы описать негативное влияние на команду.
3. Предложить альтернативные решения.
4. Описать положительное влияние, стоимость и процесс внедрения каждого решения.
4.1 Принести это всё на ревью ко мне :)
5. Презентовать результаты тимлиду и собрать обратную связь.
6. Сделать улучшения.

Упражнение очень простое, но при этом довольно просветляющее. Главное — выделить себе время и место, чтобы никто не отвлекал. Я стараюсь это упражнение выполнять раз в неделю-две, чтобы находить свежие идеи по улучшению процессов команды.

#mentoring #management #growth

Никита Ульшин про IT

12 Oct, 07:48


⚠️ Практически 100% моих клиентов страдают ЭТИМ

Одни считают его обязательным атрибутом успеха в работе, другие – проклятием и болезнью.

Запись эфира на тему: «Перфекционизм в IT: как эмоциональный интеллект помогает справляться с желанием быть идеальным?» определённо будет полезна каждому из вас :)

Мой спикер – Никита Ульшин – руководитель команды разработки в Т-Банк, более 10 лет в IT, из них 5 лет – в управлении командами
с перфекционизмом прожил бок о бок много лет, и ему было, чем поделиться.

Мы обсудили, ПОЧЕМУ перфекционизм является частой проблемой в сфере IT, и ответили на ряд занимательных вопросов👇:

02:30 – стремиться сделать хорошо = перфекционизм?
Дьявол кроется в деталях: именно в этот момент перфекционизм обретает негативное трактование понятия
06:13 – лайфхак от Никиты, что делать, если всё-таки хочется «повылизывать» 😁
11:56 – откуда берётся желание достигать перфекционизма в работе и какие автоматические программы поведения этому способствуют?
16:54 – как методология Scrum помогает справляться с перфекционизмом?
18:00 – что именно стало самой первой таблеткой от перфекционизма у моего спикера? И еще парочку хитростей :)
23:10 – как ЭИ помогает использовать перфекционизм во благо и чем же можно заменить технику «битья морд» в порыве гнева (спойлер: это очень простая, но при этом эффективная техника быстрой самопомощи :)
36:13 – влияние перфекционизма на конфликты
38:53 – ЗДЕСЬ перфекционизм может помочь!
И вот такой мем под завершение нашего полезного эфира :)

Всем перфекционистам большой привет 🙂 и приятного просмотра!

1,218

subscribers

52

photos

2

videos