⚙️ Разработка vs. техдолг: как не угробить команду

В разработке всегда хочется найти золотую середину между внедрением новых фич, поддержкой старых и борьбой с техдолгом. Типа, 50% времени на новые фичи, 30% на поддержку, 20% на техдолг — и вот тебе идеальный баланс. На деле это так не работает.

Почему это не работает?
Распределение ресурсов по задачам кажется логичным, но на практике…
▪️Команды не резиновые.
Разработчики не могут переключаться между разными типами задач без потерь. Контекстное переключение — это время, которое уходит в никуда.
▪️Фокус размазывается.
Когда команда пытается делать сразу несколько вещей, она в итоге не делает ничего по-настоящему хорошо. Прогресса нет, хотя работа вроде идёт.
▪️Скорость падает.
Постоянная смена фокуса замедляет работу, а задачи начинают тянуться на месяцы. В итоге сроки срываются, клиенты не довольны, а команда выгорает.
▪️80% времени уходит на поддержку.
Поддержка старого кода и багфиксы становятся основной частью работы, а не развитие нового функционала.

Зачем всё усложнять?
Проблема в том, что при распределении ресурсов не учитывается, что простое разбрасывание задач по всему процессу не приводит к прогрессу. Работа сама по себе — это не всегда результат.
1️⃣Контекстное переключение.
Разработчик не может на 30% заниматься рефакторингом, а на 70% пилить новый функционал — это просто разные режимы работы. Постоянные переключения замедляют команду.
2️⃣ Размытые приоритеты.
Когда пытаешься делать всё сразу, не получается сделать ничего качественно.
3️⃣Ограниченные ресурсы.
Если команда уже на пределе, перераспределение не даст результата. Иногда проще просто сократить задачи, чтобы сосредоточиться на важном.
4️⃣ Неучёт зависимостей.
Раздача задач без понимания взаимосвязей между ними приводит к задержкам.

Как сделать лучше?
🔹Сосредоточиться на приоритетах.
Лучше сделать одну ключевую задачу до конца, чем начинать десять мелких, которые не двигают дела вперёд.
🔹Целевые команды.
Для решения техдолга или конкретных задач проще выделить отдельную команду, чем заставлять всех заниматься всем сразу. Когда люди сосредоточены на одной цели, результат лучше.
🔹Zero Bug Policy и Kill Your Darlings.
Прежде чем разрабатывать новые фичи, важно закрывать баги. Но так же важно «убивать любимые фичи», если они не приносят реальной пользы.
🔹Гибкое перераспределение людей.
Иногда лучше сделать паузу в одном направлении и переключиться на другое, чем пытаться тянуть всё одновременно. "По чуть-чуть" редко работает эффективно.
🔹Прозрачность.
Когда команда понимает, почему именно эти задачи в приоритете, её вовлечённость растёт. Прозрачность позволяет эффективно управлять ожиданиями.
🔹Долгосрочное видение.
Инвестиции в основу, даже если это замедлит темп на некоторое время, могут дать значительный рост в будущем.

Пример: Проект как старый «рыдван»
Представьте, что у вас есть старая машина, которая постоянно ломается. Подвеска скрипит, двигатель чихает, коробка передач заедает. Но вместо того, чтобы починить эти проблемы, вы решаете поставить новый мафон, чтобы музыка играла. Мастер спрашивает: "Может, сначала тормоза починим?" Но… сидюк важнее. Через неделю машина намертво встала на обочине — двигатель накрылся, тормоза отказали. Зато музыка радует слух.

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

Как вы находите баланс между новыми фичами, поддержкой и техдолгом в своей команде?

Про важность быть в звонке (по-настоящему)

Удаленка – это вообще отдельный вид спорта. С одной стороны, кайф: ты в трениках, чай себе сделал, никто над душой не стоит. С другой – это какой-то ад из пожирателей внимания. Особенно в созвонах.

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

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

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

Методы борьбы с созвон-пожирателями (лично проверено)
1️⃣ Фокус-режим на устройстве — отключить все уведомления на время звонка.
2️⃣ Отдельное окно — встреча открыта в полноэкранном режиме, без соблазнов фоном.
3️⃣ Жесткий регламент — понятно, зачем собрались, какая цель, кто за что отвечает. Если нет смысла сидеть — лучше отказаться.
4️⃣ Камера всегда включена — с видео сложнее отвлечься, особенно если команда тебя видит.
5️⃣ Антистресс для рук — лично мне помогает держать в руках антистресс или просто ручку — это заменяет бессознательный скролл телефона. Главное руки не на клаве с мышей.

