DevToExecutive - Из Кода в Руководы

🌳 В LeSS по дрова: стоит ли вам масштабировать Scrum? Если у вас уже второй месяц не сходится план с фактом, а разработчики бегают между митингами, как белка в колесе, возможно, пора посмотреть в сторону LeSS. Но осторожно: это не серебряная пуля, а вполне конкретный фреймворк со своими особенностями. Давайте разберёмся, когда он зайдёт как надо, а когда лучше притормозить. Что такое LeSS в двух словах? LeSS (Large-Scale Scrum) — это масштабируемый Scrum для больших команд. Главная идея — не плодить новые процессы, а расширять классический Scrum так, чтобы сохранить его простоту. Вместо сотни ролей, слоёв менеджмента и фальшивой «гибкости» LeSS предлагает одно: один продукт, один Product Owner, один бэклог. А дальше – несколько команд, работающих синхронно. Когда LeSS – ваш выбор 1️⃣ У вас одна большая продуктовая команда, а не несколько независимых направлений. LeSS отлично подходит, если все работают над единым продуктом и должны синхронизироваться. 2️⃣ Вы хотите сохранить простоту, а не городить SAFe. Если ваша цель — не утонуть в сложных процессах, а масштабировать Scrum минимальными изменениями, LeSS – хороший вариант. 3️⃣ Команды готовы работать плотно друг с другом. В LeSS нет «нашего» и «вашего» — код общий, продукт общий, цели общие. Важно понимать, что появятся дополнительные встречи для синхронизации команд, что требует высокой дисциплины. 4️⃣ Менеджеры готовы трансформировать свою роль. В LeSS менеджеры отходят от командования и контроля в сторону коучинга и создания условий для команд. 5️⃣ Вы уже умеете в Scrum. Если команда не может эффективно работать даже в классическом Scrum, масштабирование только усугубит хаос. LeSS работает лучше, когда базовые принципы уже освоены. Когда LeSS лучше пока не трогать ▪️ У вас несколько независимых продуктов. Если каждая команда работает над своим направлением, лучше выбрать другой подход, например SAFe или отдельные продуктовые команды. ▪️ В компании сильная культура иерархии. LeSS требует высокой автономности команд. Если каждое решение должно утверждаться сверху, внедрение будет болезненным. ▪️ Вы хотите быстро внедрить процесс и забыть. LeSS – это изменение культуры, а не просто новый набор встреч и ролей. Если нужен быстрый эффект – лучше выбрать более лёгкие методы улучшения процессов. ▪️ Команды привыкли к жёсткому распределению ответственности. В LeSS нет места узким границам между ролями. Команды должны быть готовы брать на себя общую ответственность за продукт. ——— LeSS – это мощный инструмент для масштабирования Scrum, но только при правильных условиях. Если у вас сильные команды, ориентированные на сотрудничество, и желание работать по-настоящему гибко – попробуйте. Если же ваша организация держится на строгой иерархии и контроле – лучше поискать другие варианты. Какие у вас были вызовы при масштабировании Agile? Пробовали LeSS или выбрали другой путь? Делитесь опытом!

