Полезный и вредный технический долг ч.2

Продолжу писать заметки по актуальной теме.

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

Чтобы реализовать MVP необходим минимум технической и тестовой документации и полезных процессов. Для Proof of concept (PoC) технического долга можно набрать еще больше. Важно лишь зафиксировать что конкретно хотим проверить (наши гипотезы) и какими методами, чтобы потом не создавалось искажений при интерпретации результатов. Думаю, многие согласятся с Agile подходами. Работающий прототип и быстрая проверка результата более важна чем наличие правильной полной документации и отлаженного процесса. Работающее MVP является ценностью для пользователей, PoC для команды разработки или инвестора. При этом использование долга происходит наиболее эффективным образом. Об этом я уже писал недавно в посте Системный подход vs нафигачить

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

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

@aheadofthepack