Pull to refresh

Comments 4

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

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

Но не следует списывать на технический долг низкое качество разработки, проектирования, управления, корпоративной культуры, помноженное на недостаточное выделение ресурсов. К техническому долгу эти проблемы не имеют отношения и не надо решать их в области управления техническим долгом. Да, они приводят к чрезвычайно низкому качеству продукта. Но он таким и должен был в таких условиях получиться. Бороться с техническим долгом не устраняя причину низкого качества продукта не получиться.
поддерживаю, есть мнение что «фальшивый» Agile нужен в первую очередь для того чтобы перекладывать проблемы низкого качества на прошлых этапах \ итерациях на следующего по цепочке исполнителя, и это негласное правило игры
Sign up to leave a comment.