ИТ наизнанку | Владимир Ловцов
1.12K subscribers
122 photos
8 videos
1 file
88 links
Будни ИТ без «ванили».
Реальные истории, хаос и управление проектами.
Помогаю специалистам — от старта в ИТ до роста в лиды.
Консультирую компании — продукты под ключ, команды на максимум.

Ассистент для связи: @VMLovtsov_assistant
Download Telegram
У меня две позиции для мидл- и джун+ специалистов по направлению системный аналитик dwh и инженер данных, если есть желающие пишите мне в лс. @Vladimir_Lov
1
Что думаете?
Я что-то ушёл в дела с головой и забыл поздравить победителя, которому выпал билет на Merge, а тут уже билет новый появился, но уже на онлайн мероприятие от PodLodka)
🔥2
Forwarded from Tolik
Как сервисам взаимодействовать между собой надёжно, быстро и понятно?

REST, gRPC, события, контракты, версии — деталей много, а универсальных решений нет.

На онлайн-конференции Podlodka Techlead Crew (7–11 апреля) разберёмся, как выстраивать межсервисное взаимодействие: от проектирования API до публикации событий и сравнения протоколов.

В программе:

🎯 Event Storming + DDD: проектируем EDA правильно — Кирилл Ветчинкин расскажет, как выделять правильные события, избавляться от синхронных вызовов и строить событийно-ориентированные системы без боли

🔄 Обратная совместимость в парадигме specification-first — Сергей Константинов покажет, как поддерживать REST API и работать со спецификациями типа OpenAPI

🎙️Интервью: Проектируем API — contract first — Илья Зонов поделится, когда этот подход спасает, а когда мешает. И как версионировать API без боли

⚔️ gRPC vs RESTful: битва протоколов — Алексей Романов сравнит два подхода по 10 критериям

Готовы прокачаться?

Билеты здесь🎟

А по промокоду it_underside8 получите скидку в 500р🥳
👍2
Токсичность в IT. Как понять, что пора бежать?

Когда ты работаешь в айти-команде, иногда складывается ощущение, что дедлайны тебя преследуют даже во сне, а «звёздные» коллеги смотрят свысока, будто ты обязан преклониться перед их гениальным кодом и божественными постановки для разработки. А возможно, от одного вида чата с тимлидом у тебя поднимается давление, а весь проект держится на страхе и упрёках – добро пожаловать в мир токсичности. Верю, что у вас не так, но мне о таких командах травили байки и в таком объёме, что можно еженедельный подкаст начать писать.

1️⃣Как понять, что всё совсем плохо?
- Ты замечаешь постоянные уколы и подковёрные игры – будто главная задача команды не продукт сделать, а друг друга перемудрить.
- Люди ходят в офис/созвоны как на каторгу, а текучка кадров достигает оборотов, достойных сетевого маркетинга...
- Ошибся в коде? Готовься к коллективной порке. Никто не собирается разбираться, как помочь, зато «закидали помидорами» – это запросто.

2️⃣Почему это плохо?
Да потому что, помимо нервного тика, у тебя пропадает желание развиваться, учиться, да и просто общаться с этими людьми. А ещё страдает конечный продукт: ведь, когда все друг на друга бурчат, качество кода редко взлетает до небес.

Что делать, если токсичность проникла в твой проект?
1. Проговорить всё начистоту. Ретроспективы, one-on-one – в любой удобный момент подними проблему. Молчание только усугубляет ситуацию, будет расти как "гнойник"
2. Установить понятные правила игры. Если в команде нет общих ценностей и культуры общения, без паники – придумай их вместе с коллегами и реально соблюдайте.
3. Следить за лидерскими «суперспособностями». Если твоего тимлида (PO, PM без разницы кого) хлебом не корми – дай только покритиковать всех подряд, возможно, ему стоит напомнить, что железная рука – это не универсальное решение. Хотя это проще сказать, чем сделать и возможно тебя понесёт к следующему пункту, но помни, что если можно
4. Беречь себя. Если чёрная аура токсичности не развеивается, а HR только разводит руками, подумай, не пора ли сменить обстановку. Уйти иногда проще, чем тратить нервы и годы жизни.

