🚨 Инцидент SEV-1: топливная система под угрозой
🌅 Утро, ⛽ заправка, 🚙 два автомобиля в семье: один дизель, один бензин.
🧠 Высокая когнитивная нагрузка, отсутствие ☕ — и вот уже рука тянется не к тому пистолету.
⏰ 11:02 — запах топлива кажется странным.
⏰ 11:04 — внутренний «мониторинг» сигналит: это бензин.
⏰ 11:05 — 🤬 *ять! (Эмоции)
⏰ 11:06 — ✅ решение принято: двигатель не запускаем.
⏰ 11:07 — 📞 вызван ЭКСПЕРТА
⏰ 11:20 — 🔧 снять предохранитель на топливный насос
⏰ 12:30 — 💦 промывка топливного бака на месте
📊 Severity: SEV-1.
💸 Потенциальный ущерб: ремонт двигателя и downtime на недели.
💰 Фактический ущерб: 1,5 часа простоя и стоимость промывки (≈1% от worst-case).
🕵️ Root Cause Analysis
🔑 Root Cause: нарушение процедуры double-check перед заправкой.
➕ Contributing factors:
🚗 два автомобиля с разным типом топлива;
🌙 утро, 😴 усталость, отсутствие ☕;
🔄 схожесть пистолетов.
🛡️ Detection & Mitigation
👃🖐️ Detection: сенсорные «сигналы» (обоняние, тактильные ощущения) + внутреннее правило мониторинга.
🛑 Mitigation: двигатель не был запущен (операция остановлена до «деплоя»), 🚀 эскалация по заранее известному сценарию.
💻 Параллели с нашим миром.
🚀 Запустить двигатель = деплой уязвимого билда в прод.
↩️ Отмена запуска = pre-deployment rollback.
👨🔧 Эксперт + промывка = hotfix-процедура.
🏷️ Стикер «DIESEL ONLY» = pre-deploy checklist.
📌 Action Items
🏷️ Наклеить визуальную метку «DIESEL ONLY» на люк бака (до 25.08).
📋 Ввести «pre-fuel checklist» — аналог pre-deploy checklist (до 01.09).
👀 Подумать о дополнительных визуальных/тактильных сигнализаторах (до 15.09).
📚 Lesson Learned
Инцидент-менеджмент — это не про отсутствие ошибок.
Это про то, чтобы:
👀 Обнаруживать проблему до
того, как она превратится в катастрофу.
🧭 Реагировать по плану, а не в панике.
📖 Учиться на ошибках и обновлять правила.
❓ А у вас были «житейские инциденты», которые отлично легли на IT-практики?
🌅 Утро, ⛽ заправка, 🚙 два автомобиля в семье: один дизель, один бензин.
🧠 Высокая когнитивная нагрузка, отсутствие ☕ — и вот уже рука тянется не к тому пистолету.
⏰ 11:02 — запах топлива кажется странным.
⏰ 11:04 — внутренний «мониторинг» сигналит: это бензин.
⏰ 11:05 — 🤬 *ять! (Эмоции)
⏰ 11:06 — ✅ решение принято: двигатель не запускаем.
⏰ 11:07 — 📞 вызван ЭКСПЕРТА
⏰ 11:20 — 🔧 снять предохранитель на топливный насос
⏰ 12:30 — 💦 промывка топливного бака на месте
📊 Severity: SEV-1.
💸 Потенциальный ущерб: ремонт двигателя и downtime на недели.
💰 Фактический ущерб: 1,5 часа простоя и стоимость промывки (≈1% от worst-case).
🕵️ Root Cause Analysis
🔑 Root Cause: нарушение процедуры double-check перед заправкой.
➕ Contributing factors:
🚗 два автомобиля с разным типом топлива;
🌙 утро, 😴 усталость, отсутствие ☕;
🔄 схожесть пистолетов.
🛡️ Detection & Mitigation
👃🖐️ Detection: сенсорные «сигналы» (обоняние, тактильные ощущения) + внутреннее правило мониторинга.
🛑 Mitigation: двигатель не был запущен (операция остановлена до «деплоя»), 🚀 эскалация по заранее известному сценарию.
💻 Параллели с нашим миром.
🚀 Запустить двигатель = деплой уязвимого билда в прод.
↩️ Отмена запуска = pre-deployment rollback.
👨🔧 Эксперт + промывка = hotfix-процедура.
🏷️ Стикер «DIESEL ONLY» = pre-deploy checklist.
📌 Action Items
🏷️ Наклеить визуальную метку «DIESEL ONLY» на люк бака (до 25.08).
📋 Ввести «pre-fuel checklist» — аналог pre-deploy checklist (до 01.09).
👀 Подумать о дополнительных визуальных/тактильных сигнализаторах (до 15.09).
📚 Lesson Learned
Инцидент-менеджмент — это не про отсутствие ошибок.
Это про то, чтобы:
👀 Обнаруживать проблему до
того, как она превратится в катастрофу.
🧭 Реагировать по плану, а не в панике.
📖 Учиться на ошибках и обновлять правила.
❓ А у вас были «житейские инциденты», которые отлично легли на IT-практики?
❤11🔥7
За кулисами ПыхConf:
Вчера отыграл роль ведущего на ПыхConf и вернулся с абсолютно перепрошитым мозгом. Это был не просто ивент, а громкое заявление всего PHP-сообщества.
Организация — на высшем уровне, атмосфера — заряжающая.
Хочу выделить три ключевых инсайта, которые перевернули мое восприятие:
Сила сообщества — это фундамент. Огромное уважение каждому, кто создает эту экосистему: от разработчиков, которые день за днем пишут код на PHP, до контрибьюторов, которые безвозмездно улучшают ядро, фреймворки и инструменты. Вы — огромная сила, которая двигает технологии вперед.
Личный разрыв шаблона: Drupal. 15 лет назад я его «щупал», и у меня было одно, очень крепкое мнение на букву Г. Он казался неудобным и переусложненным.
Сейчас же я в шоке! Это совершенно другой инструмент. Мощный фреймворк для разработчиков с AI в коробке, комьюнити на миллионы и сотнями тысяч коммитов.
Я понял, что все эти годы судил по устаревшим впечатлениям. Это хрестоматийный пример эволюции. Всем, кто застрял в прошлом, как я — настоятельно рекомендую глянуть свежим взглядом.
Архитектурный инсайт:
Вселенная, где в центре — Событие.
Казалось, что я отлично знаю подход Event Sourcing; но один гениальный доклад всё перевернул.
Провели аналогию: раньше мы думали, что Вселенная крутится вокруг Земли (в коде это какая-то главная сущность). Чтобы описать процессы, приходилось городить сложную логику.
А потом Коперник переместил центр на Солнце — и орбиты стали простыми эллипсами.
Так вот, Событие (Event) — это новое Солнце.
Смотришь на это через призму «центра вселенной» — и мозг буквально взрывается. Задаёшь себе вопрос а что если центр вселенной не там. Тогда все играет другими красками. Начинаешь совершенно по-другому видеть архитектуру прошлых и текущих проектов. Кажется, что знал всё это и раньше, но такой ракурс меняет сознание.
Философский взгляд и пожалуй я готов к эксперементам.
ПыхConf — это именно про такие инсайты. Про то, как выглядит по-настоящему зрелое и гостеприимное tech-сообщество, которое заставляет думать и расти.
Огромный респект организаторам и каждому участнику. Вы зажгли огонь.
Отдельное спасибо за новый ракурс Игорю Маркину с докладом про Event Sourcing
Всем,кто ещё сомневается в силе PHP-экосистемы — настоятельно рекомендую сходить в следующий раз.
Вчера отыграл роль ведущего на ПыхConf и вернулся с абсолютно перепрошитым мозгом. Это был не просто ивент, а громкое заявление всего PHP-сообщества.
Организация — на высшем уровне, атмосфера — заряжающая.
Хочу выделить три ключевых инсайта, которые перевернули мое восприятие:
Сила сообщества — это фундамент. Огромное уважение каждому, кто создает эту экосистему: от разработчиков, которые день за днем пишут код на PHP, до контрибьюторов, которые безвозмездно улучшают ядро, фреймворки и инструменты. Вы — огромная сила, которая двигает технологии вперед.
Личный разрыв шаблона: Drupal. 15 лет назад я его «щупал», и у меня было одно, очень крепкое мнение на букву Г. Он казался неудобным и переусложненным.
Сейчас же я в шоке! Это совершенно другой инструмент. Мощный фреймворк для разработчиков с AI в коробке, комьюнити на миллионы и сотнями тысяч коммитов.
Я понял, что все эти годы судил по устаревшим впечатлениям. Это хрестоматийный пример эволюции. Всем, кто застрял в прошлом, как я — настоятельно рекомендую глянуть свежим взглядом.
Архитектурный инсайт:
Вселенная, где в центре — Событие.
Казалось, что я отлично знаю подход Event Sourcing; но один гениальный доклад всё перевернул.
Провели аналогию: раньше мы думали, что Вселенная крутится вокруг Земли (в коде это какая-то главная сущность). Чтобы описать процессы, приходилось городить сложную логику.
А потом Коперник переместил центр на Солнце — и орбиты стали простыми эллипсами.
Так вот, Событие (Event) — это новое Солнце.
Смотришь на это через призму «центра вселенной» — и мозг буквально взрывается. Задаёшь себе вопрос а что если центр вселенной не там. Тогда все играет другими красками. Начинаешь совершенно по-другому видеть архитектуру прошлых и текущих проектов. Кажется, что знал всё это и раньше, но такой ракурс меняет сознание.
Философский взгляд и пожалуй я готов к эксперементам.
ПыхConf — это именно про такие инсайты. Про то, как выглядит по-настоящему зрелое и гостеприимное tech-сообщество, которое заставляет думать и расти.
Огромный респект организаторам и каждому участнику. Вы зажгли огонь.
Отдельное спасибо за новый ракурс Игорю Маркину с докладом про Event Sourcing
Всем,кто ещё сомневается в силе PHP-экосистемы — настоятельно рекомендую сходить в следующий раз.
1🔥13❤3❤🔥1👍1
🚨 [ЗАКРЫТ] Инцидент SEV-1: Топливная система под угрозой. RCA соблюден.
Помните наш пост про инцидент с заправкой не тем топливом? 🚙⛽ Время отчитаться о выполнении Action Items.
Система защиты от человеческого фактора получила долгожданный патч.
🛡️ Representational State of KOT
В рамках мер по недопущению повторения инцидента (п. «Подумать о дополнительных визуальных сигнализаторах») в архитектуру топливной системы был внедрен новый компонент.
Встречайте: Визуальный Валидатор Конфигурации «Дизель».
Помните наш пост про инцидент с заправкой не тем топливом? 🚙⛽ Время отчитаться о выполнении Action Items.
Система защиты от человеческого фактора получила долгожданный патч.
🛡️ Representational State of KOT
В рамках мер по недопущению повторения инцидента (п. «Подумать о дополнительных визуальных сигнализаторах») в архитектуру топливной системы был внедрен новый компонент.
Встречайте: Визуальный Валидатор Конфигурации «Дизель».
🔥11😁4👍3❤1🤨1
Техдол! Придуманная история про не придуманные проблемы.
Привет шишкины читатели! 👋
Знакомьтесь, это Андрей — новый технический директор на современной АЭС. Его первый рабочий день, а система мониторинга уже показывает сбой в контуре аварийного охлаждения. Инженеры разводят руками: "Так исторически сложилось".
Расследование показывает: система зависит от старой советской лампочки под зеленым колпаком в подвале 4-го энергоблока. Выясняется, что 25 лет назад молодой инженер нашел баг в схеме управления. Вместо перепроектирования системы он подключил случайную лампу к датчику через самодельное реле — "временно, на пару дней".
Но шли годы, и "временное решение" обрастало зависимостями:
2005 год: к лампе подключили систему диагностики
2010 год: через ее цоколь пустили заземление контрольной аппаратуры
2015 год: обнаружилось, что нагрев лампы регулирует чувствительность датчиков
2018 год: выяснилось, что стеклянный колпак создает нужный микроклимат для реле
Каждый новый инженер, узнавая о "лампе-стороже", лишь разводил руками: "Работает же, не трогай".
Цена вопроса 🔤
Андрей считает:
Сегодня: замена лампы = остановка реактора на 2 недели → 2 млн $ убытка
Через год: потребуется перепроектирование подсистемы + 2 месяца работ → 15 млн $
Через 3 года: полная переработка архитектуры + 6 месяцев → 50 млн $ и риск потери лицензии
Вызвали того самого инженера (уже пенсионера). Тот ахнул: "Вы до сих пор эту лампочку не заменили? Я же оставил схему для временного решения!"
О чем это вам? 🙈
Если вы заказчик/менеджер:
Техдолг = скрытая ипотека. Платить все равно придется, но с процентами
"Временное решение" живет дольше, чем ваш проект
Цена исправления растет экспоненциально с каждым годом
Если вы разработчик:
"Костыли" обрастают мясом и становятся частью архитектуры
Чем дольше тянете, тем страшнее прикасаться к системе
Ваша задача — не молчать о проблемах, даже если "и так работает" Ваша задача показать что будет. Какова цена отсрочки?
Что делать? 🧹
1. Регулярный аудит технического долга
2. Приоритизация: что опасно уже сегодня
3. Выделение 20% времени на "техническое здоровье"
4. Прозрачность для бизнеса: показывайте стоимость отсрочки
Потому что техдолг — это не про "плохой код". Это про управление рисками и деньгами. Вопрос не в том, "будем ли мы платить", а в том, "когда и сколько".
А в ваших проектах есть такие "лампочки"? Поделитесь историями — обсудим, как с ними бороться! 👇
Привет шишкины читатели! 👋
Знакомьтесь, это Андрей — новый технический директор на современной АЭС. Его первый рабочий день, а система мониторинга уже показывает сбой в контуре аварийного охлаждения. Инженеры разводят руками: "Так исторически сложилось".
Расследование показывает: система зависит от старой советской лампочки под зеленым колпаком в подвале 4-го энергоблока. Выясняется, что 25 лет назад молодой инженер нашел баг в схеме управления. Вместо перепроектирования системы он подключил случайную лампу к датчику через самодельное реле — "временно, на пару дней".
Но шли годы, и "временное решение" обрастало зависимостями:
2005 год: к лампе подключили систему диагностики
2010 год: через ее цоколь пустили заземление контрольной аппаратуры
2015 год: обнаружилось, что нагрев лампы регулирует чувствительность датчиков
2018 год: выяснилось, что стеклянный колпак создает нужный микроклимат для реле
Каждый новый инженер, узнавая о "лампе-стороже", лишь разводил руками: "Работает же, не трогай".
Цена вопроса 🔤
Андрей считает:
Сегодня: замена лампы = остановка реактора на 2 недели → 2 млн $ убытка
Через год: потребуется перепроектирование подсистемы + 2 месяца работ → 15 млн $
Через 3 года: полная переработка архитектуры + 6 месяцев → 50 млн $ и риск потери лицензии
Вызвали того самого инженера (уже пенсионера). Тот ахнул: "Вы до сих пор эту лампочку не заменили? Я же оставил схему для временного решения!"
О чем это вам? 🙈
Если вы заказчик/менеджер:
Техдолг = скрытая ипотека. Платить все равно придется, но с процентами
"Временное решение" живет дольше, чем ваш проект
Цена исправления растет экспоненциально с каждым годом
Если вы разработчик:
"Костыли" обрастают мясом и становятся частью архитектуры
Чем дольше тянете, тем страшнее прикасаться к системе
Ваша задача — не молчать о проблемах, даже если "и так работает" Ваша задача показать что будет. Какова цена отсрочки?
Что делать? 🧹
1. Регулярный аудит технического долга
2. Приоритизация: что опасно уже сегодня
3. Выделение 20% времени на "техническое здоровье"
4. Прозрачность для бизнеса: показывайте стоимость отсрочки
Потому что техдолг — это не про "плохой код". Это про управление рисками и деньгами. Вопрос не в том, "будем ли мы платить", а в том, "когда и сколько".
А в ваших проектах есть такие "лампочки"? Поделитесь историями — обсудим, как с ними бороться! 👇
❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Как я играл в IT Poker от K2 Cloud
Хочу поделиться крутым опытом и поблагодарить команду K2 Cloud за приглашение на IT POKER. Мне посчастливилось стать участником проекта, который ломает все стереотипы о покере.
Что это было?
Это не просто карточная игра. Представьте себе гибрид покерного турнира и стратегической сессии по проектированию архитектуры.
Суть в том, чтобы собирать "руки" не из карт, а из микросервисов.
Для мозга это был настоящий челлендж — непривычно и безумно интересно.
Классное комьюнити. Было здорово пообщаться вживую с коллегами из индустрии, обсудить общие боли и найти неожиданные решения.
Спасибо организаторам и съёмочной группе за безупречную работу и атмосферу. Вы создали не просто шоу, а уникальную площадку для айти-мышления.
Это тот самый случай, когда хобби и профессиональные навыки слились воедино. Уверен, что у проекта большое будущее, и он откроет покер для новой, tech-ориентированной аудитории.
Первый выпуск уже скоро в сети. Очень рекомендую к просмотру!
Спасибо вам!
Хочу поделиться крутым опытом и поблагодарить команду K2 Cloud за приглашение на IT POKER. Мне посчастливилось стать участником проекта, который ломает все стереотипы о покере.
Что это было?
Это не просто карточная игра. Представьте себе гибрид покерного турнира и стратегической сессии по проектированию архитектуры.
Суть в том, чтобы собирать "руки" не из карт, а из микросервисов.
Для мозга это был настоящий челлендж — непривычно и безумно интересно.
Классное комьюнити. Было здорово пообщаться вживую с коллегами из индустрии, обсудить общие боли и найти неожиданные решения.
Спасибо организаторам и съёмочной группе за безупречную работу и атмосферу. Вы создали не просто шоу, а уникальную площадку для айти-мышления.
Это тот самый случай, когда хобби и профессиональные навыки слились воедино. Уверен, что у проекта большое будущее, и он откроет покер для новой, tech-ориентированной аудитории.
Первый выпуск уже скоро в сети. Очень рекомендую к просмотру!
Спасибо вам!
🔥16❤8🤝6👍2
Лидерство в изменениях: как не уплыть по течению, а построить свой флот
Всем привет! ✌️ Только вернулся с мощного обучения по «Лидерству в изменениях». Не курс, а настоящий тренинг по управлению хаосом. Делюсь инсайтами и проводим яркую параллель.
Если в двух словах: управление изменениями — это не про то, чтобы тушить пожары, а про то, чтобы строить пожарные депо и учить команду ими пользоваться. А теперь — с погружением в историю!
«Зачем меняться?» или «Эпоха застоя»
Бывает такое: вроде все работает, «так всегда и делали», процессы отлажены. Но мир вокруг уже изменился. Пока мы довольствуемся свечой, мир изобрел электричество. Так и в IT: пока мы используем устаревшие инструменты, конкуренты уже выпускают фичи раз в день.
Историческая аналогия: Любая эпоха технологического застоя. Представьте общество, которое гордится своими телегами, пока соседи уже запускают первые паровозы. Стабильность есть, а будущего — нет.
Вывод для нас: Комфорт — главный враг прогресса. Если не инициировать изменения самим, они придут извне, и тогда придется не строить, а догонять.
Посмотрите на картинку вся правда жизни.
«Создание видения и работа с сопротивлением» или «Великие реформы»
Вот ты, как лидер, видишь светлое будущее: agile-команды, DevOps-культура, TTM за неделю. А команда видит лишь «болезненный и непонятный отказ от привычного». «Зачем нам этот ваш новый фреймворк? У нас и так все работало!»
Снова смотрим на картинку.
Историческая аналогия: Эпоха масштабных преобразований — основание нового города, создание флота, переход на новые технологии.
Видение: «Мы станем лидерами рынка, на который выйдем первыми».
Действия: Строительство новой инфраструктуры, внедрение современных стандартов, переобучение команд.
Сопротивление: Саботаж, консерватизм, страх перед новым.
Методы: Четкое донесение выгод + создание новой системы мотивации (карьерный рост, признание, бонусы).
1. Видение должно быть кристально ясным. Не «внедрим CI/CD», а «сократим время выпуска релиза с месяца до одного дня, чтобы обгонять конкурентов».
2. Сопротивление неизбежно. Его нужно не давить, а понимать. Люди боятся не изменений, а потери статуса, компетенций, комфорта.
3. Нужны «агенты изменений». Найдите в команде — тех, кто горит идеей. Их энергия заразит остальных.
«Управление кризисом» или «Смутное время»
А что делать, когда изменения не ты инициировал, а они на тебя свалились? Кризис, паника, нет лидера, все рушится.
Историческая аналогия: Смутное время. Старые структуры рухнули, царит неразбериха, цели непонятны. Казалось бы, конец.
В кризис нужен не менеджер, а лидер.
Собирается ополчение (кросс-функциональная команда), которое не ждет указаний сверху, а берет на себя ответственность.
Ставится четкая и простая цель («Освободить Москву» / «Восстановить работоспособность системы»).
Ключевая мысль: Кризис — это время возможностей. Он ломает старые, неэффективные процессы и дает шанс построить новые, более сильные.
🛠️ Резюме и практические инструменты:
1. Будьте архитектором, а не пожарным. Стройте прочные процессы, а не героически тушите костры.
2. Создавайте правильную мотивацию. Изменения должны быть выгодны команде. Новая система грейдов, обучение за счет компании, понятный карьерный трек.
3. Помните про волю к действию. В кризис не паникуйте, а берите на себя ответственность, объединяйте людей и ведите их к цели.
Лидер в изменениях — это не тот, кто просто объявляет о новом курсе. Это тот, кто сам становится штурманом, прокладывает путь через сопротивление и неопределенность и ведет свою команду к новой, более сильной версии себя и продукта.
А у вас были свои «Великие реформы» или «Смутные времена» в проектах? Делитесь опытом в комментах! 👇
Всем привет! ✌️ Только вернулся с мощного обучения по «Лидерству в изменениях». Не курс, а настоящий тренинг по управлению хаосом. Делюсь инсайтами и проводим яркую параллель.
Если в двух словах: управление изменениями — это не про то, чтобы тушить пожары, а про то, чтобы строить пожарные депо и учить команду ими пользоваться. А теперь — с погружением в историю!
«Зачем меняться?» или «Эпоха застоя»
Бывает такое: вроде все работает, «так всегда и делали», процессы отлажены. Но мир вокруг уже изменился. Пока мы довольствуемся свечой, мир изобрел электричество. Так и в IT: пока мы используем устаревшие инструменты, конкуренты уже выпускают фичи раз в день.
Историческая аналогия: Любая эпоха технологического застоя. Представьте общество, которое гордится своими телегами, пока соседи уже запускают первые паровозы. Стабильность есть, а будущего — нет.
Вывод для нас: Комфорт — главный враг прогресса. Если не инициировать изменения самим, они придут извне, и тогда придется не строить, а догонять.
Посмотрите на картинку вся правда жизни.
«Создание видения и работа с сопротивлением» или «Великие реформы»
Вот ты, как лидер, видишь светлое будущее: agile-команды, DevOps-культура, TTM за неделю. А команда видит лишь «болезненный и непонятный отказ от привычного». «Зачем нам этот ваш новый фреймворк? У нас и так все работало!»
Снова смотрим на картинку.
Историческая аналогия: Эпоха масштабных преобразований — основание нового города, создание флота, переход на новые технологии.
Видение: «Мы станем лидерами рынка, на который выйдем первыми».
Действия: Строительство новой инфраструктуры, внедрение современных стандартов, переобучение команд.
Сопротивление: Саботаж, консерватизм, страх перед новым.
Методы: Четкое донесение выгод + создание новой системы мотивации (карьерный рост, признание, бонусы).
1. Видение должно быть кристально ясным. Не «внедрим CI/CD», а «сократим время выпуска релиза с месяца до одного дня, чтобы обгонять конкурентов».
2. Сопротивление неизбежно. Его нужно не давить, а понимать. Люди боятся не изменений, а потери статуса, компетенций, комфорта.
3. Нужны «агенты изменений». Найдите в команде — тех, кто горит идеей. Их энергия заразит остальных.
«Управление кризисом» или «Смутное время»
А что делать, когда изменения не ты инициировал, а они на тебя свалились? Кризис, паника, нет лидера, все рушится.
Историческая аналогия: Смутное время. Старые структуры рухнули, царит неразбериха, цели непонятны. Казалось бы, конец.
В кризис нужен не менеджер, а лидер.
Собирается ополчение (кросс-функциональная команда), которое не ждет указаний сверху, а берет на себя ответственность.
Ставится четкая и простая цель («Освободить Москву» / «Восстановить работоспособность системы»).
Ключевая мысль: Кризис — это время возможностей. Он ломает старые, неэффективные процессы и дает шанс построить новые, более сильные.
🛠️ Резюме и практические инструменты:
1. Будьте архитектором, а не пожарным. Стройте прочные процессы, а не героически тушите костры.
2. Создавайте правильную мотивацию. Изменения должны быть выгодны команде. Новая система грейдов, обучение за счет компании, понятный карьерный трек.
3. Помните про волю к действию. В кризис не паникуйте, а берите на себя ответственность, объединяйте людей и ведите их к цели.
Лидер в изменениях — это не тот, кто просто объявляет о новом курсе. Это тот, кто сам становится штурманом, прокладывает путь через сопротивление и неопределенность и ведет свою команду к новой, более сильной версии себя и продукта.
А у вас были свои «Великие реформы» или «Смутные времена» в проектах? Делитесь опытом в комментах! 👇
🔥8👍2❤🔥1❤1💯1
Ну что, шишкины читатели — это случилось! 🎙️
Подкаст от Егора и Дяди Лёши — уже в эфире!
Первый выпуск в сети, и это чувство — будто выкатили прод после ночного деплоя: сердце колотится, адреналин зашкаливает, а на результат уже смотрят живые люди! 🚀
Это наш «первый коммит». Он честный, хоть и неидеальный, но искренний. (Прикольная отмазка для разработчика, да?😄 )
Говорим с Егором про IT и всё, что течёт рядом: карьера, обучение, индустрия и, главное — люди за кодом.
Тема пилота — путь в IT. Не глянец, а настоящий, с шишками, поисками и сомнениями.
🎧 Первый выпуск уже здесь:
👉 ВКонтакте: https://vk.com/podcastflow
👉 Яндекс Музыка: https://music.yandex.ru/album/38679137
Врывайтесь в «Поток»! 🦔
Слушайте, комментируйте, делитесь — ваш фидбек станет главным пул-реквестом для следующего выпуска.
P.S. А если от кода уже кипит в голове, заходите в настольный мир Егора — @polkaegora🎲 Там стратегию прокачивают иначе!
Подкаст от Егора и Дяди Лёши — уже в эфире!
Первый выпуск в сети, и это чувство — будто выкатили прод после ночного деплоя: сердце колотится, адреналин зашкаливает, а на результат уже смотрят живые люди! 🚀
Это наш «первый коммит». Он честный, хоть и неидеальный, но искренний. (Прикольная отмазка для разработчика, да?
Говорим с Егором про IT и всё, что течёт рядом: карьера, обучение, индустрия и, главное — люди за кодом.
Тема пилота — путь в IT. Не глянец, а настоящий, с шишками, поисками и сомнениями.
🎧 Первый выпуск уже здесь:
Врывайтесь в «Поток»! 🦔
Слушайте, комментируйте, делитесь — ваш фидбек станет главным пул-реквестом для следующего выпуска.
P.S. А если от кода уже кипит в голове, заходите в настольный мир Егора — @polkaegora
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥5🤩2
День отца
У меня не было того самого отца. Не было человека, который бы стал моим первым «техлидом жизни», показывал баги жизни и учил меня их фиксить. Моя система росла с нуля, без базового кода, без мануала.
Сначала это казалось багом. Потом — фичей. Теперь я понимаю: это чистый репозиторий.
И у меня есть доступ на запись. Право и возможность собрать с нуля то, чего не было у меня.
Я не могу коммитнуть исправление в свое прошлое. Но я могу создать новый проект. Проект под названием «Отец».
Архитектура: Безопасность и доверие.
Стек: Любовь, терпение и принятие.
Документация: История нашей семьи, которую я напишу сам.
Основная функция: Быть тем самым «техсаппортом», который никогда не скажет «разбирайся сам», а сядет рядом и поможет отладить любую, даже самую детскую проблему.
Я очень хочу стать для своих детей тем самым «деплой-инженером жизни», который аккуратно выпустит их в большой мир. Тем самым «сисадмином», который починит сломанную игрушку и подскажет, как починить сломанное сердце.
И мой главный коммит в этом мире — не код в репозитории, а уверенность в глазах моих детей. Осознание, что его система — их жизнь — собрана на надежном и любящем фундаменте.
У меня не было того самого отца. Не было человека, который бы стал моим первым «техлидом жизни», показывал баги жизни и учил меня их фиксить. Моя система росла с нуля, без базового кода, без мануала.
Сначала это казалось багом. Потом — фичей. Теперь я понимаю: это чистый репозиторий.
И у меня есть доступ на запись. Право и возможность собрать с нуля то, чего не было у меня.
Я не могу коммитнуть исправление в свое прошлое. Но я могу создать новый проект. Проект под названием «Отец».
Архитектура: Безопасность и доверие.
Стек: Любовь, терпение и принятие.
Документация: История нашей семьи, которую я напишу сам.
Основная функция: Быть тем самым «техсаппортом», который никогда не скажет «разбирайся сам», а сядет рядом и поможет отладить любую, даже самую детскую проблему.
Я очень хочу стать для своих детей тем самым «деплой-инженером жизни», который аккуратно выпустит их в большой мир. Тем самым «сисадмином», который починит сломанную игрушку и подскажет, как починить сломанное сердце.
И мой главный коммит в этом мире — не код в репозитории, а уверенность в глазах моих детей. Осознание, что его система — их жизнь — собрана на надежном и любящем фундаменте.
2❤52🔥11
Media is too big
VIEW IN TELEGRAM
🎥 Обещал — делаю!
Помните пост «🧠 Оцифровал свой мозг — и продуктивность подскочила»?
Тогда я рассказал, как перестроил систему заметок в Obsidian, добавил GTD и Readwise.
Пост собрал кучу откликов — и, как и обещал, держу слово!
👀 Ловите видео, где подробно показываю, как у меня всё устроено:
— структура заметок и связи между ними,
— как выглядит «второй мозг» на практике,
— как настроен Readwise и GTD в Obsidian,
— и главное — какие плагины реально дают эффект, а не просто красивые.
📂 Плюс я собрал для вас папку со всеми моими плагинами и настройками - настраивать ничего не нужно я все сделал за вас!
Папка: https://drive.google.com/file/d/1AAAg_qdpSpk0Z0ZWtmO9Nz_NTaa2VGrz/view?usp=sharing
Видео: https://rutube.ru/video/7ed0791fda5f8290b1db6b101f23bdfb/
💡 Это не просто про заметки — это про то, как организовать мышление и фокус, чтобы идеи не терялись, а превращались в решения и проекты.
Пишите, что хотите, чтобы я показал в следующей версии
Задавайте вопросы в комментариях
#obsidian #второймозг #GTD #readwise #продуктивность #инфраструктурамысли
Помните пост «🧠 Оцифровал свой мозг — и продуктивность подскочила»?
Тогда я рассказал, как перестроил систему заметок в Obsidian, добавил GTD и Readwise.
Пост собрал кучу откликов — и, как и обещал, держу слово!
👀 Ловите видео, где подробно показываю, как у меня всё устроено:
— структура заметок и связи между ними,
— как выглядит «второй мозг» на практике,
— как настроен Readwise и GTD в Obsidian,
— и главное — какие плагины реально дают эффект, а не просто красивые.
📂 Плюс я собрал для вас папку со всеми моими плагинами и настройками - настраивать ничего не нужно я все сделал за вас!
Папка: https://drive.google.com/file/d/1AAAg_qdpSpk0Z0ZWtmO9Nz_NTaa2VGrz/view?usp=sharing
Видео: https://rutube.ru/video/7ed0791fda5f8290b1db6b101f23bdfb/
💡 Это не просто про заметки — это про то, как организовать мышление и фокус, чтобы идеи не терялись, а превращались в решения и проекты.
Пишите, что хотите, чтобы я показал в следующей версии
Задавайте вопросы в комментариях
#obsidian #второймозг #GTD #readwise #продуктивность #инфраструктурамысли
🔥23❤3👍1
Media is too big
VIEW IN TELEGRAM
Пятничный деплой самого личного проекта
Три года назад была пятница. И я стоял на сцене с единственным релизом, который по-настоящему волновал.
Не перед коллегами на конференции. Не с докладом про архитектуру. Я читал стихотворение. Всего одно.
Помню, как голос срывался — куда больше, чем во время самых сложных презентаций. Это был мой самый честный «демо-день». Без MVP, без roadmap, без KPI. .
Спустя время понимаю: тот пятничный «деплой» оказался важнее сотен рабочих задач.
Мама до сих пор хранит то видео как самый ценный артефакт.
Вот вам и главный жизненный перфоманс-инсайт: самые важные системы, которые мы собираем, — не на серверах, а в сердцах ....
Три года назад была пятница. И я стоял на сцене с единственным релизом, который по-настоящему волновал.
Не перед коллегами на конференции. Не с докладом про архитектуру. Я читал стихотворение. Всего одно.
Помню, как голос срывался — куда больше, чем во время самых сложных презентаций. Это был мой самый честный «демо-день». Без MVP, без roadmap, без KPI. .
Спустя время понимаю: тот пятничный «деплой» оказался важнее сотен рабочих задач.
Мама до сих пор хранит то видео как самый ценный артефакт.
Вот вам и главный жизненный перфоманс-инсайт: самые важные системы, которые мы собираем, — не на серверах, а в сердцах ....
❤23💔4👍3🔥2❤🔥1👏1💯1
Forwarded from TeamLead Сonf
В программе TeamLead Conf 2025 вас ждет отдельный трек, посвященный инженерным процессам и практикам, — TechLead.
Спикеры поделятся прикладными кейсами внедрения и использования конкретных практик для решения реальных задач.
В этом посте — первая часть докладов трека. Выбирайте актуальные для вас темы и сохраняйте в свое личное расписание на конференции ✅
1️⃣ Когда надежность становится видимой: как связать техдолг с бизнес-ценностью. Павел Лакосников (Авито)
Как измерить метрику надежности продукта? Честную, взаправдошную, а не среднюю температуру микросервисов разной критичности. Ведь если получить настоящую метрику — ее уже легко связать и с техдолгом, и с деньгами. А ведь бизнес нас постоянно и спрашивает, сколько получим в деньгах решением техдолга.
2️⃣ Есть ли экономический эффект от внедрения инженерных практик? Евгений Харченко (Райффайзен Банк)
При внедрении различных «best-practices от лидеров рынка или из умных книжек» первый вопрос, который задают и бизнес, и рядовые сотрудники — а зачем? И если инженерам «на инженерском» донести пользу можно, то бизнесу обычно нужны цифры. И именно об этом Евгений хочет рассказать в докладе.
3️⃣ Тестирование – малое зло, но его можно сделать еще меньше. Евгений Сабиров (Точка Банк)
Евгений в докладе расскажет об антипаттернах индустрии разработки ПО, связанных с контролем и обеспечением качества, приведет примеры решений из других отраслей, а также расскажет об общем алгоритме действий, как не допускать распространенных ошибок при удешевлении разработки.
4️⃣ AI на службе техлида. Алексей Рахманов (FUN&SUN)
Доклад сфокусирован на практическом опыте внедрения AI-практик в различные участки производственного цикла. Участники увидят, какие задачи реально доверить ИИ и как встроить новые инструменты в процесс разработки без лишних потрясений.
5️⃣ Зачем инженерам техническая стратегия? Александр Афенов (Авито)
Александр в своем докладе доказывает, что, несмотря на постоянно меняющуюся окружающую среду, стоит обращать внимание на долгосрочное планирование, одним из инструментов которого является техническая стратегия.
До скорой встречи на TeamLead Conf 2025 ⚡
Если вы еще только планируете к нам присоединиться — успевайте, ведь времени остается совсем мало 😉
Пройдите на сайт, посмотрите полную программу конференции и бронируйте билет 🖐️
Спикеры поделятся прикладными кейсами внедрения и использования конкретных практик для решения реальных задач.
В этом посте — первая часть докладов трека. Выбирайте актуальные для вас темы и сохраняйте в свое личное расписание на конференции ✅
1️⃣ Когда надежность становится видимой: как связать техдолг с бизнес-ценностью. Павел Лакосников (Авито)
Как измерить метрику надежности продукта? Честную, взаправдошную, а не среднюю температуру микросервисов разной критичности. Ведь если получить настоящую метрику — ее уже легко связать и с техдолгом, и с деньгами. А ведь бизнес нас постоянно и спрашивает, сколько получим в деньгах решением техдолга.
2️⃣ Есть ли экономический эффект от внедрения инженерных практик? Евгений Харченко (Райффайзен Банк)
При внедрении различных «best-practices от лидеров рынка или из умных книжек» первый вопрос, который задают и бизнес, и рядовые сотрудники — а зачем? И если инженерам «на инженерском» донести пользу можно, то бизнесу обычно нужны цифры. И именно об этом Евгений хочет рассказать в докладе.
3️⃣ Тестирование – малое зло, но его можно сделать еще меньше. Евгений Сабиров (Точка Банк)
Евгений в докладе расскажет об антипаттернах индустрии разработки ПО, связанных с контролем и обеспечением качества, приведет примеры решений из других отраслей, а также расскажет об общем алгоритме действий, как не допускать распространенных ошибок при удешевлении разработки.
4️⃣ AI на службе техлида. Алексей Рахманов (FUN&SUN)
Доклад сфокусирован на практическом опыте внедрения AI-практик в различные участки производственного цикла. Участники увидят, какие задачи реально доверить ИИ и как встроить новые инструменты в процесс разработки без лишних потрясений.
5️⃣ Зачем инженерам техническая стратегия? Александр Афенов (Авито)
Александр в своем докладе доказывает, что, несмотря на постоянно меняющуюся окружающую среду, стоит обращать внимание на долгосрочное планирование, одним из инструментов которого является техническая стратегия.
До скорой встречи на TeamLead Conf 2025 ⚡
Если вы еще только планируете к нам присоединиться — успевайте, ведь времени остается совсем мало 😉
Пройдите на сайт, посмотрите полную программу конференции и бронируйте билет 🖐️
❤4👍1
Двигатель прогресса — это не знание, а неудобство
Задумывались ли вы, что почти всё, что мы создаём в IT, рождается из одного простого чувства? Из неудобства.
Кто-то устал вручную разворачивать сервера — и появился Docker. Кому-то надоело терять версии кода — и родился Git.
Кто-то просто не хотел ходить в магазин за книгами — и появился Amazon.
Вся наша индустрия — это грандиозный памятник человеческой лени и стремлению к комфорту. Но не в плохом смысле.
В самом что ни на есть эволюционном.
Мы — решатели проблем. Больших и маленьких. И следующая большая вещь родится не в лаборатории гиганта, а в голове того самого паренька, который где-то в гараже или на кухне будет ругаться на то, как неудобно сейчас что-то делать.
Так что в следующий раз, когда вы почувствуете раздражение от кривого процесса или тупой задачи — не игнорируйте это.
Прислушайтесь. Возможно, ваше неудобство — это семя следующего большого проекта.
А что неудобное раздражало вас на этой неделе? Может, уже пора это автоматизировать? 😉
#философия #прогресс #автоматизация #стартап #мышление
Задумывались ли вы, что почти всё, что мы создаём в IT, рождается из одного простого чувства? Из неудобства.
Кто-то устал вручную разворачивать сервера — и появился Docker. Кому-то надоело терять версии кода — и родился Git.
Кто-то просто не хотел ходить в магазин за книгами — и появился Amazon.
Вся наша индустрия — это грандиозный памятник человеческой лени и стремлению к комфорту. Но не в плохом смысле.
В самом что ни на есть эволюционном.
Мы — решатели проблем. Больших и маленьких. И следующая большая вещь родится не в лаборатории гиганта, а в голове того самого паренька, который где-то в гараже или на кухне будет ругаться на то, как неудобно сейчас что-то делать.
Так что в следующий раз, когда вы почувствуете раздражение от кривого процесса или тупой задачи — не игнорируйте это.
Прислушайтесь. Возможно, ваше неудобство — это семя следующего большого проекта.
А что неудобное раздражало вас на этой неделе? Может, уже пора это автоматизировать? 😉
#философия #прогресс #автоматизация #стартап #мышление
🔥10👍3💯1
11.11 в 10:00 AI НА СЛУЖБЕ ТЕХЛИДА
Привет Шишкины читатели!✌️
11 ноября, в 10 утра, я буду выступать на конференции TeamLead Conf на легендарной «Станции TechLead».
И я хочу рассказать не о каких-то далеких теоретических концепциях, а о том, как уже сегодня можно поставить искуственный интеллект на службу конкретным членам вашей команды.
Представьте, что ваши рутинные операции начинают выполнять AI-агенты, а команда фокусируется на действительно сложных и интересных задачах.
Я покажу это на примере нашей «виртуальной команды» — знакомых всем типажей:
👵 Баба Нюра, специалист по безопасности. Она больше не ворчит, а методично сканирует конфиги на предмет утечек ключей, токенов и подозрительных зависимостей.
🧪 Тамара, инженер по тестированию. Она не спит ни днем ни ночью, генерируя километры тест-кейсов и сценариев, основываясь на техзадании. Тамара только контролирует и правит стратегию.
📚 Дядя Толя, ведущий документации. Пока все пишут код, его агент уже структурирует коммиты, собирает черновую версию API-документации и готовит справку по новому функционалу.
🚀 Валера, автор релизных нот. Он анализирует все закрытые задачи в Jira, коммиты в GitHub и сам пишет первый драфт релизных нот, которые Валере остается лишь отполировать.
О чем конкретно пойдет речь в докладе:
1. Просто, как 2x2. Я покажу простые и доступные инструменты, с которых можно начать уже сегодня. Никакого хайпа, только работающие решения.
2. Где взять мозги. Разберем, где брать модели для таких задач: от мощных облачных API до бесплатных и локальных вариантов. Плюсы, минусы, подводные камни.
3. No-code — значит, быстро. Самый важный блок: как без единой строчки кода описать рабочий процесс взаимодействия с агентами и как его встроить в ваши текущие процессы (Slack, Jira, GitHub).
4. RAG — секретное оружие точности. Какие инструменты позволяют за полчаса построить RAG-систему, чтобы ваша модель не генерировала общие фразы, а давала точные ответы, основанные на вашей документации, кодейзе и внутренней базе знаний.
🎯 Для тех, кто будет на конференции:
Ссылка на материалы - https://drive.google.com/drive/folders/1DVOnRhDFaNkh-mnQVXcqJ5NAfyzYU9J8
🏠 Для тех, кто не смог попасть:
Не беда! Я знаю, как это бывает. Как только запись доклада выложат в открытый доступ, я сразу же опубликую ссылку здесь, в канале.
Следите за обновлениями!
Давайте вместе сделаем наши команды более эффективными и сфокусированными. До встречи на TeamLead Conf! на легендарной «Станции TechLead».
Привет Шишкины читатели!
11 ноября, в 10 утра, я буду выступать на конференции TeamLead Conf на легендарной «Станции TechLead».
И я хочу рассказать не о каких-то далеких теоретических концепциях, а о том, как уже сегодня можно поставить искуственный интеллект на службу конкретным членам вашей команды.
Представьте, что ваши рутинные операции начинают выполнять AI-агенты, а команда фокусируется на действительно сложных и интересных задачах.
Я покажу это на примере нашей «виртуальной команды» — знакомых всем типажей:
👵 Баба Нюра, специалист по безопасности. Она больше не ворчит, а методично сканирует конфиги на предмет утечек ключей, токенов и подозрительных зависимостей.
🧪 Тамара, инженер по тестированию. Она не спит ни днем ни ночью, генерируя километры тест-кейсов и сценариев, основываясь на техзадании. Тамара только контролирует и правит стратегию.
📚 Дядя Толя, ведущий документации. Пока все пишут код, его агент уже структурирует коммиты, собирает черновую версию API-документации и готовит справку по новому функционалу.
🚀 Валера, автор релизных нот. Он анализирует все закрытые задачи в Jira, коммиты в GitHub и сам пишет первый драфт релизных нот, которые Валере остается лишь отполировать.
О чем конкретно пойдет речь в докладе:
1. Просто, как 2x2. Я покажу простые и доступные инструменты, с которых можно начать уже сегодня. Никакого хайпа, только работающие решения.
2. Где взять мозги. Разберем, где брать модели для таких задач: от мощных облачных API до бесплатных и локальных вариантов. Плюсы, минусы, подводные камни.
3. No-code — значит, быстро. Самый важный блок: как без единой строчки кода описать рабочий процесс взаимодействия с агентами и как его встроить в ваши текущие процессы (Slack, Jira, GitHub).
4. RAG — секретное оружие точности. Какие инструменты позволяют за полчаса построить RAG-систему, чтобы ваша модель не генерировала общие фразы, а давала точные ответы, основанные на вашей документации, кодейзе и внутренней базе знаний.
🎯 Для тех, кто будет на конференции:
Ссылка на материалы - https://drive.google.com/drive/folders/1DVOnRhDFaNkh-mnQVXcqJ5NAfyzYU9J8
🏠 Для тех, кто не смог попасть:
Не беда! Я знаю, как это бывает. Как только запись доклада выложат в открытый доступ, я сразу же опубликую ссылку здесь, в канале.
Следите за обновлениями!
Давайте вместе сделаем наши команды более эффективными и сфокусированными. До встречи на TeamLead Conf! на легендарной «Станции TechLead».
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤6🔥4⚡3
Друзья 🙏
Я участвую в создании большого и светлого проекта — «Голоса Единства». Это всероссийская аудиобиблиотека сказок и мудрых историй народов России, которые будут озвучивать известные актёры, музыканты, спортсмены, общественные деятели, лидеры мнений и дети.
2026 год объявлен Годом единства народов России, и наш проект как раз про это — про доброту, уважение, взаимовыручку и культурное наследие, которое объединяет людей сильнее любых различий.
Мы создаём открытую аудиотеку, доступную каждому ребёнку, каждой семье, каждой школе.
Это будет библиотека добра, мудрости и светлых смыслов.
🎙 Звукорежиссёры, дикторы, актёры, музыканты, продюсеры, звёзды — все, кто может и хочет помочь — присоединяйтесь!
Ваш голос, ваш профессионализм и ваше участие могут стать частью большого доброго дела, которое услышит вся страна.
Мой контакт +7916-023-02-02
@alexsdks
Спасибо каждому, кто откликнется.
Спасибо за вашу доброту, поддержку и готовность быть частью этого единства.
Мы разные, но мы — едины
Сейчас проект особенно нуждается в поддержке.
Любая помощь важна — финансовая, информационная, организационная.
Каждый рубль имеет значение.
👉 https://www.tbank.ru/cf/3EmKMvrkg8t
Я участвую в создании большого и светлого проекта — «Голоса Единства». Это всероссийская аудиобиблиотека сказок и мудрых историй народов России, которые будут озвучивать известные актёры, музыканты, спортсмены, общественные деятели, лидеры мнений и дети.
2026 год объявлен Годом единства народов России, и наш проект как раз про это — про доброту, уважение, взаимовыручку и культурное наследие, которое объединяет людей сильнее любых различий.
Мы создаём открытую аудиотеку, доступную каждому ребёнку, каждой семье, каждой школе.
Это будет библиотека добра, мудрости и светлых смыслов.
🎙 Звукорежиссёры, дикторы, актёры, музыканты, продюсеры, звёзды — все, кто может и хочет помочь — присоединяйтесь!
Ваш голос, ваш профессионализм и ваше участие могут стать частью большого доброго дела, которое услышит вся страна.
Мой контакт +7916-023-02-02
@alexsdks
Спасибо каждому, кто откликнется.
Спасибо за вашу доброту, поддержку и готовность быть частью этого единства.
Мы разные, но мы — едины
Сейчас проект особенно нуждается в поддержке.
Любая помощь важна — финансовая, информационная, организационная.
Каждый рубль имеет значение.
👉 https://www.tbank.ru/cf/3EmKMvrkg8t
4❤16👍6❤🔥3🙏2
Друзья,
15 декабря я выступаю на Team Lead Today в отеле Azimut Смоленская (Москва, ул. Смоленская, д. 8) — прикладной конференции для тимлидов. Не пропустите день нетворкинга лидеров IT-команд в новогодней атмосфере!
Team Lead Today — уникальная площадка для обмена опытом между тимлидами: от новичков до топ-менеджеров. Лучшие практики в области IT расскажут, как строить эффективные команды, управлять сложными проектами, развивать IT-культуру и совмещать техническую экспертизу с лидерскими качествами. Специалисты найдут ответы на свои самые острые управленческие вопросы.
Для кого мероприятие: тимлидов в IT, Senior-разработчиков, руководителей направлений (Engineering Managers), топ-менеджеров (CTO, CIO).
200+ участников
20+ спикеров
10 часов нетворкинга
Присоединяйтесь к масштабной предновогодней встрече IT-профессионалов!
Получите скидку 20% на билеты по промокоду TLTFRIEND.
Сайт: teamleadtoday.ru
15 декабря я выступаю на Team Lead Today в отеле Azimut Смоленская (Москва, ул. Смоленская, д. 8) — прикладной конференции для тимлидов. Не пропустите день нетворкинга лидеров IT-команд в новогодней атмосфере!
Team Lead Today — уникальная площадка для обмена опытом между тимлидами: от новичков до топ-менеджеров. Лучшие практики в области IT расскажут, как строить эффективные команды, управлять сложными проектами, развивать IT-культуру и совмещать техническую экспертизу с лидерскими качествами. Специалисты найдут ответы на свои самые острые управленческие вопросы.
Для кого мероприятие: тимлидов в IT, Senior-разработчиков, руководителей направлений (Engineering Managers), топ-менеджеров (CTO, CIO).
200+ участников
20+ спикеров
10 часов нетворкинга
Присоединяйтесь к масштабной предновогодней встрече IT-профессионалов!
Получите скидку 20% на билеты по промокоду TLTFRIEND.
Сайт: teamleadtoday.ru
10👍9🔥8❤6🏆2
Привет! Шишкины читатели!
Хочу поделиться рекомендацией:
Я работал с Дашей Мулык — бизнес-тренером и коучем. Пришёл к ней запросом по целям, у меня их много, нужно было выбрать основные и продвигаться по ним. Кстати, во время работы с Дашей я запустил этот канал, провел на нем практикум, собрал медиа-кит, и стал больше преподавать.
У Даши за плечами больше 25 000 часов практики и десятки реальных кейсов — от личных выборов до управленческих и командных задач.
К ней можно прийти, если у вас:
— сложный выбор (переезд, отношения, работа, проект)
— ощущение тупика или потери направления
— запрос на стратегию жизни или конкретной сферы
— желание понять свои сильные стороны и опереться на них
— вопросы как у руководителя: команда, развитие, состояние
Сейчас к Даше можно записаться на бесплатную встречу и обсудить вашу ситуацию. Пишите Даше в ЛС слово "знакомство", если хотите тоже достичь результатов, очень рекомендую.
Хочу поделиться рекомендацией:
Я работал с Дашей Мулык — бизнес-тренером и коучем. Пришёл к ней запросом по целям, у меня их много, нужно было выбрать основные и продвигаться по ним. Кстати, во время работы с Дашей я запустил этот канал, провел на нем практикум, собрал медиа-кит, и стал больше преподавать.
У Даши за плечами больше 25 000 часов практики и десятки реальных кейсов — от личных выборов до управленческих и командных задач.
К ней можно прийти, если у вас:
— сложный выбор (переезд, отношения, работа, проект)
— ощущение тупика или потери направления
— запрос на стратегию жизни или конкретной сферы
— желание понять свои сильные стороны и опереться на них
— вопросы как у руководителя: команда, развитие, состояние
Сейчас к Даше можно записаться на бесплатную встречу и обсудить вашу ситуацию. Пишите Даше в ЛС слово "знакомство", если хотите тоже достичь результатов, очень рекомендую.
Telegram
Дарья Мулык | Бизнес-коуч
Коуч ICF, бизнес-тренер, спикер⭐️ Помогаю увидеть свои сильные стороны и сделать на этом результаты 🚀 Обо мне - https://www.mulykdarya.ru/
❤10👍4
This media is not supported in your browser
VIEW IN TELEGRAM
Чувство гордости за свою работу
🔥20❤9❤🔥6
Изменения — это не баг, это фича.
Или как 8 шагов Коттера применить к переезду канала.
За 16 лет в IT я пережил:
— внедрение Agile,
— переход с монолита на микросервисы,
— смену трёх поколений языков,
— и тысячи совещаний, где все согласны, но ничего не делается.
Сейчас — очередной виток.
Можно ныть. А можно применить модель управления изменениями.
Я решил честно: пройду 8 шагов Джона Коттера на примере «Айти Шишки».
1. Создать ощущение срочности
Telegram больше не даёт гарантий.
Мы не ждём инцидента — делаем превентивную миграцию.
2. Сформировать коалицию
Вы — не подписчики, а команда.
Без вас миграция не взлетит.
3. Видение и стратегия
Я не закрываю старый канал. Я делаю parallel run.
Контент будет дублироваться. Выбор платформы — за вами.
4. Донести видение до команды
Весь этот пост — шаг номер четыре.
А вот и новая площадка:
https://max.ru/join/T8Cf3MHYbNxXE3zQZKu7bqIwvhXTE4fSswWfZZduzpE
5. Устранить препятствия
Никаких VPN
Просто переходишь и читаешь.
6. Быстрые победы
Первые 100 человек в Максе — мой личный KPI.
7. Закрепить успех
Через месяц здесь останутся только анонсы.
Всё мясо — там. По ссылке выше.
8. Внедрить в культуру
Гибкость — это не про технологии.
Это про готовность менять инструмент, когда старый перестаёт работать.
Кто со мной —
Присоединяйся к каналу по ссылке: https://max.ru/join/T8Cf3MHYbNxXE3zQZKu7bqIwvhXTE4fSswWfZZduzpE
Кто пока сомневается — почитайте Коттера. И приходите.
Или как 8 шагов Коттера применить к переезду канала.
За 16 лет в IT я пережил:
— внедрение Agile,
— переход с монолита на микросервисы,
— смену трёх поколений языков,
— и тысячи совещаний, где все согласны, но ничего не делается.
Сейчас — очередной виток.
Можно ныть. А можно применить модель управления изменениями.
Я решил честно: пройду 8 шагов Джона Коттера на примере «Айти Шишки».
1. Создать ощущение срочности
Telegram больше не даёт гарантий.
Мы не ждём инцидента — делаем превентивную миграцию.
2. Сформировать коалицию
Вы — не подписчики, а команда.
Без вас миграция не взлетит.
3. Видение и стратегия
Я не закрываю старый канал. Я делаю parallel run.
Контент будет дублироваться. Выбор платформы — за вами.
4. Донести видение до команды
Весь этот пост — шаг номер четыре.
А вот и новая площадка:
https://max.ru/join/T8Cf3MHYbNxXE3zQZKu7bqIwvhXTE4fSswWfZZduzpE
5. Устранить препятствия
Никаких VPN
Просто переходишь и читаешь.
6. Быстрые победы
Первые 100 человек в Максе — мой личный KPI.
7. Закрепить успех
Через месяц здесь останутся только анонсы.
Всё мясо — там. По ссылке выше.
8. Внедрить в культуру
Гибкость — это не про технологии.
Это про готовность менять инструмент, когда старый перестаёт работать.
Кто со мной —
Присоединяйся к каналу по ссылке: https://max.ru/join/T8Cf3MHYbNxXE3zQZKu7bqIwvhXTE4fSswWfZZduzpE
Кто пока сомневается — почитайте Коттера. И приходите.
👍6👎5😱2🤮1🤣1
Доброе утро, шишкины читатели.
Начнём с базы, без которой разговор про методологии теряет смысл.
SLDC (или чаще SDLC — Software Development Life Cycle) — это не абстракция и не модный ярлык. Это каркас. Скелет, на котором держится любая стройка, от мобильного приложения до госинформсистемы.
Классический жизненный цикл разработки состоит из семи этапов. Звучат они обычно так:
Первый — анализ требований. Команда выясняет, кому и зачем вообще нужен этот продукт. Без этого этапа вы пилите функциональность, которую никто не просил.
Второй — планирование. Оценка ресурсов, сроков, бюджета, рисков. Здесь принимают волевое решение: «да, мы в это ввязываемся» — или закрывают проект до первого потраченного миллиона.
Третий — проектирование. Архитектура будущей системы. Высокоуровневая — связи между модулями. Низкоуровневая — алгоритмы, структуры данных, протоколы. Чем качественнее этот этап, тем меньше вероятность, что на продакшене всё упадёт.
Четвёртый — разработка. Собственно, написание кода. Превращение схем и спецификаций в работающие строки.
Пятый — тестирование. Поиск того, что пошло не так. Модульное, интеграционное, системное, приёмочное. Чем позже найдена ошибка, тем дороже её исправление.
Шестой — развёртывание. Релиз. Загрузка на серверы, публикация в сторы, передача в эксплуатацию.
Седьмой — поддержка и сопровождение. Самый длинный этап. ПО не живёт без апдейтов: меняются операционные системы, требования регуляторов, ожидания пользователей. Если продукт не дышит — он умирает.
Эти этапы могут нарезаться спринтами, выстраиваться в линейку или закручиваться спиралью. Но суть одна: SDLC — это всегда про предсказуемость, контроль и обратную связь.
И вот тут я вспоминаю Сперанского.
В 1809 году этот блестящий администратор выдаёт Александру I «Введение к уложению государственных законов». Идеальный Waterfall-проект. Анализ текущего положения — есть. Планирование — эталонное. Проектирование архитектуры власти — разделение ветвей, чёткие модули, прописанные интерфейсы взаимодействия. Сперанский сделал всё, что от него требовалось на первых трёх этапах SDLC.
А дальше — провал. Потому что не сработали этапы пятый, шестой и седьмой.
Тестирования на элите не провели. Обратную связь от целевой аудитории — дворянства и бюрократии — не собрали. Развёртывание пошло в отказ. Поддержку проекта царь не обеспечил. В 1812 году Сперанского отправили в отставку, а систему свернули до патча.
Но вот что важно. После 1812 года Александр I возвращается к реформам. Только теперь это уже не водопад. Это чистая инкременталика: устав Академии, эксперименты в Прибалтике, точечные изменения через Аракчеева. Короткие итерации, быстрая обратная связь, низкая цена ошибки.
Сперанский дал нам идеальный документ. Но документ — это не система. Можно идеально пройти этапы с первого по третий и похоронить проект на этапе развёртывания, потому что ты не заложил в план право на изменение требований.
Поэтому, когда в следующий раз скажут: «У нас внедрён SDLC, мы работаем строго по этапам», — уточните: «А какая у вас модель?» Если Waterfall без права возврата — вы повторяете путь 1809 года. И финал, скорее всего, будет таким же.
Начнём с базы, без которой разговор про методологии теряет смысл.
SLDC (или чаще SDLC — Software Development Life Cycle) — это не абстракция и не модный ярлык. Это каркас. Скелет, на котором держится любая стройка, от мобильного приложения до госинформсистемы.
Классический жизненный цикл разработки состоит из семи этапов. Звучат они обычно так:
Первый — анализ требований. Команда выясняет, кому и зачем вообще нужен этот продукт. Без этого этапа вы пилите функциональность, которую никто не просил.
Второй — планирование. Оценка ресурсов, сроков, бюджета, рисков. Здесь принимают волевое решение: «да, мы в это ввязываемся» — или закрывают проект до первого потраченного миллиона.
Третий — проектирование. Архитектура будущей системы. Высокоуровневая — связи между модулями. Низкоуровневая — алгоритмы, структуры данных, протоколы. Чем качественнее этот этап, тем меньше вероятность, что на продакшене всё упадёт.
Четвёртый — разработка. Собственно, написание кода. Превращение схем и спецификаций в работающие строки.
Пятый — тестирование. Поиск того, что пошло не так. Модульное, интеграционное, системное, приёмочное. Чем позже найдена ошибка, тем дороже её исправление.
Шестой — развёртывание. Релиз. Загрузка на серверы, публикация в сторы, передача в эксплуатацию.
Седьмой — поддержка и сопровождение. Самый длинный этап. ПО не живёт без апдейтов: меняются операционные системы, требования регуляторов, ожидания пользователей. Если продукт не дышит — он умирает.
Эти этапы могут нарезаться спринтами, выстраиваться в линейку или закручиваться спиралью. Но суть одна: SDLC — это всегда про предсказуемость, контроль и обратную связь.
И вот тут я вспоминаю Сперанского.
В 1809 году этот блестящий администратор выдаёт Александру I «Введение к уложению государственных законов». Идеальный Waterfall-проект. Анализ текущего положения — есть. Планирование — эталонное. Проектирование архитектуры власти — разделение ветвей, чёткие модули, прописанные интерфейсы взаимодействия. Сперанский сделал всё, что от него требовалось на первых трёх этапах SDLC.
А дальше — провал. Потому что не сработали этапы пятый, шестой и седьмой.
Тестирования на элите не провели. Обратную связь от целевой аудитории — дворянства и бюрократии — не собрали. Развёртывание пошло в отказ. Поддержку проекта царь не обеспечил. В 1812 году Сперанского отправили в отставку, а систему свернули до патча.
Но вот что важно. После 1812 года Александр I возвращается к реформам. Только теперь это уже не водопад. Это чистая инкременталика: устав Академии, эксперименты в Прибалтике, точечные изменения через Аракчеева. Короткие итерации, быстрая обратная связь, низкая цена ошибки.
Сперанский дал нам идеальный документ. Но документ — это не система. Можно идеально пройти этапы с первого по третий и похоронить проект на этапе развёртывания, потому что ты не заложил в план право на изменение требований.
Поэтому, когда в следующий раз скажут: «У нас внедрён SDLC, мы работаем строго по этапам», — уточните: «А какая у вас модель?» Если Waterfall без права возврата — вы повторяете путь 1809 года. И финал, скорее всего, будет таким же.
👍3🔥3