Планирую проверить:
1️⃣ Фиксирование договоренностей в моменте — сам пишешь в чат краткое резюме по итогам каждого блока, это дисциплинирует.
2️⃣ Чек по роли — прямо перед созвоном проговорить себе: «Моя роль на этой встрече — принять решение, дать обратную связь, получить информацию».
3️⃣ Физический блокнот или планшет для заметок — рукам всегда хочется что-то делать, так пусть это будут записи по теме встречи, а не скроллинг.
4️⃣ Фокус-мониторинг — можно после встречи честно спросить себя: на сколько % я был включен? Если 60% и ниже — значит что-то пошло не так, надо докопаться до причины.

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

Кто тоже с этим борется — поделитесь, какие фишки заходят у вас?

🌳 В 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 или выбрали другой путь? Делитесь опытом!

🇯🇵 vs 🇷🇺: как управляют командами в Японии и России

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

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

1. Контроль vs доверие
🔴В Японии всё под контролем. Не в смысле "микроменеджмент", а в смысле — всё расписано, всё под присмотром. Каждый шаг — по инструкции, каждый результат — проверен. У руководителя 100% ощущение, что процесс идёт как надо.
🔵У нас — наоборот: дали задачу, махнули рукой и верят, что ты сам разберёшься. Контроль минимальный, максимум — "ну чё, как там продвигается?". В хороших командах это работает. Меньше формализма, больше гибкости и доверия к индивидуальности. Иногда в плюс, иногда в хаос.

2. Иерархия vs горизонталь
🔴Япония — культ старших. Даже в молодёжных стартапах чувствуется: слово сеньора — закон. Все на “сан”, все очень вежливые, даже в неформальной обстановке.
🔵У нас в команде может сеньор получить за шиворот от джуна в кодревью — и это нормально. Главное, чтобы аргумент был. Уважение — по скиллам, а не по табелю о рангах.

3. Стабильность vs скорость
🔴Там команды работают медленнее, но надёжнее. Изменения внедряются осторожно. Их DevOps — это скорее “DevSlowButSafeOps”.
🔵Тут— “вкатил в прод, а потом посмотрим”. Быстрее, дерзко, но и багов больше. Зато адаптируемся быстрее. Кризисы, резкие повороты — привычная среда.

4. Лояльность vs карьера
🔴Японцы до сих пор могут работать в одной компании 10+ лет. Это не считается застоявшимся болотом, это гордость. Команда — как вторая семья. Хотя, ситуация уже начала постепенно меняться.
🔵У нас всё больше "год — и на повышение". Рынок такой. Команды меняются, как состав футбольного клуба в межсезонье. Хорошо для роста, плохо для командной химии.

5. Ошибки
🔴В Японии ошибки воспринимаются болезненнее. (здесь шутка про сэппуку)
🔵Мы проще относимся — “ну с кем не бывает”. Ошибку признаём, фикс выпустим, дальше поехали. Иногда это расслабляет, но чаще помогает не застревать.

Вывод?
Ни там, ни там не идеально (идеально не бывает). Но поучиться друг у друга стоит.
🔴Японцам — гибкости, адаптивности, умения ошибаться и не закапываться в этом.
🔵Нам — уважения к процессу, последовательности и чуть больше командной лояльности.
Так же нужно учитывать, что везде есть исключения. И там и здесь есть команды которые в корне отличаются от большинства.

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

生き甲斐, или почему успех без радости - горькое поражение

Когда всё в порядке: деньги есть, карьера удалась, семья рядом - а ощущение пустоты всё равно никуда не девается. Вроде бы всё правильно сделал, а радости нет.
Что не так?

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

1. Автономия, мастерство и смысл
Идеи Дэниела Пинка (если коротко):
▪️ Автономия - когда сам решаешь, чем заниматься и как.
▪️ Мастерство - когда реально становишься крутым в своём деле.
▪️ Смысл - когда чувствуешь, что делаешь что-то важное, а не просто двигаешь таски.
Эти три штуки лежат в основе внутренней мотивации. Если хотя бы одной из них нет - будет тяжело.