Токсичная среда – штука противная и способна убить даже самую крутую идею. Будь начеку, отстаивай своё право на нормальное общение и помни: хороший командный дух важнее любой «горящей» фичи.

P.S. Ладно я был у таких токсиков, каких вы и не видели и ушёл оттуда через пару месяцев, не ушёл, а улетел как бешеный огурец))

@it_underside
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Ретроспектива?? Да это фигня и ненужная потеря времени!

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

1️⃣ Зачем это всё?
Ну, если без ретро, то так и будем каждый раз наступать на одни и те же грабли, а мозоль на лбу не украшается, даже если забрендировать его логотипом компании. Как руководителю, тебе важно:
- Услышать, что реально беспокоит команду (вдруг девопс всё ещё вручную сервера перезагружает?),
- Понять, как распределялась нагрузка и почему некоторым коллегам совсем «прилетало» в спринте, а другие спокойно пили чай,
- Получить пищу для размышлений: какие процессы пора менять или «закручивать гайки», а где лучше «расслабить булки».

2️⃣ Как настроить всех на нормальную волну
Сразу скажу: заставить команду говорить искренне и без страха – это отдельный квест с боссом в конце. Вот несколько лайфхаков:
- Прозрачно и понятно объяснить, зачем ретро нужно. Если люди думают, что это «бюрократическая обязаловка», никакой пользы не будет.
- Договориться, что на ретро нельзя ругаться «в лицо». То есть конструктив приветствуется, а вот превращать встречу в битву за правду – не вариант.
- Похвалить всех, кто не стесняется высказываться. Даже если кто-то понесёт околесицу, сам факт активности уже круто. С правильным подходом из «бреда» иногда рождаются шедевральные идеи.

3️⃣ Что всё равно останется за кадром
Как бы ты ни пытался, часть вещей сотрудники никогда не скажут прямо. Может, кто-то затаил обиду на своего коллегу из-за личных тараканов, а кто-то просто стесняется признаться, что не успевает учить новые технологии и «плавает» в коде. Бывает и так, что в команде есть негласный «авторитет», которого все побаиваются, и критиковать его вслух – табу.
Тут важно понимать: за одну ретроспективу ты всё не вытащишь, но, если проводить их регулярно и общаться с людьми в личных форматах (one-on-one, чатики), даже самые молчаливые рано или поздно раскроются. Или хотя бы намекнут, куда смотреть.

4️⃣ Главное – не забывать действовать
Если ретро превращается в «поговорили и разбежались», то доверие к процессу быстро уходит в ноль. Как руководителю, тебе нужно:
- Фиксировать итоги. Пусть будут четкие «экшн-пойнты» (из серии «добавить в pipeline новый шаг, чтобы тесты гонялись автоматически» или «собраться вне работы и поиграть в настолки, чтобы развеяться»).
- Назначать «ответственных» за эти действия. Без этого всё закончится в разделе «полезные идеи, которым не суждено сбыться».
- Устраивать «проверку» через спринт. Сработало? Не сработало? Почему? Исправляем.

5️⃣ Пара слов в конце
Ретроспектива – действительно мощный инструмент. Но только если её не превращать в ритуал «покаянной молитвы» или в «церемонию по затравливанию виноватого». Это про командное взросление, про исправление процессов и честность друг с другом. Естественно, какие-то обиды и недоговорённости всегда останутся, но твоя задача – свести их к минимуму и создать атмосферу, где люди не боятся признавать косяки и вместе их решать.

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


@it_underside
Please open Telegram to view this post
VIEW IN TELEGRAM
👍31
Когда впервые слышишь про Event Storming, в воображении может возникнуть ритуальный круг со стикерами вокруг доски. На деле это инструмент, который помогает вытащить из вашей системы все реальные события и понять, кто за что отвечает. А DDD задаёт логику и названия для этих событий, чтобы не плодить монстров вида «ItemCreatedButActuallyDeleted».

В чём суть?
В Event-Driven Architecture (EDA) микросервисы обмениваются событиями, а не гоняют запросы напрямую. Если забить на Event Storming и DDD, легко получить бардак из никому непонятных оповещений. Но если продумать доменные события и их связь, всё становится ясно: какой сервис что «выкрикивает» и как остальные реагируют.

