Проектный долг

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

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

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

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

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

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

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

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

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