Чистка дизайн-долга

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

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

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

Что мы и сделали.

Как фиксируем

Основных источников для фиксации у нас три:

1. Экспертная оценка долга от дизайнера
2. Замечания при тестировании и разработке
3. Обратная связь от пользователей (прямая или через саппорт)

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

QA и разработка приносят нам то, что могли отложить для доработки после релиза MVP какого-то функционала. Да, к сожалению, в некоторых случаях первоначальная версия не пересматривается должным образом и долгое время остается в незавершенном состоянии (но мы обязательно до неё добираемся, ага).

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

Как гасим

Дизайн-долг в Trucker – часть стратегии. Все задачи по нему видны в таск-трекере и входят в обсуждения при планировании, поэтому все готовы к тому, что команда «не делает новые фичи».

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

По итогам встречи на выходе получается конкретный список долгов, приоритеты которых определяется сочетанием двух факторов:

1 Влияние на продукт

• Проблема влияет на критический путь.
• Проблема встречается часто.
• Проблема мешает аналитике или автоматизации.

2 Сложность исправления

• Мелкий косяк или системная переделка компонента.
• Возможность закрыть быстро или требуется координация нескольких команд

После приоритезации проблемы попадают на отдельную доску.

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

Чтобы дизайн-долг не разрастался, технически поддерживаем это через систему компонентов и автоматизацию: стандартные компоненты и токены уменьшают рассинхронизации, а на кросс-функциональных ревью дизайн, PM, Dev и QA согласуют решения до реализации, чтобы не создавать новых долгов.

Пока работаем так.