2. Радость
Но одной мотивации мало. Коэн добавляет к модели Пинка личный опыт: без радости от процесса даже осмысленная работа может превратиться в рутину.
Не радость как вечный праздник, а как внутренняя энергия, которая появляется, когда делаешь что-то своё. Когда горд за результат. Когда кайфуешь от процесса.
Без радости вся остальная конструкция рассыпается.

3. 生き甲斐 (икигай)
Японцы ещё тысячу лет назад поняли, что счастье - это заниматься любимым делом для пользы окружающих.
Это не просто стать крутым мастером (мастерство), а сделать так, чтобы твоя работа приносила добро другим людям (смысл).
И именно это помогает людям в Окинаве жить по 90+ лет и не хотеть выходить на пенсию.

4. Начинаем с "почему"
Синек («Start With Why») показывает, что компании с ясной миссией (“почему”) часто создают лояльные сообщества. Но это не единственный путь к успеху - важно сочетать “почему” с сильным “как”
Не "чтобы заработать деньги".
Не "чтобы делать продукты".
А что-то большее.

Например, "помогаем сохранить планету" (Patagonia) или "делаем человечество межпланетным видом" (SpaceX).
Когда у человека или компании есть ясное "почему" - к ним притягиваются другие.
Люди становятся фанатами. И работать хочется в сто раз сильнее.

5. Ловушки, на которые легко попасть
Когда ты кайфуешь от процесса, залипаешь в потоке, но делаешь штуки, которые корпорации важны, как велосипед рыбе.

⚡️Радость + Мастерство − Необходимость = Бесполезный поток
Ты доволен собой, кодишь, рисуешь, придумываешь... только вот толку ноль, потому что это никому не надо.

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

⚡️Радость + Необходимость - Мастерство = Потешная неудача
Вместо реального результата - куча потраченного времени и самообман типа "ну я же старался".

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

⚡️Мастерство + Необходимость - Радость = Выгорание
Тащишь на себе то, что должен был бы давно отдать другим, злишься, ненавидишь работу - и в итоге сгораешь.

Итак - Итог.
Чтобы найти настоящее удовлетворение, нужно собрать четыре вещи:
▪️ свободу выбирать путь;
▪️ рост в мастерстве;
▪️ ощущение важности того, что делаешь;
▪️ радость от процесса.
Без хотя бы одной из них полноты не будет.
А если всё сойдётся - появится то, ради чего реально стоит жить и работать.

А что для вас главное в работе? 🤔
Го в комменты.

Fake Stage 4 — когда «мы-команда» только на слайде

В айтишке уже никто не говорит «я начальник - ты дурак».
Теперь всё культурно: «мы», «вместе», «единая цель», «сильная команда».
На митингах - уважение, на презентациях - ценности, на онбординге - мантры про «поддерживаем друг друга».
Выглядит как уровень 4 по Tribal Leadership - когда люди реально работают вместе.

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

Что вообще за уровни?
Если опираться на книжку «Лидер и племя», то там пять культурных уровней команды.
Идея простая: как люди «мирощущают», так и работают. В зависимости от жизненной ситуации и зрелости можно перемещаться между уровнями.

На первых двух совсем мрак.
На уровне 3 - каждый сам по себе: «Я крут, остальные мешают»
На уровне 4 - появляется «мы»: общее дело, взаимное уважение, синхронность.
На уровне 5 - уже миссия, влияние на мир, и всё такое (редкость).

Так вот, часто уровень 4 пытаются симулировать. Но он не работает, если просто сказать «давайте жить дружно».

Как симулировать 4 уровень?
▪️ Все говорят «мы», но каждый решает свои задачи.
▪️ Ценности где-то формально задекларированы, но живут отдельно от людей.
▪️ На встречах позитив, а в кулуарах - пассивная агрессия и отстранённость.
▪️ Один человек тащит всё на себе, остальные - «в команде», но на дистанции.
▪️ Конфликты не обсуждаются. Сложные темы обходят стороной, чтобы «не подпортить атмосферу».

Это не культура сотрудничества. Это культура молчаливого соглашательства.

