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

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

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

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

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

Не будем утомлять вас рассказами о ДМС, крутых офисах и других плюшках. Вот главное о том, почему тимлиды выбирают Т-Банк:

✔️Актуальный стек. Здесь следят за трендами и быстро внедряют новое.
✔️Вы окажетесь среди профессионалов, у которых можно многому научиться.
✔️Общение на «ты». Так проще.
✔️Здесь развивают комьюнити. Можно участвовать в митапах и подкастах.

Больше о вакансиях здесь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#management

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

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

О чём книга

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

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

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

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

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

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

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

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

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

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

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

SQL миграции в Postgres

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#mentoring #management #growth

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

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

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

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

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

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

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

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

Джеймс Стэньер "Карьера Software Engineering Manager"

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

Senior-инженеры часто думают, что переход в роль тимлида — это повышение. Но это скорее переход в абсолютно новую профессию, где вчерашний крутой разработчик вновь становится джуном. На этом пути всегда пригодятся учебные пособия, и "Карьера Software Engineering Manager" — одно из них.

О чём книга

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

Сама книга состоит из трёх больших частей.

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

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

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

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

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

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

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

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

Как перфекционизм мешает развиваться

На выходных я получил очередное напоминание о том, что перфекционизм вредит развитию навыков.

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

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

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

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

Эта ситуация напомнила мне историю годичной давности, когда преподавательница подталкивала меня (тогда ещё совсем новичка) не засиживаться на грувах. «Более-менее нормально получается — двигайся дальше».

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

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

P.S. Напоминаю, что сегодня в 18:00 буду на эфире у Елены Логачёвой, где мы поговорим про перфекционизм. Приходите и задавайте вопросы. До встречи!

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

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

Завтра в 18:00 по Москве я буду гостем на эфире Елены Логачевой, где мы обсудим эту непростую тему.

Елена Логачева - автор проекта «Эмоции успеха» и ментор IT-лидеров: переводит из мидлов в топы, развивая эмоциональный интеллект у людей с высоким IQ.
➡️ 9 лет работы старшим преподавателем в IT МВА ВШЭ
➡️ 10 лет управления HR-агентством, входившим в 5-ку лидеров, понимает HR задачи, стоящие перед топовыми IТ-компаниями, и знает, с каким проблемами в карьере сталкиваются IT-менеджеры.

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

Эфир будет на канале Елены, ссылку на подключение я выложу ближе к началу. Запись будет, но рекомендую подключаться вживую - так интереснее и вопросы можно будет позадавать. До встречи на эфире!

Хорошо работать важнее работы мечты

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

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

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

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

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

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

Есть у меня одна мини-«традиция». Раз в несколько лет я в очередной раз от кого-то слышу, как ему «взорвала мозг» какая-то из книг Виктора Пелевина и принимаю решение в очередной раз дать шанс этому автору.

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

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

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

В этот раз я бросил на середине «Generation П». До встречи через несколько лет 😂

Читали Пелевина? Как вам?

#художественная_литература

Книги, по которым я прокачивал Go

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

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

📚 Михалис Цукалос, "Golang для профи"

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

Скажу честно, мне не очень понравилось. Книга слабо структурирована, некоторые советы сомнительны. Но при этом в ней много интересных особенностей Go и лайфхаков. Всё это подкреплено примерами кода, которые можно запустить и посмотреть в деле.

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

📚 Джон Боднер, "Go. Идиомы и паттерны проектирования"

Книга Боднера мне понравилась гораздо больше. По сути, это углублённое руководство для новичков по Go. Автор рассматривает все базовые темы, но дополняет их особенностями и нюансами языка Go. Например, в главе про конкурентность Боднер объясняет, в каких случаях следует применять те или иные примитивы синхронизации.

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

Если бы я сейчас начинал изучать Go с нуля, я бы порекомендовал пройти A Tour Of Go и дополнить его книгой Боднера. Такая связка даст очень хорошую базу для изучения языка.

📚 Тейва Харшани, "100 ошибок Go и как их избежать"

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

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