Роль руководителя – не просто собрать народ у доски (реальная или виртуальная не важно), а следить, чтобы всё важное фиксировалось, и никто не увёл обсуждение в чаевые мелочи. Важно понять, как ваши события влияют на соседние сервисы и что делать, если вдруг в проде вылезло что-то типа «PaymentDoneButNotDone».

В итоге лучше потратить пару часов на «штурм стикерами», чем потом ловить хаос в логах и гадать, откуда взялись странные ивенты. Правильный подход к Event Storming, подкреплённый DDD, – залог того, что EDA будет радовать, а не сводить тебя с ума.

P.S. Частенько пренебрегаю, а потом думаю зря, в прошлый раз не воспользовался... Знаю да, а вот пользуюсь, не всегда)))

@it_underside
👍5
Когда тебе в голову приходит идея "Давайте проведём Event Storming", обычно слышишь два типа реакции: одни радостно готовят стикеры и маркеры, другие крутят пальцем у виска в стиле «опять эти ритуалы», поверили???? Т.е. реально у вас в команде все такие прошаренные и знают об этом? У меня за плечами не один "штурм событий", так что поделюсь личным опытом, чего хорошего и не очень вас может ждать.

💪📈Плюсы
1. Общее понимание домена.
Все, от разработчика до бизнес-аналитика, наконец-то начинают говорить на одном языке. Когда видишь события визуально, инсайты приходят даже к тем, кто до этого «молчал в тряпочку», те самые коллеги, которые не отсвечивают, но вспоминаешь о них, когда начинаются сборы не "др"
2. Выявление пробелов и конфликтов.
«А что происходит после того, как оплата прошла?» – «Э-э, не знаю…» Этот диалог лучше всплывёт на встрече, чем на продакшене.
3. Ускоряет командное взаимодействие.
У вас появляется общая доска с «картиной мира», и ребята охотнее обсуждают спорные места, потому что всё видно, как на ладони.
4. Повышение вовлечённости.
Кто любит бумажки, тот счастлив, что можно лепить стикеры. Кто ненавидит бумажки – вдруг понимает, что так идея «оцифровывается» быстрее, чем долгими разговорами.

😆😆Минусы
1. Затраты времени.
«Штурм событий» может занять пару часов, а то и целый день. Некоторые (особенно интровертные) разработчики могут предпочесть это время тратить на реальный код.
2. Риск увязнуть в деталях.
Если модератор не «рубит» бесполезные ветвления, сессия превращается в бесконечные дискуссии о названиях ивентов.
3. Нужен толковый фасилитатор.
Без активного ведущего можно получить хаос: кто-то будет «подминать» под себя, кто-то вообще молча прятаться.
4. Иллюзия завершённости.
Даже если вы всё круто расписали на доске, это лишь «снимок» ситуации. Процесс надо постоянно пересматривать, а не считать, что «всё, мы изучили ивенты навечно».

Итог, ну или как бы логическое умозаключение
Event Storming – мощный инструмент, который объединяет людей вокруг единого понимания системы. Но это не магия, которая решит все проблемы за пару часов стикеротерапии. Важно, чтобы у вас был человек, способный направлять обсуждение, и готовность затем поддерживать модель в актуальном состоянии. Зато, если подойти к делу с умом, вы избежите внезапных «белых пятен» в логике и улучшите командное взаимодействие.

P.S. Если после сессии кто-то приклеит себе на лоб стикер «PaymentFailed» – это нормально. Главное, чтобы он понимал, как этот ивент ведёт к «PaymentRetried» и «PaymentSucceeded».
Please open Telegram to view this post
VIEW IN TELEGRAM
👍32
Кажется я всё меньше и меньше затрагивают системный анализ, а если быть чесным, то на проектах перестал им заниматься, на смену этому пришло управление командами, управление продуктами и solution архитектура.... Даже на моих личных проектах не всегда дохожу да СА. Кажется это тот самый сдвиг, когда хочется ещё попроектировать и более глубоко проработать дизайн системы и каждого компонента, но чисто физически уже не хватает ресурсов. Из-за нехватки времени пришлось откзаться даже от выступления на Merge, хотя доклад и все нюансы проработаны😭.

