Продукту Mindbox больше 15 лет, он всё это время активно развивается и сейчас обрабатывает миллионы бизнес-транзакций в минуту. В 2022-м году, в одной из команд у нас было 70+ нарушений SLA в месяц, legacy код на Windows-серверах, а ещё к нам регулярно приходили продакты и спрашивали: «Ребята, когда мы начнём делать новые фичи?»

Сейчас 2025-й. Мы снизили количество нарушений SLA почти в семь раз — с 70 до 11, сделали их менее болезненными и масштабными, переехали в Kubernetes и обеспечили большую надёжность продукту. Но главное — теперь продакты не спрашивают, когда будут фичи. Они нанимают новых продактов, чтобы успевать подносить нам задачи.

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

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

• как радикальные решения могут улучшить ситуацию с техдолгом;

• почему термин «техническая задача» только мешает;

• как продавать бизнесу задачи, которые кажутся «чисто техническими»;

• почему выделять определённую часть  времени на техдолг — недостаточно;

• как ускорить отдачу техдолга за счёт усиления фокуса;

• как лиду перейти от ручного контроля к автономной работе команды.

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

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

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

2. Если с техдолгом ничего не делать, всё рано или поздно взорвётся: система перестанет работать, отказы будут случаться чаще, разработка –– всё больше и больше буксовать.

Техдолг появляется в процессе разработки нового функционала. Олег Федоткин в одном из своих докладов классно это показал: все причины появления техдолга так или иначе нанизаны на ось поставки ценности (пользы, прибыли, или иной ценности, если вы работаете не ради прибыли).

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

Радикализм в решениях

Mindbox занимается автоматизацией маркетинга и коммуникаций. У нас больше тысячи клиентов — бизнесов, для которых критично, чтобы их сообщения клиентам уходили вовремя. Мы даём публичное SLA на массовые отправки сообщений. Во время рекламной акции, миллионы писем должны улететь за часы.

SLA у нас жёсткое, дефекты (его нарушения) случались несколько раз в день, в том числе ночью. Автоматизация будит разработчиков звонками: «Пора чинить дефект!». Это, очевидно, сильно демотивирует.

Первые 25% дефектов удалось срезать за несколько месяцев: мы разгребали узкие места, чинили, улучшали. Это дало небольшое улучшение, но нужно было еще. С этим помогли более радикальные решения. 

В какой-то момент архитектор провёл анализ дефектов за большой период времени  и заметил: 20% — это ситуации, когда 99% писем ушло вовремя, а оставшийся 1% из крупной миллионной рассылки задержался из‑за различных пограничных случаев вроде разницы часовых поясов. Письма всё равно доходили, просто чуть позже.

Мы посмотрели на это и задумались, зачем вообще даём конкретно этот SLA? Чтобы клиенты массово получили вовремя коммуникацию. Пришли к продакту и спросили: «Если 99% писем ушло вовремя, а 1% задержался (но дошли позже), это ок для массовой рассылки?» Клиенты и продакт подтвердили — да, это нормально. Мы предложили исключить такие рассылки из SLA и вообще ничего больше с ними не делать.

В итоге за счёт такой корректировки требований мы убрали 20% проблем за 30 минут: достаточно было поправить формулы в автоматизации дефектов. Для сравнения: месяцы работы дали минус 25%, а одно радикальное решение — минус 20% за пару дней.

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

Как понять, что есть шанс на радикальный шаг

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

• Посмотреть сверху

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

• Определить проблему и разобраться с её причинами

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

• Попробовать изменить условия

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

Пара методов, которые также могут вам помочь: «пять почему» и «мозговой штурм».

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

Почему стоит забыть про «технические» задачи

Термины и то, как мы говорим, формируют мышление. Когда мы называем одну задачу «технической», а другую — «бизнесовой», то почти всегда интуитивно противопоставляем их.

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

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

Но вообще-то, нас наняли и платят за то, чтобы мы приносили пользу компании, а не просто писали код. А значит:

«Если задача не приносит пользы, её делать не нужно».

Скорее всего, сейчас кто-то думает: этот парень как продакт — хочет забрать весь ресурс на бизнесовые задачи, а техдолг кто выпиливать будет?

Выпиливать нужно, но не весь техдолг одинаково полезен:

• Во первых –– выше говорили что весь техдолг вы не уберёте никогда. Он появляется постоянно, это часть развития продукта.

• Если вдруг вы выпилили всё, значит, бизнес, скорее всего, потерял прибыль: вы тратили время не на новые фичи, а на переписывание чего-то, чем пользуется 1% клиентов раз в году.

Поэтому важно уметь приоритизировать:

• Чтобы фокусироваться на максимуме пользы для команды и бизнеса, нужно выпиливать не любой долг, а наиболее значимый  — тот, который мешает работать больше всего, замедляет time-to-market и реально бьёт по продукту и результатам компании/команды. 

• Чтобы не утонуть в задачах. В Jira может висеть пара сотен  тикетов с лейблом «техдолг» — попробуйте выбрать из них самый важный. Без приоритизации на этот выбор будет тратиться слишком много времени.

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

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

Как понять, что задача полезна

На мой взгляд, главный инструмент — мотивация. По каждой задаче нужно уметь ответить на вопросы: «Чтобы что?» и «Что будет, если этого не сделать?»

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

Зачем отвечать на «Чтобы что?» в каждой задаче:

• Валидировать, что делаем не ерунду

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

• Продавать без костылей вида «мы договорились, что 20% — на техдолг»

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

• Укреплять доверие между разработкой и бизнесом

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

Есть ещё два классных побочных эффекта:

1. Улучшится качество продуктовых решений

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

2. Долгосрочно вырастет мотивация команды

Работать интереснее, когда понимаешь, какую пользу приносишь и можешь влиять на то, что делает команда. Сначала вопросы «Чтобы что?», как и любые другие новшества, будут раздражать, но со временем станет лучше.

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

Как описать мотивацию задачи

Один из способов описывать мотивацию — использовать паттерн из Sociocracy 3.0. Покажу на примере задачи из трекера той самой команды, которая когда-то разгребала 70 дефектов по SLA.

1. Описываете ситуацию — констатируете факты на текущий момент. 

В нашем случае настройки бета-кластера неконсистентны другим кластерам.

2. Описываете эффект — как это влияет на нас.

При добавлении новой нагрузки в бета-кластер нам приходится обращаться к SRE и синхронно блокироваться на пару дней.

3. Указываете Relevance — почему нам не всё равно.

Поставка новых фичей замедлится на 1-2 дня. Здесь неплохо бы добавить, насколько часто это будет происходить: если это случается раз в год, может, и не стоит решать эту задачу.

Если в каждой задаче прописана мотивация, вам будет сложнее сделать не тот техдолг или бесполезную работу. Но если вы начнёте вообще везде, по каждому маленькому поводу спрашивать разработчика «А для чего ты собрался здесь переименовать метод?» или «А зачем  ты собрался что-нибудь сделать?», никто счастлив не будет. Поэтому, если вопрос касается мелких задач на 15–30 минут, то пусть люди просто делают.

ОК, мы отменили деление задач на «технические» и «бизнесовые». Теперь любая задача описывается одинаково, через мотивацию: ситуация, эффект и почему это важно.

Как продавать бизнесу «технические» доработки

Начнём снова с кейса: как мы продали рефакторинг на ~20 человеко-месяцев.

В начале статьи я рассказывал про легаси код на Win-серверах. Конечно мы хотели переписать старый сервис и переехать в кубер. Разработчик бы описал проблему так:

• Страшный код: методы по 400+ строк, большая связность в коде, читать и изменять его очень сложно, из-за этого у нас низкая скорость разработки.

• Сложная выкладка в продакшн, нужно вуду-магию применять, чтобы выложить без дефекта.

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

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

Вот с чем нам придётся столкнуться в сервисе, через который проходят ключевые клиентские механики — 98% пользователей используют его ежедневно:

• Проблемы с доставкой писем чинить полгода, а не два месяца.

• Любая малая доработка займёт две недели вместо пары дней.

• Раз в год будем вынуждены тратить не менее месяца на масштабирование.

• Починка отказа не 20 минут (как во всей компании), а три часа из-за уникального и устаревшего стека. С течением времени сроки будут только расти из-за того, что SRE-инженеры, которые знают как поднять Windows сервер, это исчезающий вид в компании. 

• В течение года есть 70% шанс потерять и не отправить все сообщения за день из-за legacy.