Рекомендую к прочтению, если вы разработчик уровня middle и выше, или если вы переходите на Go с другого языка программирования.

Полезные IT-каналы

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

Торбек | IT и около - канал про IT, жизнь и саморазвитие, часто поглядывает в сторону предпринимательства. Senior Frontend Developer в Сбер. Разрабатывает платформу партнёрских программ.

AShip++ канал о том, как строить успешную международную карьеру в IT, много полезного и мало воды от Анны Шипиль, Senior Backend Developer в крупнейшем немецком банке.

life in dev - изначально авторский дневник разработчика с большой мечтой, сейчас набор мыслей про жизнь в IT и все что около от Золотов Всеволод, Frontend Tech Lead, Спикер, ПСБ

Семён обо всём Нейросети в каждый дом - канал про разбор нейросеток, рекомендаций по внедрению и запуску «без регистрации и смс» от Мартюшов Семён, Исполнительный директор в платформе Байкал, Сбер.
Круг интересов: itsec, проектное управление, бигдата, data science, спорт.

The CTO - попытка дать другую точку зрения для ИТ-спецов на ИТ-отрасль (и не только): со стороны пользователей, бизнеса, HR и любых других. Без рекламы, анализа новостей, мнений экспертов. От директора проектного офиса Бюро 1440.

Большие проблемы маленьких изменений

Не так страшны первые 90% проекта, как вторые 90% проекта.

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

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

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

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

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

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

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

Что бы я посоветовал другу?

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

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

Помощь неожиданно пришла из книги Дэвида Бернса «Терапия беспокойства». Сама по себе книга прекрасная, и я очень рекомендую её к прочтению, если вы страдаете от тревоги. В ней описано множество техник, которые помогают справиться с тревогой. Одна из этих техник и помогла мне ослабить самокритику.

Техника называется «Что бы я посоветовал другу?». Суть её заключается в том, чтобы сменить точку зрения на проблему. Я рассматриваю ситуацию так, будто с ней ко мне обратился мой друг, и стараюсь ответить себе на вопрос: «Что бы я сказал ему в такой ситуации?»

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

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

#self_management

Как я провёл это субботнее утро

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

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

У Drumeo есть классное шоу, где приглашённые барабанщики должны подобрать партию к песне, которую они никогда раньше не слышали. При этом песню им включают без ударных, оригинальную партию они слышат только после того, как отыграют свою. Забавнее всего, что песня частенько оказывается довольно популярной. И сегодня этой песней оказалась Toxicity группы System Of A Down, которую я сейчас разучиваю.

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

Видео тут: https://www.youtube.com/watch?v=hyR5-b1wfrw

А чем вы с утра занимаетесь?

Грег Хорин "Управление проектами с нуля"

Совершая камбэк в роль тимлида, я решил освежить и систематизировать знания в области управления проектами. Мой выбор пал на книгу Грега Хорина "Управление проектами с нуля".

О чём книга

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

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

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

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

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

Пятая часть содержит главы, которые не показались мне слишком полезными: например, про использование Microsoft Project и подготовку к сертификации. Однако довольно интересными оказались главы про управление проектами в реальных условиях. Здесь, по сути, обсуждается ответ на вопрос: "Что делать, когда всё идёт не по плану?" (то есть примерно каждый день).

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

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

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

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

Отличная книга для тимлидов всех уровней — знания по управлению проектами ещё никому не вредили. :)

#management #book

Забор Честертона

Представьте, что вы идёте по цветущему ромашковому лугу и внезапно упираетесь в забор. Просто забор, без ограды или чего-либо ещё. "Что за ерунда?" — скорее всего, первое, что вы подумаете.

Наверняка у вас возникнут мысли о том, что забору здесь не место, и вообще, было бы неплохо его снести. Но это плохое решение, потому что вы не знаете назначения этого забора. В своё время по этому поводу удачно выразился Гилберт Честертон: «Никогда не ломайте забор, не узнав, зачем его поставили».

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

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

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