⚡️КодоРук: Evolution — проверь себя в роли руководителя! На выходных наваял бота, где можно испытать себя в роли управленца, принимать важные решения, решать задачи и видеть, как выбор влияют на развитие событий. Настоящая жизнь руководителя, но без стрессов (ну, почти 😉). Что внутри? ⚡️ Блиц-режим Быстрые управленческие вызовы. Задачи из реальной жизни: мотивация команды, конфликты, рост бизнеса. ▪️Выбор тематики — хотите прокачаться в чем-то конкретном? Выбирайте направление и тестируйте себя. Отдельные тематики можно купить за руккоины, которые можно заработать за хорошие решения. ▪️Советы — каждое решение приносит баллы и полезные инсайты, которые пригодятся в реальной жизни. 📖 Интерактивные истории Здесь вы — главный герой. Каждое решение влияет на ход событий, так что думайте, просчитывайте и ведите команду к успеху. ▪️Новая история — начните свежий сценарий. ▪️Продолжить — вернитесь туда, где остановились. 🏆 Бейджи и достижения Собирайте награды за успехи, эксперименты и нестандартные ходы. Например: ▪️Перспективный лидер — за 10 успешных решений. ▪️Легенда — за 5000 очков. И это только начало! 🔝Рейтинг Сравнивайте свои результаты с другими, поднимайтесь в топ и докажите, что вы Big-босс. 💬 Обсуждения Делитесь своими ходами, обсуждайте стратегии и находите неожиданные инсайты. Либо просто укажите, что кейс совсем мимо и нужно поправить. Учитывать нюанс... Это пока совсем альфа-версия. Так что если что-то пойдет не так (надеюсь, упадет не при первой попытке) — не кидайтесь помидорами, а лучше напишите, что можно улучшить и какие ситуации стоит подправить. Любое мнение нужно, любое мнение важно. Функционал и база кейсов еще будут подъезжать. Как начать? Просто жмите на ссылку ниже, жми /start и прокачивайте управленческие навыки! Вот сюда -> @DevToExecutiveBot

Про важность быть в звонке (по-настоящему) Удаленка – это вообще отдельный вид спорта. С одной стороны, кайф: ты в трениках, чай себе сделал, никто над душой не стоит. С другой – это какой-то ад из пожирателей внимания. Особенно в созвонах. Знаете, вот этот момент, когда ты подключился, включил мьют, вроде слушаешь… а потом ловишь себя на том, что уже 10 минут листаешь почту или, чего хуже, листаешь ленту телеги. И не потому что ты плохой, просто наш мозг сейчас так работает — клиповое мышление, короткие дофаминовые вспышки, вот это всё. Онлайн-встреча — это соревнование между «сиди и слушай» и «о, а что там в телеге мигнуло». И чаще побеждает второе. А потом хоба — ты вообще выпал из контекста. Кто что решил, почему сроки сдвинулись, зачем тебя вообще добавили в эту задачу — уже не ясно. Последствия простые: ты либо постоянно переспрашиваешь потом, либо принимаешь решения вслепую, либо просто забиваешь (что в перспективе еще хуже). Что теряешь, когда не в фокусе 📌Контекст — ты теряешь мелкие детали, которые потом складываются в большие косяки. 📌Вовлеченность — мозг привыкает, что звонки — это фоновый шум, не требующий включенности. А дальше это переходит в привычку вообще поверхностно относиться к командным процессам. 📌 Уважение команды — если ты сам в телефон уткнулся, то почему они должны вести себя по-другому? 📌 Контроль над ситуацией — чем больше выпадаешь, тем больше решений команда начинает принимать сама, не всегда так, как ты ожидаешь. И самое коварное — это эффект накопления. Один раз пропустил деталь, второй, третий — и вот уже кажется, что эти встречи вообще бесполезны, хотя на самом деле проблема не во встречах, а в твоем уровне включенности. Методы борьбы с созвон-пожирателями (лично проверено) 1️⃣ Фокус-режим на устройстве — отключить все уведомления на время звонка. 2️⃣ Отдельное окно — встреча открыта в полноэкранном режиме, без соблазнов фоном. 3️⃣ Жесткий регламент — понятно, зачем собрались, какая цель, кто за что отвечает. Если нет смысла сидеть — лучше отказаться. 4️⃣ Камера всегда включена — с видео сложнее отвлечься, особенно если команда тебя видит. 5️⃣ Антистресс для рук — лично мне помогает держать в руках антистресс или просто ручку — это заменяет бессознательный скролл телефона. Главное руки не на клаве с мышей. Планирую проверить: 1️⃣ Фиксирование договоренностей в моменте — сам пишешь в чат краткое резюме по итогам каждого блока, это дисциплинирует. 2️⃣ Чек по роли — прямо перед созвоном проговорить себе: «Моя роль на этой встрече — принять решение, дать обратную связь, получить информацию». 3️⃣ Физический блокнот или планшет для заметок — рукам всегда хочется что-то делать, так пусть это будут записи по теме встречи, а не скроллинг. 4️⃣ Фокус-мониторинг — можно после встречи честно спросить себя: на сколько % я был включен? Если 60% и ниже — значит что-то пошло не так, надо докопаться до причины. Короче, быть в звонке — это управленческая гигиена. Хочешь быструю, четкую, вовлеченную команду — начни с себя. Кто тоже с этим борется — поделитесь, какие фишки заходят у вас?