Эти оценки могут быть экспертными и не обязательно точными — бизнесу важна понятная картина рисков.

Таким образом мы успешно продали крупный эпик и решили задачи. Из этого кейса можно вынести, что результативнее действовать через описание проблемы, которую мы хотим решить, опираясь на цифры и метрики, понятные бизнесу. На решение важных проблем ресурсы найдутся. А на аргумент «тут не соответствует SOLID» — нет.

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

Чем ещё можно мотивировать изменения

До этого я в основном говорил про TTM и отказы.  Но есть ещё один важный фактор — состояние команды.

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

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

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

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

• Иногда бизнес может устраивать, что инженеры увольняются

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

• Бизнес может устраивать, что всё падает раз в неделю

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

Пример:

В Mindbox 4-5 лет назад была ещё одна история про глобальный рефакторинг стека с NET framework на NET Core на десятки человеко-месяцев. Долгое время писали код на старом .NET Framework и хостили его на виндовых виртуалках. Однако в какой-то момент стало очевидно: сильным инженерам с таким стеком у нас неинтересно. Стало практически невозможно нанять сильного SRE, да и разработчика тоже –– кандидаты не видели перспективы роста навыков, актуальных на рынке. Более того, некоторые из текущих инженеров компании начали уходить.

Без сильных инженеров разрабатывать и поддерживать продукт  невозможно. Так было продано крупное обновление стека на уровне CPO и топ-менеджмента именно через эту мотивацию. Вся разработка  несколько месяцев переписывала систему.

Как ещё быстрее отдавать техдолг

Сначала о том, почему, на мой взгляд, вредно выделять процент ресурса под техдолг.

Да, договорённость «30% времени — на техдолг» помогает. Вы точно будете что-то делать с техдолгом. Однако:

• это не гарантирует, что вы делаете самое нужное;

• приоритизация упрощается, но её качество падает.

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

Это работает в обе стороны. Может быть и так, что вы договорились на 30% техдолга, а на самом деле туда нужно отдать 70% или все 100%.

Элияху Голдратт сказал:

«Чтобы повысить эффективность системы, нужно оптимизировать её целиком, а не отдельные части».

Когда мы разделили бэклоги на несколько, то стали оптимизировать каждый по отдельности.

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

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

Крупные эпики (на человеко-месяц и более) однозначно стоит ставить в один ряд с новыми изменениями в продукте.

Так как же ещё быстрее отдавать техдолг?

Чтобы ответить на этот вопрос надо на самом деле разобраться, как быстрее работать. Ответ банальный:

1. Выберите самое важное.

2. Сфокусируйтесь на этом.

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

Как выбрать важное

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

• статистика поддержки,

• количество багов,

• данные по задачам и их срокам,

• затраченное время на устранение проблем.

Цифры дают объективную картину и помогают понять, где техдолг действительно мешает.

Пример 1. Статистика поддержки

Мы регулярно анализируем  алерты, которые падали в команде за определённый период. Их количество и частотность позволяет нам определить, на что обратить внимание в первую очередь и насколько велика проблема. Например, на рисунке выше –– сначала нужно браться за ApdexLow и EmailProcessingDoesNotWork.

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

Пример 2. Статистика по задачам

У нас есть большой сервис CDP — бывший монолит. Посмотрев на статистику задач команды, мы смогли сделать интересные выводы. 

«На основании статистики за полгода: 33% всех задач мы делаем в CDP — это много. Но есть проблема. В обычных сервисах больше трети задач закрывается за день, ещё треть — за два, и только оставшаяся треть делается около пяти дней. В CDP всё наоборот: две трети задач тянутся по пять дней, почти ни одна не закрывается быстро. Более того, мы постоянно ошибаемся в оценках в CDP— почти все задачи потом оказываются просроченными, потому что никто толком не понимает, сколько времени они займут».

Отличная мотивация, чтобы пристальнее посмотреть на код в CDP и понять, а нет ли там какого-то огромного, закопанного техдолга. В итоге мы продали бизнесу отрыв одного из компонентов CDP в микросервис — тоже на много человеко-месяцев. И сделали это не через «30% техдолга», а как отдельный эпик в роадмапе команды 

Пример 3. Скоринг

Ещё один способ выбрать важное — использовать скоринг. Опять же, это просто пример, не стоит использовать его as is.

