Рассмотрим влияние долгов на развитие проекта в динамике. И наибольший интерес представляет сравнение двух разных подходов[98]: разработка проекта с хорошим внутренним дизайном кода, с тестами и без этого (рис. 60).

Рис. 60. Момент платы за технические долги

На рисунке показана скорость, с которой команды наращивают функциональность в проекте. Команда синих забыла о дизайне кода и о тестах. Она решила в кратчайший срок добиться впечатляющих результатов.

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

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

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

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

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