К чему это?

А вообще я ищу сейчас себе помощника по курсам, т.к. есть риск получить "well-done"🥩. Если интересно, то обращайтесь в лс.

@Vladimir_lov
@it_underside
Please open Telegram to view this post
VIEW IN TELEGRAM
7👍3
С прошлого года стал управлять кластером разработки по банковским продуктам , со всеми вытекающими, и решил пересмотреть концепцию команд и вспомнить хорошую и давно забытую (у кого как, но на крайне сложных и сжатых по сроку проектах нужны эксперты и специалисты высокого уровня чаще всего) практику набора джунов, ну когда делают соотношения по сеньерности 1:2:4 или 1:3:9. И ... порой джуны удивляют скоростью и производительностью. Пример из текущей практики, человек ещё не знал ничего месяц назад, а сейчас уже пишет постановки (тз) на разработку и это впечатляет, а что ещё впечатляет, что такие молодые специалисты дают фору экспертам со стажем в пару десятков лет опыта. Не буду скрывать, что у нас хороший онбординг и т.п., но "Карл". О чём пост? Берите джунов, они вас ещё удивят😁
1👍4🔥2😁2🤗2
Есть заказчик, готов финансировать проект (если каждый член команды будет живой и готов двигаться, то будем вам классный проект и хорошая зп без бюрократической обвязки), проект представляет из себя разработку продукта для erp с множеством ai функций.

Кого ищу?

1. Data scientist (не нижу Middle+, а желательно senior)
2. Системный аналитик (не ниже middle)
3. Python разработчик (нужен хороший фуллстек, по уровню не ниже middle)

Если будет что ещё, буду писать)

P.S. а да, выключил комментарии, так как наплыв ботоподобных сущностей...
1😁3🔥2👍1
Знаете, ещё обидно, что накидал куча материала за 2 года в черновом виде для канала, но до которого не доходяд руки. Думал тут может повысить личную эффективность, даже джедайские техники пробовал и тестировал, но как то не дали они мне существенного изменения😀😀 то ли я 😐, то ли уже и так много знаю, ну знаете, сам себя не похвалишь, никто не сделает этого)))
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥3😁1
Всем привет, что-то лето началось раньше, чем хотелось, а именно с дачи и если вы спросите на кого или на что я променял кучу активностей, скажу честно, на дачу)))) постигаю совершенно новое для себя - молоток, лопату, кисть, ну и т.п.😀😀

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

Как книга? Введение и глава N°1- готовы, а остальное в процессе


Всем хорошего лета))) возможно буду реже писать, ну вы поняли, дача)
Please open Telegram to view this post
VIEW IN TELEGRAM
😁6🔥3
Если у кого есть желание поболтать и вы в Питере, пишите) а так я на конференции HighLoad)
🔥2
Вот всё так, попадание прям в точку
Forwarded from СофтТех
Джуны в минусе

По словам Андрея Тарасова, директора службы занятости населения Москвы и руководителя центра «Профессии будущего», IT — единственная отрасль в столице, где наблюдается снижение заработных плат.

Однако падение касается не всей отрасли, а только джунов. Если раньше стартовые позиции в среднем предлагали 70-80 тыс. руб., то сейчас это около 60 тыс. руб.

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

У тех, кто только «вкатывается в IT», есть два варианта: либо быстро прокачивать свои скиллы за скромные деньги или даже бесплатно, либо идти получать рабочие специальности и уже сейчас зарабатывать нормальные деньги📌

™️ СофтТех
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🤬1
🌞 Утро доброе, друзья!

Ну как у вас там дела? У кого-то уже день, а у кого-то ещё утро? 😭
Хотелось бы красиво заявить: «Из пепла восстану я!»
Но честнее будет: «Из земли вылез я… и рядом с кротом».

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

История такая....
В мае я купил участок в 18 соток с домом, который стоял заброшенный лет 10, а чтобы вы понимали масштаб трагедии: кусты смородины там выросли метра на четыре и явно пытались конкурировать с берёзами. Яблони слились в некий хаос, часть деревьев решила уйти на пенсию и сухо напомнила о своём возрасте, а местные жабы и мыши устроили коммуну без счёта за ЖКХ.