Суть простая:

• определяете частоту нарушений,

• оцениваете количество затронутых пользователей,

• считаете по этим параметрам.

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

Be pragmatic, not dogmatic

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

Если чуйка говорит: «Не верь», — копайте глубже. У вас может быть нормальное объяснение, почему пятая по скорингу задача должна быть сделана первой. В этом случае — наплюйте на алгоритм и сделайте так, как думаете.

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

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

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

Сфокусированная работа важнее её количества

Все знают, что контекст-свитчинг — зло. Переключение между процессами и задачами тратит время и снижает эффективность. Поэтому вводят WIP-лимиты: одна задача в работе — и пока она не закончена, новую не начинаем.

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

Когда разработчик сделал задачу в одном домене, в WIP-лимитах и ни на что не отвлекаясь, а следующая — уже из другой области, и он теряет контекст: старое выгружается из головы, новое загружается. Это тоже тормозит работу.

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

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

Как делаем в Mindbox

У нас есть несколько уровней фокуса:

• Малые задачи
  Здесь действует правило: один момент времени — одна задача. Не начинаешь новую, пока не закончишь предыдущую.

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

• Стратегический фокус
  Если есть возможность, мы задаём команде стратегическое направление на 3-6 месяцев и инвестируем в самый проблемный домен (или парочку, которые выбрали). В остальных областях — только фикс критических багов. Это также позволяет ускориться.

Как не контролировать всё вручную

Как сделать так, чтобы не приходилось превращаться в чайка-менеджера, который только и делает, что летает по команде с вопросом: «А чтобы что?»

• Личный пример

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

• Продажа команде изменений — как техдолг продакту

Изменения в команде продаются так же, как техдолг продаётся бизнесу — через мотивацию. Используйте формат: «проблема» → «решение». Например, вы хотите, чтобы команда начала писать мотивацию к задачам. Не приходите с «новой классной фишкой с конференции». Вместо этого объясните: «Ребята, есть проблема — мы часто делаем задачи, смысл которых не до конца понятен. Хочу это исправить. Как думаете, работает ли идея описать мотивацию? Давайте попробуем». Так изменения заходят гораздо лучше.

Второй совет в этом пункте — повторяйтесь. Не все воспримут новое с первого раза — это нормально. Придётся повторять, возможно, под разными углами. Каждый понимает со своей стороны.

Как сделать так, чтобы команда работала это автономно

Главное — прививать майндсет, идеи. Какие идеи должны стать нормой в команде:

• Не бывает «технических» задач. Любая задача должна приносить пользу компании. Если пользы нет — её не стоит делать.

• В каждой задаче есть мотивация. Нужно понимать, зачем вы это делаете и что будет, если не сделать.

• Не понимаешь пользу — задавай вопрос «чтобы что?» и добивайся ясности.

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

Что получилось у нас

В Mindbox этот подход дал заметные результаты.

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

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

У нас в компании есть регулярный опрос сотрудников, позволяющий, в том числе оценить, как они ощущают нагрузку и полезность своей работы. Как видно из графиков, ощущение адекватности нагрузки и полезности выросло за год на 20 пунктов из 100. Как видите, команда действительно почувствовала, что делает более полезную работу, при этом большая её часть оценивает объём задач как адекватный.

Итоги

1. Всегда помните — инженеру платят за бизнес-пользу и решение проблем, а не за то что он пишет код.

2. Часто решение вне кода приносит кратно больше эффекта. Ищите такие варианты первыми.

3. Забудьте деление задач на «технические» и «бизнесовые». Важен только один критерий — польза для компании и команды.

4. Оценивайте и продавайте техдолг через то, какие проблемы он решает для компании и команды. Говорите на языке понятном тому, кому продаёте. 

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

6. Продавайте эти идеи команде — и вам не придётся микроменеджерить.

Скрытый текст

Ещё больше полезной информации вы можете узнать на конференции TeamLead++ 2025, которая пройдёт в ноябре в Москве! Принять участие можно и в оффлайн, и в онлайн-формате. Программа конференции построена так, что каждый участник сможет найти лекарство от своей боли — и тимлид небольшого стартапа, и опытный CTO крупной компании. Такая концентрация тимлидского опыта на человеко-час и квадратный метр бывает в Москве только один раз в год. Не пропустите!