⚙️ Разработка vs. техдолг: как не угробить команду В разработке всегда хочется найти золотую середину между внедрением новых фич, поддержкой старых и борьбой с техдолгом. Типа, 50% времени на новые фичи, 30% на поддержку, 20% на техдолг — и вот тебе идеальный баланс. На деле это так не работает. Почему это не работает? Распределение ресурсов по задачам кажется логичным, но на практике… ▪️Команды не резиновые. Разработчики не могут переключаться между разными типами задач без потерь. Контекстное переключение — это время, которое уходит в никуда. ▪️Фокус размазывается. Когда команда пытается делать сразу несколько вещей, она в итоге не делает ничего по-настоящему хорошо. Прогресса нет, хотя работа вроде идёт. ▪️Скорость падает. Постоянная смена фокуса замедляет работу, а задачи начинают тянуться на месяцы. В итоге сроки срываются, клиенты не довольны, а команда выгорает. ▪️80% времени уходит на поддержку. Поддержка старого кода и багфиксы становятся основной частью работы, а не развитие нового функционала. Зачем всё усложнять? Проблема в том, что при распределении ресурсов не учитывается, что простое разбрасывание задач по всему процессу не приводит к прогрессу. Работа сама по себе — это не всегда результат. 1️⃣Контекстное переключение. Разработчик не может на 30% заниматься рефакторингом, а на 70% пилить новый функционал — это просто разные режимы работы. Постоянные переключения замедляют команду. 2️⃣ Размытые приоритеты. Когда пытаешься делать всё сразу, не получается сделать ничего качественно. 3️⃣Ограниченные ресурсы. Если команда уже на пределе, перераспределение не даст результата. Иногда проще просто сократить задачи, чтобы сосредоточиться на важном. 4️⃣ Неучёт зависимостей. Раздача задач без понимания взаимосвязей между ними приводит к задержкам. Как сделать лучше? 🔹Сосредоточиться на приоритетах. Лучше сделать одну ключевую задачу до конца, чем начинать десять мелких, которые не двигают дела вперёд. 🔹Целевые команды. Для решения техдолга или конкретных задач проще выделить отдельную команду, чем заставлять всех заниматься всем сразу. Когда люди сосредоточены на одной цели, результат лучше. 🔹Zero Bug Policy и Kill Your Darlings. Прежде чем разрабатывать новые фичи, важно закрывать баги. Но так же важно «убивать любимые фичи», если они не приносят реальной пользы. 🔹Гибкое перераспределение людей. Иногда лучше сделать паузу в одном направлении и переключиться на другое, чем пытаться тянуть всё одновременно. "По чуть-чуть" редко работает эффективно. 🔹Прозрачность. Когда команда понимает, почему именно эти задачи в приоритете, её вовлечённость растёт. Прозрачность позволяет эффективно управлять ожиданиями. 🔹Долгосрочное видение. Инвестиции в основу, даже если это замедлит темп на некоторое время, могут дать значительный рост в будущем. Пример: Проект как старый «рыдван» Представьте, что у вас есть старая машина, которая постоянно ломается. Подвеска скрипит, двигатель чихает, коробка передач заедает. Но вместо того, чтобы починить эти проблемы, вы решаете поставить новый мафон, чтобы музыка играла. Мастер спрашивает: "Может, сначала тормоза починим?" Но… сидюк важнее. Через неделю машина намертво встала на обочине — двигатель накрылся, тормоза отказали. Зато музыка радует слух. Вот так часто происходит в dev-командах: стараются улучшить продукт, но важные проблемы остаются нерешёнными. Распределив ресурсы по всем направлениям, команда не двигается вперёд, и в результате страдает всё: пользователи, бизнес и сама команда. Как вы находите баланс между новыми фичами, поддержкой и техдолгом в своей команде? Больше на канале Из Кода В Руководы