А почему?
Потому что всем хочется выглядеть взрослыми, осознанными и «командными».
Руководителю же может быть выгодно, что «все дружат - никто не ругается».
В некоторых корп. культурах 4 уровень вообще может играть роль витрины, где важен «вид», а не суть.

Признать, что команда на уровне 3 - сложно и больно (еще больнее, если на 1ом и получить заточкой в бок😃).
Проще повесить красивый баннер, чем копаться в реальности.
Потому "бутафорский уровень четыре" даже опаснее третьего.
Когда каждый за себя - хотя бы ясно, откуда проблемы.
А здесь - вроде всё ок, но никто не включён по-настоящему. Рост замирает, инициатив меньше, а усталости - больше.

Так, и что с этим делать?
Иногда просто полезно назвать вещи своими именами, уже шаг к решению проблемы.
Увидеть, что текущее «мы» - скорее риторика, чем практика.
И заметить: а где в команде реально есть взаимодействие, а где только имитация?
Настоящее «мы» обычно начинается не с ценностей на ватмане, а с момента, когда люди перестают играть роли.
Иногда одна честная реакция важнее, чем десять созвонов с фразами «мы всё вместе делаем».

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

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

⚙️ Цифры есть — смысла нет

POV: Строим процессы вокруг метрик ради самих метрик. Рисуем дашборды в зеленый. Velocity растёт? Coverage 80%? CI зелёный? Все радуются.
Только вот бизнесу может быть слегка пофиг.

Ошибка: подменять результат метриками.

Что реально волнует "бизнес":
▪️ Быстрые релизы (а не «высокий velocity»)
▪️ Предсказуемость, четкие сроки (а не «все коммиты в срок»)
▪️ Меньше пожаров (а не «95% тестов»)
▪️ Деньги (выручка 💱 или затраты 💱)

💱 Что не работает:

1. Сырые цифры без интерпретации
«У нас 95% coverage!» → а топы думают: «Здорово! Вы большие молодцы! И что?»
Проблема: метрика без контекста = шум.

2. Технический жаргон вместо бизнес-логики
«Надо уменьшить цикл коммита до прода!» → менеджер думает: «Они опять что-то усложняют».
Проблема: если нельзя перевести в деньги или сроки - это просто твой личный интерес.

3. Игра в «Agile-монахов»
«Мы самоорганизующаяся команда, не мешайте нам!» → через месяц: «Почему релиз опять сдвигается?»
Проблема: отсутствие прозрачности = потеря доверия.

💱 Что бизнес слышит и слушает:

1. Связь метрик с бизнес-последствиями
Плохо: «У нас много багов в беклоге».
Хорошо: «Каждый production-баг = +5 часов работы поддержки → +₽80K/месяц. Если починим CI - сократим на 70%».
Фишка: показываешь причинно-следственную связь → менеджмент видит конкретный ущерб/выгоду.

2. Говорим через тренды, а не точечными цифрами
Плохо: «В этом спринте velocity 50».
Хорошо: «Velocity падает 3 спринта подряд → если продолжится, сорвём релиз к кварталу».
Фишка: тренды предупреждают проблемы, а не констатируют.

3. Подменяем процессы через ценность
Плохо: «Надо внедрить тесты».
Хорошо: «Без автотестов каждый релиз = риск багов на $10K. Тесты окупятся за 2 месяца».
Фишка: фокус на ROI, а не на «правильных практиках».

4. Используем «язык боли»
Плохо: «Надо апгрейдить сервера».
Хорошо: «Сейчас сервера падают раз в месяц → теряем $15K/инцидент. Апгрейд снизит риски до нуля».
Фишка: у бизнеса два слова: «теряем» и «зарабатываем».

Если цель быть услышанным, надо говорить на языке:
▪️рисков («если не сделаем Х - потеряем N денег»),
▪️предсказуемости («это даст стабильные релизы раз в N недель»),
▪️денег («сэкономим ₽100кк/год»).

Формула идеального предложения:
«Если не сделаем [X], то [потеря N денег/сорвём сроки]. Решение [Y] даст [выгоду Z] через [время]».

Пример:
«Если не починим сборку - каждый релиз будет задерживаться на 3 дня → к концу года потеряем 50KК. Автоматизация окупится за месяц».

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

Попробуй прямо сейчас: возьми любимый технический показатель и 'упакуй' его в бизнес-контекст (риски/деньги/сроки). И пиши в комменты.