Чистка дизайн-долга
У себя в Trucker под дизайн-долгом мы понимаем совокупность решений, которые мы сознательно приняли в ущерб качеству, чтобы ускорить функциональное развитие. Например, к таким решениям мы относим какие-либо визуальные несоответствия, компромиссы в пользовательском опыте, технический долг в фигме, пропущенные ревью или когда мы осознанно игнорируем мелкие недоработки, ожидая накопительного эффекта (в разумных пределах).
Хотя долг и воспринимается как некий показатель роста, игнорировать его обслуживание не стоит, потому что неучтённый долг создаёт некотролируемую нагрузку на команду и вместо «чистки» хвостов приходится всё время искать обходные пути или использовать устаревшие решения.
Юрий Ветров в своей книге о дизайн-менеджменте как раз отмечает: без систематической фиксации долг становится частью культуры, и команда перестаёт замечать, как он управляет продуктом вместо стратегии. Поэтому ключевой шаг – вывести долг из головы и разговоров в явный бэклог.
Что мы и сделали.
Хотя долг и воспринимается как некий показатель роста, игнорировать его обслуживание не стоит, потому что неучтённый долг создаёт некотролируемую нагрузку на команду и вместо «чистки» хвостов приходится всё время искать обходные пути или использовать устаревшие решения.
Юрий Ветров в своей книге о дизайн-менеджменте как раз отмечает: без систематической фиксации долг становится частью культуры, и команда перестаёт замечать, как он управляет продуктом вместо стратегии. Поэтому ключевой шаг – вывести долг из головы и разговоров в явный бэклог.
Что мы и сделали.
Как фиксируем
Основных источников для фиксации у нас три:
- Экспертная оценка долга от дизайнера
- Замечания при тестировании и разработке
- Обратная связь от пользователей (прямая или через саппорт)
Путь от фиксации до конкретных карточек
Каждый дизайнер проводит аудит своей работы и уже на этом этапе может формировать список проблем, которые по его представлению могут ломать целостность продукта. Смотрит и на несоответствия пользовательского опыта, и на визуальные расхождения, и на операционку (используется устаревший компонент, запрос «прыгнул» по процессу и прочее).
QA и разработка приносят нам то, что могли отложить для доработки после релиза MVP какого-то функционала. Да, к сожалению, в некоторых случаях первоначальная версия не пересматривается должным образом и долгое время остается в незавершенном состоянии (но мы обязательно до неё добираемся, ага).
Для саппорта и пользователей у нас заведена отдельная табличка, в которую мы раз в неделю смотрим на синках по обратной связи и можем достать оттуда материал для погашения, который прошёл мимо других источников.
QA и разработка приносят нам то, что могли отложить для доработки после релиза MVP какого-то функционала. Да, к сожалению, в некоторых случаях первоначальная версия не пересматривается должным образом и долгое время остается в незавершенном состоянии (но мы обязательно до неё добираемся, ага).
Для саппорта и пользователей у нас заведена отдельная табличка, в которую мы раз в неделю смотрим на синках по обратной связи и можем достать оттуда материал для погашения, который прошёл мимо других источников.
Как гасим
Дизайн-долг в Trucker – часть стратегии. Все задачи по нему видны в таск-трекере и входят в обсуждения при планировании, поэтому все готовы к тому, что команда «не делает новые фичи».
Если список проблем у нас фиксируется реактивно, то бэклог по долгу формируется раз в 2 недели на встречах по приоритезации. Приоритезация долга встроена в планирование, где дизайн и разработка совместно принимают решение о том, что делать в первую очередь и как это влияет на текущие фичи.
Если список проблем у нас фиксируется реактивно, то бэклог по долгу формируется раз в 2 недели на встречах по приоритезации. Приоритезация долга встроена в планирование, где дизайн и разработка совместно принимают решение о том, что делать в первую очередь и как это влияет на текущие фичи.
Упрощенная визуализация фиксации долга
По итогам встречи на выходе получается конкретный список долгов, приоритеты которых определяется сочетанием двух факторов:
1 Влияние на продукт
После приоритезации проблемы попадают на отдельную доску.
1 Влияние на продукт
- Проблема влияет на критический путь.
- Проблема встречается часто.
- Проблема мешает аналитике или автоматизации.
- Мелкий косяк или системная переделка компонента.
- Возможность закрыть быстро или требуется координация нескольких команд
После приоритезации проблемы попадают на отдельную доску.
Матрица приоритезации
Те проблемы, которые команда дизайна и фронта могут решить своими силами (высокая ценность, низкая сложность), исправляются в рамках процесса по чистке долга, а крупные системные исправления (высокая ценность, высокая сложность) встраиваются в общий производственный процесс, но всё так же находятся в зоне видимости на доске со списком долгов.
Чтобы дизайн-долг не разрастался, технически поддерживаем это через систему компонентов и автоматизацию: стандартные компоненты и токены уменьшают рассинхронизации, а на кросс-функциональных ревью дизайн, PM, Dev и QA согласуют решения до реализации, чтобы не создавать новых долгов.
Пока работаем так.
Чтобы дизайн-долг не разрастался, технически поддерживаем это через систему компонентов и автоматизацию: стандартные компоненты и токены уменьшают рассинхронизации, а на кросс-функциональных ревью дизайн, PM, Dev и QA согласуют решения до реализации, чтобы не создавать новых долгов.
Пока работаем так.