🏔 Горы или долина: где ваша команда работает лучше? 🌿 В разработке можно выделить два противоположных ландшафта: горы и долина. Каждый из них символизирует определённый подход к работе. Горы — это строгость, дисциплина и минимальные риски. Долина — это свобода, эксперименты и гибкость. Какой из них подходит вашей команде? Давайте разберёмся. 🏔 Горы: чёткость и контроль В горах всё по расписанию. Никаких отмазок, всё должно быть сделано вовремя и без косяков. Тут всё напоминает классический подход типа Waterfall: этапы расписаны, план фиксирован, и любое отступление может дорого обойтись. 🔺Жёсткие сроки и мало ресурсов. Время жмёт, и ошибки не прощаются. 🔺Ошибок быть не должно. Любой сбой — и проект может провалиться. 🔺Планирование на 100%. Всё расписано, как в сценарии, и контроль — на высшем уровне. Что нужно в горах: 🔻Подробная документация на каждом шаге. 🔻Строгий контроль кода и тщательное тестирование. 🔻Чёткие дедлайны и ответственность у каждого. Когда выбирать горы? Этот подход идеален для проектов, где важны чёткость, предсказуемость и соблюдение сроков. Например, если вы разрабатываете продукт с фиксированными требованиями, где изменения маловероятны или нежелательны. Когда есть вызов, цель и нужно ее достичь не покидая маршрут. 🌿 Долина: свобода и эксперименты А в долине всё по-другому: можно расслабиться, попробовать новые идеи и не париться, если что-то пойдёт не так. Это скорее Agile: гибко, итеративно и с постоянными улучшениями. 🔺Гибкость и эксперименты. Можно пробовать новое и учиться на ошибках. 🔺Ошибки — не катастрофа. Если что-то не зашло, исправляем и двигаемся дальше. 🔺 Пошаговое развитие. Маленькие итерации, постоянная обратная связь и улучшения. Что важно в долине: 🔻Командная ответственность — каждый вносит свой вклад. 🔻Регулярные поставки продукта и постоянное обновление. Когда выбирать долину? Этот подход подходит для проектов, где важны гибкость, адаптивность и постоянное улучшение. Например, если вы работаете над стартапом или продуктом, требования к которому могут меняться в процессе разработки. Как выбрать подходящий подход? Выбор между горами и долиной зависит от специфики проекта и команды. Задайте себе несколько вопросов: 🔺Насколько стабильны требования к проекту? Если они чёткие и неизменные, выбирайте горы. Если требования могут меняться — долину. 🔺Как ваша команда справляется с рисками? Если ошибки недопустимы, строгий подход гор будет предпочтительнее. Если команда готова экспериментировать и учиться на ошибках, выбирайте долину. 🔺Какие сроки и ресурсы у вас есть? Если время и ресурсы ограничены, горы помогут действовать эффективно. Если есть возможность двигаться итеративно, долина даст больше свободы. Итог Горы — для тех, кто ценит порядок и предсказуемость. Долина — для тех, кто готов экспериментировать и адаптироваться. Какой бы путь вы ни выбрали, главное — чтобы он соответствовал целям вашего проекта и особенностям вашей команды. В какой среде работает ваша команда — в горах или в долине? Делитесь в комментариях! Больше на канале Из Кода В Руководы

