Привет! На связи Ира Белица и Святослав Сычев. Мы работаем в Mindbox над высоконагруженным продуктом рассылок: более 850 наших клиентов генерируют свыше 20 тысяч RPS. Такой продукт требует много ИТ-поддержки, при этом клиенты постоянно запрашивают новые функции. Отсюда рассинхрон в команде: разработчикам важно поддерживать стабильность рассылок, менеджерам продукта — помогать клиентам решать их проблемы, зачастую с помощью новых фичей.

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

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

Пара слов об авторах

Ира Белица — менеджер продукта в команде рассылок. Отвечает за email, SMS и Viber, а также доставляемость писем.

Святослав Сычев — engineering manager в команде рассылок, отвечает за выполнение целей команды из 27 разработчиков. Один из менторов школы лидов Mindbox, преподает в МГТУ им. Баумана на кафедре ИУ7 «Программная инженерия».

Как работают с техдолгом и фичами в Mindbox

Мы работаем по Pipedrive Agile Framework. Вся разработка разделена на команды по 15–30 человек (трайбы), отвечающие за разные продукты: рассылки, отчеты, программу лояльности. Внутри каждого трайба выделяются: 

— миссии, которые занимаются глобальными изменениями продукта, например разработкой нового отчета «Здоровье email»; 

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

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

Почему команда рассылок сфокусировалась на тойле в ущерб клиентским задачам

В команде рассылок долгое время был фокус на тойле. 

Во-первых, наш домен — один из самых старых в Mindbox и частично легаси. И самых высоконагруженных: через сервисы нашей команды каждый час уходят миллионы сообщений 24/7, год от года нагрузка растет. Мы гарантируем клиентам определенную скорость отправки сообщений: у нас есть соглашение об уровне сервиса (SLA). Чтобы соблюдать SLA на фоне роста нагрузки и с легаси доменом, нужно быстро реагировать на инциденты и часто что-то чинить. 

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

Постепенно самые острые проблемы удалось решить — количество дефектов начало снижаться. Но по инерции команда продолжала выделять максимум ресурсов на надежность: разработчики боялись повторения прежней ситуации. В результате скопилась очередь нереализованных малых задач. 

В основном это были проблемы с пользовательским опытом, иногда болезненные баги или доработки для решения ежедневных клиентских задач. Например, часть старых рассылок нельзя было клонировать: маркетологам приходилось заново создавать, скажем, письмо к 8 Марта, вместо того чтобы копировать и доработать прошлогоднее.

К чему привело откладывание клиентских задач и к какому решению пришли в команде

Улучшения откладывались — росло недовольство клиентов и напряжение внутри команды:

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

• разработчики ланчпада не видели, как их работа влияет на клиентов, — со временем это демотивирует.

Для разрешения ситуации лиды трайба — engineering manager, архитектор и менеджеры продуктов — провели серию встреч один на один. В результате все признали проблему и договорились ее решить. 

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

Как навели порядок в бэклоге с помощью фреймворка на базе RICE 

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

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

В бэклог не включены малые доработки: они с тойлом имеют слишком разную природу и автоматизировать их скоринг в одном бэклоге нам пока не удалось — это в планах. Приоритизацию малых задач отдаем на откуп менеджерам продукта — подробнее об этом расскажем ниже.  

Для каждой задачи в бэклоге тойла заполняем ряд параметров:

• Impact — влияние проблемы на нас и/или клиента (например, потеря денег);

• Frequency — частота повторения проблемы;

• Blast radius — сколько клиентов затронуто, насколько массовая проблема;

• Estimate — примерная оценка сроков.

Каждое из значений имеет коэффициент. Используя формулу, получаем приоритетность задачи: 

Параметр estimate мы добавили недавно, чтобы уточнить оценки. И без него модель работала: большинство наших задач могут быть сделаны максимум за пять дней. Но примерная оценка сроков позволяет понизить приоритет у доработок, на которые нужно несколько недель, и повысить у тех, что могут быть сделаны за один день.  

Разработали шаблон приоритизации техдолга. На базе нашей модели подготовили шаблон. 

Перед использованием подумайте, какие значения колонок и веса коэффициентов нужны в вашем случае и поправьте их на листе «Значения»: 

Веса мы определяли «на чуйке», общий принцип — чем важнее проблема, тем выше коэффициент. Например, для нас дефект в 16 раз страшнее, чем препятствие в работе. 

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

Проводим регулярные встречи. Чтобы система работала, придерживаемся ритуалов. В команде есть две еженедельные встречи по 30 минут каждая, с помощью которых формируется и чистится список задач: 

1. Пополнение очереди спринта из бэклога — для выбора приоритетных задач.

2. Ревью бэклога — чтобы вычистить лишнее и оценить, насколько текущая автоматическая приоритизация корректна. Например, можем повысить impact со «страдает клиент» до «дефекта».

Добились улучшений. Главные результаты: 

• всем понятно, какую задачу команда делает, как именно и почему;

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

Как выделили ресурс на малые задачи и приоритизируем их 

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

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

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

Менеджеры продукта отвечают за приоритизацию малых задач. При этом любая малая задача должна иметь описанную мотивацию в мире клиента, то есть любой член команды должен понимать, какую проблему клиента и/или нашего бизнеса мы решим этой задачей. Например, не просто «добавить one-click unsubscribe», а «выполнить новое требование Gmail по наличию one-click unsubscribe (отписки в один клик) в рассылках». 

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

Резюме: как организовать работу команды, чтобы работать с техдолгом и пилить фичи

1. Оценивайте все задачи с точки зрения пользы для бизнеса.

2. Настройте автоматическую приоритизацию бэклога, например на базе нашей модели. 

3. Держите бэклог актуальным, пополняя его и время от времени проверяя актуальность модели для автоматического скоринга. Мы, например, для этого проводим две еженедельные встречи по 30 минут: одну для пополнения очереди спринта, вторую — для перепроверки автоматической приоритизации.

4. Выделяйте ресурс — отдельно для каждого направления работы. В нашем случае разделяем тойл и малые задачи.