И тут я, ИТ-лидер, директор по управлению проектами, человек переговорок и диаграмм Ганта — внезапно оказался с лопатой и граблями. Скажу честно: сидячий образ жизни растворился где-то между грядками и газоном.

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

Причём это не только мой личный опыт. Есть исследования: работа на земле снижает уровень кортизола (того самого гормона стресса, который у нас подскакивает от дедлайнов), а контакт с почвой стимулирует выработку серотонина. То есть условно — перекопал грядку → получил дозу счастья. Бесплатно, без абонентки и багфиксов 💊.

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

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

Ваш ДПУП, распределяющий не только ресурсы в проектах, но и грядки @it_underside
Please open Telegram to view this post
VIEW IN TELEGRAM
18🔥6👍3❤‍🔥1👎1🤩1😍1
😎 бодрого утречка, коллеги!

Сегодня вы, как и я, проснулись и поняли: «У меня 24 часа, а задач — как на три рабочие недели»? Бюджеты, согласования, стратегические цели, развитие сотрудников… и обязательно кто‑то лажанулся, сорвал договорённости или просто забыл, что сегодня пятница, а не завтрашние дедлайны.

И вот что я понял: если у тебя нет плана A, Б и до Я — ты спалился🔥🔥🔥🔥. Особенно когда в твоих руках — сложный проект или портфель, например как у меня сейчас, по персональным клиентским предложениям для банка: десятки микросервисов, сложнейшая логика интеграционных взаимодействий, бешеные показатели..... И ты либо учишься делегировать, либо тебя “выносят вперёд ногами”.

Факты на твой менедж-уровень

💡Gallup проанализировал 143 CEOs из списка Inc. 500 и обнаружил, что те, у кого высокие навыки делегирования ("delegator talent"), генерируют на 33 % больше выручки и на 112 процентных пунктов быстрее растут за 3 года — по сравнению с теми, кто плохо делегирует - ссылка.

💡Harvard Business Review в последнем материале отмечает: часто лидеры знают, что нужно делегировать, но не понимают что именно и кому — ключевая ошибка большинства руководителей - ссылка.

Мой стиль делегирования — это не «свалить всё на кого-то», а:

✏️Стратегия и долгосрочные цели — мои.
✏️Операционные задачи и экспертиза — на заработавшую команду.
✏️Приоритеты — так расставлены, что даже если всё идёт по S-плану, проект всё равно едет, ну или как минимум ты так думаешь🐱

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

Немного стёба на десерт

🟢Делегировать — это не значит “скинуть задачу на разработчика”, это значит “распределить ответственность так, чтобы команда верила, что на неё равняется”.
🟢И да, иногда легче договориться с Kafka, чем с частью менеджеров. Но у тебя всегда есть резервный план (единорогов не хватает, поэтому плана Я 😉

Как итог

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

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

---
Ваш ДПУП (Директор по портфелю проектов, планам B–Z и нервным клеткам)
@it_underside
Please open Telegram to view this post
VIEW IN TELEGRAM
14🔥4🤝4👏1
Добрый вечер, коЛЛеги!

Сегодня день такой, что голова раскалывается…
И вроде бы хочется по-умному рассказать: «Команда должна быть сбалансированной, ответственность распределена, культура доверия и бла-бла-бла».

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

👉 Вот в чём правда: если у тебя работает один герой — у тебя не команда. У тебя хрупкая система, которая развалится при первом же сбое.

📊 Deloitte писали, что сбалансированные команды на 20% продуктивнее и на 30%,
а Harvard Business Review добавляют: большинство лидов умеют делегировать задачи, но забывают делегировать ответственность.

💡 Личный инсайт:
⚙️рутину надо делить на всех;
⚙️важные решения — тем, кто должен вырасти;
⚙️и всегда держать команду в логике «мы делаем вместе», а не «он нас спасает».

👉 Итого, делегирование спасает не только проекты, но и нервы руководителя, а если вы руководитель, спасите себя)

---

Ваш ДПУП (директор по портфелю проектов и бывший герой-одиночка с таблеткой от головы)
@it_underside
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5😁3🤝2