Когда коллега сливается с тимбилдинга – это тревожный звоночек! Ребята, давайте по-честному: если кто-то из команды постоянно пропускает встречи, бары, тренинги и прочие тёплые ламповые движухи – это сигнал. И не просто "ой, не успел", а реальный тревожный звоночек. Человек может уже мысленно не с нами. Почему вообще важны совместные тусовки? Это не просто повод убить время после работы. Это про укрепление команды, про доверие, про "своих". Когда мы собираемся вместе, мы лучше понимаем друг друга, быстрее решаем задачи и вообще чувствуем себя в нормальной рабочей атмосфере. Кроме того, общение в команде (и особенно неформальное) стимулирует выработку серотонина – гормона, который отвечает за чувство доверия и принадлежности. Чем больше позитивных моментов в коллективе, тем крепче связи между сотрудниками. Люди работают не на компании, а на людей внутри этих компаний. Если человек избегает тимбилдинга, то... ✔️ Он уже не так вовлечён в работу ✔️ Его что-то бесит (начальство, коллеги, задачи – кто знает) ✔️ Он подсознательно готовится к уходу (очень много живых примеров) Если человек с каждым разом находит всё новые оправдания ("Ой, у меня тренажёрка", "Ой, семейные дела", "Ой, просто не хочу"), то это не про отсутствие времени. Это про отсутствие желания быть с командой. А это звоночек. Почему так происходит? 🔺Разочаровался в компании – ожидания не совпали с реальностью 🔺Тупо не нравится коллектив – конфликты, недопонимание, токсичность 🔺Не любит корпоративные движухи – интроверт, ему проще в одиночестве Ну и иногда это не про плохого сотрудника, а про атмосферу в компании. :) Может, ваши тимбилдинги – это реально скучные лекции, которые никто не хочет посещать? Заставить человека быть частью команды нельзя. Но можно создать среду, где он сам захочет ею стать. Что делать? ✔️Да для начала хотя бы поговорить с человеком – узнать, что не так. А не просто поставить прочерк в списке участников. ✔️Поощрять вовлечённость – Признавать вклад каждого и показывать, что все важны. ✔️ Создать атмосферу, где комфортно всем – и тем, кто любит тусить, и тем, кто нет Вывод: если кто-то начинает избегать командных встреч, не игнорируйте это. Может, человеку просто не заходит формат. А может, он уже на hh обновляет свою резюмеху. Как у вас с тимбилдингами? Есть постоянно ускользающие коллеги? Пишите в комменты! 👇 Больше на канале Из Кода В Руководы

На канале появился бот для вопросов. Теперь ты можешь спросить всё, что угодно, без страха осуждения! Как это работает? 🔺 Отправляешь свой вопрос/комментарий/историю/тему для разбра в бота 🔺Просматриваю и отвечаю (на вопросы по тематике) на канале анонимно Можно также присылать обратную связь по материалам. 🟢 Хотите узнать что-то, но стесняетесь? Пора это исправить! Присоединяйся прямо сейчас: 👉 @DevToExecutiveBot Также в процессе доработки мини-игра для проверки менеджерских навыков. Скоро в том же боте… Больше на канале Из Кода В Руководы

Боимся ИИ, а что, если... Блуждающий ум во время утренней рутины натолкнул на такую мысль: все переживают, что искусственный интеллект выйдет из-под контроля. Но что, если глобальный хаос устроит не сверхразумная машина, а банальный баг в обычном будильнике? Представьте: ночью выходит обновление, и из-за ошибки будильник просто не срабатывает. Или это плавающая ошибка, зависящая от определённой даты. Утром миллионы людей по всему миру… проспали. ▪️Метро пустое, но к обеду – транспортный коллапс. ▪️Биржи рушатся: трейдеры спят, рынок теряет миллиарды. ▪️ Врачи не выходят на смену, операции откладываются. ▪️ Заводы, офисы, магазины — всё стоит. Экономика замирает. ▪️ Службы экстренного реагирования не укомплектованы. ▪️ Логистический хаос, авиарейсы отменяются… И самое страшное — мы даже не сразу поймём, что пошло не так. В современном ПО огромная вложенность зависимостей: библиотеки используют другие библиотеки, которые зависят ещё от десятков других. Одна незаметная ошибка глубоко в коде — и цепная реакция неизбежна. Помните Y2K — миллениум-баг, который чуть не остановил цифровой мир? Тогда разработчики вложили миллиарды в исправления и предотвратили катастрофу. Но сегодня экосистема настолько сложна, что заметить критический баг до его массового проявления гораздо труднее. Мы боимся, что ИИ нас «перехитрит». Так что, может, бояться стоит не ИИ, а кодеров, которые ночью перед дедлайном пишут «а, вроде работает»? 🤔 Больше на канале Из Кода В Руководы